The Allegro Wiki is migrating to github at https://github.com/liballeg/allegro_wiki/wiki

Difference between revisions of "Allegro Hack Day/2007 May 12/log"

From Allegro Wiki
Jump to: navigation, search
(New page: All times in -0500 UTC. == Log == <table> <tr><td class="time">07:10</td><td class="sender">tjaden</td><td class="sender-message"><span>how about we start off with the simpler stuff</span...)
 
m
Line 1: Line 1:
All times in -0500 UTC.
+
All time is in -0500 UTC.
  
 
== Log ==
 
== Log ==

Revision as of 16:05, May 12, 2007

All time is in -0500 UTC.

Log

07:10tjadenhow about we start off with the simpler stuff
levertonthat would probably mean something I've done
07:11tjadenwhat did you want to discuss about the MSVC project files?
07:12levertonthere's not a whole lot to discuss on my end ... Matt had been working on a ASM version of asmlock.s for MSVC
levertonnot sure where he is with that
levertonhttp://wiki.allegro.cc/MSVC_Project_Files <-- I updated my status here
07:13tjadeni'm not sure that's useful (the asm version)
levertonme neither
levertonit could be if there were compatibility problems between the ASM and C DLLs
MattyMattI've not tested it yet, but I reckon it's done
tjadenfor 4.3, we want to move away from asm anyway
07:14levertonI think there were problems with the asm file getting recognized within a MSVC project too
MattyMattI agree, there's no point using non-C calling conventions
allefantand even in case someone adds asm stuff, it should keep C calling convention (if that was the problem)
07:15levertonanyway, as my wiki page describes, the MSVC project files are built via a PHP script
levertonmanually keeping them up to date would be a chore
tjadenwhy php?
MattyMattthe code in question does naughty things too, that cause far worse slowdowns than a few params on the stack
levertonbecause I'm writing it ;)
07:16levertonit someone wants to redo it in another language, they won't hurt my feelings
tjadenit'll be hard to generate as part of the zipup process
MattyMattI'm happy to keep the project updated by hand. it doesn't need many changes even between major allegro versions
levertonMattyMatt, there are three versions (one for 6, 7, 8)
levertonwell, at least 2
07:17MattyMattthere will be 4 once I have done .mdp for VC4 :)
levertonheh
levertonthe script would be easy to rewrite in another language if someone wants to do it
07:18MattyMattI've found the option in VC6 to write a makefile from a project
levertonthere are just some templates and a file listing config file
tjadenXML would be hard to deal with in shell though
allefantwe already have perl and python and bash stuff, so why not also some php stuff :)
tjadeni don't want to install another p- language!
allefanti assume, it's enough to do "apt-get install php" to run the zipup script from unix
MattyMattand nmake hasn't changed in years. in theory a single nmakefile would work on any VC
07:19allefant(but tjaden is the one who will have to run it :P)
levertonwell, I could easily create them for now
levertonthey'd have to be tested anyway
tjadeni'm only half serious
07:20levertonMattyMatt: I'm not sure if nmake stuff is even useful for allegro
levertonseems like if someone wants makefile support, that MinGW-make would be good enough (assuming they aren't on Vista...)
07:21tjadeni actually managed to build allegro with mingw on vista, but it was a royal pain to set up, and it didn't work when i tried it a week later
MattyMattyeah it's a minor convenience for M$-only shops, who want to look at allegro quickly
07:22MattyMattand those places would prefer .dsw or .vcproj anyway
levertonyeah
levertonI'm currently working with the project files in a /build/msvc folder in the Allegro source
levertonthere's too many files to put them in the base folder
07:23levertonI didn't know if there is a better place to put them
levertonI think the root folder of the Allegro distro is already pretty messy...
MattyMatti think the base folder is the place. it's all the makefile fragments that shouldn't be there really
tjadeni think build is used by the scos build for object files, etc.
tjaden*scons
07:24tjadenwe have cmake and scons directories, so...
levertonthere will be (3 + # of demos + # of examples) * 3 project files
leverton# of tools, that is
07:25MattyMattall the projects could go in one big workspace
MattyMatti mean all the examples
levertonyeah, but each exe needs its own project
MattyMattah yes
levertonso there's 1 example workspace, but X number of project files
MattyMattI forgot about that
07:26levertonat some point there might be an OS X project file ?
levertonso maybe a neutral base dir would be good
levertonand then sub dirs for the platform
tjadenwhat to call it?
07:27MattyMattbuild is good
allefantwe could use build_msvc and build_scons
tjadencan we get scons to put its files in a different directory?
allefantyes
tjadenok, good
MattyMattbuild/msvc and build/scons
07:28levertonpersonally, I think it would be nice to see all the build related files in a subdir , instead of the root ... but I won't volunteer to make any of those changes ;)
allefantwhere does cmake put its files?
allefantyes, i think a nice build system won't touch the source tree at all
tjadenit wants CMakeLists.txt in each directory, but the aux stuff could be moved to build/cmake
07:29allefantok, so build/[msvc|cmake|scons]
tjadenyup
levertonit will probably be build/msvc6 build/msvc7 and build/msvc8
levertonI'm not sure if 7 and 8 share formats
07:30leverton8 is XML
tjadenmaybe even build/make if anyone is up to it
leverton6 is an ugly nmake/comment system
levertonI think that's settled then, which brings me to one more comment on MSVC stuff
MattyMattmoving the makefile fragments is easy enough. it's how to check it in to SVN that I couldn't do
07:31levertonI'm not sure if the link time generation optimizations are good for distributing the Allegro .lib files
levertoneg: http://www.allegro.cc/forums/thread/590727
leverton1>Linking...
leverton1>fatal error C1047: The object or library file 'C:\allegro\lib\alleg_s.lib' was created with an older compiler than other objects; rebuild old objects and libraries
levertonjust a note
levertonI did come up with a work around that I posted at the end
07:32levertonbut building Allegro with the /LTCG stuff makes the .lib MSVC version dependent
07:34levertonanyway, that's all I've got ... I should have the project files stuff finished this week
tjadena rock and a hard place?
allefantso we need a different set of libs for each msvc version?
MattyMattwith a working project file, nobody will need precompiled binaries anymore
levertonwith LTCG stuff, MSVC 2005 and MSVC 2005 Express aren't even compatible
levertonit only affects binary distributions
07:35levertonwhich are very popular on Windows
MattyMattonly because it saves setting up mingw
levertonbut as Matt says, with a project file, they won't be as vital
levertonit's mostly just a note; I can easily not use that switch when providing binaries
07:36tjadenok, add it to the readme for msvc
07:39MattyMattI'll get 4.2 built with asmlock.asm this week. It's still needed so long as alleg42.dll is current
MattyMattor is it?
07:40tjadenyes
07:41tjadenmatt suggested to give the c-only version a different name if there were incompatibilities
07:42levertonis there an easy way to check for incompatibilities?
MattyMattthat would make clashes less mysterious.
levertonI've not had any problems running other people's 4.2 stuff with the C DLL
MattyMattI think you'd need to use banked SVGA on Win 98 to notice
07:43MattyMattafaics that's what these funcs are for
tjadento be safe we should rename
07:44levertonwell, that can easily be done in the project file
levertonI suppose in the makefile too, but it's less important there
-> kazzmir has joined allegro-dev
ChanServ sets user mode +v: kazzmir may now speak if the room is moderated
tjadenwe should do the same on other platforms too
MattyMatt_C suffix?
tjadenthen it would be easier to phase out the asm version (for 4.2) if we want
07:45tjadenyes, something like that
07:47MattyMattI can put asm in the project now. It needs custom rules (vc6 by default doesn't have default rules which is strange)
tjadenall ok?
MattyMattyep, sounds good to me
07:49MattyMattI can try to build 4.3 with djgpp too, as my old machine is set up again
tjadendon't bother
tjadenwe stripped it bare
tjadeni mean src/djgpp got deleted
MattyMattah ok, so 4.2 is the ultimate DOS version?
tjadenyes, unless someone forks
07:50MattyMattwill the NDS version be folded into the main trunk eventually?
07:51tjadeninto 4.2, probably
MattyMattit seems to me that every new platform adds exponentially to the complications of maintaining the whole lib
tjadena little bit
07:52levertonit's better than the alternative
MattyMattI'm wondering if having a single distro for all platforms is really the best way
tjadenwe already tried the other way :)
MattyMattback in winalleg days?
allefantwinallegro
allefantheh
07:53tjadenalso xwinalleg
tjadenand the incomplete linalleg
tjadenok, what about the gfx stuff?
07:54allefantwell, i didn't get around to do what i wanted since last time
allefantso the beginnings of a display API on the wiki is all that's new
MattyMattthe windows build would benefit from losing all the platform #ifdef #includes. msvc pre-processor can't grok them as not dependents
07:55allefantmy way would still be to get this API implemented in my X11 branch
levertonare we talking about http://wiki.allegro.cc/NewAPI/Display?
tjaden
leverton, yes
tjadenallefant, it kind of doesn't help anyone wanting to help not on x11
07:56tjadenby which i mean leverton :)
allefantyeah
07:57allefantbut basically, any API which handles multiple resizable windows as AL_DISPLAYs should be fine
allefantcan then still work out the final API
MattyMattI don't know about that, if the API is solid and well-documented then one implementation doesn't affect the others
tjadenthat's what we're missing
07:58allefantyeah, hard to create a solid API without knowing the problems
MattyMattah :) the API won't be solid until it's proved BY implementation
MattyMattyep, that's reality of coding
07:59levertonin exnew_events.c:
levertonif (!al_create_display(GFX_AUTODETECT_WINDOWED, AL_UPDATE_DOUBLE_BUFFER, AL_DEPTH_32, 640, 480))
levertonis that just filler code?
MattyMattafter all. Shawn didn't write the docs until the code was done
allefantthat's Bob's original API
tjaden
leverton, yes
allefantah, and yes, the implementation is just a wrapper around set_gfx_mode
08:00levertonok, that's what I assumed
allefantthat was the original idea - implement 4.3 API as 4.2
08:01levertonhow much of the display api is questionable?
levertonlike are we trying to develop for lowest common denominator and build the features from that?
08:02allefantas i see it, the main improvement compared to 4.2 is an unified update mechanism
allefantso no more need for manual "double buffer" and "page flipping" and so on
allefantand support for multiple resizable windows
MattyMattI don't see a way of specifying a resizable window in there
levertonwhat's preventing anyone from implementing what you've got written so far?
08:03allefantnothing i'd say
levertonI think if the big picture is known, the details will work themselves out
MattyMattGFX_AUTODETECT_WINDOWED_RESIZABLE ?
allefantso even Bob's original API would work
08:04tjadenit sounds solid enough then :)
allefantif someone implements a driver for that, it can drivially be fitted to the new one
levertonimplicit bitmap targets is new from Bob's, right?
allefantin my X11 driver, the vtable entries are called like display->line(current_display ,...) so it even has explicit parameters for everything internally
08:05tjadendon't worry about internally
allefantyep
tjaden(n/m)
08:06tjadenMattyMatt, it would be a AL_RESIZABLE flag to al_create_display I'd say
allefantinternally, it would be best to follow the way tjaden implemented stuff in the events and input API
08:07allefantbut i guess, any clean design should work
08:08allefantby now, i think once we have an API and working drivers, doing a clean up on that will be much easier, then writing something in the first place
allefant*than
tjadenso the display api is basically fine as you've written it, and we can stick in stubs for the functions?
08:09levertonwhat's the high level process of implementing the display api?
allefantwhere i stopped it all the color format specifications
allefanti'm not sure i understand everything in Bob's API there
allefanti'd somehow like to just be able to use OpenGL commands, without caring about color depth or RGB format used.. but not sure that makes sense
08:10MattyMattI think we should have at least one standard RGBA format that isn't platform dependent
tjadenfor the process i would say (1) stick in stubs, (2) get abstract types sorted, (3) figure out how to do implcit targets, (4) write a driver
08:11tjadenjust as a starting point for discussion
08:13levertonI'm not familiar with Allegro at that level, which is the biggest obstacle preventing me from doing any real work
allefanthttp://alleg.svn.sourceforge.net/viewvc/alleg/allegro/branches/4.3-xdummy-system/include/allegro/display_new.h?view=markup
allefant^ that's how it started
allefantthat was with an older API idea in mind though
08:14allefanthttp://alleg.svn.sourceforge.net/viewvc/alleg/allegro/branches/4.3-xdummy-system/include/allegro/internal/aintern_display.h?view=markup
tjaden
leverton, you could stick in the stubs at least :)
allefantthat would be the internal structure
MattyMatti learned how allegro works by tracing the DOS build process, then comparing it with the GDI one
08:15levertonthe MSVC 8 project file makes everything nice
levertonit does a good job deciphering all the #define magic
levertonso it's easy to find where stuff is declared and used, etc
08:16MattyMattah so no more "missing file : aldjj.h" ? :)
levertonheh, no
kazzmirmaybe we should keep those project files around for building on windows
kazzmirwell, non-mingw
allefanti should svn merge my branch, then it should be possible to view it with that
MattyMattkazzmir, we are agreed on that altready :)
leverton4.2.2/4.3.2 will have MSVC project files
kazzmiroh. i slept late :p
08:17allefantbut then, i won't claim that the system i used is the best.. so basically, internals are left to the implementor for now
allefantoh, this reminds me.. what is our current policy on merging 4.2 stuff?
tjadenmerging what to where?
allefanti did only commit the last patches to 4.2
08:18allefantthe polygon() and stretch_blit() one
tjadenpretty much you should merge all fixes to 4.3, but if you don't it's fine too
allefantleaves only somewhat more work for you when doing a merge, i guess :)
08:19tjadenand i might miss something, that's all
allefantok
tjadendo you use svk?
allefantand let's hope 4.3 will soon be enough on its own so this won't be that relevant much longer
allefantno, only svn
allefantso "svn merge" is a bit tricky to use sometimes
08:20allefantshould i get svk?
tjadenwith svk i commit to 4.2, then merge to 4.3 with: svk merge -c <rev> -l --verbatim $br/4.{2,3}
tjaden(using -C first to check there are no conflicts)
kazzmirwhats so hard about merging with regular svn
allefantneed to figure out the revision numbers
allefant-c in svn doesn't seem to work
kazzmirx=svn log --stop-on-copy svn -r$x:HEAD
allefantand the HEAD PREVIOUS and so on names i couldn't figure out at all
08:22tjadensvk is a pain to install though
allefantyes, i did apt-get it at one point, but gave up before i had it working
08:24tjadento be honest, i don't think i ever managed to fit bob's gfx api in my head
levertonyou are not alone
08:25tjadeni think dividing the display api part out was very good
MattyMattyep
tjadenand we can do the same for the rest
allefantmaybe a "drawing primitives" proposal
08:27tjadenalso some things don't seem like they would be that useful and maybe it would be best just to drop them initially
allefantyes, Bob said so himself
MattyMatti think the method for adding color depths is maybe overkill, but the alternative is to let the vtable grow
allefanthe dropped the idea of having source clipping
levertonI think a FLIC player is #1 priority  :D
allefantand i think for dest clipping, we don't need a list of rects
allefantsingle rect might be fine
08:28allefantwell, just as example, must think about clipping yet
tjadenwhat about patterns? i never used them
allefanti'd say no need for them
08:29allefantwhat would be nice is an addon which does things like cairo
allefanthave anti aliased lines with patterns and everything
MattyMattnope never used them myself. they could disappear into the depth convertors for doing 32 bit on 8 bit h/w
tjadenthat's another direction we could go: use cairo as our gfx api
tjadener, for primitives
MattyMattcairo is SVG isn't it :p
allefantwhatever we put into the base API, it will never cover any needs, so best to keep it minimal instead
08:30allefanttjaden: you mean, have cairo as required dependency?
08:31MattyMatta/a lines are easy to do in software, and trivial in GL
allefantyes - but should al_line be able to do things like a/a and patterns?
MattyMatti would say there should be flags
tjadenmaybe provide very little, and expect users to use cairo or GL depending on their needs
MattyMattwhich may or may not be ignored for now
08:32levertonI think things should be kept as simple as possible in Allegro
allefantwhat tjaden said would be easier for us though
allefantnot just ignore it for now, but just ignore it, and instead make it easy to use cairo or opengl directly
08:33MattyMattthat's what we've got with 4.2 + agl
allefantyeah, it's something i also put on the wiki, how do we handle addons
allefantagl only is a problem because there's no combined distribution
08:34tjadeni think its time to merge agl into 4.2
allefantfor someone who compiled both libs from source, it always was easy to use it
levertonAllegro should provide as many hooks for seemless addons as possible
MattyMattagl should be merged into 4.3 for sure. not so sure about 4.2 tho
tjadenwhy?
08:35tjadenit should still be buildable without allegrogl, of course
08:36allefantdoing a complete merge (i.e. unify window creation and things like that) would be some work though
MattyMattthat would do. my only reservation is some alleg42.dll with agl, and some without
mimixgood idea, i'll look into it
tjadenlet's keep them in separate dlls
08:37tjadenjust have a combined source tree so there's no version problems
MattyMattyeah, although I think agl has such a short future as a seperate lib, that an agl dll is pointless
levertonshort is long in allegro terms
08:38MattyMattthe agl part may as well be static, even in the dll build of allegro
levertonie, Bob's GFX api is almost 4 years old
allefanttrue, we could release allegro 4.2.2 in the summer, with allegrogl merged in
allefantand it should make life easier for those who want to use allegro + opengl
08:39tjadengreat
tjaden(static agl would be fine too)
allefantthings like dallegro and pyallegro shouldn't be hard to adjust
08:40allefanthm, actually, should just keep working
08:41allefantas the API won't change at all by this
MattyMattyep. maybe -lagl removed from the makefile
kazzmirhow will allegro users without agl handle such a thing
08:42mimixmake WITH_ALLEGRO_GL=0
MattyMattgive -DALLEGRO_NO_GL to make, for building without agl
tjadenor autodetect
kazzmiri meant if you distribute your game that uses allegro+agl and I have an allegro dll without agl, ill get runtime errors right
08:43tjadenif agl is dynamically linked, you'll need agl.dll before it even loads
08:44kazzmiroh you just meant physically building agl as part of the allegro build process
tjadenyes, allegro.dll should be identical in either case
MattyMattyep, but you will have agl for sure if you use the merged source
08:45allefantok, so agl never would be linked into allegro.dll
08:46MattyMatt4.2.2 sounds good for that, although maybe 4.4 would be easier to remember as "the one with agl"
allefantyes, but then 4.3 would be numbered wrong..
MattyMattand then the wip can continue at 4.5.x
allefantlikely we never will have a 4.4
tjadenyeah, calling the development series 4.3 was a mistake
allefantas the new events/input erally is A5
tjadeni guess that's the next topic
08:47tjadenwhat do we need for 5.0
MattyMatta fully working 4.3 :)
levertonhaha, so simple
tjaden:)
levertonI don't think we should shoot for the moon
08:48tjadenme too
allefanti want to an example which opens 2 windows and lets me use OpenGL in both
MattyMattmm. me too
tjadeni was thinking display, gfx, init APIs and maybe sound
tjadeneverything else, 5.2, 5.4, ...
08:49MattyMattKC and entheh are both in #allegro. they should be here before discussing sound
allefantboth are somewhat out of allegro devel time though
levertonis 5.0 going to be just like 4.3? Or is stuff going to be simply dropped for the sake of cleaning up
tjadendrop stuff from 4.2 you mean?
levertonyeah
08:50allefantcompatibility layer
allefantshould that be working in 5.0?
MattyMattthe FLI player could be external, using the same hooks as the SWF/SVG player I'm writing
tjadenisn't it working?
allefantit is
levertonI was going to use FLI an example ... I assume it's still in 4.3, but will it be in 5.0?
08:51mimixdo you even spend time think about compbility layer when thinking of new API? me not
allefantbut if we drop FLI we could also drop the GUI
allefantmimix: same here
allefantwe do the compatibility layer only to increase user acceptance
MattyMattthe GUI would need to be in the distro because the tools use it
tjadeni'm inclined to keep things if they work
\BAF64\oh man
\BAF64\i over slept
08:52tjadenmaybe build them as physically separate libraries?
MattyMattit's OK :) you were here virtually from 11am at least. you've got the whole thing logged
allefanti usually like to keep things, unless i get confused by all the files and then just want to svn rm everything :p
MattyMattyeah the GUI could be a seperate lib easily
08:53tjadenbut automatically and part of the same download
MattyMattyep
levertonis it possible to use a /addon folder to automatically configure allegro add-ons?
MattyMattsame makefile & all
allefantsounds nice
allefantyes, i want the same for PNG and OGG addons
kazzmirthats what was supposed to happen with the scons stuff
levertonPHP uses a system like that, and it's very slick (although it benefits from not having to worry about distributing DLLs)
tjadensounds ok
\BAF64\MattyMatt: yeah, I was idling in here so i do have complete logs
08:54tjadensounds like the agl solution in 4.2 actually..
allefantwe could have each addon build its own dll (if dll compatibility is a big issue)
\BAF64\then you end up with DLL hell
MattyMattwill PNG have licence problems if in the distro?
allefantyes, so the other way is that everything gets linked to allegro.dll
levertonalso I think it's useful for some add-ons to be considered "official"
levertoneven if they aren't distributed with Allegro
allefantbut then you can't replace one allegro.dll with another
08:55tjadenMattyMatt, the only problem is if we disttributed libpng source with Allegro
MattyMattah right yeah
08:56MattyMattso then loadpng should be included
tjadenyes, i think so, not that i'm biased
levertonI wish allegro just used the zlib license
MattyMattwith -DALLEGRO_NO_PNG if you can't be bothered getting libpng and zlib
08:57tjadenwell, make install-loadpng if you want it
MattyMattok :)
MattyMattyeah, that's more backwards-friendly
allefanti think, we even could distribute the libpng source, as long as we make clear it has a different license
MattyMattno need to obsolete all the existing online docs unnecessarily
08:58allefantit's like like GPL where the rest of the project gets affected by the license
allefanter, *not like
tjadenwell, but then we'd be responsible for building and installing libpng/zlib as well
MattyMattallefant yeah that would work, but lots of ppl have those libs already. they are fairly universal
tjadenno thanks
08:59levertonyeah, I don't think it's wise to bundle other library's code
levertonunless it's minimal
MattyMattthey have official msvc binaries already
tjadenso it's not really a licence problems but a CBF problem
allefantCBF?
tjadencan't be fucked
allefantheh
MattyMatt:)
09:00\BAF64\hmm
\BAF64\so Alleg won't be changing much in that aspect then
\BAF64\we will still have loadpng, but it would be official now?
09:01tjadenwhat's official?
allefantmaybe there should be a distribution team who makes bundled distributions
allefantlike a download for windows, which has libpng and zlib (and others) included
MattyMattloadpng and jpegalleg are fairly light
\BAF64\why jpeg?
09:02allefanti also need .ogg in almost all my programs these days
levertonI have a sneaking suspicion the team would end up being me
tjaden:)
09:03tjadenbetter not
allefanton the wiki page someone also mentioned openlayer, they did (do?) something similar i think
allefantat least for agl
levertonopenlayer is a huge package
MattyMattjpeg is by far the most common gfx format used these days
09:04allefantand we have jpegal for jpeg, so would be simple
MattyMattooh. and gif. are we agreed the patents have expired for sure, worldwide?
levertongif is crazy though
levertonbecause of multi frames
levertonand people thinking it means animation
allefantno need to distribute libjpg like with png
09:05MattyMattyeah, so gif should have an api similar to fli, rather than bmp
allefantin algif, you get a struct GIF_ANIMATION which has an array of bitmaps and timing and position info for each
tjadenwell, it needs both
allefantthe function registered with load_bitmap only loads the first frame
09:06MattyMattso alogg should do the same?
MattyMattit would be handy for thumbnails
09:07MattyMatteven tho in most videos, the first frame tends to be black :p
allefantvideo is different
tjadenno one stores single frame images in oggs
09:08allefantyeah, i assume, it uses an mpeg like compression, so you'd get all those blocky artefacts
09:09allefanthm, must ask KittyCat about that
MattyMattbut still, a version of load_bitmap() that takes a frame number, may be useful to ppl (but probably only if they are writing a video editor)
09:10\BAF64\you can't load one frame of an ogg video
\BAF64\at least not easily
tjadenanyway, let's just start with agl :)
\BAF64\you have to replay it from the last key frame to "build" that frame
09:11MattyMattwell that would all be hidden behind the load_bitmap_frame() magic :)
MattyMattbut this is a digression, I agree
09:12allefantmimix: did you release allegrogl 0.4.1?
mimixno, it's still rc3
allefantguess i should also test it (even if only in linux)
MattyMattso, where will load_png.c live? in addons/src?
09:13tjadenaddons/loadpng
MattyMattwhy give it its own dir?
allefantso after AGL is "merged", what would change?
tjadenloadpng is multiple files
allefanti guess it should still have its own version number..
tjadenyeah, i was just thinking about that
09:14tjadenagl is still not that stable
allefantalgif and jpegal also are multipe files
tjadenallegro 4.2 is _stable_
MattyMattjpegal is 3 files. the encoder, the decoder, and the load_jpg func
mimixyeah, it should still be considered expreimental
allefantso rename current 4.3 to 4.9, and do this for a 4.3 which is to be going to a 4.4 which has agl merged?
09:15MattyMattthat sounds good for me
allefantit just is somewhat against the idea of concentrating all effort on the new version, but oh well
09:16tjadenagl probably should have its separate version number
MattyMatteven after merging?
09:17tjadeni imagine from now on allegrogl will get more releases than allegro
tjaden(4.2)
mimixshould there be some API changes when agl is merged?
MattyMattnone really
mimixwe can put draw_sprite_ex into it
levertonwell, I don't think there's any harm in upping the version of 4.2 because a merged AGL has been updated
09:18leverton4.2.x versions could stand to be released more frequently
tjadentrue
MattyMattalso, if the GUI is demerged, agl's GUI will have to go with it
09:19MattyMattso seperate versions would be hell
tjadenwhy agl has a GUI, I will never know
MattyMattbut that's not relevant for 4.2
MattyMattagl just has a GL-friendly version of allegro's GUI
09:20MattyMattmage ported painlessly
mimixa few wrapper functions basically
allefantat the time it was added, there was that allegro gui mailing list, and things like AGUP
09:21MattyMatta bit more than that. it replaces the dialog_player with a "redraw everything" one
tjadenonce agl is merged, any documented API should be as stable as allegro. i don't know how you'll expose experimental agl stuff. maybe a development branch was the right answer
mimixMattyMatt: you know about it more tha me obviously :)
09:22allefantshould the documentation be merged?
MattyMattexperimental releases are OK, IMO. most users know the diff between those and stable releases
allefanti.e. convert doxygen docs to _tx
tjadenwould be nice
09:23MattyMattwould be nicer if _tx was converted to doxygen :) except doxygen's output is ugly as sin
allefantwell, an improved ._tx (basically allow docs in wiki syntax) wouldn't have been such a bad idea
09:24MattyMatti think self-documenting tags in the code is basically a good thing tho
levertonmy suggestion has always been to move all docs to an online wiki format
allefantfor things like the current 4.3 is definitly is nice
levertonand export them into some other format for allegro source
allefantfor final docs i like them separated
levertoneven wiki -> ._tx would work
09:25allefante.g. when adding a function to 4.2, the time it takes to update the docs is minimal compared to implementation
MattyMattand ._tx to wiki (a job for tomasu and his amazing perl scipts I think)
tjadenwould merged agl be in addons/agl ?
allefantduring developing new code, it would be impossible to always keep up-to-date docs, so here naturaldocs seems perfect
09:26levertonallefant: I agree
MattyMattyeah that sounds like a good place in 4.2
MattyMattbut in 4.3 it should be in the platform tree
MattyMattsrc/GL or sth
allefant4.3 will do a deeper merge anyway
09:27allefantyeah
tjadenso would agl be a special citizen among any other addons? i don't want all sorts of addons to officially become stable if they get merged
09:28MattyMattyeah AGL would eventually be in the main source, as just another gfx driver
MattyMattso giving it special status for now would be good
09:29MattyMattI think all addons should be kept once they are in tho. png and jpeg support is not bloat
09:30allefantthis is only about 4.2 currently, right?
tjadenyes
MattyMattor 4.4 :)
09:31MattyMattif we add agl, png and jpeg all in one go
allefantwait, so did we agree to actually rename the A5 API WIP away from 4.3?
09:32tjadenno
MattyMatti don't think so :) I'm happy either way but I'll vote for 4.4 + 4.9
allefantah, ok, wasn't sure
allefantso well, if we don't, there won't be 4.4
levertonI'd rather see people work toward 5.0
09:33allefantbasically, the name change won't affect anyone but those in here now
allefantyeah
levertonI think 4.3/4.9 discourages from that
levertonnot that I'm against it completely, because any work is better than none
tjaden4.4 and 5.0 are the logical choices, hmm
levertonthe question is... is 5.0 still years away?
09:34tjadenit's just that 4.3.0 and 4.3.1 got released..
allefantif MattyMatt codes resizable windows for Windows, 4.4 also can have resizable windows
allefanthm, true
tjadenabout 5.0, was there anything more we want included?
09:35levertonsemi-related: http://wiki.allegro.cc/Gemini%27s_DirectInput_Wrapper
tjadenthe more we drop the faster it is out the door
levertonI haven't looked at that yet
MattyMattsupport for more modern controllers
MattyMattWii, 3d mice etc
tjaden:p
levertonbut it's Kris Asik's new input code he wrote because of bugs he was encountering with Allegro's input
09:36tjadenshould be just an implementation issue, right?
levertonI asked him to document it, because it might just be a useful resource to track any problems with Allegro's current code
09:37levertonplus, he might be a useful resource for Win32 related 5.0 stuff
allefantyes
tjadensure
levertonI really don't know if his DirectInput code will be useful itself, but it's good to see someone willing to work on stuff
MattyMattif 4.3 still has the whole 4.2 API, then it can't be too hard to merge new input code into both 4.2 and 4.3
allefantthe current code is what was state of the art at the time DX5 came out i think
09:38levertonDInput is going backward though
levertonWindows is moving toward XBox-only controllers
MattyMattI'll bet 4.2 is getting far more testing than 4.3 atm
09:39levertonthat is, I think the new Windows input stuff ignores mice and keyboards completely
MattyMattso actually 4.2 is the place for testing low-level changes
levertonhttp://en.wikipedia.org/wiki/XInput
09:40tjadenhey, 4.3.0 got 6300+ downloads and not one bug report!
MattyMattheh, that's funny :) WindowsXP doesn't even see an x-box controller as a HID without a 3rd party driver
09:41MattyMattI thought they were just being awkward trying to HIDE the fact that an xbox is just a pc
09:42levertonaccording to wikipedia, "It should be noted that Microsoft recommends that new applications make use of the windows message loop for keyboard and mouse input instead of DirectInput"
MattyMattand now they want to pretend xbox controller is the only PC one :)
09:43levertonwell, thankfully Allegro on Vista hasn't been too painful
09:44MattyMattewww. action mapping at the OS level?
MattyMattthat's nasty, for a cross-platform game
09:45allefantfor the allegro driver, it shouldn't matter much
allefantif the new one works better than the dinput one, we should replace it
MattyMattthe dinput one works, it just gets the axes a bit muddled
09:47tjadenok, i think 4.4 should be 4.2+agl, and the next release of the unstable branch will be 4.9.0 which includes the start of the new display api
09:48tjadenhow's that?
MattyMattthat's fine by me
tjadenif the nds or whatever guys want more breathing room, they get 4.6, etc.
MattyMattyep
levertonis it possible to just pretend 4.3.2 was 4.9.2 ?
09:49tjadenyes
tjadenprobably a good idea
09:50MattyMattand it makes 5.0 LOOK much closer :)
levertonheh
levertonI remember the 3.9.50 days
tjadenhey, the last one was 3.9.40
MattyMattme too :)
tjadeni wanted it to end at 3.9.42
levertonso is 4.3.0 going to be re-used for the first 4.2+agl version?
09:51MattyMattis that yo momma's birthday?
tjadenhitchhikers man
MattyMattah :)
09:52MattyMatt3.9.39 was the day we declared war on Hitler
allefantyeah, but nobody wants to make the bot to keep the number of people in #allegro at 42
allefantheh
tjadeni think reusing 4.3.0 would be way too confusing
allefantso 4.3.2?
09:53tjadenwhy don't we skip some numbers :)
MattyMatt4.2.2 rc1
allefant4.3.41?
MattyMattmerging agl will be fairly painless
MattyMattit's only the build that needs merging
allefant4.5.0 also should be fine
09:54levertonskipping 4.4 altogether?
allefantif we are in danger of catching up with 4.9 that way, something relly goes wrong
MattyMatt4.39.x for experimental builds of 4.4?
09:55allefanthm, likely 4.4.0 will be out quite soon
MattyMatteither they build, or they don't, so tehy are unlikely to get released if they don't work. all the code is tested
09:56allefantso maybe already name it 4.4.0 beta
levertonI don't see a big problem with just picking up with 4.3.3
levertonI don't think many people actually seriously are involved with the whole 5.0 dev stuff
allefantindeed
mimixi wonder how will AGL font API fit into allegro
MattyMattyeah 4.3 is marked as unstable and unusable
09:57tjadenanother weird one: 4.3.9 for the first agl merged release
MattyMattyep, that's what I said effectively
09:58allefant4.3.9 is good
MattyMattmimix, for now, the same way it does
mimixfonts in allegro are not handled by vtables, yet agl needs it's own routines
allefantfor this 4.2 + AGL merge, that's ok
09:59allefantfor 4.3, we don't have any font API proposal at all yet i think
MattyMattyeah 5.0 needs freetype support etc
allefantahrgh
allefanti must now stop using the term 4.3
MattyMatt:)
tjadenit will take me a while too
MattyMattAllegro 5 is ALIVE!
allefantwell, .ttf is like .png and .ogg, quite useful to have in any game
10:00mimixwell that was easy :)
levertondo we need any platform-specific gurus for 5.0?
tjadenyes
10:01tjadencan we have some opengl-on-platform-x type gurus, thanks in advance
levertonis that the biggest problem?
10:03MattyMattnot afaics
allefantfor OSX, someone still has to check the input code i in 4.3.1 (4.9.1) i think
MattyMatta couple of MacOS dudes and a PS3-Linux guru would be sweet
levertonpeter hull just mentioned on a.cc that he's no longer available
10:04tjadenthe mac osx port does hold everything up
tjadenalso windows to a much lesser extent
10:05levertonat least windows has plenty of users and testers
MattyMattthat problem will diminish now we've got a working project :) semi-competents like me can now hack
10:06MattyMattthe build/test cycle is now drastically shortened
levertonyeah, I should be able to put together Windows stuff
tjadenexcellent
levertondespite no working experience ;)
10:07MattyMatt23 knows his way around the Win api too
levertonI have the 10000 pound Petzold book
10:08MattyMatti have the 400k petzold.chm :)
levertonbut I've never used DX natively
tjadenstarting with the 4.2 windows code is also a good idea
10:09allefantit might be useable in 4.3
MattyMattyep. you want to be able to compare with a working example when hacking
levertonwhat's the latest DX supported on 98?
MattyMatt9.0c works
10:10MattyMattor 9.0b at least. that's what I needed to play Age of Mythology
10:11tjadeni think i'll try to write an "API plan" tomorrow, but i still don't know what it would involve. i can note down the decisions about merging agl, etc. but what else?
10:12MattyMattinputs and events? they are already covered tho, aren't tehy?
allefantif the target audience are developers, then mentioning internals might be a good idea
allefantsomething like a skeleton driver
10:13MattyMattyeah and source layout. what the build and addons dirs are for
10:14MattyMatteven what the src dir is for, for the real newbs :)
10:15MattyMattI'm sure I started writing a plain-english description of the build process. I can't remember where I put it tho
tjadenwell, i was thinking less technical than that
tjadenmore like, where this project is headed, what is planned, etc.
levertonhttp://wiki.allegro.cc/AllegroRoadmap
levertonthat page is horribly outdated
levertonI just deleted a big chunk of it the other day
10:16tjadenroadmap, that's the word
tjadenthanks for your wiki work btw
levertonI'm starting to dominate the recent changes page
10:17levertonI need to come up with other identities to make it look like a community project, heh
allefant:)
levertonthe naturaldocs stuff is helpful
10:18levertonI think it should be a requirement that all new code is documented in such a descriptive way
allefanti agree
tjadencool
levertonlike most of http://wiki.allegro.cc/NewAPI/Events just came from me reading the comments
allefantin 4.2, we also have this double documentation (comment over function plus ._tx)
10:19allefantso in 4.3, the comment automatically is visible as naturaldocs, and we'll see about online wiki docs
allefanti mean
allefant5.0
levertonwell, I think there's a place for hand written Wiki documentation
levertonwith the Events page, I linked to the source documentation when useful
10:20levertonbut having a descriptive document can be very helpful to someone who is unfamliar with everything
MattyMattyep, short code examples have no place in the comments, but are good in wiki/._tx
10:21levertonthe nice thing about the inline documentation on the new events code is that it actually answered most of my initial questions
10:22tjadenyou'll notice almost all of it was from the spec written years ago :)
levertonit's just that comments like "Trying to register an event source with the same event queue more than once does nothing." are nicer than reading the code
10:23MattyMattwell I gotta run to the store. I know what my jobs are. resizable windows and asmlock.asm in 4.2
allefantyes, original proposals were here: http://alleg.sourceforge.net/future
levertonreading proposals dated 2003 is scary ;)
allefantindeed
MattyMatta good API ages slowly :) it took 20+yrs for printf() to become deprecated
10:24-> CGamesPlay has joined allegro-dev
ChanServ sets user mode +v: CGamesPlay may now speak if the room is moderated
levertonbut seeing it inline is assuring
tjadenanything else to cover today?
levertonI hope not, I'm hungry
allefanti'll just take working on my X11 display implementation as my job, unless someone wants to assign something else to me :)
tjadenyes, finish the gfx spec please
10:25allefanttrue, and that
levertonyeah, I can take a stab at a windows implementation of that
tjadenby that, i mean cut down bob's api into small chunks and discard less useful bits
levertonunless a better qualified person volunteers
-> trentg has joined allegro-dev
ChanServ sets user mode +v: trentg may now speak if the room is moderated
tjadeni will work on the roadmap and make pronouncements and such :)
10:26mimixi'll keep implementing agl vtables
allefanttjaden: will you svn mv 4.3 4.9?
tjadenok
10:27levertonI'll update the wiki with a log and a brief outline
10:28tjadendid the people who just joined want to raise something?
allefantthey are just late i think
MattyMattwill there be a log of this discussion online?
allefanthm, is DDustin "Dusty" on the wiki table?
10:29levertonam I on your ignore list, MattyMatt? ;)
allefanttrentg: oh, btw, do you have the link to your ogg addon again?
allefantforgot to bookmark it
trentgallefant: http://trent.gamblin.ca/logg
10:30allefantand it looks like a good candidate for official addons
MattyMattleverton ah :) sorry. didn't connect "log" w "log"
allefantoh, btw, this reminds of something else..
10:31allefantwhat should we do with the 50$ of donations?
10:32MattyMattwell convert it to euros at least :)
levertonhaha
levertonbuy somebody a book or something
levertonor take yourself out to dinner
tjadendirectx for dummies or something
10:33CGamesPlayThe Allegro account has $57.70 in it.
CGamesPlaysorry, $51.70
MattyMattyeah I've got a couple of nice DX books in chm/pdf. a copy of one of them to Kris Asik or someone would be good
10:34MattyMatta real copy I mean :)
MattyMattIntroduction to 3D
MattyMattGame Programming
MattyMattwith DirectX® 9.0
10:35levertonas long as it goes to an active developer in some way, I think it's well spent
levertonno need to fuss over $50
MattyMattby Frank D Luna, pubblished by Wordware Pub. Inc.
10:36MattyMattdunno if it's the best, but it's good
10:37MattyMatti like it because it taught me what dot-products and cross-products are and do :) so maybe I'm biased
10:39tjadenanyway, that's all folks