Monthly Archives: August 2012
Just a bit more of the character bases I’ve been messing with. Standing pose looks okay so far, but the walking frames are giving me a headache.
**Edit: Also, hair. I like the two styles I’ve come up with for the female bases, but the male hairstyles are kinda.. not good. Especially the darker-complexion male base – the hairstyle shown here doesn’t work at all on him.
**Edit: Progress animation – stand, walk, and crouch put together. Still needs work (crouch especially), but getting closer to usable.
I fired up Bits & Bots the other day with ‘top’ running in a console, and holy crap, it uses a LOT more CPU than should be necessary. Ran some random tests on it, and found that CPU usage drops significantly on the title screen when I hold Space or S to hide the scrolling background layers.
So, looks like my background rendering is pretty craptastic. It’s written in a pretty brute-force manner: render every tile, every frame, which is stunningly inefficient when you think about it. 40×30 tiles per layer, times up to 4 layers, is potentially 4800 operations per frame (and that’s JUST for the backgrounds). Factor in text operations, which are written the same way (render every character separately, every frame), and you’ve got huge overhead for what should be a relatively simple scene.
How do we fix this? The best way I’ve seen so far is to use OpenGL Framebuffers to render a chunk of background to a texture, then blit the texture all at once rather than each tile piecemeal. To reduce how often it composes the background chunk, I would likely crib off the old DS version of the engine and load a section of background 2×2 screens in size, centered on the camera; the camera could then pan up to 1/2 a screen in any direction before it leaves the loaded area, at which point the engine would render another 2×2 screens centered on the camera.
This is probably the best way to attack the text rendering as well, though it’d need to be slightly altered – you’d need to be able to update the rendered string, and if the new value’s rendered size exceeds the size of the allocated texture, you’d need to release and reallocate it. Shouldn’t be too hard – I already have all the math worked out for the backgrounds in the DS code, since you could ONLY load a 4-screen chunk into the BKG VRAM at once.
Biggest drawback? Large textures – I’d need to allocate a 1024×512 texture per background layer. That’s not large by modern standards, but it’s larger than my current self-imposed 64×64 limit per texture. Time to ditch some old habits, I guess.
..Really, I should be working on pixelart for the next project, but if dicking around with rendering is what it takes to get me motivated again, so be it.
**Edit: Also, WIP pixel art: