You can alternatively use load_bmp instead of load_bitmap and be able to drop the .bmp extension in your datafile; but again, be sure to grab the bitmap as binary data and not a BMP datafile object.

This is a slightly unusual way to load data from a datafile, as the "usual" way to to it is using the built-in Allegro datafile object types; maybe it would be better for the newbies to use those built-in types.

I prefer using the # syntax. Problem with load_datafile is that it loads all the objects into memory, and it's not very easy to open individual objects. Plus, if you use thing like PNG and Ogg and whatnot, it becomes an unnecessary burden to load them, convert them if needed, and leave them loaded when you no longer need them.

I found one prima facie error in my code, which was that I was directly comparing a floating point result of an sqrt to zero in order to avoiding a later divide by it becoming nan. Obviously you shouldn't compare floats to exact values anyway, but in any case I've changed it to test for less than 1 as I can afford to be more cutting on that front.

I've also chucked all of the game resources that are expected to survive until the end into datafiles.

Latest everything is attached. It dumps some stuff to stdout while parsing the level so that if Elias's errors persist (they are consistent with a potential result of the bug explained above) I can bug hunt more properly. Included is stdout.txt which is the output of my machine.

Please please please test this!

EDIT: have just now realised that like an idiot I have no overarching acquire/release_bitmap for my level draw! Please no nasty comments about speed for now...

EDIT2:

I'm using #. As I understand it, once you've load_datafile'd you index an array of data objects using integers that you obtain from a header file spit out by the grabber. This would mean that the game had to know about all the materials that may exist before it is run and tie art creation to programming to such a degree that I am unwilling to do it.

That's one of miran's! I'll fix it.

I was able to replicate the bug on my own machine (using a slightly different geometry) and have now properly fixed it. The problem is that edge stripping is really edge vertex stripping and a fundamental assumption of the code is that all vertices are part of at most two (collidable) edges. The error was that when a vertex was removed, both of the edges that were joined to it end up with the same start and end point - i.e. they become the same edge. But the old code wasn't succeeding in removing either. Hence it starts to look as though more than two edges meet at a vertex and things go wrong.

As I say, all solved now.

On the contrary, there is one datafile that is statically loaded in the way you would like and another that is read 'item by item' as necessary by load_bmp. Surely as an example program it is good to show both ways of doing things?

While I'm on the topic of good practice, at the minute the code has a hard coded list of allowed screen resolutions. I'm aware there is a function that returns a list of available modes but it requires an actual driver (i.e. a platform specific) to be passed rather than a dummy one. Is there any way to get a list of available drivers and if possible their attributes as far as which dummy driver they would fall into? I can see absolutely no use for the mode list function otherwise but I can't find anything in the docs.

Okay. So I'll put that on the list of Allegro features I find useless!

Attached is source that should have the problems that have been occuring recently fixed. It also has a degree of resolution indpendence but at the the minute it makes an incomplete attempt to scale the physics, as a quick fix. In particular, returning to the menu then switching resolution and continuing game usually causes the player to fall through any platform he's on and the gravity and air resistance aren't scaled. That doesn't matter because the physics won't be 'scaled' in the end - but it provided a useful way to test the edge clipping.

Allegro's lack of subpixel accuracy on scaled bitmaps is also painfully evident.

Anyway, I hope it works okay.

How's the actual game coming along? Isn't there some kind of time limit for this competition?

Whoa, whoa... what? You're not saying that Allegro 4.3 will use OpenGL as a driver... are you? . . . don't phunk with me . . .

Compiling the newest source provided by Thomas Harte:

about_menu.c:22: initializer element is not constant
about_menu.c:22: (near initialization for `menu[7].name')
about_menu.c:22: initializer element is not constant
about_menu.c:22: (near initialization for `menu[7]')
about_menu.c:23: initializer element is not constant
about_menu.c:23: (near initialization for `menu[8]')
about_menu.c:24: initializer element is not constant
about_menu.c:24: (near initialization for `menu[9]')
about_menu.c:25: initializer element is not constant
about_menu.c:25: (near initialization for `menu[10]')
about_menu.c:26: initializer element is not constant
about_menu.c:26: (near initialization for `menu[11]')
about_menu.c:27: initializer element is not constant
about_menu.c:27: (near initialization for `menu[12]')
about_menu.c:28: initializer element is not constant
about_menu.c:28: (near initialization for `menu[13]')
about_menu.c:29: initializer element is not constant
about_menu.c:29: (near initialization for `menu[14]')

The compiler (MinGW; gcc version 3.2) seems not to like allegro_id in line 22 of about_menu.c:

{ demo_text_proc, allegro_id, 0, 0, 0, 0 },

Replacing allegro_id with a string literal fixes the problem.

By the way--it's "Goodbytes," not "Goodbyte." I thank you for putting my name in the credits; hopefully I'll have something more to show for it soon

[EDIT]
Uh-oh... I fell through a wall. I attached a screenshot of where it happens... this results from just running back & forth and picking up speed - when the character reaches that point in the wall, he falls through. This is a very repeatable bug... it's not supposed to happen, is it?

[EDIT2]
It seems to happen right at the point where the track becomes fully vertical on the left side.

Sounded like a useless complaint to me.

edit: See, it may have been what some call "Constructive Criticism", but just how constructive was it? What did it accomplish? The devs KNOW we need stuff like that, but currently (as you are fully aware of), allegro's underlying system doesn't support it. The feature you want will likely be in 4.3, but who knows, it probably wont be if all we get is "constructive criticism".

read my edit, and note that I place that last quote of yours on the same level of "usefullness".

Certainly. By all means, remind us of things that need to be done. It helps keep our list of priorities straight (even if it can be annoying at times )

There's a drv->windowed flag in the gfx driver struct. Again, you need to figure out how what drivers are available.
There actually is a way to do this, but you probably shouldn't do this in a demo game as it involves some of Allegro's internals that shouldn't be exposed. It's more or less like this (code adapted from set_gfx_mode, but untested):

The modelist contains information about width, height and colour depths. The driver has a `windowed' field that indicates wether it is a windowed or fullscreen mode driver.

So it's possible to get this information, but once again, I don't recommend it for a demo game.

No, I don't think we want to expose the contents of the system driver. If we want to do this, the proper way to do it is through a documented API function - which it's too late to add to 4.2 right now.

To whom it may concern (probably Thomas ):
I've been playing around with some music... do you like the 'feel' of the 30 second clip I've attached? If I end up making some music for this thing, I don't want it to suck, so give me an honest opinion.

The melody will probably change, it's just something I threw in for now...

[EDIT] I should have mentioned, Thomas - I fall through that vertical wall even when jumping to it from the opposite wall of the half-pipe; so I pass through it regardless of how I approach it. It's as if the edge isn't even there...