efence found one buffer overrun for TanTable.. the very last element may get referenced in Game.c:215 (SCREEN_H << 2), but the malloc only allocates (SCREEN_H << 2) slots.. so the last one is not allocated.

Valgrind said the below, but it seems to be false alarms. Posting here anyway, but I couldn't see much wrong on any of the locations.

==17405== Use of uninitialised value of size 4
==17405==    at 0x80629BE: InitEdge (Level.c:329)
==17405==    by 0x8063592: LoadTriangles (Level.c:648)
==17405==    by 0x8063E2F: LoadLevel (Level.c:901)
==17405==    by 0x805F54C: LoadResources (Game.c:93)
==17405==    by 0x805F95A: GameInit (Game.c:164)
==17405==    by 0x805F243: run (framework.c:192)
==17405==    by 0x805E83E: main (demo.c:9)
==17405==
==17405== Conditional jump or move depends on uninitialised value(s)
==17405==    at 0x805FD3A: GameDraw (Game.c:216)
==17405==    by 0x8068C1B: create_transition (transition.c:22)
==17405==    by 0x805F27F: run (framework.c:193)
==17405==    by 0x805E83E: main (demo.c:9)
==17405==
==17405== Conditional jump or move depends on uninitialised value(s)
==17405==    at 0x8068168: DrawQuadTreePart (QuadTree.c:541)
==17405==    by 0x806828C: BeginQuadTreeDraw (QuadTree.c:584)
==17405==    by 0x806210E: DrawLevelBackground (Level.c:28)
==17405==    by 0x805FFA3: GameDraw (Game.c:250)
==17405==    by 0x8068C1B: create_transition (transition.c:22)
==17405==    by 0x805F27F: run (framework.c:193)
==17405==    by 0x805E83E: main (demo.c:9)
==17405==
==17405== Use of uninitialised value of size 4
==17405==    at 0x805CD30: AdvanceAnimation (Animation.c:12)
==17405==    by 0x8067109: RunPhysics (Physics.c:278)
==17405==    by 0x8060726: GameUpdate (Game.c:380)
==17405==    by 0x805F17A: run (framework.c:180)
==17405==    by 0x805E83E: main (demo.c:9)
==17405==
==17405== Conditional jump or move depends on uninitialised value(s)
==17405==    at 0x805FD3A: GameDraw (Game.c:216)
==17405==    by 0x805EF58: draw (framework.c:125)
==17405==    by 0x805F2EF: run (framework.c:212)
==17405==    by 0x805E83E: main (demo.c:9)
==17405==
==17405== Conditional jump or move depends on uninitialised value(s)
==17405==    at 0x805FD51: GameDraw (Game.c:216)
==17405==    by 0x805EF58: draw (framework.c:125)
==17405==    by 0x805F2EF: run (framework.c:212)
==17405==    by 0x805E83E: main (demo.c:9)
==17405==
==17405== Conditional jump or move depends on uninitialised value(s)
==17405==    at 0x805FD3A: GameDraw (Game.c:216)
==17405==    by 0x8068B7C: create_transition (transition.c:14)
==17405==    by 0x805F27F: run (framework.c:193)
==17405==    by 0x805E83E: main (demo.c:9)
==17405==
==17405== Conditional jump or move depends on uninitialised value(s)
==17405==    at 0x805FD51: GameDraw (Game.c:216)
==17405==    by 0x8068B7C: create_transition (transition.c:14)
==17405==    by 0x805F27F: run (framework.c:193)
==17405==    by 0x805E83E: main (demo.c:9)

And lastly, my fortify-like debug library said this, probably false alarms as well: [Edit: yes, they are]

Oh, and I added some stuff to the level, it's attached.

Any chance someone could attach a windows EXE and the relevant allegro DLL so I can see the latest version working?

I'm going on holiday by the end of the week. So for me, it will barely make a difference if you're a few days late. Given the amount of work already done, it'd be a shame to not use the new demo!

That's ok, we can do stress-tests before packaging up 4.2 release.
I haven't really looked at the code at all yet myself. Just make sure you're prepared for all sorts of questions and requests. As I said before, I'll probably do a massive sed session to rename things to follow Allegro's naming convention and pass it through indent to fix formatting issues at least.

About two weeks late for that
But yeah, please do!

Would a sleep(1) help here?

Yes, I know, so can't compare it to things like Doom3 where the gfxcard does that work (and therefore uses less main CPU than the Allegro Demo ). But, reducing the default update rate to let's say 60 should make this somewhat nicer.

I could make the platforms more slippery. But when I made the hills slippery (first the one above all were ice), you don't get up any slopes. (And due to the new air friction, you can't build up much speed by rolling/sliding downwards anymore, it seems.)

I agree - but then, it's a matter of running indent and some small sed/perl/python scripts over the code. So no problem if you keep your preferred style for now, and let the work of conversion to someone committing it to CVS (I guess I just volunteered ).

Thanks to Matthew Leverton I just played the demo. Looks great and plays really nice too! Well done everyone, I'm impressed with the game!

No, I mean like 'functions are named_like_this in order to follow the Allegro API definitions'. I don't want to explicitly distance myself or suggest that they were changed by someone else. 'Disclaim' was clearly a very poor choice of word. It really isn't any different to one comment I've already written which says something along the lines of 'all variables are declared in a block up here because Allegro is written in C89, please ignore this and look for descriptions of used variables where they crop up'. And I assume that sort of comment won't be frowned upon?

I've just tweaked it a little to make it 'harder' so that in more places you are required to use the preceeding down slope to build enough momentum for an up slope and if you fail to use the down slope properly the first time on the loop onto the platforms the first time you pass the exit then you actually have to do a little back and forth momentum building to get up - which is relatively hard but not impossible. It took me four or five shots.

I also just figured out how to get onto the "Shawn Hargreaves" text and fell through his 'w'. So perhaps more bug testing is required. I intend to fix the flickery nature of the main sprite and the gamepad controller dialogue (which has a habit of writing text over the edge of its box) then hopefully get some binaries together and put it out for wider testing simultaneously to the big code clean up and document.

EDIT:

Thanks. I had a search for these but couldn't think of an automatic way to find them so was just reading myself (in XCode 2.1, which sits upon gcc 4.x). Obviously I missed most of them!

Sounds good. I couldn't really get it to enable the momentum building. If I make high friction (e.g. 1.0, like now), you can't build up much momentum. If I make it less, then you don't get back up anywhere. Can't wait to play the tweaked version, mine was too easy I guess.

Heh. There are actually two ways. One is, if you jump up just before the top of the hill to the left, and gave enough momentum, you will jump over all of the "Allegro" and land somewhere on "Shawn". The other way obviously is top fall through from above.

I also noticed that you can fall through, but that may be a problem in the mesh. Blender likes to degenerate faces.. I'll do a manual check for such faces.

Oh, and when you said "tweaked" above, do you mean, you actually got Blender to load it - or just the friction values in the .txt?

[Edit: Oh, and this thread catapulted me over the 1000 posts mark.. not sure this is good or bad..]

Heh, ok. Unfortunately, Blender simply is confusing at first. I had played with it a few times in the past, but never could really do anything with it. After creating this level, it's the first time I start feeling somewhat confident while using it. Just what I had hoped for

Anyway, I'll make sure to update the .blend file accordingly to your changes, in case there will be any suggestions about the level geometry and therefore I'll modify it again.