It is currently Fri Nov 24, 2017 9:59 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 59 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Fri Oct 20, 2017 12:24 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2370
Attachment:
darkstalkers felisha.png
darkstalkers felisha.png [ 3.06 KiB | Viewed 543 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.

Attachment:
darkstalkers VRAM.png
darkstalkers VRAM.png [ 4.12 KiB | Viewed 531 times ]


Here is the VRAM table version.


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 7:01 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 932
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").

_________________
.


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 7:32 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2370
How many bytes is that? The sprite would take up 3kB VRAM.


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 7:46 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 932
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:
$ 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.

_________________
.


Last edited by zzo38 on Sat Oct 21, 2017 9:34 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 8:31 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 932
Here are the programs:
This may be used to make more experiments with it, and see if any improvement might be made, etc.

_________________
.


Last edited by zzo38 on Sun Oct 22, 2017 4:30 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Oct 21, 2017 7:00 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2370
Wow, you're fast. I wish I can be that fast at programming.


Top
 Profile  
 
PostPosted: Sun Oct 22, 2017 4:38 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 932
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.

_________________
.


Top
 Profile  
 
PostPosted: Wed Oct 25, 2017 7:15 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 190
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 ??


Top
 Profile  
 
PostPosted: Wed Oct 25, 2017 8:22 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19256
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Wed Oct 25, 2017 9:22 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 190
Ah ok, it's a good reason then :D


Top
 Profile  
 
PostPosted: Wed Oct 25, 2017 6:29 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 801
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?


Top
 Profile  
 
PostPosted: Wed Oct 25, 2017 6:55 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19256
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Thu Oct 26, 2017 5:40 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 190
Quote:
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:
Quote:
to prove it's possible

this is a good and valid argument .


Top
 Profile  
 
PostPosted: Thu Oct 26, 2017 12:09 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2370
Sometimes I forget that not every game needs to be 100% stock hardware.


Top
 Profile  
 
PostPosted: Thu Oct 26, 2017 12:54 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 801
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:
Quote:
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...


Last edited by 93143 on Thu Oct 26, 2017 1:18 pm, edited 1 time in total.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 59 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group