[ReBirFh]

If a game has compressed and uncompressed graphics and instead of findind a way to decompress, I just repoint it to a location with uncompressed graphics in the same order, what will happen?

[Gemini]

If the game isn't smart enough to detect literal data, it will simply crash and die shortly after.

[Ryusui]

You'll need to hack the game to read the straight data - "break the compression's kneecaps", as Gideon Zhi once put it. It's not that hard; at worst, you'll have to replace the compression routine with a straight copy into the same RAM address.

[andlabs]

If a game has compressed and uncompressed graphics and instead of findind a way to decompress, I just repoint it to a location with uncompressed graphics in the same order, what will happen?

If the game isn't smart enough to detect literal data, it will simply crash and die shortly after.

Only in extreme cases — the least that could happen is bad data where the good data should be but nowhere else, with some data corruption being the median case due to the decompressor running longer finding that magic terminator. This all depends on the format of the compressed data and the algorithm used by the decompressor.

What do you intend to accomplish by this — figuring out how the compression works? Replacing graphics?

You'll need to hack the game to read the straight data - "break the compression's kneecaps", as Gideon Zhi once put it. It's not that hard; at worst, you'll have to replace the compression routine with a straight copy into the same RAM address.

The only problem with this method is that it'll break all decompression, not just the one you want to have happen. The only way is to locate where the particular data you want is decompressed and change the particular routine call to a copy.

[ReBirFh]

I was trying to give a "facelift" to Alex in the Enchanted Castle as this game suffers from bad selection of colors, unnecessary dithering/detail, bad draw graphics and Alex itself doesn't look like he does in the Master System games.
Only alex sprites are uncompressed but I found that some objects were only partially compressed (the balls only have one quarter of their graphics compressed).

I already tried to search for kosinki or enigma without luck.

Right now I'm trying to "decode" the layout of the stages, just finished the first layer (Sprites) of the first stage. Insteresting how the stages are composed of blocks that have a minimum of 2x2 tiles.

EDIT:

*If I make a savestate in a place that has the graphics that I know are compressed, they will be already decoded in ram/vram, right?

*The decoded graphics are stored in vram with bytes swapped like palletes are in cram, in relation to how they appear in the rom (Genesis/Mega Drive related)?

[Ryusui]

You'll need to hack the game to read the straight data - "break the compression's kneecaps", as Gideon Zhi once put it. It's not that hard; at worst, you'll have to replace the compression routine with a straight copy into the same RAM address.

The only problem with this method is that it'll break all decompression, not just the one you want to have happen. The only way is to locate where the particular data you want is decompressed and change the particular routine call to a copy.

That's what I meant. You don't have to murder all the compression - just redirect the relevant compression routine calls to your own direct copy routine.

*If I make a savestate in a place that has the graphics that I know are compressed, they will be already decoded in ram/vram, right?

*The decoded graphics are stored in vram with bytes swapped like palletes are in cram, in relation to how they appear in the rom (Genesis/Mega Drive related)?

Yes, the savestate will have the decoded graphics in RAM/VRAM. Depending on how the hardware works and how the game itself is programmed, it may decompress from the ROM into RAM and then transfer into VRAM, or decompress from the ROM directly into VRAM.

I'm having a little trouble understanding your second question. The uncompressed graphics data should require no further arcane trickery to make it display properly once it's copied into VRAM, if that's what you're asking.

[andlabs]

I understand his second question (he wants to know if the savestate format is big endian or little endian), unfortunately the answer is a bit iffy. What emulator are you using to make the savestate?

(On a side note, if I was approaching this problem I would just disassemble Enchanted Castle...)

EDIT How are you determining the format for the level layouts — from the VRAM area or from the RAM area or from the ROM?

[ReBirFh]

I'm using GensKmod and fusion to play. I'm determining the layout from ROM because I thought that the RAM or VRAM wouldn't be able to hold the entire level.