Using Perl 6 Grammars: Decompressing Zelda 3 GFX | Hacker News Reader

Using Perl 6 Grammars: Decompressing Zelda 3 GFX

blogs.perl.org

73 pointsleejo14 comments

Perl grammars look awesome. There's a parser for Rust that allows parsing is somewhat similar style:

https://github.com/Geal/gif.rs/blob/master/src/parser.rs

nom is neat, but wouldn't pest be closer to P6 grammars https://crates.io/crates/pest

Perhaps it's a bit silly, but it amused me that this line: "<a byte that contains an header>" made me ask whether the author was French. A very quick search for his name comes up with predominantly French (language, at least) results, so I'm comfortable enough leaving it at that.

For those wondering, the japanese text means "sword" and is an unused sprite in the Link to the Past.

Source: https://tcrf.net/The_Legend_of_Zelda:_A_Link_to_the_Past#Swo...

Is A Link to the Past officially known as "Zelda 3" in any region? I remember having a guide for ALttP back in the day where a Nintendo representative emphatically stated that ALttP is not Zelda 3, as it is a prequel and does not feature the same Link that is present in Zelda's I and II.

Yeah according to this

https://nintendo.wikia.com/wiki/Zelda_III

The actual Zelda 3 was in development for the NES then cancelled.

I think the Zelda 3 (NES) prototype is largely considered a hoax, as far as I can tell, but this page does reference a Zelda 3 for the SNES that was scrapped and some of its ideas were repurposed for Link to the Past.

https://zelda.gamepedia.com/Community:Zelda_III_Cartridge_Ho...

Ah yeah...I kinda took the picture with a grain of salt. I assumed even if it had existed it wouldn't have gotten that far. The link you posted makes more sense though.

I wonder what the data compression ratio is for this encoding.

Part of the point of this compression algorithm is for the designer to alter the image so that it can be better compressed.

So the amount of compression really depends on how much the designer is willing to compromise their vision.

I would guess that the average amount of compression might be better than 4:1. (That is less than a quarter of the uncompressed size)

Unless I'm missing something, it doesn't appear be that great in this case. The image is supposed to be a 128x32x3bpp image, so that's 12,288 bits / 1536 bytes, plus whatever overhead for the image format. The article says the compressed data is 1500 bytes. So, er, not much compression.

The png file on the page of the same data is 741 bytes. An uncompressed 4-bit bmp of the same data is 2250 bytes.

Wow, that's a "why bother" level of compression. I guess the SNES didn't have a lot of CPU cycles left over to run a decompression algorithm, but even a simple deflate seems like it would have greatly outperformed this custom solution. I guess the big advantage is that this seems to have zero memory overhead.

Could just be this particular image, or that I'm missing something else.

The 1500 bytes size is me being lazy to search for the right size, the grammar stops at the FF header anyway so knowing the size is not that useful.

To answer the initial questions, I remember that the compression ended with like 40-20% fewer bytes for things without really big empty space. Later games on the SNES used lzss like compressions.

Thou my owns implementation of the compression give better results (most of the time) for the original datas of the game that the tools used by Nintendo and it's pretty naive.

Reply on news.ycombinator.com