News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Need help finding out where compressed graphics are located  (Read 1412 times)

lori

  • Newbie
  • *
  • Posts: 2
    • View Profile
Need help finding out where compressed graphics are located
« on: January 18, 2021, 05:37:53 pm »
Hello!!! I was wanting to do a sprite edit for Westone's Wonder Boy in Monster World on the Genesis, but... all of the graphics are compressed. Someone wrote a graphics decompressor for the specific graphics format this game and Monster World IV uses, but in order to reach the graphics, I need to point it to the hex location where the sprites are.

I tried using debugging tools, but I wasn't really sure on what I was doing... couldn't gleam what'd be loading graphics from where.

More than willing to grind it out using whatever tools I need, so if anyone could point me in the general direction to get started that'd be greatly appreciated!

USC

  • Submission Reviewer
  • Sr. Member
  • *****
  • Posts: 314
  • Obviously Outdated
    • View Profile
Re: Need help finding out where compressed graphics are located
« Reply #1 on: January 19, 2021, 12:09:47 pm »
Does your debugger have a way to view the current tiles on the screen? If so, you can find the address for the first tile in the compressed image, and then set a Write breakpoint on that address.

That will stop the game right as it starts to draw the first tile. You can then study the current variables and see if you can find where it's pulling the tile information from. It'll take some searching, but that's a good starting point.

FAST6191

  • Hero Member
  • *****
  • Posts: 3081
    • View Profile
Re: Need help finding out where compressed graphics are located
« Reply #2 on: January 19, 2021, 07:09:15 pm »
Two approaches.

1) Learn to debug. https://www.romhacking.net/documents/361/ is for the GBA and for a command line based setup but the basic workflow is the same on all systems. There will probably be some command/sequence of in there that reads from the ROM (most games have it visible in memory), does some stuff and then chucks it into the video parts all plain as day.
Compression on the megadrive/genesis is probably quite simple (64 kilobytes of RAM running at sub 10MHz does not afford a lot of things to be wasting on complicated setups) so without checking it is likely either a variation of run length encoding (either do nothing and go to next section or repeat this bit sequence so many times) or proto LZ wherein it is sectioned off and compressed sections are usually more "not compressed, go to next section" and "is compressed, go this far back, read this many bytes, go to next section". Granted you will probably come back and tell me it is some variation on the theme of huffman (big list of values and short codes for each of those). Anyway basic compression as seen on old consoles/embedded computers is usually built for speed rather than winning some crazy compression contest and that tends to lend a measure of simplicity such that even if it is not "reads from this location in ROM, destination is the video section" it is not so many steps removed.

2) Some types of compression at vaguely visible in a tile editor, usually getting more and more jumbled as time goes on. If you want to grab a palette from the game, set your tile editor to that and press down a lot you might catch a glimpse of what could be your tiles. Scroll back up until you find the start location and feed that to your decompression tool.
If you are lucky then the compression format will have some notable header/magic stamp value you can search for to get all the others -- if you ever see people discussing compression formats for the DS then the "type 10, type 11 and type 40" things you might see are in fact what the files that use those formats start with in hex. If the utility you mention has source code or a description you might even see such a thing mentioned in that.


You could try corruption as well to help narrow things down but compression and corruption is seldom a great mix.

lori

  • Newbie
  • *
  • Posts: 2
    • View Profile
Re: Need help finding out where compressed graphics are located
« Reply #3 on: January 19, 2021, 10:10:04 pm »
Two approaches.

1) Learn to debug. https://www.romhacking.net/documents/361/ is for the GBA and for a command line based setup but the basic workflow is the same on all systems. There will probably be some command/sequence of in there that reads from the ROM (most games have it visible in memory), does some stuff and then chucks it into the video parts all plain as day.
Compression on the megadrive/genesis is probably quite simple (64 kilobytes of RAM running at sub 10MHz does not afford a lot of things to be wasting on complicated setups) so without checking it is likely either a variation of run length encoding (either do nothing and go to next section or repeat this bit sequence so many times) or proto LZ wherein it is sectioned off and compressed sections are usually more "not compressed, go to next section" and "is compressed, go this far back, read this many bytes, go to next section". Granted you will probably come back and tell me it is some variation on the theme of huffman (big list of values and short codes for each of those). Anyway basic compression as seen on old consoles/embedded computers is usually built for speed rather than winning some crazy compression contest and that tends to lend a measure of simplicity such that even if it is not "reads from this location in ROM, destination is the video section" it is not so many steps removed.

2) Some types of compression at vaguely visible in a tile editor, usually getting more and more jumbled as time goes on. If you want to grab a palette from the game, set your tile editor to that and press down a lot you might catch a glimpse of what could be your tiles. Scroll back up until you find the start location and feed that to your decompression tool.
If you are lucky then the compression format will have some notable header/magic stamp value you can search for to get all the others -- if you ever see people discussing compression formats for the DS then the "type 10, type 11 and type 40" things you might see are in fact what the files that use those formats start with in hex. If the utility you mention has source code or a description you might even see such a thing mentioned in that.


You could try corruption as well to help narrow things down but compression and corruption is seldom a great mix.
Does your debugger have a way to view the current tiles on the screen? If so, you can find the address for the first tile in the compressed image, and then set a Write breakpoint on that address.

That will stop the game right as it starts to draw the first tile. You can then study the current variables and see if you can find where it's pulling the tile information from. It'll take some searching, but that's a good starting point.

Thank you both for the responses! I'm using "Gens Kmod", which may or may not be unable to do what both of you are suggesting re: finding tile addresses and writing a breakpoint...



There's a few windows but this is basically what I'm looking at here, I don't really see details on where the sprites would correlate to in the ROM, or an option to set a break point. Should I be using a different debugger?

FAST6191

  • Hero Member
  • *****
  • Posts: 3081
    • View Profile
Re: Need help finding out where compressed graphics are located
« Reply #4 on: January 20, 2021, 03:40:08 pm »
I should really get around to trialling megadrive debuggers before long as this is not the first time I have had to say this (and I do like many megadrive games). They tend to be weaker than what is seen on other systems (if you are used to something like fceux or no$gba, never mind PC based stuff, they will be wanting) but still are big enough and ugly enough to get it done. I do however have no suggestions other than maybe see what the tool assisted speedrunners have as they will tend to have good stuff here -- if your hobby necessarily revolves around understanding how the game works at the lowest levels and manipulating it accordingly...

That looks like a basic tile, palette (CRAM = Colour RAM) and VRAM viewer along with sprite positions (object area memory being the term in many other systems/emulators/tech docs, though sprite attribute table is what the main Sega docs call it http://techdocs.exodusemulator.com/Console/SegaMegaDrive/Documentation.html ).
In any case it is unlikely to contain any info on the original location of the sprites in the ROM -- it is no great use for the running of the system or those programming it (they would be expected to know where they left things after all). Some rare debugger or sprite ripper emulators might have something that tries to note it, though if compression is a thing that first bounces things around the RAM to decompress then that is one way to make such things tricky at best and more likely useless.

Either way once you have a debugger with breakpoint support you would presumably set a break on write to the location in the VRAM just before it gets written there (might be copied when a new level starts, might be when you press start on the title screen, might be... either way you can usually set them to update in real time, play the game a bit and wait for it to happen). If there was no compression then you might get a nice DMA (direct memory access, a way of grabbing data from one part of memory, which can include the ROM, to another without bothering the CPU) read from the source in the ROM to the destination in video memory (and you will also have any mode, palette or similar information likely also there already or coming shortly afterwards), hence why debuggers, or more correctly using them to perform a tracing session, is such a powerful method over reverse lookup*, pressing down a lot in a tile editor, corruption and all the other means. If compression is in the mix the the CPU will likely get involved to generate the final image before it gets copied to VRAM (or it might be able to operate in VRAM -- I don't know for this but newer systems and older systems I do know well tend not to be so keen on editing things here as much as copying data from elsewhere with less restrictive memory sections). It might be a fair few steps as a raw number of them but decompression it will likely be a simple loop it runs a few dozen times and before that it will have fetched it from the ROM. Some will work back up until something interesting happens, others might see if the decompression function is a small area of code (again 16 bit era compression is likely very simple in the abstract with it mostly being "is compressed then do this, is not compressed then go to next section, is end of compressed data go back to normal game" run a few dozens times) and set a new breakpoint on that (albeit break on execute this time) and hope the instructions preceding that before it first called (might want to go back a few more seconds before it is loaded) are the simple DMA to the main memory to then proceed with decompression. Also means you would have the method of decompression (might not be as quick or elegant as you can do on a PC to decompress the same data but will work) if it was unknown to you, or just a custom tweak on an otherwise known method. Once you do know one or two locations then do check to see if there is a nice magic stamp or something you could use to search the ROM in favour of that; for the GBA and DS stuff mentioned earlier then compression search tools do tend to be things that search the ROM for 10h, 11h or 40h and attempt to see if the following data, usually a size value and then compressed data, makes sense to call a potentially compressed spot so don't overlook the option to make things nice like that.

*dump the VRAM. Other than compression and weird games that edit things at runtime then most likely it will be the same data in the ROM. Search for that and up might pop the data in the ROM itself. Can also work for compression if you do a small snippet from early on in the sprite where compression is least but by no means guaranteed.


If the Huffman, RLE, LZ and whatever else stuff earlier served to confuse and you are curious (or maybe just want to know what you might see doing the decompression so as to skip it in favour of something interesting) then my usual introduction to compression in general is https://ece.uwaterloo.ca/~ece611/LempelZiv.pdf (despite the name it does cover good stuff).