Graphics are a bit fill-in at the moment and you can't make out the rather nice starfield backdrop in that screenshot. The backdrop and map scroll at different rates so you get a nice impression of depth.
The small red block is currently holding the place of the player's spaceship and the green blocks are just to demonstrate that the alphablending is working okay. The blue block to the left is a static item rather than part of the map and there to confirm that static blocks seem the same as map blocks in terms of collision detection. Obviously the advantage of static blocks like that is that they are not tied to grid co-ordinates like the map cells so a combination of map cells and static blocks could be used to create quite detailed and unevenly shaped levels.
Animation is working, although only with different coloured squares at the moment. The level file contains mini-scripts of the form:
Where each pair of numbers represents a frame and a duration in 50ths of a second. The colon and the less-than just mark a loop point and jump to the loop point so cyclic animations with a header part can be constructed easily. These scripts are just compiled into std::vector
Each of the map cells can either be a single static frame or be tied to an animation channel so the background can be as animated as you want. All the details like the images, animations, map cell classes, map layout and static items are loaded from the level file, meaning nothing is really hard-coded into the program itself. Map cell classes can be defined as either solid or not and non-solid cells can be flown over.
Physics is working quite well. The ship has inertia and is controlled by the left, right and up keys. Gravity applies to the ship and to dynamic blocks and stuff can land on top of other stuff okay. Stuff optionally bounces when it hits stuff which looks quite cool.
The frame-rate independance all seems to be working fine. The animation system works like the rest of the game in that it is passed a float representing fraction of a second each frame and uses that to update its internal little programmy thing.
I'm guessing I'll need a similar system to make fade-outs and so on run at a constant speed on different frame rates but I'll worry about that when I come to it. I've tested the current program with Sleep(10), Sleep(20) and Sleep(30) in the main Cycle loop and it still seems to run at the right speed. Sleep(50) or higher pushes the frame rate above the minimum threshold (0.05), at which point the Time value is set back to 0.05 so the game starts to slow down. This means that if your PC is really slow, the game will run very slowly but the collision detection will still work.
Trouble is otherwise that if a single frame happened to take ages due to the PC doing something else in the background, it would become possible for collision detection to fail and stuff to fly through other stuff.
Without resorting to massively complicating the collision system, capping the maximum time delta that is ever fed into the engine seems like an okay solution really. Currently anything managing 20 FPS or better will stay below the threshold.
[EDIT] Replaced the block with a proper ship:
Has a cool little rotation animation when it turns and sort of bobs up and down slightly while standing. Looks okay for bad programmer art.