The Allegro Wiki is migrating to github at

Allegro Hack Day/2007 October 6

From Allegro Wiki
Jump to: navigation, search


  • release of 4.9 scheduled for early December, pending some mouse API changes and merging of 4.2 changes
  • probably will migrate AGL repo into Allegro repo, maintaining history
<trentg> Has HackDay been forgotten D:
<mimix> i'm here to talk
<trentg> Well there's one thing I wanted to talk about.
<trentg> The mouse code still depends on gfx_driver vtables, and we decided it should go into the display driver.
<mimix> i'm not much into that
<trentg> How about agl going into 4.4?
<mimix> that's the plan, but no one is interested into doing it
<mimix> 4.3.10 is opened on svn and waiting
<trentg> There's something about a bounty for it on the HackDay page..
* Tigge ( has joined #allegro-dev
* ChanServ gives voice to Tigge
<mimix> yeah, elias proposed that
<mimix> i think that anyone who would do it for 25$ would do it for free anyway
* tjaden ( has joined #allegro-dev
* ChanServ gives voice to tjaden
<trentg> Yeah, it's not much... even the whole $50 isn't much
<tjaden> hello
<trentg> hi
<mimix> it's a good chance to get rid of autotools
<mimix> integrating build proces is a major problem
<trentg> Yeah. I'm pretty happy with cmake in 4.9.
<trentg> Still, I think if we could get someone to do it it would be worth it... the money is just going to sit there otherwise.
<mimix> yeah, we can try that
<tjaden> is this about merging agl into 4.3.10?
<mimix> yes
<mimix> it's not merging really, just the build process should get merged
<tjaden> ok
<mimix> it should be a satisfaction for some scons or cmake fanatic
<mimix> just imagine deleting all those autotools files
<tjaden> i don't think evert would be too happy with that
<mimix> hm, i know
<tjaden> on the other hand, maintaining autotools and makefiles for different windows compilers is probably too tough when we want agl merged
<mimix> agl and allegro have very similar build system now
<mimix> both have fix.bat, configure, msvc project files...
<tjaden> ok, so how would it work?
<tjaden> as in, what steps would the end-user take?
<mimix> fix.bat mingw, make WITH_ALLEGRO_GL=1 WITH_LIB_PNG=1;
<tjaden> well, that's easy
<mimix> allegro's makefile.lst would just include allegrogl's makefile.lst
<tjaden> would fix.bat call fix.bat for addons? or does make do that?
<mimix> fix.bat can call that
<tjaden> we wouldn't even need allegro's makefile to include allegrogl's makefile. just call recursive make
<mimix> nice
<mimix> on unix there souhld be --with-allegro-gl for configure script
<tjaden> and autodetected
<mimix> right
<tjaden> is that all there is?
<trentg> About the mouse cursor thing again...
<trentg> Should we copy the gfx_driver vtable to the display driver, since both will need it if we keep backwards compatibility.
<mimix> tjaden: i think so
<tjaden> mimix, could you copy agl into the addons directory, or however you like. i can work on the build system every now and then since it seems pretty easy
<tjaden> trentg, need more context :)
<trentg> The mouse cursor stuff uses the gfx_driver vtable, since the new api doesn't use gfx_driver, we decided to put those vtable entries in the display vtable. I'm guessing it has to be a copy though, ie. in both places.
<tjaden> why does backwards compatibility require the gfx_driver?
<trentg> Well, the old api can't be implemented with the new api, there's just too many little things that can't be done with modern graphics APIs.
<tjaden> oh, ok
<tjaden> are the little things important things?
<trentg> yeah, like masking and blending
<tjaden> for mouse cursors?
<trentg> no. /me rereads the question
<trentg> ah, well the current mouse cursor code makes calls to the gfx_driver vtable where the platform specific mouse cursor stuff lies.
<trentg> But to maintian backwards compatibility, we can't put it only in the display vtable because it's specific to the new api
<CIA-32> alleg: mmimica * r8205 /allegro/branches/4.3.10plus/addons/: Created a directory to contain addons.
<mimix> is it possible co copy something across different repositories?
<trentg> *because "displays" are specific to the new api
<tjaden> mimix, i don't think so
<trentg> and by it I mean the mouse cursor calls
<tjaden> mimix, maybe there's something we can do
<tjaden> what if we replay the agl history into the allegro repository, then copy within the allegro repo. then the agl history will be available
<mimix> you can replay history?
* tjaden has quit (Read error: 104 (Connection reset by peer))
* tjaden ( has joined #allegro-dev
* ChanServ gives voice to tjaden
<tjaden> what'd i miss?
<trentg> <mimix> you can replay history?
<tjaden> not sure
<mimix> nothing
<tjaden> oh well
* Tigge has quit ()
<tjaden> do you think it will be worthwhile?
<tjaden> ..
<tjaden> trentg, how's the new gfx branch coming along?
<trentg> Pretty good, it just made a small game with it and other's have said it works for them too.
<tjaden> cool
<tjaden> can we think about a release?
* Tigge ( has joined #allegro-dev
* ChanServ gives voice to Tigge
* kazzmi1 ( has joined #allegro-dev
* ChanServ gives voice to kazzmi1
<trentg> Yeah, we were thinking of merging back into 4.9... but the mouse thing is still a problem I think.
<tjaden> do whatever you have to :)
<mimix> tjaden: i'll have to read all that first in order not to damage something
<tjaden> i have repo backups :)
<trentg> ok. so how about a release when we get that worked out?
<tjaden> ok. what kind of timeframe?
<trentg> I guess it depends if elias has anything he needs to do too..
<tjaden> and i still need to merge 4.2 changes into the 4.9 trunk
<tjaden> maybe early december?
<trentg> ok
<tjaden> great
<tjaden> i added it to the wiki
<trentg> One thing we'll be missing is a new sound api though :/
<tjaden> that can come later
<trentg> yeah
<tjaden> and the redesigned api is fun to think about but who will use the new allegro? i don't know
<trentg> yeah, who knows
<trentg> it has disadvantages and advantages...
<kazzmi1> well it will have allegrogl built in
<trentg> I guess we should do some naturaldocs for the new graphics stuff too...
<tjaden> yes
<tjaden> should be able to copy it from the wiki
<trentg> Yeah
<tjaden> should i post a message about migrating agl repo to allegro repo?
<mimix> i really can't succeed with this svnadmin dump thing
<tjaden> i will ask on AD
<mimix> the manual says, e.g "svnlook youngest myrepos"
<mimix> svnadmin dump allegrogl gives me svnadmin: Can't open file 'allegrogl/format': No such file or director
<mimix> err "svnlook youngest allegrogl", says the same
<tjaden> it says "1267" for me
<tjaden> and svnadmin dump allegrogl worked
<tjaden> where allegrogl is a copy of the repository
<mimix> a copy made with "svn co"
<tjaden> no, the actual repository. i rsynced it
<mimix> i have only checkouts here
<tjaden> i'm trying svnadmin load now
<tjaden> strange, the commits don't show up if i try to reroot them under /allegrogl/
<tjaden> anyway
<tjaden> i'm sure it's possible
<tjaden> hey, it works
<tjaden> history going back to year 2000
<tjaden> nothing else?
<mimix> there is this bug between C-only allegro on windows and allegrogl
<mimix> ALLEGRO_NO_ASM has to be defined when compiling an AGL program
<mimix> apparently that't not needed for allegro programs
<tjaden> does it matter how allegro or agl were compiled?
<mimix> the problem is that the end-programmer can't know which version of allegro is using because they are all called just alleg.lib
<mimix> it matters on how allegro is compiled
<tjaden> ok, i just read the bugs.txt
<tjaden> do we know which compilers?
<mimix> msvc
<tjaden> i hope matthew is not distributing allegro binaries built with the msvc project files...
<mimix> i don't know
<mimix> it's something that has to be fixed before 4.4
<mimix> even before the first public 4.3.10
<tjaden> i think we will drop asm in 4.4
<mimix> it would be really strange if agl would still require ALLEGOR_NO_ASM :)
<mimix> must be something in allegro headers...
<tjaden> back in 15
<tjaden> back
<mimix> are you going to copy agl to 4.3.10?
<tjaden> yes, after the repos get merged
<tjaden> i'll try to do it tomorrow
<mimix> ok
<tjaden> ok, sleep time
<tjaden> thanks to trent for keeping the new gfx branch alive :)
* tjaden has quit ("Leaving")