The Allegro Wiki is migrating to github at

Allegro Hack Day/2008 April 5

From Allegro Wiki
Jump to: navigation, search


  • (4.9) Resource management for bitmaps if their display is deleted
  • (4.9) File location API (merge from Tomasu's branch)
  • (4.9) Text routines (link)
    • Added `count` versions
  • (all) Release schedule (link)
    • 4.9.3 release Apr20
    • pw to fiddle with stuff for 4.3.11 release
    • otherwise 4.3.11 blocked only by macosx support
  • (all) Top-down MS Windows bitmap problems (link)
    • patch committed (4.3.10plus, 4.9)


<tjaden> ok, somebody pick a topic
<trentg> 4.9.3 release
<trentg> We could do it any time now I guess
<tjaden> unless there is something that really needs to get in there?
<tjaden> how is mac support now?
<trentg> It plays the demo at least, haven't tried it personally though (no mac)
<mimix> then it's much better than it was in 4.9.2 :)
<trentg> I can test D3D and opengl on windows
<trentg> On 3 different machines
<mimix> should add a note in build docs that it can be built with cmake-msvc
<tjaden> with workspaces? excellent
<trentg> Ya
<mimix> yep
<mimix> there are some things to tweak, but nothing critical
<tjaden> so update a few docs, write up the changes, few tweaks and make sure the build system actually works this time ;)
<tjaden> next weekend or the one after?
<peterhull> hello all
<peterhull> morning peter!
<tjaden> morning :)
<tjaden> saved by DST giving back an hour
<trentg> Must we write changes when we have commit logs?
<tjaden> yes
<peterhull> heh
<peterhull> About MAc support - it's OK, keyboard, mouse, audio and windowed graphics but no fullscreen yet
<-- elias has quit (Connection timed out)
<peterhull> But I don't think anyone else has tested apart from me
<mimix> has anyone tried to build with cmake-msvc? (except me)
<trentg> Not me
<-- trentg ( has left #allegro-dev ("Leaving")
<mimix> very well :-/
--> trentg ( has joined #allegro-dev
--- ChanServ gives voice to trentg
<mimix> hopefully some users will
<trentg> What would I need to install?
<peterhull> Matthew uses msvc, maybe you could ask him to test it
<peterhull> On the release, how about if we try to get all the changes in by next weekend, then spend a week just testing and getting it all packaged up
<peterhull> then announce it the weekend after
<peterhull> April 20th or so
<mimix> trentg: some version of msvc, i have 8 (2005)
<trentg> Will the express edititions work?
<mimix> i'm no sure
<mimix> does cmake have a generator for it?
<trentg>  I don
<trentg> 't know but last time I needed a bunch of stuff and it was a big mess... then I swore off msvc forever
<mimix> i can try with msvc6, but the question is do we still want to bother with it?
<mimix> IMO no
<mimix> anyways, there are some warnings to fix and other trivial things..
<tjaden> peterhull, sounds like a plan
<mimix> yeah, i think it can be done
<trentg> I guess since I don't have a task, I can work on the changelog again
<peterhull> I've got some stuff not checked in yet.
<peterhull> I said before that fullscreen isn't there yet, is that a prerequisite for the this release?
<trentg> I don
<trentg> 't think s9o
<trentg> What was the revisin at the time of 4.9.2?
<peterhull> OK. I think it will require a bit of work to sort out what happens if you create both windowed and fullscreen displays, etc etc
<tjaden> trentg, it'll be on the tag
<trentg> ok
<peterhull> trentg: 9935
<trentg> thanks
<trentg> I was just looking for that :)
<peterhull> Shall we move on to the next item?
<trentg> Yes please
<peterhull> The topdown windows bitmaps problem looks straightforward
<peterhull> David Capello submitted a patch which I think is ok
<tjaden> yes
<tjaden> forgot to apply it
<peterhull> He mentioned that site which has all different possibilities for bitmap formats, and hinted that not all of these worked with Allegro
<peterhull> I propose we don't bother since no-one has filed a bug due to these in five years or whatever
<tjaden> we should try not to crash on those though
<peterhull> sorry, I'm wrong. He did post a second patch to fix all those
<tjaden> oh ok
<mimix> will there be a 4.2.3 because of it?
<peterhull> mimix: I'd say not if that's the only thing that's changed since 4.2.2 ... just because we're busy on 4.9 ;)
<mimix> not the only change, but I think we should release 4.3.11 instead
<tjaden> what needs to be done for that?
<mimix> this
<mimix> macosx build system mostly
<tjaden> i can work on the unix stuff
<mimix> " should convert files to Unix format by default, otherwise you get weird cpp errors building from the .7z/.zip archives on Unix"
<mimix> is this really neccessary?
<tjaden> yes
<mimix> ok
<tjaden> cpp doesn't like backslash-CR-LF sequences, it looks like
<tjaden> it doesn't recognise them as line continuations
<mimix> aren't gzip archives for unix?
<tjaden> yes but the .zip and .7z archives should be usable as well
<mimix> if you really wan to use .7z/zip run ./ --dtou
<mimix> i think that's even stated in the docs somewhere, if it isn't it should be
<tjaden> that's too much trouble
<tjaden> i'm not sure it worked properly in the last release either, due to the addons (from memory)
<tjaden> btw it's almost a year since the first hack day
<mimix> ok, i don't run that much to mind
<tjaden> i might try consolidating the separate dtou/utod scripts
<tjaden> each addon has its own variation
<mimix> yes, i should have though of this
<tjaden> so we'll release 4.3.11, let users test it for a while, and then is that enough for 4.4.0?
<mimix> without macosx support in addons?
<trentg> 4.3 has png and ogg loaders?
<mimix> yes trentg :)
<mimix> your ogg loader
<trentg> Ok, I haven't followed 4.3
<trentg> ah
<tjaden> i assumed macosx support would be fixed in 4.3.11
<mimix> heh, with that fixed it's fine
<peterhull> I haven't followed 4.3 either
<mimix> it felt almost like my own private project
<trentg> Don't get me wrong, I thnk it's important
<trentg> I just felt I had too much to do already
<mimix> nah, it's fine, i just think it's funny
<mimix> i felt like i've just had a baby when was 4.3.10 released
<trentg> heh
<CIA-31> alleg: tjaden * r10113 /allegro/branches/4.3.10plus/addons/jpgalleg/src/encode.c: Silence a signedness warning.
<mimix> oh gcc 4.3.0 produces a lot of warnings on 4.3
<mimix> include/allegro/internal/aintvga.h: In function _read_vga_register:
<mimix> include/allegro/internal/aintvga.h:46: warning: inportb is static but used in inline function _read_vga_register which is not static
<mimix> and so on
<tjaden> easy to fix?
<mimix> i can't... i'm afraid not to break something
<mimix> i don't know how to fix
<tjaden> oh well
<tjaden> maybe when gcc 4.3 is more widespread
<mimix> just warnings afterall
<CIA-31> alleg: tjaden * r10114 /allegro/branches/4.3.10plus/src/bmp.c: 
<CIA-31> alleg: David Capello fixed the BMP loader to handle (valid) .bmp files with negative
<CIA-31> alleg: heights and other uncommon features.
<CIA-31> alleg: For reference, David tested against a "bmp suite" from Jason Summers.
<CIA-31> alleg:
<peterhull> I'm afraid I have to go
<peterhull> bye for now
<-- peterhull ( has left #allegro-dev
<trentg> next?
<trentg> There's some stuff on the wiki
<trentg> "Resource management for bitmaps if their display is deleted"
<trentg> Bitmaps arent tied to displays in the D3D driver
<CIA-31> alleg: tjaden * r10115 /allegro/branches/4.9/src/bmp.c: 
<CIA-31> alleg: David Capello fixed the BMP loader to handle (valid) .bmp files with negative
<CIA-31> alleg: heights and other uncommon features.
<CIA-31> alleg: For reference, David tested against a "bmp suite" from Jason Summers.
<CIA-31> alleg:
<CIA-31> alleg: [merge from 4.3.10plus]
<CIA-31> alleg: tjaden * r10116 /allegro/branches/4.9/examples/ (exnew_drawpixels.c exnew_multiwin.c): Set svn:eol-style.
<tjaden> exnew_multiwin doesn't work for me in opengl, does it work elsewhere?
<tjaden> i think peter hull said he had the same problem, the bitmap only display in one of the windows
<mimix> yep
<mimix> that's related to the "Resource management for bitmaps"
<tjaden> yep. so when can i expect that to start working? ;)
<mimix> probably not this week
<mimix> oh, that reminded me that *some* examples *often* crash on exit, in windows
<mimix> i don't have anything specific, using a invalid mutex iirc
<trentg> Which driver?
<mimix> both i think
<mimix> i'll try to come up with more info soon
<trentg> Hmm.. mine don't seem to crash
<trentg> Any ones in particular?
<mimix> i remember that multiwin always does
<-- Dawie has quit ("ChatZilla 0.9.81 [Firefox]")
<tjaden> back to the resource management for bitmaps
<trentg> Weird, it did hang the first time I ran it, then the next 10 times it exited
<trentg> Ctrl-c worked the first time
<-- elias_ has quit ("Client exiting")
<mimix> each display should keep and list of bitmaps 
<mimix> this can be used to recreated them when necessary
<trentg> Bitmaps should be independant of display
<trentg> Or is that the goal here?
<mimix> textures are dependent to context in ogl
<trentg> Can't you just use 1 context?
<mimix> each display has it's own context
<trentg> That's how I did the D3D driver initially, but then switched to only 1 context shared
<mimix> hm
<mimix> i think the API requires a context per window (display) on both windows and x11
<mimix> but it let's you share resources between them
<mimix> *lets
<trentg> I think shared is the way to go
<mimix> but it needs identical pixel format
<CIA-31> alleg: trentg * r10117 /allegro/branches/4.9/src/win/d3d_disp.c: Fixed a warning
<trentg> Oh, I see
<tjaden> you can share resources between contexts, right?
<tjaden> opengl objects, that is
<mimix> in some cases yes
<mimix> we have a display vtable entry upload_compatible_bitmap() if not, right?
<mimix> hm, no
<mimix> nvm, i got confused with upload_compat_screen()
<mimix> if the resources cannot be shared, an intermediate memory bitmap should be used
<mimix> that is not difficult to implement, it's slow but who cares
<mimix> also, the bitmap must be destroyed when the display is destroyed, we can use the list of bitmaps for that too
<goalieca> 4.9 fails to build on my ibook g4 :(
<CIA-31> alleg: trentg * r10118 /allegro/branches/4.9/examples/exnew_multiwin.c: Made escape work in exnew_multiwin
<kazzmir> goalieca, using what?
<goalieca> xcode. aintosx.h was missing a declaration for NSObject
<goalieca> and now its bitcing about NSApplication
<mimix> currently cmake can't generate debug and release projects at the same time, even though MSVC would support that
<goalieca> also got another question. What is the plan with the audio system.
<goalieca> okay. so some of the allegro osx code depends on IOHIDLibObsolete.h
<trentg> you've done some work on an addeon rightA?
<goalieca> i've made it work in an addon
<goalieca> but i've left it alone otherwiswe
<trentg> Should it be an addon on in the base?
--> tjaden_ ( has joined #allegro-dev
--- ChanServ gives voice to tjaden_
<-- tjaden has quit ("Leaving")
<goalieca> audio for now is easiest to work on as an add-in but i think it should be in the base
<tjaden_> what are you doing on the audio?
<trentg> It uses openal and what else under windows?
--- tjaden_ is now known as tjaden
<goalieca> well.. the wiki code works for openal (but not on my linux box) and alsa
<goalieca> i would assume directsound will have to be the way on windows
<trentg> I would like to try it with openal on windows
<trentg> Maybe it should be committed to svn as it is now
<tjaden> you can put it in a separate directory at least
<goalieca> it's in addons/audio
<goalieca> i also got a few audiocodecs but there's no streaming support or anything yet
<goalieca> i was hoping to get around to that stuff this week
<tjaden> there was streaming support in the kc/milan api
<goalieca> i honestly haven't looked at the old stuff. does the api match allegro4? we could repackage what already works then
<goalieca> oh. i meant i haven't added streaming support into the codec addon
<tjaden> oh, ok
<trentg> do you have svn write access goalieca ?
<goalieca> nope.
<-- Tigge has quit ()
<tjaden> eh, what's your sf username?
<goalieca> goalie_ca
<tjaden> let's see if i can remember my sf password
<tjaden> since they forced everyone to change
<tjaden> added
<tjaden> oh yeah, "don't do anything stupid"
<tjaden> that's the pep talk
<goalieca> heh. yeh. thanks
--> Tigge ( has joined #allegro-dev
--- ChanServ gives voice to Tigge
<tjaden> nothing else?
<goalieca> so what needs to be done before a 5.0 release?
<tjaden> lots :P
<mimix> many things we're not even aware
<goalieca> i'm just thinking of long-term planning here
<mimix> when you have a closer look you figure that many things don't work properly
<tjaden> the main sections are in the NewAPI page
<tjaden> peter hull's idea to port an existing game was a good one
<tjaden> we'll find out a lot
<goalieca> how hard would it to be to port skater or shooter
<goalieca> shooter uses a lot of configurable stuff.
<goalieca> and GUI
<goalieca> skater already uses allegrogl
<tjaden> shooter should be easy, don't know about skater
<mimix> a5 doesn't have an equivalent of quad3d()
<mimix> and skater uses it
<mimix> but i think that's all
<goalieca> i have a feeling skater will be a lot cleaner to translate
<tjaden> could be a test case for opengl/d3d integration
<trentg> ) File location API (merge from Tomasu's branch)
<trentg> What's that about?
<trentg> I think someone needed it, but I forget who and for what
<goalieca> Tomasu wants to include virtual file system support
<trentg> Yes but what's special about location?
<tjaden> oh, dunno
<mimix> al_get_display_mode() just can't be implemented in windows/ogl
<trentg> Is that the last thing he needs to do?
<goalieca> question: how is allegro support in terms of unicode
<tjaden> crap
<trentg> mimix, what parts of it or all of it and why not :(
<mimix> it wouldn't be a problem if ALLEGRO_DISPLAY_MODE wouldn't contain "format"
<mimix> the available pixel formats is not that easy to get
<trentg> Impossible or not easy :)
<trentg> I don't know if the format is needed anyway...
<mimix> you need to create a graphics context to get a list o pixel formats
<mimix> and the list you will get probably depends on how you create the GC
<trentg> So we can let the user pick a format, and if it's not supported, faiil
<mimix> yes
<trentg> I think that's fine
<CIA-31> alleg: goalie_ca * r10119 /allegro/branches/4.9/ (22 files in 7 dirs): Initial check-in of audio addon and audio codecs.
<trentg> They will likely use one of the ambiguous modes that will choose a proper one
<goalieca> the test-bench for audio is in the acodec addon (needed to be able to load sound files for testing)
<goalieca> should i upload sample sound files as well?
<tjaden> no
<tjaden> actually the files for the a5teroids are too big already
<goalieca> well i could convert them to ogg/flac and use the new sound engine in the demo
<goalieca> some of the small wavs might get bigger with compression but title_music should shrink a lot
<trentg> I'd bet they would all get a lot smaller
<trentg> as ogg at least
<mimix> when using ogl in windows, exnew_fs_resize fails to show up when resized, because of foreground window rules
<mimix> the example should be rewritten to get some input before resized
<mimix> but since d3d is default no one will notice :)
<trentg> Should d3d be default on windows?
<trentg> I guess with all platforms supporting opengl, it should be
<mimix> yes, d3d works better in general on windows
<trentg> ya, I guess there's that
<-- mimix has quit ("bye")
<goalieca> yeh. down from 2.8MB of wav files to 430Kb of ogg files
<goalieca> err 477
<trentg> Last thing is ") Text routines"
<trentg> from the wiki
<trentg> Someone wants length specified instead of null terminated strings
<tjaden> fine by me
<trentg> I'll try and do it this week. I will keep the null terminated versions though.
<CIA-31> alleg: tjaden * r10120 /allegro/branches/4.9/misc/ ( 
<CIA-31> alleg: Update for to move.
<CIA-31> alleg: Bump version number in to 4.9.3.
--> Tomasu ( has joined #allegro-dev
--- ChanServ gives voice to Tomasu
<tjaden> yep
<trentg> Tomasu, ) File location API (merge from Tomasu's branch) ... what's that about?
<Tomasu> not ready. soon hopefully
<Tomasu> oh...
<Tomasu> no, that can go anytime I suppose
<Tomasu> I was thinking all of it ::)
<Tomasu> sorry I wasnt here
<Tomasu> got a tooth removed :)
<trentg> Why is just that part needed?
<trentg> *For what
<Tomasu> I Dont follow?
<trentg> Why is that on the wiki
<CIA-31> alleg: tjaden * r10121 /allegro/branches/4.9/addons/ (15 files in 5 dirs): 
<CIA-31> alleg: Delete CMake-generated files.
<CIA-31> alleg: Set svn:eol-style properties.
<Tomasu> oh is that on the wiki?
<Tomasu> I didnt put it there :P
<trentg> Yup
<Tomasu> but it can go to 4.9 anytime so long as you can find the code
<Tomasu> al_get_dir or whatever I called it
<Tomasu> I dont think it escaped my last "merge" error, so its in the rev before the merge.
<Tomasu> I still need to fix all that
<trentg> Well if noone knows I guess it can wait
<Tomasu> it shouldnt take much work for finish the base fshook stuff anyhow...
<Tomasu> then I need to split the packfile and datafile stuff off into addons
<kazzmir> another thing to build..
<Tomasu> yup
<tjaden> trentg, why did you rename liballd to liballegd?
<Tomasu> rather simple stuff though
<trentg> Honestly, I don
<trentg> 't remember why
<goalieca> -lalleg and -lallegd follows a common convention
<tjaden> oh well, as long as all the build systems agree (eventually)
<trentg> I think they do now
<trentg> Mostly for sure
<tjaden> nope
<tjaden> well, not the old makefiles and scripts
<tjaden> i'll have a search and replace
<tjaden> fg
<trentg> No, I only meant cmake and scons
<goalieca> i never added the audio support to scons
<tjaden> hm, maybe i shouldn't update the makefiles
<goalieca> we should just stick to cmake
<Tomasu> ja
<Tomasu> much easier...
<Tomasu> but then some platforms cant or wont have cmake...
<Tomasu> so they need thier precious autocrap
<goalieca> which ones?
<goalieca> i'm sure that even the xcode files can be generated by cmake
<Tomasu> older unix boxen
<Tomasu> like at universites...
<Tomasu> even on newer ones where youre not aloud to install stuff
<tjaden> well, configure is still a familiar and in some ways more user-friendly interface for non-developers
<goalieca> no. i think ccmake (And the gui tool) for windows is a lot easier for non-developers
<Tomasu> fuck windows ;)
<Tomasu> jk
<goalieca> ccmake is ncurses
<Tomasu> is that a separate package
<Tomasu> ?
<goalieca> nope
<Tomasu> hmm
<Tomasu> I'll have to start using that
<tjaden> ./configure --prefix=/usr --enable-foo is pretty nice
<Tomasu> I can never remember the proper -DCMAKE commands
<tjaden> exactly
<goalieca> "ccmake -I ." brings up a list of options.. 
<Tomasu> I can never remember that either.
<Tomasu> at least configure has a standard naming scheme ;) --prefix, --enable-* --disable-*  etc
<Tomasu> --with-*
<Tomasu> and a simple --help
<goalieca> but ccmake has a menu ;)
<goalieca> bbiab
<Tomasu> as much as I hate autocrap, the configure user interface has been drilled into me, so I know it...
<Tomasu> and I prefer things I know ;)
<Tomasu> (that doesnt make me xenophobic does it?)
<kazzmir> who added addons/acodec?
<Tomasu> I dont even know what it is
<CIA-31> alleg: tjaden * r10122 /allegro/branches/4.9/misc/ ( 
<CIA-31> alleg: Updated allegro5-config for `liballd' to `liballegd' and `liballp' to
<CIA-31> alleg: `liballegp' move (which are the names in the CMake and scons builds).
<kazzmir> oh tjaden did
<Tomasu> but I assume its someone thats working on a simple addon that lets you use all sorts of audio codecs...
<tjaden> no, goalieca did
<Tomasu> of course thatll break once the sound api is done... if and when that happens
<kazzmir> addons/acodec/flac.c:104: error: 'FLAC__StreamDecoderInitStatus' undeclared (first use in this function)
<kazzmir> im not using cmake so maybe i dont have the right flags
<Tomasu> if there is a way to make cmake and scons load the same "flags" from a single place, that'd be sweet
<Tomasu> I doubt it though
<kazzmir> well its always possible to make scons parse the cmake stuff
<Tomasu> true, it is a hll after all.
<Tomasu> (add an e and its a hell)
<Tomasu> ;D
<kazzmir> probably would have to write an entire cmake interpreter thing
<Tomasu> eh.. it might just be better to learn cmake and use that instead.
<kazzmir> oh, instead of scons?
<Tomasu> ja
<kazzmir> oh the reason i dont like cmake is exactly because its not an hll
<kazzmir> thats it really
<Tomasu> heh
<Tomasu> I dont think it needs to be...
<kazzmir> make -> cmake is just trading one set of arcane commands for another, imo
<Tomasu> cmake generates make files...
<Tomasu> and make is one hard beast to replace
<kazzmir> well, scons :p
<Tomasu> which proves the point ;)
<Tomasu> to be honest, both seem hacky to me.
<Tomasu> they dont do what I need in a real build system...
<Tomasu> none of them do.
<Tomasu> its a pain.
<Tomasu> even cbuild didnt.
<Tomasu> it was nice to play with...
<goalieca> acodec only needs 1 function from the audio 
<kazzmir> well no matter what the architecture of the build system is i think it should always be based on a hll so that you have the option of extending it
<goalieca> i included it because it has the testbench for audio
<goalieca> ex.c
<tjaden> the flac stuff doesn't build for me either. i set WANT_ACODEC off
<Tomasu> kazzmir: or the build system should support all the things a project needs...
<tjaden> the scons files look like "programming" to me. i don't want to program the build system
<Tomasu> instead of making projects code special crap
<Tomasu> tjaden: and m4 is any better ;)
<Tomasu> jk
<tjaden> i want to _declare_ things and let it figure it out
<Tomasu> ja
<kazzmir> thats fine until project A wants feature X, project B wants feature Y, but project A will have a heart attack if the build system has both X + Y because thats "bloated"
<Tomasu> I want simple, powerfull AND easy
<kazzmir> well scons is declarative, until you want to do fancy things
<Tomasu> kazzmir: then project A can jump off a cliff
<Tomasu> they dont have to use the system if they think its bloated :P
<Tomasu> no single build system will be a perfect match for everyone.. but I havent found one I even LIKE yet...
<kazzmir> fine. but neither cmake nor make seemed "declarative" to me
<tjaden> make is declarative
<kazzmir> they just seemed like very hacky programable systems
<Tomasu> in make you just declare targets and depends
<tjaden> make is beautiful at its core
<Tomasu> I made some gmake macros to get it to detect libs and stuff.
<Tomasu> it was _fun_
<Tomasu> but it wasnt meant for that...
<kazzmir> ok i guess i agree that if make's job in life is just to build a target based on a dependancy then its entirely declarative, but if that was good enough then people wouldn't have built extra nonsense on top of it, such as automake
<Tomasu> its good enough to do what it does. its just one tool. 
<tjaden> yes, automake is nonsense
<Tomasu> very
<Tomasu> thankfully allegro got rid of automake already
<Tomasu> or never used it....
<tjaden> we never used it
<Tomasu> something, I know it got rid of one of the Autos.. probably autoheader then
<kazzmir> ah i needed to upgrade flac to 1.2 from 1.1
<kazzmir> probably need the same thing for ogg now..
<kazzmir> 1.1.2 -> 1.1.3??
<kazzmir> oh that was just libogg, libvorbis is at 1.2
<goalieca> i'm using 1.1.3 right now
<goalieca> that's what's in ubuntu
<kazzmir> for libogg or libvorbis
<goalieca> libogg
<kazzmir> oh yea thats fine, acodec just needs libvorbis
<goalieca> ya. libvorbisfile
<goalieca> 1/2
<goalieca> 1.2
<kazzmir> yea
<goalieca> for the audio API, the wiki version used strings to pick which driver, (ie: "alsa" "openal")
<goalieca> would you prefer automatically picking or a user selection
<goalieca> i don't like the string idea
<kazzmir> strings as opposed to global constants?
<kazzmir> cant it just work the same way as picking a video mode, GFX_AUTODETCT or GFX_D3D or whatever
<Tomasu> it should probably be a constant
<goalieca> ?
<Tomasu> just to stick to the same style
<kazzmir> i like that style
<CIA-31> alleg: kazzmir * r10123 /allegro/branches/4.9/ (6 files in 5 dirs): build acodec and audio addons in scons
<-- Vanneto has quit ()
<CIA-31> alleg: tjaden * r10124 /allegro/branches/4.9/src/xglx/xdisplay.c: xdpy_show_cursor should set cursor_hidden to false.
<trentg> I can't get openal to build on windows...
<goalieca> :(
<trentg> The binaries are missing alext.h
<goalieca> those are openal extensions maybe
<goalieca> alext.h is in the
<trentg> Yup, and after a few hacks it's compiling now
<goalieca> the only test i have is ex in acodec
<trentg> I'm not quite there yet
<goalieca> hehe okay. 
<CIA-31> alleg: kazzmir * r10125 /allegro/branches/4.9/ (4 files in 4 dirs): clean up addon build files
<-- trentg has quit ("brb")
<goalieca> how do i check if i'm in linux in a5, #ifdef LINUX ??
<tjaden> ALLEGRO_LINUX i guess
--> trentg ( has joined #allegro-dev
--- ChanServ gives voice to trentg
<trentg> Hmm, got openal sorted I think but now it's trying to build alsa
<goalieca> i figured that would happen.
<goalieca> i'm trying to deal with that stuff right now.
<goalieca> that and autodetect
<tjaden> is al_draw_scaled_bitmap supposed to be working for opengl yet?
<trentg> I would have thought so
<tjaden> huh, scaling down works but not scaling up?!
<trentg> It must have broken at some point, because exnewapi worked
<tjaden> i don't know what's going on
<-- tjaden has quit ("Leaving")
<goalieca> cmake.. how to find out if windows or not
<goalieca> is there a convention you have been using trentg 
<trentg> WIN32
<goalieca> heh. i changed the init and now openal works for me. I don't see why though :S
<CIA-31> alleg: goalie_ca * r10126 /allegro/branches/4.9/addons/ (6 files in 4 dirs): 
<CIA-31> alleg: Changed audio driver initialization code.
<CIA-31> alleg: Updated audio CMakeLists.txt for non-linux builds
<CIA-31> alleg: Updated acodec example to reflect changes in audio.
<goalieca> trentg, does that build now on windows without problems?
<trentg> I had to change two #elifs to #elif defined... now another problem.. no usleep
<trentg> Can that be approximated with Sleep on windows?
<goalieca> usleep is in microseconds. which file is that in?
<trentg> openal.c
<goalieca> we should use al_rest
<trentg> Right, that was my first hunch then I thought we wanted it to be independant of allegro for some reason
<goalieca> i have no idea what that sleep is for
<goalieca> in fact, i'm trying to integrate it with allegro more. the error handling is all stderr at the moment.
<trentg> now it builds but tries to link with -lesd
<goalieca> esd is for linux only (alsa)
<goalieca> forgot about that
<Tomasu> fuck esd
<Tomasu> drop it
<goalieca> well i don't know what's going on but the alsa.c needs to link with it. there is no libalsa
<trentg> It's called libasound
<goalieca> lol. good call 
--- Tomasu is now known as TomasuDlrrp
<CIA-31> alleg: goalie_ca * r10127 /allegro/branches/4.9/addons/audio/ (CMakeLists.txt audio.c openal.c): Build fixed for windows and linux.
<goalieca> trentg, ^^
<trentg> Ahhh is there a switch to disable flac? I'll try that tomorrow, I gotta go to bed
<trentg> It built though :)
<goalieca> okay good
<goalieca> no there isn't a switch to disable codecs
<goalieca> thanks for the effort.. and also thanks for getting me svn'd ;)
<trentg> heh, well there probably needs to be switched for each codec at some point
<trentg> switches*
<goalieca> heh. maybe i'll do that now
<trentg> ok, well gn