You do not load any bitmap ? tga ? pcx ?

I think it is a big good and nice reason to keep any support for non-accelerated graphics. You can not imagine how many people do not have their graphic card drivers installed, and how many drivers who are not happy with opengl ( here I think to nvidia & laptop graphic drivers ).

I'm not sure what you're asking.
However, if you mean `will Allegro have hardware accelerated primitives when using the OpenGL driver, just as OpenLayer does now', then yes, it will. There's no reason not to.

That would make some things a bit difficult, mostly I mean the things that need CPU access to bitmaps.

Though I think these things can be done with PBO's or what ever was the name of the extension

Well, 'action' functions type has the verb first method, e.g. al_get_joystick but the methods that set/return state have it the other way round, e.g. al_joystick_num_sticks

Don't know, but some of the function names are just silly, it sounds like you're talking to the computer not calling a function

for example:
al_wait_for_specific_event()

would be much better as:
al_event_wait()

not only is it smaller to write, it's easier to remember and more importantly it makes it easier to pass in a state, thus making two functions (in the case of the event wait functions) into one.

I guess the other advantage is it makes it easier to guess functions, e.g. If I wanted to do something with a bitmap I know I could type: al_bitmap_xxx and if xxx verbs/adjectives/adverbs were consistent across the objects then we'll be coding twice as fast

But hey, I'm easy.

Not in Japanese
And Japanese is a cooler language than English.

I personally disagree (though I haven't been using Allegro recently so I don't know how valid it is), but I like namespaces (at least, in C#) and they seem to clean up the API to me.

I'd strongly support that, though some people still like to make retro games and also can't work in 3D... Perhaps a compromise?

Nobody responded to this:

I was under the impression that dos support was being dropped. If anyone wants to use allegro with dos/qnx/mac os classic/whatever then they should use the last MAJOR release (4.0?). Is that correct?

Looks like the sourceforge page may need to be updated to reflect the changing nature of allegro...

The last stable release is 4.2.0, with 4.2.1 probably being release in some time, which will likely be the final 4.2 version, and final version to support DOS, BeOS, QNX.

4.3 only is planned to support Windows, Linux, OSX initially, but implementation for additional platforms are always welcome. 4.3.0 itself is just a very early WIP version not ready for any production use.

From previous discussion I don't think we will provide lots of separate DLLs where selective things (like memory bitmap access) will be cut out. So that means, you would distribute an allegro.dll along with your game, which indeed would have those functions in it.

But if you static link, the linker will not included unused functions, so I don't see a problem either way.

I really don't see how that's a problem! Maybe DOS and BeOS people are going to complain that they've lost support, but I'm sure the 10 remaining Classic OS users can cope with not getting brand new code.

Maybe problem wasn't the proper word to use. `matter' was probably closer to what I meant.
But I agree, the person using MacOS Classic can go on without Allegro.

No. I meant if you were drawing a circle you'd have different methods for drawing. Either drawing to a video buffer an image of a circle, or using OpenGL/DirectX to draw triangles to make up the circle.

Or call the al_draw_circle() function and let it pick whichever is best.

The problem with that is that flags are an important part of the operation being performed. It's not some optional thing at the end that twiddles with some knobs in the algorithm. It changes the algorithm altogether.

That was my exact initial reaction. However,

This is quite right. It's not like selecting flags, really. It's specifying the mode of operation. Maybe flags is a bit of a misnomer and we should instead call the parameter `mode', or something like that.

I agree, putting the flags last makes perfect sense. Putting the mode of operation first also makes perfect sense.

Hehe, well, this wasn't about something like set_gfx_mode.
More al_blit(MASKED, ...) versus al_blit(..., MASKED).
The first one does feel more natural to me after having played around with it.