Joypad stick and num button detection is borked in 4.0.3, but seems to be fixed in the later WIP versions.

Regarding documentation, I have a few issues with some entries. I'll post soon. I can't think of any bugs at the moment.

Evert, I read your post to the mailing list, today. It's exciting to see an aggressive schedule for the 4.2 release. Things are really picking up--even I can see that.

-- edit --

Okay, most of the problems I notice come from the docs, because that's where I spend my time. I've noticed a few entries that could use some discussion--minor things, mostly:

• Keyboard->key: Mention of key[0]. Kitty Cat and I talked a bit about this once (key[0], not adding a doc reference)

• Bitmap: In the current description of sub-bitmaps: "Make sure not to destroy a bitmap before all of its sub-bitmaps..." Looking at the source, it seems entirely okay to destroy a bitmap that has a sub-bitmap--as long as the bitmap being destroyed is also a sub-bitmap. Am I correct?

• Text->textout_right_ex: I would clarify "right edge" as being exclusive, not inclusive.

• Text->textprintf_ex: Merely describing the potential length limit as "extremely long" doesn't sit right with me. Checking the source, the buffer seems to be 512 chars. How about a mention of this in the docs, something like, "At the time of this writing, this limit is 512"? Or, if the limit is likely never to change, just mention 512.

• Available: Naming the example app node "Available Allegro examples" is ambiguous when the doc format references only the first word (i.e. the info viewer). "Examples Programs" would be a more appropriate title, in my opinion.

• The test app(s) output doesn't reflect the new textout_ex family. For example, allegro/tests/text.exe outputs that it tests the textout functions, when it actually uses the textout_ex functions.

I've made all these changes to my copy of Allegro, at version 4.1.15. I never submitted them because I figured it wouldn't matter much, and I'm not in an authoritative position, so it might seem annoying to submit such small changes. Anyway, that's it.

Arbitrary may be a bit too much to ask for; remember that they must all be called from a single thread. At some point, it would make more sense to use different threads than adding more timer function, I think. Still, increasing the limit may not be such a bad idea at all.

Sounds like a good idea - unless you want to repost it in june 2005?
EDIT: There was some discussion about the patch in 2003. At the time, Eric objected because of possible portability issues (it should then also work in *nix and MaxOS X, but it's not clear how). Another issue could be with mice having more than 4 buttons: we'd have to support those too, or justify why we don't. Still, I'll bump the post and see what the current ideas on the issue are.

EDIT2:

Yes, please post a patch if you can! Some of those look quite sensible.

Allegro's buildin buffer limits are deliberately not mentioned in the docs because they may change and hunting them down in the docs is a pain. At least, that's the reason I once heard for it. Might be worth bringing up again though, and of course, eliminating arbitrary limits would be even better.

I see your point. Would you say it's fair to assume that the buffer will never decrease in size? If this is the case, I think it would be worth mentioning in the docs the minimum buffer length as 512. Any sort of concrete value is better than "extremely long".

Yes, that would be the best solution. Though, all this talk has made me realize how nice it is to have source code available: Pretty much anyone can find the answer in a minute.

Is there any plan to rewrite the demo or create a new demo?

The current demo is nice but the code is really a bit too complex for most beginners to learn from. The demo.c source isn't as readable as the examples are. The source refers to the meteor sprites as "aliens".

Maybe even just a simple well-written pong game included with the Allegro distribution would help a lot of newbies. It could demonstrate the basics like blitting and screen updating and timers all in one small program so beginners can see a very basic game structure using Allegro's most essential functions. It might go a long way toward eliminating the simple questions that are asked here over and over again. I know there are some very well written games in the depot that beginners can learn from but maybe it would be helpful to include such a game with the Allegro?

Just an idea

And, yes, I would be happy to go to work on such a demo if the devs would be interested in this idea.

(Edited) I see your point. My apologies.

I guess there is now...

I am. I think this was discussed very briefly recently and I don't think anyone objected, at least not more strongly than as in `I'm not doing it'.
I do like some of the things in the current demo, so my suggestion would be to just make a new one and include both. Maybe that's too conservative though, and we can just add the current demo to the depot here as `Allegro 4 demo game' and create a new one. If you're interested in doing that, I say great! Although, it's probably a good idea to announce this on the mailinglist too.

Do you want to write a new demo game in time for the Allegro 4.2 release? If that is so, then time may be an issue...

Hmm... this could be a nice idea for a competition! Write a game that has to meet some pre-set criterial (uses only standard documented Allegro features in 4.2, no addon libraries, data not exceeding 1MB (say)) and the winner gets his game shipped with the new version of Allegro. I like this idea...

I have my Tetris game and my Asteroids game. Both are finished, engine-wise, and could be expanded a bit to demonstrate certian functionalities. Though I should probably remove the advanced stuff, like the template particle system, and infinite scrolling area (keep it to one screen). Plus I need to do actual stuff like menus and such. I could also clean up my Gem Findy game from Blitzhack, which is a good simple tilemap demo. I'll contribute them if you want.

We could have a "games" folder alongside the "examples" folder. Ask DanielH if you can steal some of the simple games off AGDN (Pac-Man, Pong).

Great idea, one that should have been done a while ago!

Of course, the new demo should also have to incorporate the AUTHORS list.

Thanks. I just posted two patches to the AD mailing list. I just realized that the buffer length of 512 was mentioned. I supposed that can be edited, if need be.

-- EDIT --

I take that back. Since one of the patches is larger than 100KB, it can't be posted there. I'm posting it here, instead. See below for the other file.

One more: nothing legally dubious.

EDIT:
From another thread: touchscreens (and tablets, I think) don't work in Windows (and probably other OSes too). There was a post about this on [AL] too, recently.