Page 3 of 5
Re: Whatcha want in a fighting game?
Posted: Fri Oct 20, 2017 12:24 pm
by psycopathicteen
- darkstalkers felisha.png (3.06 KiB) Viewed 4663 times
You can break this up into 8x8 tiles for compression. I'll also post a "VRAM pattern table" version for a better idea of how it would fit in a ROM uncompressed.
- darkstalkers VRAM.png (4.12 KiB) Viewed 4651 times
Here is the VRAM table version.
Re: Whatcha want in a fighting game?
Posted: Fri Oct 20, 2017 7:01 pm
by zzo38
I wrote the encoder, and am now starting writing the decoder too. My initial experiment shows that it seems to be about as good as PNG (but there is something wrong with the comparison, because PNG is a whole picture format rather than a tile set format; I did compare only the IDAT chunk though; I also expect that with a larger picture and better compression settings, PNG might work better anyways, but I am not sure and it might not), although I will need to write the decoder too in order to test if it is correct, and then I will release the files (including source-codes) as public domain, and then further tests can be made and/or the program can be altered in order to make improvement.
Note: I did not use your "VRAM table version". Before you posted the VRAM table version, I wrote my own program to remove duplicate tiles instead, which I have already released (it is called "ff-uniq").
Re: Whatcha want in a fighting game?
Posted: Fri Oct 20, 2017 7:32 pm
by psycopathicteen
How many bytes is that? The sprite would take up 3kB VRAM.
Re: Whatcha want in a fighting game?
Posted: Fri Oct 20, 2017 7:46 pm
by zzo38
psycopathicteen wrote:How many bytes is that? The sprite would take up 3kB VRAM.
I got it to 1674 bytes, but that includes a 42 byte header (2 bytes give the tile size (8x8 in this case), and then there are two and a half bytes for each of 16 colours, giving the information about the five most common adjacent colours (storing additional adjacency data is worthless due to the Huffman tree used)). My calculation of storing uncompressed is 3040 bytes (1 byte for 2 pixels). These are the results with PNG format to compare:
Code: Select all
$ pngff < felisha.png | ff-strip 8 8 1 | ff-uniq 8 | ff-strip 8 8 19 | ffpng w32768 n258 | pnglist
IHDR 13
PLTE 48
IDAT 1701
IEND 0
I have started writing the decoder and will post it soon if it is working, so that we can then make more discussion of improvement and other details.
Re: Whatcha want in a fighting game?
Posted: Fri Oct 20, 2017 8:31 pm
by zzo38
Here are the programs:
This may be used to make more experiments with it, and see if any improvement might be made, etc.
Re: Whatcha want in a fighting game?
Posted: Sat Oct 21, 2017 7:00 am
by psycopathicteen
Wow, you're fast. I wish I can be that fast at programming.
Re: Whatcha want in a fighting game?
Posted: Sun Oct 22, 2017 4:38 pm
by zzo38
Allowing both horizontal compression and vertical compression does in fact help. I have also added a report mode, to display the encodings in case that helps anyone; and now ffbit/bitff can support (uncompressed) Super Nintendo format graphics too. However, I do have some other ideas too (none of which I have implemented yet, and I also don't know what will help and what doesn't help):
- Order the palette so that colours 1 to 15 are the most to least frequently adjacent to colour 0, in order to save 20 bits (two and a half bytes) in the header; but, depending on details that I do not know about both the game and the Super Nintendo, this might not be suitable.
- The type codes themself could be huffed to save a few bits, since horizontal and vertical compression seem to be much more common than uncompressed tiles (with the example data given, no tiles are uncompressed), and of course the end marker can only occur once. But it also care, the decoder intended to be used, how much it would complicate it, I suppose.
- I don't know what ratios are achieved using your old Huffman tables, although they would require a larger file header to support them.
Re: Whatcha want in a fighting game?
Posted: Wed Oct 25, 2017 7:15 am
by TOUKO
You are speaking of compression, but what you want exactly ??
On the fly decompression, or the best compression possible ??
Because i don't think that huffman is particularly well suited for on the fly decompression or graphic datas, and so why using compression today when big roms are cheap ??
Re: Whatcha want in a fighting game?
Posted: Wed Oct 25, 2017 8:22 am
by tepples
TOUKO wrote:why using compression today when big roms are cheap ??
Because big ROMs are serial, and serial ROMs are slow to access unless you run them on the 21.5 MHz master clock and have some circuit on the cart act as a shift register. Bit-banging an SPI flash would feel like "loading" on a CD system.
Re: Whatcha want in a fighting game?
Posted: Wed Oct 25, 2017 9:22 am
by TOUKO
Ah ok, it's a good reason then
Re: Whatcha want in a fighting game?
Posted: Wed Oct 25, 2017 6:29 pm
by 93143
What on earth are you talking about? There are already two SNES-specific interfaces defined for outsize ROMs. One (the MSU1) allows 4 GB of data, and the other (S-DD1) is legit official period hardware and has onboard decompression circuitry. Both can feed DMA.
You're not going to outperform the S-DD1 with a software codec, not once the bankswitching capability is accounted for. I can only think of a few reasons why one would try to do heavy-duty manual decompression on the S-CPU in the current year:
- to prove it's possible
- to avoid accusations of "cheating"
- to avoid having to source a rare, poorly understood (?) chip
- to allow the use of a different special chip that's incompatible with the S-DD1, without relying on the blatantly unhistorical MSU1
- uh... how much current does an S-DD1 draw? Can you use it with a multitap?
Am I missing anything?
Re: Whatcha want in a fighting game?
Posted: Wed Oct 25, 2017 6:55 pm
by tepples
93143 wrote:I can only think of a few reasons why one would try to do heavy-duty manual decompression on the S-CPU in the current year:
[...]
- to avoid having to source a rare, poorly understood (?) chip
There's the big one. Remaking S-DD1 or MSU1 for a production single-game cartridge might be cost prohibitive.
Re: Whatcha want in a fighting game?
Posted: Thu Oct 26, 2017 5:40 am
by TOUKO
to avoid accusations of "cheating"
The teams who's developing for the MD, don't care about this assumption .
For exemple:
Pier solar 64 MB
Paprium 64/80 MB
Overdrive 2 64 MB
it seems that all SF2 versions (exept alpha) were uncompressed,so you can easily make a good fighting game with 40/64 MB without any compression .
however:
to prove it's possible
this is a good and valid argument .
Re: Whatcha want in a fighting game?
Posted: Thu Oct 26, 2017 12:09 pm
by psycopathicteen
Sometimes I forget that not every game needs to be 100% stock hardware.
Re: Whatcha want in a fighting game?
Posted: Thu Oct 26, 2017 12:54 pm
by 93143
And sometimes I forget that the special chips aren't just there by default, especially if you plan to actually manufacture the game.
TOUKO wrote:to prove it's possible
this is a good and valid argument .
It's the only reason I'm in SNESdev in the first place. Mind you, it did turn out to be a really fun hobby...
The game I'm porting is advanced enough that I feel no shame at using the Super FX with extra CPU ROM. (And since it
is a port of somebody else's IP, mass production isn't high on my priority list.) If I were to attempt a port of Thunder Force IV, I'd try to do it with stock hardware only. Ideally SlowROM (Rendering Ranger was SlowROM), but that might be pushing it...