Weird topic will everyone says. Since a lot of people brings topics back those days for some reason, I'll too.
I finished completely the game engine for my curent project, only design "data" part is left (exept code to move enemies, which is proper to enemies themselves). I only use about half of BSS RAM and 2/3 of zero-page RAM for now, and I find it's a shame to not use it to its full potential.
I guess I'd do anything to save ROM since I have about 16k of code and a couple of k for data right now, I'd like to have as much data fit the remaining 16k (I'll design the game in those limit tough). I guess I'd like to copress something or something like this, so that less bytes of ROM and more bytes of RAM are used. I don't have any idea yet, all my maps are RLE compressed and are decompressed in RAM already. All objects have a ton of variables at their disposal (most of time not all of them are used), and are done in an object-oriented fashion.
Something that takes an insane amount of ROM space are sprite definitions, where 3 bytes are needed per sprite per animation frame for each enemy, plus pointers that goes with it. I haven't any idea to improve here without adding drastical limits to the sprites themselves, which I want to avoid.
Of course I'd still leave some room for what is up to come (cutscenes, etc...), but I'd like to have a way to use all this free RAM efficiently, cause only $200-$580 and $00-$90 are used right now. This leaves $90-$1df and $580-$7ff to be used for other/better use.
Ideas to "Waste" RAM
Moderator: Moderators
Yeah, if you are able to put in RAM something that would normally be decompressed in the ROM, you gain some space by storing it compressed.
Well, to really maximize the extra space you get I'd suggest you use something slightly better than RLE. It's possible to make a very simple implementation of LZ compression, that makes use of repeating patterns as well as repeating bytes, so I imagine you'd gain a lot from that.
I don't think you should be afraid to decompress LZ data to VRAM (if that's even what you are doing), because you could very well use all that RAM you have to spare as a sort of buffer.
In fact, that's a good use for the RAM. You can use it as a decompression buffer for more robust compression schemes.
I don't know what else you could compress because I don't know much about your engine (I remember you show one screen at a time, but don't know anything about the inner workings). Maybe metatiles or collision maps, if you have any of that stuff.
Other things like object definitions and sprite mappings don't compress very well, because you simply don't place the same object in the same position, or use the same sprites in the same positions.
Well, to really maximize the extra space you get I'd suggest you use something slightly better than RLE. It's possible to make a very simple implementation of LZ compression, that makes use of repeating patterns as well as repeating bytes, so I imagine you'd gain a lot from that.
I don't think you should be afraid to decompress LZ data to VRAM (if that's even what you are doing), because you could very well use all that RAM you have to spare as a sort of buffer.
In fact, that's a good use for the RAM. You can use it as a decompression buffer for more robust compression schemes.
I don't know what else you could compress because I don't know much about your engine (I remember you show one screen at a time, but don't know anything about the inner workings). Maybe metatiles or collision maps, if you have any of that stuff.
Other things like object definitions and sprite mappings don't compress very well, because you simply don't place the same object in the same position, or use the same sprites in the same positions.
In fact you're a bit right, I'm not planning to do any drastical changes to my engine, nor to make a lot of things more complicated or anything, beacause I want to progress on the game itself too.So you want ideas to make use of all the RAM available. One drawback of doing this is that adding new features which need RAM will be harder. If your engine runs at a reasonable speed and is easy to use, why make it use more RAM than it has to?
As tepples said, however, since ROM is rather limited if you don't use PRG bankswitching, I'd like to make the best use of it. If I really couldn't finish my game beyong CNROM boundaries I could make it MHROM and add 64KB PRG, but I don't think I'll do this anyway. I'll design the game to be beyond 32KB limits, and that should be okay in my calculation, however compressing a thing or two could make it take less space, allowing me for longer levels, more music, or something like this.
In fact I alrady use every bit I could in all my data storage forms, so I don't think any will compress well easily. The only thing I leave uncompressed for now is textes, but there won't be many of them anyway. I could easily find someway to compress them if I would because only 26 letters are available, so using 8-bit on each of them is a waste.
What really takes space is data for enemy sprites, I don't know much how to compress it tough. As I said I use 3 bytes, one for attributes, and two for relative position. I also implemented a programm that can make consecutive horizontal sprites see as a single one, so that this reduce the number of sprites needed. Since most objects have sprites for all 4 directions, this quickly wastes a lot of space, but in the counterpart I won't have that many different enemies due to limited CHRROM so even if this is ineficient data, there isn't a lot of them.
For now I only use compressed format that "the human can understand", I don't do any automated compression, because I have currently no experience in doing this (I could still attempt to do it).
I guess I could compress the music too, but here I use every bit I can in a pratical way, so I should use a type of automated compression if I want to go further. Unless I try general-puropse algorithms, I won't be able to do any better where. If anyone has any experience using general-purpose compression (that the human cannot understand easily, unlike RLE or basic stuff) or knows any awesome turorials to this, please let me know. Of course I find things by googleing, but most of the stuff they say are made for more advanced computers than the NES. 6502.org has some awesome source code when it does to do complicated-general-purpose things, but not for compression.
I really remember Memblers saying "You can save a lot of ROM by using a little RAM to good usage", and this has given me some serious troughts. I'm not sure what exactly he was meaning here.
LZ77 compression seems really weird to me, as it will refer to backwards data in RAM. I guess I understand the thing, but I don't see why it would work in fact. Also it would seems that it would need a really big array of RAM, most stuff I can find on the net talk about 16k or 64k when I just want to use about 512 bytes to good usage.
EDIT : Last thing that I'm pretty sure that could be permanently compressed quite well is simply code... Since a lot of opcode (such as lda, sta, asl A, lsr A) comes REALLY often, I guess this would compress well, but that would be quite impratical to have to decompress a routine before calling it.... Actually that'd be a fun thing to do, but the time lost to do this is certainly not worth the ROM space given. That would do pseudo-mini-PRG bankswitching... Load routine, then execute it (instead of just execute as usual). Also, I'm searching the net more seriously for compression algorithm, I may find something really usefull eventually with some patience. This may look rather interesting.