Skirmish Online makes more steps today through its tender infancy on the fast-track to becoming something that can be considered a game.
Today I fixed up a few remaining (minor) map bugs, which finished off the map milestone I had set. I quickly followed that with the creation of the "LID Generator", which creates one big lump of data from a large number of individual bitmaps. This not only prevents the vast majority of art-theft, but it also looks infinitely cleaner in the directory than seeing 200+ bitmap files strewn about. It's just bad housekeeping. (LID stands for "Lump of Image Data", BTW)
The sprite engine now uses std::list rather than std::vector, since I'm under the impression that std::list traversal is quicker than the vector equivalent. Time will tell. Resources -- at least the key ones -- now are neatly deallocated when they aren't needed anymore. At the moment this primarily texture data, since they're easily the biggest memory-eater in the game.
The 'Player' class is now underway! Players can now be fully drawn, based on their weapon type (unarmed, rifle, single pistol, dual pistols, or cannon), if they are in a running state or a firing state, and what colour their external armour is. All of which fully animating.
So why not make a silly demo out of it, and toss in 100 randomized soldiers on a map?
(Arrow keys to scroll!)
Download Skirmish Online v0.1 Sprite Demo
If you do give it a try, be sure to let me know what sort of framerate you're getting (displayed in the outputted Log.html file), and of course any abnormal occurances that may occur. I realize the file size of ~1.9mb might be a little daunting at such an early stage, but once the planned autopatcher is in place, updating your version will be a snap!
Additionally added today was game-update-regulation, which is a fancy compound word for ensuring that the game moves forward at the same speed irregardless of how fast the game is drawing. This is accomplished by getting the ratio of how long the frame took to render, to how long an ideal render should take (1000 / 60 = ideal 60FPS rate). With this I can run twice as many game logic updates if the player is running at 30FPS to compensate for their inferior video card ([lol]), or at half the updates if they are flying along at 120FPS. Not a vastly complex thing, but it was a huge problem before I implemented it in the last Skirmish for low-framerate players. [smile]
Up for tomorrow is player movement/control/physics, and collisions with both the map and map objects. Pixel-based detection should be a fun challenge. Afterwards I can get onto figuring out how on Earth I'll pull off movement prediction.
(And give Ravuya's latest Glow demo a go, too! [smile])
(EDIT: And Sir Sapo's!)
Here's the bottom of my log:
Now you've made me want to make a top-down shooter lol.