Ok, I'd like to hear about problems, bugs and other issues people have encountered with Allegro, the reason being that I'd like to have a clear idea of what needs to be fixed for 4.2.

I'm not looking for major feature requests or suggestions like `remove the GUI from the core distribution' or `add PNG support' because that's not going to happen for 4.2. I'd like to hear about bugs, glitches, unexpected behavior, or inconsistencies in the documentation - most preferably issues with 4.1.16 rather than an earlier version.

I know about the blitting error Richard Phipps reported last week and it's already on the list of things to look into. Spellcaster's keyboard-layout detector is another example of something I'd personally like to look into.

So, even if they've been mentioned here before, please report bugs and problems!

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

This ones kind of half and half, so I'll say it anyway.

Support for an arbitrary amount of timers.

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.

How about the fourth button mouse patch for windows that I posted to the AD list on 24-Apr-03 and 4-May-04?

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.

Well, I must have missed the original discussion. Unless I participated in it and have forgotten about that as well. (Which is quite likely!)

If other OS's don't support four buttons, then I don't see how that should limit the Windows port. That's like saying because DOS doesn't support hardware acceleration, neither should Windows.

The argument that "not all people have four button mice", is not good as well. Not all people have hardware accelerated equipped machines. Not all people have sound cards, etc.

We aren't talking about additional functionality, we are talking about providing more complete support for what already is implemented.

AFAIK, the structure currently being used supports four buttons. So, we should support four buttons. We cannot support more than four, because that structure supports four. Seems quite simple...

Edit: I just browsed my archives, and saw there was indeed discussion!

And, I think all the arguments against supporting a fourth button are senseless. Let's be realistic here. A programmer knows that a fourth mouse button is not the norm. So if he decides to use it, he will do so sparingly - as a bonus. I am entirely unconvinced by the con arguments.

Maybe I'm just being cynical, but if we cannot agree to add support for a fourth mouse button, the future of A5 is dead.

But let's not let this thread become a pro/con argument for a button.

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".

Or have documented constants for the buffer lengths, that way the user can find the exact size of ther buffer, but the docs need not describe that size.

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.

Unless of course you only have the binary releases like those for borland compilers (pieces of krap with a k)

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.

I think that's a great idea.
If you only used simple primitives you could have say, pong, snake, tetris and that could let people learn as the games increase in complexity.

(Edited) I see your point. My apologies.

I agree, but please start a new thread for this. I don't want to derail this equally valuable thread on allegro problems.

Evert: Did you also note the sound configuration problems I mentioned some time ago?
[url http://www.allegro.cc/forums/view_thread.php?_id=384996]
(It ignores any setting up I do in code in favour of the allegro .cfg file, and if that doesn't exist I can't use anything but the default settings. Allegro 4.0.3)

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...

A-Demo-Hack! Getit?

Should be simple, if people can motivate themselves..

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).

Sounds great, Evert

Yes, I imagine it might be difficult to put a very good demo together in time for 4.2. But a competition sounds like a neat idea. I bet we'll wind up with quite a few great potential demos to choose from.

I'll start working on my entry, but I'm sure someone will beat me to it!

(edit) Already beaten

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

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

Good point. I'm sure everyone would agree that including the authors list should be mandatory.

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.

That would be one of the requirements, yes. Other things that come to mind are the use of a significant portion of Allegro's capabilities (the demo does a lot with rotating sprites and some blending), several update methods supported, use of a timer to regulate game speed, and not to forget: C code.
Anyway, I think this is best discussed in a new thread. I'll think on it a bit and discuss it to decide what the exact requirements would be.

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.

Here's the other patch.

Under MacOS X: I think the project template (for Xcode [I have no idea about Project Builder as I do'nt have that software) should include allegro as
#include <allegro.h>

and not

#include <Allegro/Allegro.h>

Since the former works fine, it's definitely a better idea as it supports cross compiling much better than the latter. AFAIK, Allegro installs it's headers into a general location that #include <allegro.h> will grab it properly on any system. Right?

Well I just returned to Allegro after a long period away so this is really jumping in with both feet: I'm getting an intermittent issue with an Allegro app' hanging in an odd way... the program keeps running but ignores the keyboard (can't tab out or anything, and any key being pressed at the time gets stuck as active) and although this will only occur every now and again it's a complete killer when it kicks in.

Oddly, clicking the mouse sometimes seems to restore matters, as if the focus had been lost or something. Anyway, this is with the 4.1.16. devpack via the latest DevC++ - there's a massive, massive chance that I'm doing something dumb but the "bug" being hard to replicate (the same exe will run fine one time then suffer the next) AND being seemingly present in the demo game too makes me think it worth a mention. Maybe my keyboard is just cack.

sledge, do you know if it happens with 4.1.15? There were a couple of changes to the Windows keyboard driver in 4.1.16, though I don't think they should have any effect like you're seeing.

Other people have mentioned this as well. They seemed to fix the problems by using sleep(1) to restore the input thread.

Could you try that?

They only have the latest package over at devpaks.org and I don't see 4.1.15 on the Allegro homepage. I've played enough Vigilante to know that it definitely used to work at some point though

I've tried a few fixes that I've seen suggested but had not spotted this - will give it a try, thanks (Fingers crossed!)

You can get older versions from the sourceforge page ([url http://sourceforge.net/project/showfiles.php?group_id=5665&package_id=40805])

It'd be nice if people mentioned the problem and we can try to fix it rather than work around it though (which was sortof the point of this thread).

Oops, sorry. I've never experienced it myself, just heard people talking about it.

You might get behavior like this if you acquire a bitmap but don't release it (if it's not an Allegro example program) or it might be the way your system deals with mutex locks (ie. your system lets go of and re-locks the screen bitmap lock before the input thread can be locked to get input). Tthis is an X (and DirectX?) limitation that you can't get input while you have the screen locked. Yielding in the main loop should be just as effective as rest(1) if it's not that you're failing to release the screen.

I'm pretty confident I'm locking and releasing properly as my blitting code is encapsulated in a single set of acquire/release instructions and the demo game exhibits the same problem as my pogram. So far using Sleep seems to have fixed matters (although it's obviously a bit difficult to prove that something doesn't exist so my fingers are still crossed that the problem is really gone!) but, having spent time testing different drawing methods to determine the fastest, I don't really now want to just give CPU cycles away. Can I expect either Sleep(0) or a Yield make less of a performance hit than Sleep(1)? I don't quite appreciate the distinction just yet [fumbles through docs].

Ah! If 4.1.15 is as straightforward to set up (prior to DevC++'s package system I had no confidence whatsoever that I would be able to reinstal Allegro in the event of a catastrophe and directed my attention elsewhere) I will give it a look.

Thanks everyone.

EDIT: Typo

Here's my fix for allego's windows mouse driver:

The changes:

friendly htm format
txt format

And here's the new wmouse.c file.

If you want to test it, you don't even need to recompile allegro. Just stick the new dll into the same directory as whatever you are testing and it should work. If you downloaded Clovekx's Priority: Survive, then that's a good one to test it on.

I've kept this patch as simple as possible, addressing only the main problem (messed up acceleration scaling) with the old code. So in terms of sensitivity, the mouse movement feels much as it used to.

I have, however, written a slightly more complicated patch which, in my opinion, gives even better results. For the moment I'll just give the simple patch as it's real purpose is to fix a problem, not to tweak the mouse movement to my personal taste.

That was pretty simple. Nice to see the differences highlighted so well in the htm file.

What is different with the more complicated patch?

Cool, thanks!
One thing though: could you generate a unified diff (pass -u) next time? It's generally easier to read.

I wonder if the touch-screen problem can be fixed here too? But I think that's going to be a bit more complicated..

Would it be a possibility to provide some C++ examples, that would only compile if its a C++ compiler, ofcourse. That way there could be some simple examples for handling units and other stuff in oop fashion. I'd love that sort of thing, but I know there are a few people who arent paticular for C++ very much.

So.. what do you guys think?

You can use rest(0) to yield in a cross-platform way. Yes, using rest(0) should give better performance than rest(1).. since rest(0) will only give away the CPU if something's waiting and resturn ASAP, and rest(1) will give it away regardless.

ImLeftFooted: Hasn't got anything to do with Allegro... language tutorials are, and should be, a bit beyond the scope of Allegro's examples IMO.

I would like to see the FAQ displayed in a more prominent place in the manual though - even with the updated layout it's still hidden in the middle of a lot of (for the newbie) unnecessary information under the heading of "miscellaneous". Heck, even I have problems finding the link when I'm just skimming the text, and I know where it is .
I'd like to see it moved to say, right beneath "A general introduction to Allegro"...

Automatic multiline support for the gui alert function. (as in reading \n characters instead of having to supply three strings)

Edit:

I didnt mean to suggest a language tutorial. What I'm meaning to suggest is an example program that demonstraits (a) technique(s) used commonly by game developers, but to not limit said example to C code.

Hopefully that clears up what im trying to say a little bit.

There is a C++ test/example already. Most of the examples are simple enough anyway that you making an explicit distinction between C and C++ is overkill. Things like managing units more properly belong to a tutorial or demo game.

Makes sense to me.

Yes! I actually have a custom routine that does just that (also takes a printf-style format string). Not sure why I never submitted it. Probably because the code is too ugly or gcc specific.

Yes, makes sense to me as well. The current docs layout is just the old one (the huge flat list of topics), subdivided into API, Platform specifics, Miscellaneous and Tools.

Are there any other ideas what could be re-ordered? (I think in the FAQ, DJGPP problems should be moved down to the end. They certainly aren't asked frequently. Most of the FAQ actually seems a bit outdated.)