Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add in Batman & Robin compression #22

Open
vladikcomper opened this issue Jun 8, 2021 · 3 comments
Open

Add in Batman & Robin compression #22

vladikcomper opened this issue Jun 8, 2021 · 3 comments
Assignees
Labels
blocked The issue is blocked by another issue enhancement

Comments

@vladikcomper
Copy link
Contributor

vladikcomper commented Jun 8, 2021

The Adventures of Batman & Robin uses quite powerful, yet fast compression format with the sliding window of 0x6A0 bytes and maximum dictionary reference length of 0x113 bytes.

Below are my notes on this format, based on my research from 2014:

The game uses its own LZSS-based compression format. Unlike many others implementations, this one is notable for storing description fields and dictionary in separate data blocks, most likely to make fetching 16-bit fields faster as M68K would have problems with reading 16-bit words from unaligned locations.

The compressed data starts with 32-bit relative offset, which points to the beginning of the dictionary. Theoretically, this allows for 'global' or shared dictionaries, meaning different compressed data may use same dictionaries with just different description fields streams to handle decompression. However, this may be difficult to implement with the given compression format, unless the data in the question is nearly identical.

Right after the dictionary offset, description fields that operate decompression start. Those fields can be interpreted as one continous bitsteam, but technically, they are being fetched as 16-bit words.

The following combination of codes are possible in the description fields:

	%0			- Uncompressed byte

	%10[disp]		- Set copy count to 2

	%11cc[disp]		- Set copy count to 3..5
	%1100cccc[disp]		- Set copy count to 6..$14
	%11000000cccccccc[disp]	- Set copy count to $15..$113
	%1100000000000000[disp]	- Quit decompression

	[disp]:
	%00ddddd		- Set displacement to 1..$20
	%01ddddddd		- Set displacement to $21..$A0
	%10ddddddddd		- Set displacement to $A1..$2A0
	%11dddddddddd		- Set displacement to $2A1..$6A0

Here's also a working decompressor implementation that also searches for compressed art in the ROM: https://pastebin.com/RahSijzh

@vladikcomper
Copy link
Contributor Author

vladikcomper commented Jun 8, 2021

TODO: Check if B&R compression (much like the sound driver) was actually developed by Zyrinx and was featured in their own games, like Red Zone.

@flamewing flamewing self-assigned this Jun 8, 2021
@flamewing
Copy link
Owner

flamewing commented Jun 8, 2021

The split streams for descriptor/dictionary from issue #8 is important here.

@flamewing flamewing added the blocked The issue is blocked by another issue label Nov 17, 2021
@flamewing
Copy link
Owner

Blocked by #25

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked The issue is blocked by another issue enhancement
Projects
None yet
Development

No branches or pull requests

2 participants