GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion

[acceptable67]

There is a file I am interested in, at 0x16808C in ROM. It runs for 0x38C8. The header is 0x00 0x00, followed by decompressed size at 0x2 then 0xFF which starts the data (I believe.) I have contacted Zoinkity about this, and he believes it is LZSS compression specifically 1k dictionary, whichso do agree with, as it fits the layout with data being seperated early on by NULL values and 0xFF. I've ran it through many decompressors, but the output is always fudged or very 'off', some parts in little endian, which leads me to believe that a different algorithm based on LZSS may be at play.

Just wanted to throw this out there if anyone is capable of tackling it, as I've toyed with the decompression methods (ran through MIDWAY, WILLIAMS, LZSS_0, LZSS_0B with various flag values) from multiple sources (including Zoinkity's own source code for Midway LZSS) for days straight and have gotten no where, really. I'm about to put up the towel, but if anyone could shed some insight, I'm all ears! I'll check out his source code for the lzss 1k tomorrow. Would have to convert much of it to fit Bomberman file scheme though .

Thanks.
AC
_________________

Rare wrote:

Perfect Dark Forever.

[SubDrag]

Compression is hard...really, hard...it takes a lot of experience and effort I'm afraid. Zoinkity is really, really good at it, while I usually have to grunt through it and find it rather difficult. Part of the process is just learning about compression, which I think you already did, about the general ideas of algorithms, so when you find out, you sort of have an idea what's going on.

I'm afraid the issue you're hitting is one you probably are fearing...it's not matching any known compression and has it's its own subtle variant...The only thing you can do, if you want this badly enough, is really grunt through and reverse engineer the compression using Nemu, and then hope it's just subtle modifications of an existing LZSS algorithm so you can figure it out and do some compression by tailoring existing lZSS code. My strategy, is usually to kind of turn the assembly code into C++ code, and then once I get it working (input -> output), try and turn the hard-asm into real code and learn how it works. It takes a lot of effort, and learning, but you do get very skilled after doing it. It's definitely achievable with enough effort and time and learning.

Unfortunately Zoinkity hasn't done this game yet. He's exceedingly busy right now, maybe eventually he will be able to do it for you, but he's been very tied up alas.

[acceptable67]

Yes entirely. Its a very simplistic decompression. Im going to check on emu break, but also compare bits to see why they're making the bytes disappear . I think I've already found the issue . Initial value is being shifted right , then &0x100 then flag is set . This in theory creates many null values. This alone can be completely reworked. I'm just going to heavily modify the official lzss decide to fit Bomberman. Also can increase shift amt after & 1 is hit. Will give this all a go in a few.
_________________

Rare wrote:

Perfect Dark Forever.

[acceptable67]

Solved, it was using 1k LZSS_0 variant, just as Zoinkity said. Stole a routine from his MidwayDec. Just had to specify start of data, spits out perfectly fine now!
_________________

Rare wrote:

Perfect Dark Forever.

[AL64inthedark]

Would love to know what Zoinkity is working on. He should have a blog because he already done so many exciting things related to N64.
_________________
Listen to me
https://youtu.be/BzZ3k3NmhLM?t=25m51s