I'd also like funcWithCaps(). So it's one more. But that's mainly because I'm used to the Java coding rules...

But I don't think the header idea is that cool... I'm using a doxygen variant of the allegro docs, so my editor can display all of the help directly while I type... but if I'd use a macro, that wouldn't really work anymore.

Oh, while we're at this: A javadoc / doxygen style documentation would be cool. I handmade a "parse_me.h" header with javadoced function decls, so my editor can parse it, and present me my inline help. Took me sometime, though to do it... and I would hate do it again. Can't you guys not simply add another doc dir with a doxygen-ed header? Since the functions will be created from scratch anyway, so documenting it doxygen style or XML might be a good idea.

quote:
AllegroGL already provides sufficient functionality. And I can make an OpenGL program run faster than any D3D program on an nVidia card (thanks to NV_Vertex_Array_Range). I can access more functionality of that nVidia card in OpenGL than D3D. And, most importantly, I can use that OpenGL program on non-Windows machines.
Allegro should not define the 3D API. Allegro doesn't grow fast enough to keep up with OpenGL or D3D's progress. Not only that, making a good 3D API requires a great deal of time and effort. Even OpenGL 1.0 didn't get it right (no texture objects). What if someday, they come out with a fully programmable interface to texture lookup, allowing the user to write some type of microcode or something that will allow you to change how texture lookups happen (replacing bilinear or trilinear). D3D would have a new version that exposes this functionality. Popular vendors would produce OpenGL extensions to this mechanism (assuming OpenGL2.0 wasn't already written with this in mind). And Allegro 3D wouldn't be able to keep up.
Not only that, Allegro's 3D routines would provide additional overhead to D3D/OpenGL routines, which are already an indirection away from the hardware. Since good 3D is so performance driven, we don't need another layer of indirection.

I do not mean that Allegro should have the best 3D in the world. I am saying that Allegro needs reasonable 3D support, in order to easily make 3D games, not of professional level maybe. Current 3D support in Allegro is very very primitive. You can not do a lot of things with it.
What I would like to see is a reasonable API for :
1) specifying the 3d objects (common 3d object format)
2) specifying translations in these 3d objects
3) letting the hardware do the texture mapping, where available
4) letting the hardware do the 3d transformations, where available
5) providing an easy api for implementing the game loop, just like it has been proposed in the other thread(where the library chooses the update mode, etc), automating the process of transformation-projection-texturing-updating the screen.
As you say, it can be very difficult. I think that it would be a real challenge, much more challenging than adding 'al_' in front of every function or using strings for configuration routines. The real challenge is in going 3D.
Performance is not a problem; the API can always be inlined, so as that it would be almost the same as if using native GL or D3D.
And extensions is also not a problem; if D3D comes out in a new funky way of texture lookup, then we will question ourselves "do we really need that for Allegro ?". The answer most probably would be "no". And if you are dying to incorporate the latest changes to it, then if the internals where really thought out in the first place, then it would not be a problem.
Just because Allegro does not grow fast enough for keeping up with GL and D3D, that does not mean that it should. I need the basic 3d, with reasonable texture mapping and transformations speed...current 3d in Allegro is good enough for educational purposes only.
On the other hand, if Allegro 5.0 comes out in 4 years, the current Allegro 3D routines will fly on the Pentium 10 GHz...

I'm on Bob's side!

Let's_use_underscore (I do in my functions and it's much easier to read.) And I'm a lazy programmer at heart too! So If I can do it then so can you! Still a wrapper should be fine for all those CapsLoversOutThere..

Can I request support for a new kind of masked_blit?

It would be useful for some of my ideas if I could have a masked_blit where the mask is read from a seperate bitmap or the same as the source image but from different co-ordinates. So add three new parameters.. Mask_bitmap, Mask_x, Mask_y to a function called something like "Masked_blit_seperate" or something like that..

I know this would be slower than the normal masked_blit, but it wouldn't be used for every sprite drawn..

This new function would allow me to do things like materialisation effects without predrawing the effect for every sprite (but only for the mask)

Anybody else like this idea, would it be hard to implement?

Rich.

Korval : Although OpenGL is nice and I agree with you, it feels to me that Allegro is incomplete (as a games lib) without 3D. I can't say to my buddies "hey, do you want to write a game ? use Allegro! it covers everything you need!", because ...it lacks 3D. In fact, this has happenned.

If it is so difficult to write 3D routines that use the underlying hardware, due to hardware constantly evolving and because of different standards, can we have at least a nice software 3D renderer(good enough to write good games with it) ? Maybe intergrate some add-on ? maybe intergrate p3d or other libraries that provide the same stuff with Allegro, only being much faster ?

I'd agree with the idea of Allegro being completely plugged in. I.E. Everything is a plug in to the main package. You would be able to download different sets of packages dump them all into \allegro\ and run make
any missing dependencies will produce an error message.
Also, the datafile plugins might do well to be connected to the main ones. If you plug something in it will add itself to both. Additionaly, what if the header file contained pointers instead of #defines no need to worry about loading the wrong data type.
Perhaps there should be an online registry for addon names all addon functions would be something like al_network_init(); With the registry double-naming could be prevented.
Or perhaps it should happen in some cases i.e. to create a couple different plug-ins which have the same interface but have slightly different outcomes - different looking GUI systems for instance

In X11, part of the reason many of my programs run slowly is because of mouse support. Would it be possible to make it so that, when the "default" Allegro cursor is being used, that the standard X cursor / routines etc could be used? I'm not an expert, but I think this could significantly increase performance when dealing with the mouse.

I long awaited to scream about this just needed the right place and time.
WHEN I SEE AN APPLICATION LOAD UP ON A COMPUTER AND I MEAN I CAN SEEEEEEEEE IT LOADING AND LOADING DRAGGING WINDOWS ON THE
MONITOR THAT I CAN SEEEEEE BEING DRAWN ALMOST LINE BY LINE AND I KNOW THAT THIS COMPUTER HAS A PENTIUM II OR BETTER I THINK
OF C++...AND BLOAT A LOT OF BLOAT AND I WANT TO SCREEEEEEEEEEAAAAAAAAAAAAAAAAAMMMMMMMMMM !!!!!!!!!!!!!!!!!!!!!!!!!! HOW CAN THIS BEEEEEEE ?
ANYONE WHO COMES UP WITH ANYTHING LIKE THIS
FOR ANY REASON IS MENTALLY DISTORTED !
Thhank yuo four lissening !

Deleted duplicate post.

The nice thing about Allegro 5 is that a lot of the new stuff can be built on the old code (ex: the new graphics core). As new features are added, the new code will progressivaly merge with the old code. Or at least, that's how I see it

On a slightly more mundane note, it would be nice if there was:
a) consistent parameter ordering
b) consistent function naming
c) reduction in the function count
On (a), I mean stuff like dest/src mixing round in the draw_sprite and blit functions
On (b), I mean not only have the same noun/verb/other order but make it more intuitive, e.g.
clear_bitmap -> bmp_clear
clear_to_color -> bmp_clear_to_colour
draw_sprite -> sprite_draw
create_bitmap -> bmp_create
set_clip -> bmp_set_clip
bitmap_color_depth -> as is
As for (c) reducing the function count, this could be achieved by having optional parameters and function overloading. But this delves into the realm of C++. Saying that, this is the reason why C++ is better for writing more intuitive C programs without the actual need for objects.
It could also be achieved by passing in ORed parameters or parameter specifieers, e.g.
load_bmp(AL_PCX,"file.pcx");
Also, all those interal globals and stuff, like allegro_id, os_type, etc. should be palmed off somewhere far away. Maybe a global allegro structure instead?
Neil.

Adding my own comments in the last minute:
I will hunt down and strangle the one who kills DOS. DOS is not in the way. But throw out the DOS-specific stuff
Threads is of no need for a gamelib
Ditch blit and draw_**sprite and unify them. make the command use flags instead. consider further prefixing, like al_bmp_draw(), it makes it easier to remember names and follows the good ISO structured ways of programming.
Throw out the current blenders and use bob's stuff instead.We need no windowing system more than we have, there already exist by far superiour GUI libs like GTK that works swell with allegro.Add datafile saving routines
No more bloat to allegro!! Move out the crap if possible. LBM? Never even heard of the format before. Put it in some module or a completely external lib.
A modularised idea is a stupid idea IMHO. Why? Because we got .dll's and .so's. Ppl will sooner or later get the whole lib anyway so it's badly invested time.
Yeah, we can start with this

I can add another thing; We should merge in AASTR with Allegro. It's a really nice set of features that at least I think fits into the core dist. This works with the idea of a flagged blit. I had this problem earlier that I had to use function pointers to incorporate antialiasing properly in my code