Anyway, what have I done today. Work, obviously, but I'll get raped if I talk about that. There's some stuff I can talk about though. The Nintendo DS cartridges we have are 4 kilo-bit. I thought "Oh, that's fine." But wait, 4 kilo-bit is 512 bytes. Hmm.
We have to store around 210 bytes of data for or racing game, and that's just for the players progress, not for replays. I've already been bit-stuffing my ass off for 2 days over this. Anyway, Fudgepacker to the rescue. Our engine half-has support for zlib (It can read but not write as far as I know), and so does fudgepacker. So I wrote a utility during my lunch break (took 10 mins) to take a bunch of hex digits from our debug spew (That I coded to represent our replay data) and convert that to binary data. That data then represents what would be stored on the cartridge (The DS devkit can't write to a file on the PC as far as I know, so the debug output is the best PC-savable-output I have). One of the nice things about fudgepacker is it tells you the actual size of the file it compressed, which doesn't include the header to let you unpack the file. If you just want to compress an arbitrary chunk of data you only need to store the compressed data itself and the uncompressed length (zlib may let you just keep appending, but that's ugly and horrible).
Anyway, the point in this, is it lets me see what size the data would be if it was compressed. The results: 192 bytes of replay data compressed to 78% original size normally. After fucking about with the data (Re-ordering bytes, essentially), it now manages 34%. Which isn't half bad. But it's still only enough to semi-reliably store the game state + 1 replay on the cartridge. Let's just hope we get more than a 4KB cartidge (I don't know or care if that's supposed to be a lower-case 'b', you know what I mean).
In other news, the code for my MMORPG client is comming along nicely. The "engine" (I say that in quotes because there's no real seperation between the two yet) now supports three primitive types:
The tilemaps are implemented as before, using tile sheets and all that crap. I'm halway through writing another version of that object that uses ID3DXSprite's for rendering, but passing the tile sheet crap off to a manager class (Which will be handy in other places anyway), so I'll profile to see which is better. By "Profile", I mean throw a bunch of them onscreen and see which gives a higher FPS. "Accurate and sophisticated" is my middle name(s). I want to support layered maps, so I can do paralax scrolling. Because it's cool and retro.
Two main classes I need to do next are the sound manager (The code was converted / cleaned up slightly, and still works, but could be better) and input manager (Which will practically have sex with my window class to extract vital information [WM_KEYDOWN / WM_KEYUP messages] from it). Once they're done, I'm a happy Steve.
And just to brighten this up a little, a screenshot of the code in it's current state, along with the full code for this state:
// SplashScreen.cpp - Splash screen state
CSplashScreen::CSplashScreen() : CBaseState(STATE_SplashScreen)
m_pSprite = new SOSprite("Admiral Spritey", "Data/Test/Alpha.dds");
m_pMap = new SOMap("Zomg, map!", "Data/Maps/Map0000.map");
m_pSprite2 = new SOSprite("Admiral Spritey II", "Data/Test/Alpha.dds");
m_pAlphaSprite = new SOAlphaSprite("Captain Alpha", "Data/Test/Alpha.dds");
m_pAlphaSprite2 = new SOAlphaSprite("Captain Alpha II", "Data/Test/Alpha.dds");
m_pSprite = NULL;
m_pSprite2 = NULL;
m_pAlphaSprite = NULL;
m_pAlphaSprite2 = NULL;
m_pMap = NULL;
Ok, bed for me I think...