For my remake of BatteryCheck the tileset that makes up the entire level is almost exactly 1024 with a few of the higher "slots" either unused or reserved for animated tiles. Just to keep things simple I made the texture 1024x1024 pixels and never looked at it again since it works perfectly on Linux, Wii/GC, 3DS and the Rpi (although that is basically just Linux). Working on the DS(i) and PSP now makes this more difficult as they only support textures of max 512x512 pixels.
Again because it was easier the level object like the recharge gate, conveyor belts, elevator, battery holders, Freddy the dragon, etc....were also a single 1024x1024 pixel texture! The same thing applies to the player animations of which there are A LOT....about 600 individual sprites for our little hero batteryman!! Ofcourse some are special animations that are triggered by some kind of event and I think there are even a few that are not even part of the actual original game! I have finished it many years ago and do not remember some of them....but who knows if I have seen every route in the game and I should probably need to play through it again some day
Luckily during the normal walking, jumping and other crazy stuff he can do....like doing a moonwalk dance! I am serious!!! When you do nothing in the game for a bout 2-5 seconds he starts doing random actions and animations of which one is the moonwalk and he even makes a shout while doing it.
. But the player's animations are not the ones I see the most potential for VRAM savings in. It's actually the friendly Freddy the dragon where you can turn in your used batteries that takes up a lot of space!
The same method could be applied to the convyors, blue/green "doors", purple stampers etc...for similar savings in VRAM. Maybe this sounds like "early or unnecessary optimization" but consider I am now working on devices with restricted VRAM: PSP 2MB and DS(i) with only 656kb! I don't even want to think about the GBA anymore just yet with it's tiny 96kb of VRAM, hahaha
The second way to optimise VRAM usage I was thinking of is putting every object into it's own texture and maybe only the "stationary" resting position of the door's/stamper's so those can be loaded quickly and when the animation needs to be run that specific texture needs to be loaded. But than I can at least make the average VRAM usage much lower than keeping everything in a single huge texture.
The above is not what I have done yet by the way....it's an idea and I just wanted to write it down and do some calculations to see if it was worth the extra complexity. I think it is but it won't be an easy thing to keep track of what's in VRAM and what needs to be replaced all the time though. First thing is getting the tiles for the level into smaller textures though so I can enable it on the PSP and hopefully the DSi too. Neither of these ports are stable yet so a release might be weeks or even months away
I am not sure how long it's going to take but looking at what's already working in the PSP emulator I think when preview v0.4 get's released it will be included! The main thing I also want in v0.4 is background music on the Wii and GameCube which requires porting libmikmod and writing a driver for it. I am really doing far to much at once now I think of it ....but at least it keeps me busy and entertained I guess.
Thanks again.
Again because it was easier the level object like the recharge gate, conveyor belts, elevator, battery holders, Freddy the dragon, etc....were also a single 1024x1024 pixel texture! The same thing applies to the player animations of which there are A LOT....about 600 individual sprites for our little hero batteryman!! Ofcourse some are special animations that are triggered by some kind of event and I think there are even a few that are not even part of the actual original game! I have finished it many years ago and do not remember some of them....but who knows if I have seen every route in the game and I should probably need to play through it again some day
Luckily during the normal walking, jumping and other crazy stuff he can do....like doing a moonwalk dance! I am serious!!! When you do nothing in the game for a bout 2-5 seconds he starts doing random actions and animations of which one is the moonwalk and he even makes a shout while doing it.
. But the player's animations are not the ones I see the most potential for VRAM savings in. It's actually the friendly Freddy the dragon where you can turn in your used batteries that takes up a lot of space!Why they have chosen a dragon for this I have no idea....but he is part of the game so he will have to stay in there! He has 9 sprites that are close to 150x114 pixels each! I can fit that in a 512x512 pixel texture but I kept looking at it for some reason.....they are nearly 90% the exact same image in every frame!!!!! 
The only thing that really moves is his right arm pointing at the battery box to indicate you can recycle your batteries there. For every 3 empty ones you get 1 full battery in return. Nice of him right?
The first thing to reduce the footprint of Freddy is to store his battery bin only once which saves 46 pixels in width for each frame of animation already! Then it's his arm that only moves in a region that is smaller than 50x50 pixels....except for when you have recycled your batteries his head tilts a little to the right in two frames and his tail looks different. I really wish I had the guts to just post the images to show exactly what I mean....but the legal stuff about the rights and permissions of the graphics bugs me!! Hopefully those who have played the original or one of my previews already know how Freddy looks....and what he does in the original game.
My point is that Freddy's body does not move at all during all frames except two...but that's just his tale that is a bit different. I doubt it's noticeable but I am going for 100% replica so it needs to be in there...but how I reproduce that image and animation does not have to be the exact same as the original game ofcourse. My idea is to store is to store the battery bin and his body only a single time. Then for the animated frames I only need 50x50 pixels for his arm movement...and maybe two slightly larger ones for his tilted head. And the changed tail is just 32x64 pixels. It will make drawing him a bit more complex than just drawing a new single image ofcourse, but I was already planning on making every "event object" a class that handles everything for that object. And since every object needs to keep track of the animation state and initiate the drawing commands anyway it should not matter much that it needs to draw one or two overlayed images using this method.
In most cases an image with an indexed palette and a size of 512x512 pixels takes up 256kb of VRAM. Using the method described for Freddy all of his animations should fit into a 256x256 pixel image and that is only 64kb in size! That is 75% of savings in VRAM usage without losing any details or quality of the animation frames!!! And since in the first level there are only three actual places where you run into Freddy there is no reason he should be included in the main textures anyway. Only when the player is near him he needs to be loaded into VRAM again to be animated with his own small texture
The only thing that really moves is his right arm pointing at the battery box to indicate you can recycle your batteries there. For every 3 empty ones you get 1 full battery in return. Nice of him right? The first thing to reduce the footprint of Freddy is to store his battery bin only once which saves 46 pixels in width for each frame of animation already! Then it's his arm that only moves in a region that is smaller than 50x50 pixels....except for when you have recycled your batteries his head tilts a little to the right in two frames and his tail looks different. I really wish I had the guts to just post the images to show exactly what I mean....but the legal stuff about the rights and permissions of the graphics bugs me!! Hopefully those who have played the original or one of my previews already know how Freddy looks....and what he does in the original game.
My point is that Freddy's body does not move at all during all frames except two...but that's just his tale that is a bit different. I doubt it's noticeable but I am going for 100% replica so it needs to be in there
...but how I reproduce that image and animation does not have to be the exact same as the original game ofcourse. My idea is to store is to store the battery bin and his body only a single time. Then for the animated frames I only need 50x50 pixels for his arm movement...and maybe two slightly larger ones for his tilted head. And the changed tail is just 32x64 pixels. It will make drawing him a bit more complex than just drawing a new single image ofcourse, but I was already planning on making every "event object" a class that handles everything for that object. And since every object needs to keep track of the animation state and initiate the drawing commands anyway it should not matter much that it needs to draw one or two overlayed images using this method.In most cases an image with an indexed palette and a size of 512x512 pixels takes up 256kb of VRAM. Using the method described for Freddy all of his animations should fit into a 256x256 pixel image and that is only 64kb in size! That is 75% of savings in VRAM usage without losing any details or quality of the animation frames!!! And since in the first level there are only three actual places where you run into Freddy there is no reason he should be included in the main textures anyway. Only when the player is near him he needs to be loaded into VRAM again to be animated with his own small texture
The same method could be applied to the convyors, blue/green "doors", purple stampers etc...for similar savings in VRAM. Maybe this sounds like "early or unnecessary optimization" but consider I am now working on devices with restricted VRAM: PSP 2MB and DS(i) with only 656kb! I don't even want to think about the GBA anymore just yet with it's tiny 96kb of VRAM, hahaha
The second way to optimise VRAM usage I was thinking of is putting every object into it's own texture and maybe only the "stationary" resting position of the door's/stamper's so those can be loaded quickly and when the animation needs to be run that specific texture needs to be loaded. But than I can at least make the average VRAM usage much lower than keeping everything in a single huge texture.
The above is not what I have done yet by the way....it's an idea and I just wanted to write it down and do some calculations to see if it was worth the extra complexity. I think it is but it won't be an easy thing to keep track of what's in VRAM and what needs to be replaced all the time though. First thing is getting the tiles for the level into smaller textures though so I can enable it on the PSP and hopefully the DSi too. Neither of these ports are stable yet so a release might be weeks or even months away
I am not sure how long it's going to take but looking at what's already working in the PSP emulator I think when preview v0.4 get's released it will be included!
The main thing I also want in v0.4 is background music on the Wii and GameCube which requires porting libmikmod and writing a driver for it. I am really doing far to much at once now I think of it ....but at least it keeps me busy and entertained I guess. Thanks again.
