The Allegro Wiki is migrating to github at https://github.com/liballeg/allegro_wiki/wiki
Allegro Hack Day/2008 January 5
- Can we use MOUSE_STATE and KEYBOARD_STATE instead of MSE_STATE and KBD_STATE?
- How should mouse cursors work? In X11, a cursor is a property of a window - so with multiple windows, each one has a cursor. If we only have one global mouse cursor in Allegro, then we'd loop through all windows to change it. Alternatively, we could give a display parameter to cursor related functions, or instead have them work on the thread's current display. Personally, I'd tend to the latter. It allows the simple API without display parameters, but in the (rare) case a program uses multiple windows, the user can set only one to have no cursor. E.g. have a game window with no cursor, but some control window with a cursor (like e.g. UAE).
Per-window mouse cursors.
- Allow Allegro4 and Allegro5 to co-exist? I.e. use different names for headers and libraries
- Move allegro5.h to allegro5/allegro5.h.
- Eventually provide allegro5/allegro.h for A4 compatibility, relying on allegro-config --cflags to provide -Iallegro5 for A4 programs.
- Addon headers are like allegro5/a5font.h
- Libraries go into the normal library location, and always include the version number.
- Addon libaries also go into the normal library location.
- Release 4.9.2 in January?
- merge the skater demo into the 4.4.0 release, or keep it separate?
- remove the old demo?
- should draw_sprite_[h|v|hv]_flip_ex() even exist when there is draw_sprite_ex()?
No, they should be deleted on sight
- Should we make threading functions public?
Seems there was no general opposition, but some points were not resolved.
- Should we have al_fill_triangle?
<mimix> i mean, come on, a game programming gfx api that doesn't support drawing of filled triangles or polygons
- Please can we split off the OpenGL code so that it can be used by both Linux and Mac ports?
<peterhull> Hello <tjaden> hi <dacap> hello <peterhull> Is everyone here who said they were going to be here? <dacap> trentg yes <dacap> elias yes <dacap> Matthew Leverton ??? <dacap> mimix yes <dacap> Peter Hull yes <elias> peterhull: just replied to your [AD] post <mimix> hi <peterhull> elias: I look forward to reading it. <elias> :) <peterhull> I think I got myself into a bit of confusion --> zap0 (firstname.lastname@example.org) has joined #allegro-dev --- ChanServ gives voice to zap0 <zap0> did i miss it? <peterhull> no (unless I did too !) <mimix> heh, i don't think we even started <elias> that time converter link says it starts right now (if we adopt the 15 minutes late convention used in universities :P) <mimix> we start... now! <peterhull> On OSX I have written some platform-dependent code for tls.c <tjaden> let's whip through the questions then, shall we? <tjaden> Can we use MOUSE_STATE and KEYBOARD_STATE instead of MSE_STATE and KBD_STATE? <elias> i put that, i really don't like abbreviations like that for user code <mimix> sounds better <zap0> silly abbreviates are ..well, just silly... and lead to confusion. <tjaden> i don't like the abbreviation MSE myself <tjaden> but ALLEGRO_MOUSE_STATE and ALLEGRO_KEYBOARD_STATE are very long <zap0> its not like anyone is short of screen real-estate or HDD space these days <elias> yeah, we have a lot of long symbols now <peterhull> I don't think they would clash with anything else <peterhull> (there is a MOUSE_STATE in Windows device driver kit) <mimix> "ALLEGRO_" part is too long but it has to be that way <peterhull> Are they user-visible or only internal? <elias> user visible <elias> you use them for what you used key and mouse_* in A4 <mimix> but it's ALLEGRO_MOUSE_STATE, isn't it <elias> yes, it's with ALLEGRO_ <trentg> They're not use all the time.. normally all you have to do it "ALLEGRO_MOUSE_STATE state;" so they don't wrap around or anything <elias> maybe there could be #defines to shorter versions <zap0> either its done properly with ALLEGRO_ or it has to be namespace'able. i completly *hate* the BITMAP situation on windows. <zap0> i dont want that to happen again. <mimix> so it's ALLEGRO_BITMAP now? <peterhull> I don't think the long names are a problem, as trent says it's not a commonly used symbol <elias> yes, that's why we use ALLEGRO_ (even though everyone agreed it's too long :/) <elias> but AL_ was taken by OpenAL.. <zap0> ALG_ <mimix> BITMAP is commonly used though <trentg> In practice I find using ALLEGRO_ is not a big deal <mimix> ALG sounds like AGL <tjaden> ugh, let's not discuss prefixes again <elias> heh <mimix> right <zap0> ALL_ AGR_ <tjaden> anyway, i wouldn't mind the rename <mimix> we agreed that ALLEGRO_ is best, but still bad :) <zap0> ok. <elias> #define key(K) al_key_down(al_get_keyboard_state(), K) <peterhull> Curse those SDL guys, they beat us again ;) <elias> we could provide a file with a few defines like that ^ .. or users could make it themselves <peterhull> (on name length I mean) <zap0> why can't C just have namespaces! <elias> yes, we should encourage using C++ and D wrappers <dacap> we could use C++ ... (long history, I just joking :P ) <elias> those can then also provide a different naming scheme if they want <mimix> zap0: we'd still have same problem <tjaden> i refuse to endorse C++ <tjaden> :P <peterhull> Well, FWIW I say we _should_ use the longer names. <elias> heh <mimix> we'd have to just the namepace name and it would have been "allegro" again <elias> yes, i think it just is the only way to have a somewhat consistent API <zap0> i refuse to endorse 80% of C++. 20% is useful... like namespaces. <elias> if we use an abbreviation here, then why not somewhere else <zap0> with completion capable IDE's, its not really an issue. <dacap> elias: we could use abrreviations just for libraries/addons (the prefix only) <trentg> 232 lines of 6500 contain ALLEGRO_ in my project <trentg> So it's not like you're wasting a lot of time typing it <elias> what prefix does the font addon use? <dacap> trentg: I think that that's right <mimix> trentg: you could have saved 232*5 bytes with AL_ :P <trentg> The font addon uses A5FONT, a5font <trentg> Maybe not a good idea to use A5 in prefixes <zap0> ugly idea. <elias> i guess at some point in the future, we *will* reopen the prefix discussion :P <dacap> elias: hahaha <tjaden> ok, moving on. here's an easy one: Allow Allegro4 and Allegro5 to co-exist? I.e. use different names for headers and libraries <trentg> We're already doing it AFAIK <elias> yes, we put all A5 headers into <prefix>/include/allegro5 now <tjaden> i think allegro5.h should be in the allegro5 directory as well <tjaden> i.e. #include <allegro5/allegro5.h> <elias> there was something mingw related why we didn't do it, I think <trentg> That would be fine with mingw <zap0> really? but mingw is nothing special. <elias> mingw has no allegro-config <elias> anyway, i would be fine with that <zap0> i like the idea of clearly seperate names. <tjaden> for A4 compatibility, what we could do is have an allegro5/allegro.h. A4 programs can still use #include <allegro.h> as long as they use the allegro-config --cflags (and eqv on other platforms) <elias> or we could even have allegro.h including that <tjaden> but we want A4 and A5 to be installable at the same time <elias> so programs would compile without changing compiler options on platforms without allegro-config <elias> ok, then that sounds like the best way <peterhull> So, you mean having allegro.h in /usr/local/include/allegro5 ? <tjaden> yes <elias> then you can use plain A4 or emulated A5-A4 by changing compiler options <elias> but have both installed <peterhull> sounds OK to me <elias> and libraries just always will have versions in there name <zap0> and that'd be the same on winblows? /<compiler>/include/allegro5 <tjaden> yup <trentg> Yes. So it remains almost the same as it is now, except allegro5.h goes into allegro5/ <zap0> and that would require #include <allegro5/allegro5.h> instead of #include <allegro5.h> <trentg> Yeah <zap0> that seems a very sensible plan. <trentg> Where should we put addons dlls/sos? <elias> where are they right now? <trentg> Where are they on Unix? <elias> /usr/local/include/allegro5/addons/font/a5_font.h <elias> looks that's what I get here <elias> so a user would have to do: #include <allegro5/addons/font/a5_font.h> <elias> which doesn't seem optimal at all <trentg> Hm, ok, they're in include/allegro5/addons/a5_font.h here <trentg> And also I meant the libs themselves <elias> yes, i was just trying to figure out what names libs have <elias> only found .so files so far, there I get /usr/local/lib/liballegd-4.9.2.so here currently <trentg> They in lib/allegro/addons on windows <elias> does mingw/VC also embed the version number? <trentg> For the main lib, yes <mimix> addons are in /usr/local/lib/allegro/4.9.2/ <elias> so -lallegd-4.9.2 <trentg> So we have to get things the same on both platforms <trentg> Also it's alld on Windows :b <zap0> msvc/vc/lib/all421d_s.lib <zap0> but i can't remeber if i renamed them or not. <elias> so should we try to use the same names everywhere? <trentg> Makes compiling for two different os's easier <elias> but then, in unix it doesn't matter at all if you can type them, as you never should type them <zap0> where possible yes. <elias> it's always `allegro-config --libs` (plus parameters for addons) <trentg> I can make it the same on Windows as it is on Linux <elias> /usr/local/lib/allegro/4.9.2/ is the modules path.. i wonder by now if this is a good place to also put the addons <tjaden> why aren't addons just in the usual include/lib paths? <elias> a5font.so would be fine just living in /usr/local/lib/a5font.so <elias> I think they should be <tjaden> that's what we're doing for 4.3.10+ <elias> also means no -L required for mingw/VC <trentg> Ok, and no LD_LIBRARY_PATH needed on Linux <elias> well, that never should be needed <trentg> Are the addons built statically? <elias> no, we'd just have stored the SO path as allegro/4.9.2/liba5font.so <elias> (if that is possible) <elias> but anyway, no reason for that <trentg> I see, so we put them in include/ and lib/? <elias> or include/allegro5 <trentg> Yeah <elias> ok, so next topic? <zap0> right-o.. <zap0> "Release 4.9.2 in January?" <zap0> is it ready ? <-- dacap has quit (Read error: 110 (Connection timed out)) <tjaden> wasn't it supposed to be released in December? ;) <elias> there's lots of small things which shuold/could be done.. but then, it's just a development release <zap0> the dec meeting has a list of TODO's for 4.9.2 <elias> oh, indeed <tjaden> they're pretty much all done <elias> trentg took over the readme and changelog :) <zap0> the scons item? "should we have an allegro-config on unix with scons?" <tjaden> not sure about the allegro-config/scons things <elias> yeah, it does not output an allegro-config right now <zap0> is that a problem for anyone? <tjaden> yeah, who uses scons anyway <tjaden> ;) <elias> does cmake create one? <tjaden> yes <elias> should be fine then <tjaden> someone should make a release. it's only a WIP <mimix> WIPs used to be releases <elias> yes, the 5.1.* series will be like that again <tjaden> hmm> <tjaden> i mean, hmm? <peterhull> do you think anyone else would use/test it if there were a release? <elias> i assumed mimix meant that releases like 4.1.x were quite stable releases.. <elias> while the 4.9.x ones are just tests of highly-in-development code <mimix> ok <mimix> it isn't much more than doing a SVN tag <tjaden> i doubt many people will test it, but it shows some progress :) <trentg> Yeah, I think we should do a release after changing include/lib paths like we discussed <elias> hm, about the mouse cursor question, it basically was, should we allow per-window cursors <peterhull> tjaden: that's a good point <tjaden> yes to per-window cursors --> dacap (email@example.com) has joined #allegro-dev --- ChanServ gives voice to dacap <peterhull> elias: I think yes, on OS X the cursors are per view anyway (ie. per window in our case) <elias> yeah, X11 only has per-window, so that's what is implemented there <peterhull> Anyone know about windows? <elias> in windows they have to be implemented by capturing certain window changing messages from what I remember <tjaden> however it's done, it's certainly possible <peterhull> In 'normal' windows the cursor is part of the window class structure I think, dunno about DirectX <zap0> i dont understand the context of this 'cursor' thingy you are talking about.. is this the graphic on the screen, or the co-ord data ? <elias> http://alleg.sourceforge.net/naturaldocs/files/mousenu-c.html#al_set_system_mouse_cursor <elias> should that function affect all windows owned by your program, or just the current display <mimix> current display sounds better, if it's doable <zap0> the word system in there implies all of them... "system-wide" <elias> the "system" is just as opposed to "user" <elias> i.e. you can set the system's clock cursor, or your own ALLEGRO_BITMAP (with al_set_mouse_cursor) <elias> but yeah, documentation certainly has to be improved <elias> once the API is final <zap0> could a flag be added to the function for specifying "apply to all" <peterhull> If you can set the cursor on each display, then it would be pretty easy to iterate over all displays and set it, if that's what the user wanted <elias> likely we will use external docs then (in addition or instead of natural docs) <elias> true, looping should be easy enough - given how unlikely it is someone uses more than one display, i don't think we should have special support for it <zap0> agreed. <elias> hm.. "Please can we split off the OpenGL code so that it can be used by both Linux and Mac ports?" <elias> i'd say yes :) <elias> also should be shared by Windows <tjaden> how is it now? <elias> just some simple GL code in the src/xglx directory <elias> it was originally intended as just a "dummy driver" <elias> somewhat related, i'm struggling myself between porting AllegroGL's extension mechanism over, or requiring http://glew.sourceforge.net/ <elias> right now my GL code is limited to OpenGL 1.0 <elias> but likely we want to provide extension management to users, as well as use extensions in the driver implementation <tjaden> oh, glew is under BSD licence now <elias> does that mean we could just copy it over? <elias> or we can not? <elias> (i'm no good with licenses) <elias> (if it was for me, i would make A5 GPL :P) <elias> but just out of utter ignorance to the issue I guess.. :) <mimix> release 4.3.10? (isn't on the topics list but still) <tjaden> well, it'd be simplest if we change allegro to BSD/MIT <dacap> elias: with BSD license you can copy & paste the code (you have to copy the copyright notice) <mimix> i don't think we can change a license just like that <elias> wasn't A5 already going to be MIT anyway? <mimix> every contributor would have to agree with that <elias> i.e. i remember png/zlib <elias> well, A5 is a new library based on A4 <elias> and A4 allows using any code without contribution <elias> so we should have 0 problems there, luckily <mimix> hm, that is right <tjaden> the giftware licence is ambiguous but the way i read it, anything goes, including relicencing <elias> well, "do everything you want" isn't that ambiguous i think :) <elias> we only said in the past we can't change the A4 license itself, as that wouldn't technicaly even be a derived work <tjaden> certainly some jerk could take allegro, rename all the functions and sell it under a proprietary licence so it's no different for us to switch <elias> yeah. so even that should not have been a real problem. for A5, it certainly isn't <zap0> allegroPro! <elias> that just took the name, but no code <elias> hm, and likely we have no rights on the name <elias> like, everyone is free to name their library "allegro" <zap0> as they have done on sf <elias> well, we now have liballeg.org :) <zap0> & .com ? <elias> and http://allegro5.org/ <zap0> ha ha! <elias> .com is only for companies I think <zap0> i guess we are an org <tjaden> should draw_sprite_[h|v|hv]_flip_ex() even exist when there is draw_sprite_ex()? <tjaden> do those functions exist? <elias> that's 4.3.10plus I guess <mimix> yeah, those were in the patch <mimix> i didn't notice <mimix> neither you did apparently <tjaden> but not in SVN? <elias> kazzmir's patch? <mimix> i'v already removed some inlines from svn because i believed they were there by mistake <mimix> elias: yes <mimix> but i didn't remove everything when i realized that it wasn't a mistake, draw_sprite_[h|v|hv]_flip_ex() were actually exported <mimix> so they are broken currently :) <tjaden> but they shouldn't be there, right? <mimix> imo, no <tjaden> ok, marking as no <elias> it would have meant something like this would be possible? draw_sprite_h_flip_ex(..., FLIP_V) <mimix> i'll remove them completely from the public then <mimix> without the flip param <mimix> they are used internally by draw_sprite_ex() <mimix> the patch containing them was approved, so i wasn't sure, that's all <tjaden> i didn't try to understand the patch very hard <tjaden> just looked at formatting mostly :P <mimix> merge the skater demo into the 4.4.0 release, or keep it separate? <elias> probably depends on if someone wants to do it <mimix> i would merge it <mimix> remove SConstruct from it? <elias> i think the demo is really nice, and especially for showing off allegrogl (all the polygon calls) <tjaden> it was written with the understanding that it would be merged, so merge i guess. but it's still undocumented and slightly buggy <tjaden> *uncommented <elias> yeah, would need to integrate into the 4.2 build system, no scons <mimix> makefile are there and working <mimix> it is quite commented though <mimix> when else is part of scons? <tjaden> i think there's less than ten lines of comments per .c file <elias> i think only that one SConstruct <mimix> we can even leave it then <elias> i wonder if we could ask the original authors on a.cc to comment it more? <mimix> some files are mode comented then the other ones <mimix> *more <elias> the SConstruct would probably only confuse, best to get rid of it in this case <mimix> build dir is also scons specific <elias> that shuld not be in svn though <elias> scons just creates it when run (or so I remember) <mimix> ah, ok <mimix> so remove the old demo? <tjaden> no, i don't think so <elias> btw, the old demo for the longest time was one huge undocumented mess <elias> so the new one really isn't that bad :) <tjaden> i can't make head or tails of the new one <tjaden> so i doubt a newbie will understand it easily <elias> indeed <mimix> in one a.cc thread evert asked for skater to be documented more, it was, and he said it's fine <tjaden> ok. well, i must be blind <elias> tjaden: which files in particular are you thinking of? <elias> it starts in demo.c.. goes to framewk.c.. and so on <elias> hm, framewk.c doesn't use a very clean main loop <elias> oh well <elias> at least it has lots of comments <elias> and the really hard parts like the quadtree and the level formats have rather detailed descriptions as well, but likely they are too complex to try and understand anyway <tjaden> yes, framewk.c has comments <elias> do we still have the 8.3 restriction in 4.4 btw? <elias> well, i guess, in theory it would still work in DOS <mimix> if we do in 4.2, i'd say yes <elias> just not in dosbox <mimix> it it because some unzip programs? <mimix> or cause of dos? <elias> dos <elias> for maybe fat16 or whatever was used with it <tjaden> well, we broke the 8.3 rule in places beginning in 4.0 <elias> the dos i used had long file names i think <elias> but it used fat32 <mimix> i broke it few days ago with makefile.name <zap0> are there any DOS devs? <zap0> no one is going to write for DOS.. drop it. <mimix> 4.3.10 has working dos code <elias> well, there's no reason to actively drop it in 4.* <elias> A5 won't have any dos code <zap0> good. DOS is dead. <dacap> DOS = Dead OS :P <elias> so, framewk.c *could* be renamed to framework.c then.. but up to whoever merges it :) <zap0> anyone needing an environment like DOS, can use linux. <tjaden> you should have seen the names before <tjaden> well, i guess you did <mimix> sk8er.c <elias> heh <elias> i think that was someone from a.cc trying to prove a point :P <tjaden> yes, up yours too <tjaden> why don't you just stab me in the eye <mimix> will the first release be named 4.3.10? <tjaden> yes <-- peterhull has quit () <elias> ok, so "Should we make threading functions public?" <elias> wasn't put their by me, although i always supported that, but usually was alone with it <tjaden> i still don't want to <tjaden> (very much) <elias> getting pthreads to work in Windows just is a pain, and i think with worse performance than a simple wrapper <elias> also SDL, GLFW and all those have threading APIs exposed <tjaden> so what synchronisation devices would you have? --> peterhull (firstname.lastname@example.org) has joined #allegro-dev --- ChanServ gives voice to peterhull <elias> the ones we already have, so i think mutex and condition variable <elias> just change _al_ to al_ <elias> one alternative would be to have a small addon with wrappers like that <tjaden> i forgot i implemented condvars for win32 <elias> hm, just trying to find the internal naturaldocs docs <elias> ah, it doesn't have them documented <elias> but yes, "mutex" and "cond" are there <elias> http://glfw.sourceforge.net/GLFWReference26.pdf <elias> they have just those 2 as well <tjaden> wrappers for win32 are really easy, except for condvars <elias> SDL adds semaphores <elias> (but i never understood those) <elias> just a mutex with a counter or something <tjaden> a mutex is a binary semaphore <tjaden> the counter is 0 or 1. semaphores are more general <tjaden> e.g. you have N resources. if you use a semaphore with an initial counter of N, then N threads can decrement that counter to zero without blocking. The next thread that tries to acquire the semaphore blocks. <elias> I'd need a concrete example I guess <tjaden> i guess i don't have any real objection to exposing the thread API. we can peek at the SDL or glfw condvar implementations if need be <tjaden> and the a5 code uses condvars already so they probably will need to be present <elias> yes, so probably no need to make it an addon <zap0> mutex on win32 is different from mutex on linux.. i think, is mutex on linux system wide, or just process wide? <tjaden> process <elias> for system wide, you need some kind of interprocess communication <elias> which pthreads doesn't provide AFAIK <zap0> a mutex on win32 is system wide. <tjaden> but win32 has critical sections <tjaden> which is what we use <elias> how can you obtain a mutex of another process? <zap0> the objects are there, but in naming these things for the API, the word mutex may lead to confusion. <elias> or you mean, the win32 "mutex" is the same as CLI? i.e. nothing can interrupt it? <tjaden> no, win32 mutex really are system wide mutexes <zap0> if 1 process on win32 has a mutex, another process can block on it. <zap0> for threads of a process to block on each other, you use a Critical section. <elias> ah, ok <zap0> i use them to prevent another instance of my app from running. <elias> so you pass some kind of application handle to the mutex functions? * zap0 fetches some code. <zap0> HANDLE h = OpenMutex( MUTEX_ALL_ACCESS, false, strMutexName ); <tjaden> pthread can have inter-process mutexes as well, via a mutex attribute <zap0> named mutex (system wide).. or use CreateMutex( ..., strName ); if the name already exists, the function fails. <elias> i see <zap0> the technical issues are non-existant, its just a naming problem that i want to avoid. <tjaden> we'd hardly be the first to name interprocess mutexes as "mutexes" <zap0> most (ab)users make lots of presumptions about multi-threading code, i dont want there to be any more confusion for the API names. <elias> we would go with SDL and GLFW at least <elias> i.e. no way to assign a system-wide name to it <-- peterhull has quit () <elias> myself, i only had use for it for network related stuff.. and (A4's) internal API was the easiest way to do it :) <zap0> im not familiar with the SDL way.. either we use completely different names (not likely) or we stick with the conventions of win32 or *nix, might be best to just stick with *nix conventions, and docuemnt it well for win32 users. <elias> well, since the API has no "id" or "name" parameter, it should explain itself <elias> from another process, you have no way to reference it.. so you won't be able to be confused :P <zap0> a const char* name within an app provides every instance of the app with the same mutex name. <elias> al_init_mutex(ALLEGRO_MUTEX *mutex) <elias> if we would add a const char*, then it wouldn't be clear <elias> but since there is no const char*, it should be <zap0> oh ok. <elias> GLFWmutex glfwCreateMutex( void ) <elias> i guess if we expose it, we could start arguing what is the better API :P <elias> hm, anyway.. was there something else.. <elias> "Should we have al_fill_triangle?" <elias> well, i put that in response to that allegro.cc thread <elias> myself, i don't really care, as i don't think i will go back to using any other API besides OpenGL for graphics <-- dacap (email@example.com) has left #allegro-dev <zap0> in teh end i dont think i'll be using the API anyway (personally), the reasons i choice threading as a solution is for raw speed. and "just another wrapper" is not going to help that any. unless this wrapper adds "value" to the problems of writting multi-threading code, I dont see the point. (other than x-platform value). <elias> low-level graphics like textured/untextured triangles at least <elias> well, threading became important with multi cores now <elias> e.g. if you have a random level generator <elias> you should divide it into 2 or 4 threads <tjaden> what allegro would provide is the bare *bare* minimum <elias> the number would be best specified by the user or detected somehow <zap0> i know the advantages of threads (my app uses about 8 or 9 (at present)). <elias> exactly. and you should not have to know how to use threads on Linux or OSX for that <elias> (and likely, you also do not use pthreads for them, coding for Windows..) <tjaden> the problem is, if you have a thread utility library that sits on top of, say, pthreads, you cannot use it with any wrapper API <zap0> i had pthreads or windows at one stage, but it was "just another wrapper" around what seemed a fairly simple win32 api anyway. <zap0> a threading API has value to those producing cross platform code. <elias> and cross platform is our main goal with A5 <zap0> k, what was next... "al_fill_triangle?" <zap0> who requested this? <tjaden> i'm going to sleep <-- tjaden has quit ("Leaving") <zap0> nighty night! <elias> the last posts there.. http://www.allegro.cc/forums/thread/594591 <elias> i.e. triangle could be considered as one of the base drawing primitives <elias> so instead of just rectangle and line we'd also have that.. <mimix> we don't have polygons? <zap0> has anyone got, or willing to contribute code for it? <elias> not so far, and the A4 polygon functions were, in short, crap <elias> well, Thomas Harte sounds like his code is rather good <zap0> which version is his code for? <elias> just conceptual :/ <elias> but still, getting that to work as an A5 memory function would be much less work than having to start from scratch <zap0> can't the do_line() be used with a big a math to do triangles <zap0> bit* of math <elias> no. that's basically what A4 ones do <elias> but it causes overlaps and gaps if you try to do anything with it <elias> of course, just using glBegin(GL_TRIANGLE_STRIP) or something is easier to use then anyway <zap0> sounds like GL is better suited for anyone trying to implement triangle drawing. <elias> yes, i would agree - the question really is, who is the target for A5's basic drawing/blitting API then <elias> and do they want triangle/polygon or not <zap0> 2D hackers, like me! and no.. triangles are not that useful. <elias> so let's say, addon then, I guess <mimix> not if you've got polygons <elias> yeah, the skater demo would not be doable with A5 <elias> but also not if we had al_triangle <mimix> i'm meanm, come on, a game programming gfx api that doesn't support drawing of filled triangles or polygons <mimix> *i mean, <elias> font drawing also is an addon <elias> of course, one which right now does not need anything platform dependent <mimix> it's ok if it's supported by addons <mimix> a5 addons are still part of allegro project <mimix> like modules <elias> yes. just separates things more <elias> so we have a better chance of getting the "core" done <mimix> by a5 i usually mean a5 + addons, it's what the user gets <mimix> gota go now, bye <-- mimix (firstname.lastname@example.org) has left #allegro-dev ("gone") <zap0> i have to go too... work in 4 hrs. must sleep. remember to update the wiki page (it looks have done already!) <zap0> have/ half <elias> i'm away for a bit now as well <zap0> ok, bots: talk amongst yourselves ;)