First of all: Great work done by everyone who contributed to the Demo Competition's entry.
I love it, and although I decidedly suck at playing it, that's quite ok. I think it would be a nice replacement for the current demo, but there are some issues that need to be cleaned up first. I haven't gone through the code line-by-line (yet), but below is a list of some things that will need to be done or clarified at any rate. I can and will do some of this myself (I will do the renaming part, for instance), but all of it is beyond me (especially where it concerns comments or clarification).

Code:

• strdup is not an ANSI C89 function, use Allegro's ustrdup instead.

• Use snprintf instead of sprintf throughout.

• Actually, use Allegro's unicode text functions.

• Two warnings:

• Justify why Allegro's dialog manager isn't used for the menu code. There's no need to use the standard widgets, but implementing a new dialog manager in the demo in addition to the one in Allegro seems overkill. It also doesn't properly demonstrate Allegro's functionality in the sense that there is already a dialog manager there.

Cosmetic:

• Indentation is three spaces. Replace all tabs used for a single indentation level with three spaces. This must be done manually because a tab also replaces eight spaces at deeper indentation levels. A clever regular expression can probably take care of this (replace all tabs followed by a non-white character with three spaces).

• Rename functions and variables to use lower_case_and_underscores instead of MixedCaps. Can easily use sed to do this.

• Always declare functions with an argument list, or (void). Never ().

• Be consistent in declaring functions in headerfiles with the extern keyword or without. Prepend all function declarations in headerfiles with an explicit extern.

• There are inconsistencies in indenting for some defines as well: between the #define keyword and the symbol there should be just one space.

• Put #include <> lines before #include "" lines, or at least don't mix them!

Technical:

• Is there a reason to store some bitmaps as binary data in the datafile rather

• About the datafile - either strip the origin property, or store it as a

• Would it be possible to use a config file other than allegro.cfg for the demo settings and call set_config_file() after Allegro's drivers have been initialised? This is probably minor, but the presence of a fresh allegro.cfg causes Allegro to ignore the one in my home directory, which means that I don't get MIDI sound during the game if I start it a second time. This is arguably an issue with Allegro itself rather than the demo, so mark it as a `nice to have' feature rather than a requirement.

Gameplay:

• I don't care if you can set default keybindings by distributing a config file with the demo: there needs to be a default fallback in case no config file is present. This isn't even difficult, just add it as the default parameter to get_config_int.

Commenting:

• There is insufficient commenting in the code, even if it is fairly self-documenting in many cases. For instance: what is demo_textprintf()? Why is it there? What does it do? Functions should be preceded by a line or two of comments that describe their function, large chunks of code should have a descriptive comment too.

Again, great work by everyone, but it needs a bit more before it can be put up as the Allegro Demo Game. Please don't be put off by these requests, even if they seem daunting.

I've attached the latest version Thomas posted on the forum, with a few minor warnings already fixed. These include: DOS <---> UNIX line ending conversions and indent cleanup (using the indent.pro file that comes with Allegro). I don't know what is easier, that anyone who makes a change from this point onward simply attaches the full source to his or her post and the next person starts from that, or submitting patches.

These technical issues aside, gameplay tests and bughunting is of course still welcome! We've had some of that already and most of them have probably been fixed already (I hope...)

That's true, but I don't think we should put it in right now, if we want to do RC1 tomorrow (oh damn, yet another thing I need to do ).
I would also like to have a closer look at the file naming and splitup to make sure it's ok.

That said, I think we can open up a seperate CVS module for it. We can close it down again when the work is done.

Yes. They all have individual associated palettes. Allegro remains in a single member minority with respect to this sort of thing as it doesn't associate palettes with bitmaps. This is, in my opinion, the cleanest solution to that.

Of course, it doesn't fully alleviate the problem, hence the death of the planned 8bpp mode. If I'm in 8bpp mode with a particular palette set then load_bmp (for example) has the following behaviour:

- if the bitmap being loaded is 8bpp, silently do no colour mapping
- otherwise map the bitmap to the current palette

And I just didn't have the energy to write a work around and then justify it in commenting. In particular, I couldn't think of one that wouldn't cause the screen to flash unsightly colours if I loaded a bitmap during play. But perhaps I'm not entirely up on Allegro's colour conversion stuff.

This design decision also has the benefit of showing off more Allegro functionality, which surely is a substantial part of a demo project.

I haven't attempted to fully understand Miran's code and as a result haven't commented any of it. Anything to do with menus or the framework is his and I'm not in a much better position than anyone else to figure it out so in the absence of him CVS makes even more sense.

Of course, it's all very nice to be able to pass the buck like that, but I haven't even fully commented my code yet!

It also still needs to count ASCII text file lines from 1, not 0, and to draw edges defined from right to left (i.e. downward facing) correctly! Both of which are 2 minute fixes, but...

There's something wrong with the title font palette. Did no one notice this before?

As for commenting my framework code, I'm really supposed to be doing something else right now, but since I've already thrown weeks away, one more day won't hurt. I'll see what I can do...

Oh and about not using Allegro's dialog manager, I don't know, I suppose I could have used it but, I thought writing my own would be a lot easier, especially since I had done it many times before. Also the last time I attempted to use Allegro's GUI I had a lot problems getting it to do something useful. Although that was years ago. Anyway, what's done is done, there's no way back now...

EDIT: Another thing I noticed is that at the smallest resolution (640x480) the about box doesn't quite fit on the screen. Also when switching between resolutions only the graphics should be reloaded so that the music doesn't restart every time you change something in the gfx settings...

Attached are fixed aboutmnu.c and credits.c

The bitmaps are stored paletted to conserve space. It was found that each individual bitmap looked fine with a 256 colour palette, so this works to reduce data size. If they all have the same palette then they look a little more ugly, which is fine as an option for those with low spec systems but cannot be justified in this context because it would make all colour depths look like 8bpp and as a result make the game look uglier for those with a perfectly decent 15/16/24/32bpp frame rate.

That's cool. I didn't really mean to drag the discussion off topic, I'm just no longer a regular Allegro user and I was hoping to explain why the solution I chose isn't Allegro-optimal with comments about "minority of one".

My problem with the behaviour you expect is that it means for users of 8bpp mode, load_bmp operates quite differently depending on the bit depth of your bitmaps. So your code has to know in advance (with which Allegro won't help) which type it is loading, or else to jump through hoops and invoke a colour conversion three times for non-8bpp images in order to allow for the possibility.

Or, to put it in other terms, either 8bpp mode becomes harder to support for bitmap based programs which want to support better looking 15+bpp modes, or else file sizes have to needlessly grow across the board.

I was not aware of that function, so clearly my manual reading skills are at fault here. On an unrelated topic arising from my first reading of select_palette, do the docs really need to describe it as an "ugly hack" and imply that if you're looking at it then you must be dealing with some sort of "dodgy situation"? I'm not really sure the manual should be quite so judgmental about my coding...

It's extremly well done and fun, excellent work, everyone!

Comments: I got stuck in the 'w' of 'Shawn' there's something tricky about the movement in such situations. Oh, and I really hope the cloud sprites are changed.

In which case we'll need non-anti-aliased sprites (or aliased sprites if you prefer) if Allegro still doesn't do alpha transparency. At the minute the clouds are predrawn to that background colour and stretch_blit'd. Which is also why they are a little sparse and never overlap!

In the strict sense they're anti-aliased. The intention is to provide different pixels with apparently different 'depths'. In clouds the 'depth' of the cloud makes it darker or lighter and very thin depths don't fully remove the colour of whatever is behind. Allegro has (to my knowledge) no true alpha channel support, so in order to do this the edges are pre-blended with the background colour. This is anti-aliasing as if it wasn't done then the cloud edges would blend to a different colour, causing them to assume the alias of something other than clouds.

Allegro supports 32 bit RGBA images. It's all done in software and I think you need to enable the alpha blender (with set_alpha_blender), but it works fine as far as I know.

Allegro's source uses a screwed up (IMHO) formatting where indentation is 8 spaces, but eight successive spaces are stored on disk as one tab character. Apparently, Shawn prefered it that way. It confuses the hell out of some editors and in any case it requires some manual intervention in many cases.
It was never changed en-mass to all-space indentation because doing that would break the CVS history. New indentations are (supposedly) all spaces, with 3 space indentation per level.

I'm not sure we actually support RGBA textures.. I somehow remember a patch about it from long ago, but the docs don't seem to indicate any mode which can use RGBA. It would be trivial to add though I guess.

It doesn't display like that on my machine. It looks like this:

http://imageheap.com/theheap/32696676.png

Although I continue to have a mouse cursor on top. I did try to switch it off, but was apparently unable.

I get the same thing as miran on my Mac Mini.