The Allegro Wiki is migrating to github at

Allegro Hack Day/2007 December 1

From Allegro Wiki
< Allegro Hack Day
Revision as of 18:04, December 5, 2007 by Trent Gamblin (talk | contribs) (New page: = Topics = * 4.9.2 release * what is missing for 4.4.0 release * put PNG, TTF and OGG support into 4.3.10 plus? * planning for multi-monitor support * OS X 10.5 build issues. = 4.9.2 rele...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


  • 4.9.2 release
  • what is missing for 4.4.0 release
  • put PNG, TTF and OGG support into 4.3.10 plus?
  • planning for multi-monitor support
  • OS X 10.5 build issues.

4.9.2 release todo

  • merge 4.2 to 4.9 [pw] --- done
  • some kind of readme [elias]
  • write change log [elias]
  • maybe improve some documentation
  • prerelease around Dec 8 or Dec 15


  • update the msvc project files for the windows asm issue [matthew]
  • OSX build system updates for 10.4, 10.5 [matthew]
  • bcc32 patch: "[AD] fix for bcc32" July 27
  • unicode/SYSTEM_NONE problem: see "[AD] filename encoding again" by Elias on aug 5
  • check dmc.txt will be in
  • release 4.2.3 asap


  • apparently, interest and developer capacity is too low to pursue a speedy 4.4.0 release
  • this means, 4.2.x and the separate AllegroGL can get more focus (and main effort is A5 work of course)


<trentg> hi
<zap0> did i make it in time ?
* Timorg waves
<Timorg> what is the etiquite for this thing?
<Timorg> shut up and be quiet if you cant contribute?
<zap0> i've just come from a festival; 40°C day.. i got burnt.. (neck/face very red).
<trentg> Timorg: no, we appreciate comments
<trentg> zap0: haven't started yet
<zap0> Timorg, im sure anything (politely) is OK.
<Timorg> :)
<Timorg> sorry for interupting, continue
<zap0> im so dehydrated...  yet have a cold also..   body dry, nose sloppy, face red, brain throbbing (from 8 hrs of loud music)..   i hope i can still be conscience in 30 mins...
* Harteex (n=harteex@reactos/translator/Harteex) has joined #allegro-dev
* ChanServ gives voice to Harteex
* elias (n=allefant@allegro/developer/allefant) has joined #allegro-dev
* ChanServ gives voice to elias
<elias> hm, did it start now or an hour ago?
<elias> or in an hour?
<zap0> shortly... apparently.
* leverton ( has joined #allegro-dev
* ChanServ gives voice to leverton
<elias> i guess everyone in US/Canada is still sleeping
<elias> except leverton :)
<leverton> it's cold and I should be
* tjaden ( has joined #allegro-dev
* ChanServ gives voice to tjaden
<tjaden> hello
<leverton> hi
<tjaden> is everyone just waking up?
<trentg> been up an hour
<zap0> been up 19hrs... 12 of them at a music festival!
<trentg> So what's first?
<trentg> Says 4.9.2 release on the wiki
<tjaden> ok
<trentg> Anything we need to do before releasing?
<tjaden> the oct 6 log says, "pending some mouse API changes and merging of 4.2 changes"
<tjaden> i can't remember if we did either
<trentg> Did the mouse api stuff, don't know about merging
<elias> tjaden did the merging last time I think
<elias> maybe we should bundle a5teroids as demo with it?
<trentg> It's c++ though
<elias> shouldn't matter
<elias> i was just thinking, else there's not that much to see for someone trying it
<Timorg> could it be ported to C and included?
<trentg> Porting it to C would be more trouble than it's worth I think
<leverton> I wouldn't let it being in C++ stop it from being in an unstable release
<elias> yeah, it would only be a temporary demo I guess
<elias> just for this one release or so
<trentg> I can add it and add it to the cmake build
<zap0> are there any hardcore `C only`-zealots using allegro anyway? 
<tjaden> i didn't merge 4.2 to 4.9.  will try to do it tomorrow
<tjaden> yes
<elias> I'm not using any C++
<leverton> me neither
<zap0> but i mean, are you against inclusion of a C++ demo.
<leverton> no
<tjaden> fine by me
<zap0> is this being considered because there are no other alternative demos?
<elias> there's also that raindrops game, forgot the name :)
<trentg> a5teroids is the better demo though
<tjaden> any documentation still need to be done?
<elias> maybe some kind of readme
<elias> oh, btw, should we remove the old makedoc stuff?
<trentg> I think all the functions are documented, could be better though
<tjaden> i don't think we should remove makedoc stuff yet
<elias> ok
<zap0> demo:  how c++-ish is it?   does it use templates, or weird stuff like that?   ..   or would alot of passing the this* work for most of it?
<elias> it just might be confusing, but we should emphasize that it's very WIP anyway
<elias> and the API docs are only in naturaldocs
<trentg> zap0: that would just make it worse
<zap0> ok.
<zap0> i think its common to expect the docs to be incomplete for new WIP's.
<elias> yes, but e.g. readme.txt is still the 4.2 one
<zap0> it shouldn't hold up a release..  (unless the docs are incorrect)..    incomplete OK, incorrect, not OK.
<trentg> We could use a new readme, explaining that cmake or scons must be used
<tjaden> yeah, otherwise it will really hold things up
<elias> ok, so let's just replace readme.txt with a short note on how this is WIP, how to compile, and which examples are supposed to work
<trentg> Sounds good
<elias> just for the unlikely case someone un-knowing downloads it :)
<leverton> it's not that unlikely, people are used to "development" versions actually being more stable than year-old ones for most open source stuff
<elias> OSX is completely broken, right?
<elias> in 4.9, I mean
<tjaden> i'd be surprised if it wasn't
<zap0> is the OSX 'platform' stable?  the API's..  (not being in Mac-land, i've no clue), but from what i hear of some Mac programmers, new features are being added rapidly (at least to the new OS ver).
<elias> no clue as well, but my impression always was that try a lot harder than Windows/Linux to not break things
<elias> *they
<leverton> I'd put Windows over OS X as being better in that regard
<leverton> Windows 3.11 apps still run on Vista ;)
<zap0> no way!?!  really.. 
<trentg> There's a problem with win_set_window in 4.2.2, as posted on the list, but I couldn't figure out how to fix it
<elias> some problem with the way the keyboard driver works, I guess
<elias> wasn't there some other change regarding key states recently?
<trentg> Yes, but this is something different
<elias> ah, ok. wasn't really following the windows stuff
<tjaden> so 4.9.2 will work pretty well on windows?
<leverton> the asteroids demo worked great on Vista
<trentg> Well, I think I'm the only one to compile it so far, so it's yet to be seen :)
<elias> it worked mostly on my X11
<elias> probably not so well with GLX < 1.4
<leverton> can we make a 4.9.2 prerelease first ?
<tjaden> of course
<leverton> just put the final zip up somewhere to test
<tjaden> timeframe?
<trentg> I need a few days to a week to get a5teroids bundled
<trentg> (lazy)
<trentg> Maybe in a week or two?
* Archon ( has joined #allegro-dev
* ChanServ gives voice to Archon
<tjaden> i suppose i will write the change log again?
<tjaden> damn tedious
<elias> changelog from 4.9.1 to 4.9.2?
<tjaden> yes
<elias> i can try doing it
<tjaden> would be nice :)
<elias> i guess reading through the svn2cl output should give me all the info
<tjaden> all the branching and merging could make it a bit harder
<elias> yeah, was wondering about that
<tjaden> prerelease next weekend or the one after then
<elias> i can also try writing short release notes/readme.txt
<tjaden> i put you down on the wiki, hope you don't mind
* Archon ( has left #allegro-dev ("Konversation terminated!")
<elias> of course not
* mimix ( has joined #allegro-dev
* ChanServ gives voice to mimix
<tjaden> hello
<mimix> hello everyone
<zap0> woot!
<mimix> is it over?
<trentg> no
<elias> no, basically we did the "4.9.2 release todo" so far:
<trentg> What about 4.4.0 release?
<tjaden> honestly i can never remember what that's supposed to be
<trentg> me either
<trentg> Isn't it +agl
<elias> 4.2 with allegrogl (and some more addons?) bundled
<trentg> and addons
<tjaden> and no asm
<zap0> and the asm issues fixed...
<zap0> oh.. you just said that!
<elias> there also was talk about some missing draw_sprite_* thing and window resizing
<leverton> there's the unicode / SYSTEM_NONE problem
<mimix> not much has been done to 4.4, almost nothing
<tjaden> we need a champion for it
<mimix> what about 4.2.3? With the win ASM issue fixed?
<leverton> I don't care much about 4.2.3 if 4.4 can be released within 3 months time
<mimix> are the prebuilt libs on built with NO_ASM?
<leverton> yeah
<leverton> the MSVC ones
<zap0> i'd love to see a 4.2.3 with asm fixed.
<mimix> i don't thin we will have 4.4 within 3 months
<leverton> 4.2.3 (or 4.4) also needs updates for OS X 
<leverton> Apple has broken a couple of things
<mimix> honestlly, i don't think we will have it within a year
<leverton> there are problems with 10.5 and I think the latest 10.4 update
<tjaden> yeah, we need a 4.2.3
<tjaden> what kind of updates for OSX?
<leverton> well they moved some directories around
<tjaden> just the build system then?
<leverton> so make install puts some stuff in the wrong directories, I think
<leverton> yeah
<leverton> and on 10.5 , gcc-3.3 is broken 
<tjaden> any patches floating around?
<leverton> I think the 10.5 stuff can easily be fixed within the gcc-uni file
<leverton> no
* mimix is afc
<leverton> I don't have 10.5, but perhaps I can get someone from to edit the gcc-uni script
<leverton> basically it needs to detect 10.5
<leverton> and if so, default to using gcc-4 for both i386 and ppc 
<leverton> and there is an extra switch that is required to target 10.4
<leverton> the other problem with the incorrect folder is probably a makefile thing
<leverton> I might be able to look at that if it affects 10.4, but I hate Allegro's makefiles :P
<tjaden> i'm putting you down on the wiki :)
<tjaden> if those are the only issues we should get 4.2.3 out asap
<zap0> yes please!!
<tjaden> the windows asm patch was already committed anyway
<leverton> what was the fix for that?
<leverton> just new names?
<tjaden> yes
<leverton> so I'll need to update msvc project files
<tjaden> maybe "fix" is the right spelling
<leverton> so there will be 24 build directories in the obj/msvc folder? heh
<mimix> the whole no-asm thing went out wrong obviously
<leverton> well it's been wrong since Allegro's beginning
<leverton> what's the naming convention for non-asm build ?
<leverton> alleg.lib => 
<leverton> alleg_s.lib =>
<leverton> alleg_s_crt.lib =>
<mimix> the "_c" is added as the final suffix
<mimix> alleg_s_crt_c.lib
<leverton> okay
<tjaden> does anybody particularly care about 4.4.0?
<tjaden> i mean, enough to hack on the build system?
<leverton> not at the moment
<mimix> i was just about to say that i don't care *thaat* enough :)
<leverton> I think there might be a simple BCC patch that needs to be applied for 4.2.3
<zap0> developpers are not really in abundance here, so droping something like 4.4.0 would be wise.
<leverton> and maybe some variation of the temporary filename encoding / unicode thing?  see "[AD] filename encoding again" by Elias on aug 5
<tjaden> which bcc patch?
<leverton> "[ad] fix for bcc32" by me on Jul 27 
<elias> for filename encoding, should the patch there be applied?
<leverton> a patch exists, but there was some limited discussion
<leverton> I think it does what we talked about for a 4.2.3 solution
<leverton> (regarding filename encoding)
<elias> ok, i'll simply apply to the 4.2 branch then, including your windows version of _al_detect_filename_encoding
<leverton> the only other comment I had was whether ot not _al_detect_filename_encoding() was a good name 
<mimix> wasn't there some kind of input fix for windows too?
<leverton> in that, it actually sets it , not detects it 
<leverton> but maybe that's what detect implies
<leverton> as in, it's really _al_set_default_filename_encoding()
<leverton> the name is just a minor thing ... I think the functionality is correct
<mimix> "[AD] Revenge of the key_shifts troubles." ... was committed to 4.2
<leverton> there isa  new input problem reported with user created windows
<leverton> but unless someone volunteers to fix it, I don't think it has to go in 4.2.3
<elias> hm, not sure what to do with _al_win_unicode_filenames
<tjaden> the bcc32 patch still looks ugly to me, but it's only bcc32 so you can commit that if you like
<leverton> _al_win_unicode_filenames doesn't need to exist
<leverton> if I remember correctly ...
<elias>  if (!_al_win_unicode_filenames) {
<elias>       return ff_data->data.a.size;
<elias>    }
<elias>    else {
<elias>       return ff_data->data.w.size;
<elias>    }
<elias> i have no idea at all what this does..
<leverton> oh
<leverton> well
<leverton> what does get_filename_encoding()  do?
<leverton> something like this:
<leverton> if (get_filename_encoding() != UNICODE ) { return ff_data->data.a.size; } else { } ...
<leverton> if that makes sense
<leverton> it's been a whlie, but I think that's what I meant by:
<leverton> That code could be removed from wsystem.c then, since it will
<leverton> automatically be called. And _al_win_unicode_filenames could be
<leverton> removed and get_filename_encoding() could be used in its place (in
<leverton> wfile.c).
<elias> i see
<leverton> or if (get_filename_encoding() == ASCII), I don't even remember what the get_filename_encoding() does
<leverton> the point is, Windows has two sets of routines depending on whether or not unicode filenames are supported
<leverton> and it's supported on Windows 2000, XP, etc  
<leverton> except in the DMC build (taken care of in the al_detect_filename_encoding()), since it apprently doesn't  support it in its own C library
<elias> hm, gcc 4 has some warnings about differing signedness 
<elias> ok, committed
<elias> someone with windows should test if it still compiles now (i only did a quick cross-compilation with mingw gcc 4.2)
<leverton> I'll try it this weekend
<tjaden> i'm going now, you guys carry on. i suppose we should have another meeting next week or so, depending if anything gets done
* tjaden has quit ("Leaving")
<zap0> did multiscreens get discussed ?
<zap0> multi monitor support ?
<trentg> no
<zap0> :(
<zap0> which is it for?  the new API ?
<trentg> Yeah
<zap0> how far along is it?     
<trentg> Someone has to come up with an API, nothing is done yet
<leverton> can Windows even target multiple monitors in full screen?
<zap0> is it a multi-window thingy?   
<leverton> that is, if they are on the same card
<zap0> if the monitors are part of the same Windows Desktop, yes.
<trentg> I don't know
<leverton> I've seen applications that let me choose which video card to go full screen on
<leverton> but never that let me pick which monitor on said card
<zap0> i run a machine with 3 monitors, 2 gfx cards, 1 Windows Desktop.
<leverton> that is my setup as well
<zap0> and i can run allegro in a window spanning all 3 monitors.
<zap0> (not tried fullscreen).
<leverton> I'm talking full screen 
<leverton> Allegro 4.2 can only target the primary monitor
<trentg> I think we also need an API to specify which screen to start a window on
<zap0> ok, so the API is a way for you to specify which monitor(s) the fullscreen will use.
<leverton> if that's even possible
<leverton> but regarding windowed API, yeah 
<leverton> that is more useful
<zap0> modern directX accelerates for all screens, but i think older DX didn't accelerate the non-primary monitor for fullscreen.
<trentg> how modern?
<zap0> 9.0c with any card you can buy today will be fine.
<trentg> ok, that's what the d3d driver uses
<zap0> but it might depend on the DX interface allegro uses.
<trentg> I don't recall seeing anything to do with multi monitor in the d3d docs
<zap0> so the non-d3d driver is likely to have differing acceleration depending on monitor.
<leverton> I know you can enumerate over the video cards and video monitors
<leverton> and specify which video card to use as full screen
<zap0> most users of multi-monitor become aware of this fairly quickly anyway, and will choice there fastest monitor (so we ought to have at least an API for selecting which monitor to default to).
<trentg> Is spanning multi monitors in fullscreen really useful?
<zap0> it would be nice.
<trentg> I guess, for screensavers
<zap0> flight sims.
<trentg> How do things work with opengl and multimon?
<leverton> no idea
<zap0> with monitor/gfx cards getting cheaper, i think more people are going to get multi-setups... games will follow.
<zap0> never used openGL, i dont know.
<trentg> We need an api that will work with at least d3d and opengl
<elias> we also don't have an API so far for enumerating possible fullscreen resolutions, I think
<elias> likely they can be combined. or at least, work in the same way
<trentg> we have that one
<leverton> how do you specifiy GFX_FULLSCREEN  / etc with the new API?
<leverton> Allegro's 4.2 method is antiquated
<trentg> al_set_new_display_flags(ALLEGRO_OPENGL|ALLEGRO_FULLSCREEN);
<zap0> this week i've got to add code to my app for positioning a window as it opens, which i think is just passing x/y to CreateWindow(). 
<leverton> is full screen a suggestion or a command?
<trentg> not sure
<elias> ah, i see.. al_get_num_display_modes
<leverton> for instance, GFX_AUTODETECT_WINDOWED is a bogus mode
<leverton> because it's useless on DOS
<leverton> and every time you use it, you have to have a fallback
<leverton> but I suppose
<zap0> anyone still using DOS?
<leverton> we only support windowed environments on 5.0
<leverton> unless we support handheld devices
<zap0> do we have the dev resources to add another platform ?
<elias> i think, we should provide a way to pick a default
<leverton> I'm for picking a default between full screen and windowed, but I'm not sure that it should be enforced
<elias> and then the enumeration, where either the program can pick what it likes, or offer a user choice
<leverton> for example, I hate when people hard code a resolution that won't work on my HDTV LCD 
<elias> that's what gets enumerated in the current API
<leverton> so I hack the exe and change the driver code to windowed ;)
<elias> yeah
* zap0 fires up a project containing lots of enumeration code, to take a look at how its done.
<elias> so we can just say al_create_display always makes the best effort regarding fullscreen/windowed
<leverton> it would be sort of nice if Allegro could handle creating a screen at least as large as the requested one and center as needed
<elias> since the programmer can enumerate the modes, they know before if it works or not, if they need to
<elias> yeah
<elias> that's how it works in 4.2 under X11
<elias> i think at least
<leverton> I guess it depends on how reliable the enumerations are
<elias> true
<leverton> what I hate about Allegro 4.2 on Vista is it takes a while to set a mode
<leverton> if you ahve a non-standard screen size
<leverton> but if hte enumerations are always accurate, those could be checked instead
<elias> you can always check after the al_create_display call if it is fullscreen/windowed, and then change it if it didn't go as suspected
<leverton> yeah, I'd like to avoid that
<leverton> because that's the annoying part
<zap0> win32::EnumDisplayMonitors()
<elias> true
<leverton> for example, setting a 24-bit mode (let's say it's not supported in full screen) on vista might take literally 10 seconds to set
<leverton> becaue it tries full screen
<leverton> and who knows what the user is cycling through
<leverton> and eventually you get a window
<elias> hm
<elias> allegro could check beforehand I guess
<leverton> you can see it try around 4 full screen things, etc 
<elias> using the DX enumeration
<leverton> and due to some bug, the Windowed mode then only works 50% of the time
<leverton> something weird happens when cycling through modes or changing them on Windows with Allegro 4.2
<elias> but it works in 4.9?
<leverton> I don't know for sure, I haven't really used 4.9
<leverton> but the asteroids demo seemed to be set a lot more cleanly