|
Post by neophile on Mar 14, 2024 23:03:19 GMT
As a test to learn how PCE hacking works, I'm trying to change a single background pixel and a single sprite pixel in Rondo of Blood. Steps I've taken so far: Get the game as .cue and .bin files - Open the game in mednafen
- Press alt-d to open the debugger, press s to step through the game, and press alt-2 to access the graphics viewer
[ documenting extra granularly for any future viewers ]
- Use the graphics viewer to find the relative memory locations of the tiles I want to edit, in the background and sprites layers
Use turborip to extract the data track from the .bin
Steps I don't know how to complete: - Find the starting memory locations of the pattern tables
- Extract and edit the existing tiles from the data track into something like MAPeD/SPReD or ProMotion
I figure the section on "Storing tiles" from www.copetti.org/writings/consoles/pc-engine/ will come in handy
- Export my changes and update the data track
- Package the game back into a .bin
My naive approach to finding the locations of the layers is to somehow trace what loads into VRAM, but I'm not sure how to do that and I'm not sure that's the best approach. I figure there's something I'm not understanding about the architecture.
How can I complete my test?
|
|
|
Post by dshadoff on Mar 15, 2024 1:07:01 GMT
Most likely this game compressed the graphics on the disc, so you would need to understand the compress/decompress function. That part will not be trivial on this game (although some games store graphics uncompressed). First thing you probably will want to do, now that you know where the graphic lives in video memory, is to put a breakpoint on writing to that location - CTRL+W (and CTRL-R). See documentation here: mednafen.github.io/documentation/debugger.html
|
|
|
Post by neophile on Mar 15, 2024 3:03:40 GMT
Ah thank you! It seems my intuition about tracing what loads it was correct. I assume the best way to extract the graphics is to then write a simple program that implements the decompression function (just making sure there's no way to leverage the existing assembly)?
|
|
|
Post by dshadoff on Mar 15, 2024 5:00:34 GMT
Well, once it's in memory, I thought there was a way to export data into a file that would be in PC Engine format, but I don't remember the specifics. But I'm not sure whether that's what you're getting at.
If you wanted to change a graphic, you'd need to not only extract the existing graphics, you'd need to reverse-engineer the decompression so that you could re-compress the altered graphics back into the game (which may not fit anymore...). So it's gets tricky when compression is invovled.
|
|
|
Post by neophile on Mar 15, 2024 21:05:32 GMT
Exporting the data from memory would be a helpful shortcut, but if I'm writing something to compress the graphics I figure decompression won't be too much extra work.
Though you're right; I hadn't considered how compression would affect the size of the changed graphic. Yikes...
Well anyway, it'll be a while until I have some more time to work on this, so thanks!
|
|