Author
|
Topic: Compressed tiles (Read 2 times)
|
andwhyisit
Guest
|
 |
« on: February 27, 2009, 12:21:28 am » |
|
What does a compressed gameboy tile look like in hex? I don't care about what type of compression, I just want an example. I honestly can't figure out how it would work, my curiosity is killing me right now.
If this is an improper question to ask then just tell me.
|
|
|
|
|
creaothceann
Guest
|
|
« Reply #1 on: February 27, 2009, 03:03:47 am » |
|
Well, if you map each byte to a color in a grayscale palette, a BMP file could look like this:  The source image converted to PNG would look like this:  You can see that compression takes large areas of the same value and compresses them down to a few bytes. (What you can't see here is that the same also goes for larger repeating patterns.) The result is an image that looks a lot more "noisy" than the source image. |
|
|
|
|
Moulinoski
Guest
|
|
« Reply #2 on: February 27, 2009, 09:36:36 am » |
|
The first image is pretty. Its like an abstract piece of art done good.
Compression type varies by game, right? No two games will use the same compression (well, almost... I also suppose sequels would use similar compression methods), right?
|
|
|
|
|
RedComet
Guest
|
|
« Reply #3 on: February 27, 2009, 02:34:16 pm » |
|
Some games do use the same compression scheme. Regardless of how the compression is implemented, there's no way to look at data in a hex editor and say for certain "oh, yeah, that's compressed", which is what the original poster wants to know.
|
|
|
|
|
akadewboy
Guest
|
|
« Reply #4 on: February 27, 2009, 03:23:26 pm » |
|
Here's a real example. This is a screenshot from the game Umi no Nushi Tsuri 2 (Legend of the Sea King 2)  As you can see the majority of the graphics look like garbage and don't line up properly in the tile editor. That's a clear indication of compression. |
|
|
|
|
andwhyisit
Guest
|
|
« Reply #5 on: February 27, 2009, 07:38:17 pm » |
|
But that can also represent data such as dialogue text or tile positions for example.
|
|
|
|
|
Ryusui
Guest
|
|
« Reply #6 on: February 27, 2009, 08:06:50 pm » |
|
The 1's are a little odd, though. I think he's right; this is compressed.
Fortunately, compression is easy to handle. That's right, easy. Provided, of course, you're a decent programmer with some other language and have a passing familiarity with file I/O.
Tracing the compression routine is a simple matter. Just find out where in VRAM the tiles are decompressed to, and work backwards (or around) until you find the part where data is read from the ROM. See what the program does to the data as it goes from point A to point B. Once you've figured out how the data is compressed, you can then replicate its function in the programming language of your choice.
The only hard part is recompression, but with some trial, error and careful analysis, you can create an equivalent recompressor with little trouble.
|
|
|
|
|
Moulinoski
Guest
|
|
« Reply #7 on: February 27, 2009, 10:26:58 pm » |
|
...Easy... if you're a decent programmer... My self-esteem is lowering and my hate towards my education in general (not just computer science) is growing.
I have seen those garbled tiles plenty of times before while I messed with several ROMs.
|
|
|
|
|
Ryusui
Guest
|
|
« Reply #8 on: February 27, 2009, 10:30:55 pm » |
|
A CPU is nothing more than an electric abacus. And a good programming book on just about any subject will teach you enough of the basics to wrap your head around the general concept.
|
|
|
|
|
andwhyisit
Guest
|
|
« Reply #9 on: March 01, 2009, 07:13:35 pm » |
|
Tracing the compression routine is a simple matter. Just find out where in VRAM the tiles are decompressed to, and work backwards (or around) until you find the part where data is read from the ROM. Will VBA do the trick, or do I need something else? See what the program does to the data as it goes from point A to point B. Once you've figured out how the data is compressed, you can then replicate its function in the programming language of your choice. The problem is that most of my languages are web based. I would probably just need to make trial and error changes to the compressed tiles via hex until I have a changed tile or figure out how the compression works. |
|
|
|
|
Ryusui
Guest
|
|
« Reply #10 on: March 01, 2009, 07:35:56 pm » |
|
Will VBA do the trick, or do I need something else? You'll need either VBA-SDL-H or NO$GBA, something with some actual trace functions (please note that the former is command line-based; you'll probably want to use it in tandem with VBA so you can see where things show up in VRAM and use VBA-SDL-H for your actual tracing). The problem is that most of my languages are web based. I would probably just need to make trial and error changes to the compressed tiles via hex until I have a changed tile or figure out how the compression works. Trial-and-error changes to compressed data are likely to break something horribly. If by "web-based" you mean Java or something, then you still have a decent foundation: if you have functions for working with files in binary form, then you have everything you need to battle compression. |
|
|
|
|
andwhyisit
Guest
|
|
« Reply #11 on: March 02, 2009, 08:58:49 pm » |
|
NO$GBA Debugger or just the normal freeware emulator? |
|
|
|
|
Gemini
Guest
|
|
« Reply #12 on: March 02, 2009, 09:11:45 pm » |
|
I guess debugger. The standard version doesn't really help with this stuff.
|
|
|
|
|
SerenadeDS
Guest
|
|
« Reply #13 on: March 02, 2009, 09:20:21 pm » |
|
Tracing the compression routine is a simple matter. Just find out where in VRAM the tiles are decompressed to, and work backwards (or around) until you find the part where data is read from the ROM. Will VBA do the trick, or do I need something else? You're working with Game Boy right? Then I think BGB or NO$GMB would be your best choices, and are the ones that I use and would recommend. |
|
|
|
|
Ryusui
Guest
|
|
« Reply #14 on: March 02, 2009, 09:33:46 pm » |
|
Sorry, I forgot it was a Game Boy title and not GBA. Consider this a second vote for BGB.
|
|
|
|
|
|
RHDN Forum Archive
