Compression seems to be less of an issue than it once was for the newer consoles which tend to use standard types (we call it things like GBA BIOS compression even). The compression is seldom the hard part anyway, it seems to be more the writing of a decompression tool or a compression tool (even a compression dodging tool that just sets uncompressed flags in the case of something like LZ) is the bigger ball ache.
This is inconsistent with everything everyone but you has said about the topic. When people stop their hacking, it's usually because they can't deal with the compression.
Since we left single screen games and got scrolling then map exits are not really a hardware concept.
I didn't say they were. Map exits happen when the sprite moves beyond the logical boundaries of the map, or onto a door tile. This happens, usually, in response to the player's motion of the player to move into that space. Once the player moves into that space, the game takes over until the next map is loaded. This about always involves decompression, and is moreover the only time except at the intro/ending sequences when it actually happens. So if say, you had a control panel in which to check a button for break-on-press, you could mosey your character over to the map's edge, or next to an NPC, then pause the emulator; check the button; and press the button. Then you'd be able to trace all the code dealing with the transition between maps.
This is actually completely necessary, because the code for input handling is generally interrupt based, particularly on handhelds where it is expedient to relieve pressure on the battery by suspending execution until an interrupt forces it to resume.
Learn more. The more you learn the easier and faster it will become.
Not likely. There's too much to be learned and not enough people willing to become specialized experts.
I do think we have to do this stuff ourselves, particularly because ROM hacking divides the community. In the beginning emulator authors had to work hand in hand with hackers... this is no longer the case. One of the most notable events that I can recall in recent emulator history was the departure of one of the lead programmers of PCSX2 several years ago. The departure was abrupt and without qualm: the dev said he had been offered a job that would receive his complete commitment from that day forward. Considering how passionate people in this community tend to be about their work, it must have been quite a sum. Over the past decade emulator authoring has moved from pariah status to sought-after specialization: emulator authors, for modern systems at least, are thought of as being experts in the modeling of highly abstract systems and self-starters besides, strong qualities for any technical project lead. At least a hundred (probably more) theses have been presented around emulator design. Association with pirates and/or people who work with (presumably) pirated material is a professional liability. Even those who are not pursued for their skill (or else dismissive of the pursuit) seem to be doing fine on Google Play, except when an association with piracy is made. Emulator authors have little financial incentive to make our job easier, so we will have to make the improvements ourselves. (disclaimer: I'd find it awesome if some of these ideas were integrated into working emulators by their original authors... I just don't think it likely).
April 09, 2016, 12:09:18 am - (Auto Merged - Double Posts are not allowed before 7 days.)
I'm not sure as far as debugging on other systems but the SNES has it really nice with Geiger's SNES9X (Even though it's not 100% perfect) with the Trace Logging system it has. That is seriously a god send when it comes to debugging. More debuggers should incorporate things like that in my opinion, make it a lot easier to figure the code out.
Geiger's emulator is a start. Needs work, but a start nonetheless.
@FAST6191: it seems to me that the following approach would make your work easier:
- you could run the decomp code in a CPU core to conduct the decompression of the material to RAM, then HDD automatically. This way, you'd only need one program for all decompression needs. As for the recompression, you could replace the decomp routine with a generic (such as LZW or Huffman) and compress it with that.
Topic: Making hacking easier (Read 13071 times)