Why drop the timers? I like those . If you dump DOS support I'm sure the timers will work a lot cleaner.

Yeah, ummm, before you go off on a style, learn it first. What 23yrold3yrold did is the correct way of not using underscore. It is clearly just as readable as underscores and requires less space

- dump DOS

Well, I'm not writing any DOS code. If anyone wants DOS support, they'll just have to code it.

- dump timers

Timers are somewhat useful, but they're a pain to support. Better to provide high-resolution timers. We've already agreed on that.

- dump GUI, all packfile stuff, all software 3d
GUI is not likely to go, since many of the Allegro tools use it. It would be nice to have it replaced by some leaner framework.

- implement threads

I'm not too keen on the idea. Perhaps someone should start an add-on first, and we can go from there?

- implement proper alpha channels

Alpha is already here.

- orthogonalise

See API proposals.

- access to more hardware - gamma ramps, overlay surfaces, etc

Overlays, yes. Gamma ramps, I'm a little reticent. I don't like it when a windowed app hijacks the global gamma settings, and then crashes, leaving the messed-up gamma.

I'm well aware of hungarian notation.

ThePointStillStandsThatThisIsn'tAsEasyOnTheEyes
as this_is_when_done_correctly_but_I_guess_should_make_this_one_a_bit_longer_as_to_not_seem_like_I'm_cheating.

And I was also thinking about the typedef idea. But that could add more problems. What if someone codes with the hungarian, and starts working on an already underscore-based one?

Bah!!!!!!

Very true. So why did I write Hungarian...

Obviously, Allego 5 would now have to jump into a niche that was overlooked by SDL in order to actually become used.
TH, any significant shortcomings of SDL?

d00ds. Get to work Start groking the allegro source, read the todo list and get cracking. Me? Oh...I'm busy finding a web host, maybe I'll start the Allegro 5 forums

But getting ride of DX mixer will prevent the usage of hardware mixing, won't it? And I think one of the things allegro 5 should do is more hardware acceleration support. I have an old SB128 and it has 32 hardware voices.

Because I'd have implemented threads, so a special case for timers would be unnecessary. Besides anything else, do you realise just how many magnitudes easier it is to write the equivalent of audiostream code in SDL because it is threaded?

But suggested elements of the API have been sucessfully argued against on the grounds that they wouldn't be DOS portable.

From which we can also impliedly conclude that modularity is out? Or else, if the GUI is an option then obviously this isn't really worth arguing.

I don't like it when the API designers decide I'm not to be trusted. That's the sort of thing that makes me find an API unafraid to treat me like an adult.

Similarly, I don't like it when I read that other hoary classic 'how do I get fast true colour fades' and watch people replying 'you can't get the hardware to help with that, so it will always be slow'.

ahem surprising that a member of allegro.cc would like the idea of a dictatorship.

Apart from the missing hardware functionality already mentioned (i.e. when not in GL mode, hardware scaling and rotation of ordinary bitmaps), I've always been a little annoyed that the overlay surfaces are dealt with as a separate entity to normal surfaces, with separate functions and so on. I know that some varieties of overlay surface are planar, but I still don't see why that couldn't be part of the normal surface definition.

Also, the out of the box sound support isn't brilliant. It's more or less OSS equivalent - i.e. one 'audiostream' and some mixing functions you can call if you want help - but abstracted into its own thread. This brings us to TF's point about addons though, things like FMOD are not uncommon to link with SDL, and it took me half an hour to hook it up to DUMB. Which is because I hadn't used DUMB before.

Conversely, I've become a big fan of the event based input method, and one of the main reasons I abandoned Allegro was that threads make things so much easier for the type of application I was writing: an emulator. That's why my CPU core can be paused at any cycle where most people's can only be interrupted inbetween any particular instruction, yet does not run significantly slower.

I think the overlay surface topic is one of the things being addressed for SDL 2.0, but don't quote me on that. SDL is pretty much run under the 'dictatorship' model through Sam Latinga if that helps the discussion at all. It helps significantly that SDL is included with most Linux distributions.

If it helps any, I gave up on GGI and SVGALib (the latter being particularly abhorent - look up the joystick calibration functions if you want a lesson in how not to do it) long before Allegro.

This is the modularity that people like me advocate. My current project uses the following:

• SDL

• SDL_ttf (truetype library for SDL)

• zlib

And I'm considering libpng. The only complexity that using addon libraries has added to my code is on the commandline sent to the linker, which pulls us back to an earlier subject of this thread - that being easy to use is not the same thing as teaching people how to use their build tools.

By the way: libpng could be significantly nicer also.

Two ways of responding - one could argue that the extent to which Allegro is out of fashion due to its design as an 'all in one game programming library' is not to be underestimated, or alternately a challenge: find me one game that uses LBMs. A hint: its a graphic format. It seems to me that the ethos of an 'all in one game programming library' should not be used to justify things that simply aren't needed for games. How many people do you think actually find helpful the entirely control wrestling GUI of the present Allegro for their games?

A late thought on dictatorship - I remember around version 2.2 of Allegro, Shawn declared that he had perfectly working MOD code, but declined to incorporate it into Allegro because "it would make the code messy". To this day Allegro cannot MOD.

This is a brilliant idea. Imagine an ideal world where the developers were shadowed by the 'demo game' team, who with a direct interest in an efficient and easy to use library could provide useful empirical API and implementation feedback as library development progressed.

I agree with the majority here, Allegro has long ago been elbowed out of the market in terms of low level stuff (and was never that good at it anyway), so it should probably reposition itself as a game development library bringing the sorts of things 2d game developers want without trying to claim things like the game loop from the programmer as ClanLib does. With that aim it is perfectly acceptable that Allegro be built on top of SDL or whatever.

Some late thoughts on this. An extension of the same logic means that those working in a window shouldn't be allowed to modify the palette if a hardware palette is in use.

Alternatively, a feature of SDL appeals. It has a 'parachute' which (unless disabled) activates if your program generates an exception and releases as much as it can back to the operating system. Could we not have an Allegro parachute which, if the application crashed restored the gamma ramps to the settings they had when the application started?

An implementation of the latter would certainly defeat any argument with respect to the former about proportions of people likely to be affected.