2
Parzi
15d

At some point I need to do an older project i've had on hold a while, but it'd require writing my own ROM patch system as a major step in completing it, as i'd need to dynamically patch stuff into older games based on system, which current patch formats don't allow for. (This project will also help me learn a few things I need for yet more projects I've got stashed away, so it needs to happen eventually.)

Now, the interesting part: the patch format. I was debating on whether to use binary data, like IPS/BPS and similar formats do, which would be easier to implement... but if I were to have plaintext patches, you'd be able to not only understand what's happening, but also have things like scripting and conditionals and user-defined options and such. This would be WAY harder to implement, slow as fuck, and require an assembler per-target-system, either external or internal... but it'd be transparent, editable, and hella extendable.

This would all happen after I'm both over my burnout AND done chewing through my current stack of projects and such, of course, but still... which sounds better to you, dear reader?

Comments
  • 1
    Maybe a combination of the two? Use binary patches, but with the option to write a script that conditionally applies certain patches?

    I feel like a full plaintext patch format would result in unnecessarily huge patch files, but only using binary patches robs you of a whole bunch of interesting features.
  • 0
    @EmberQuill I was thinking about pre-compiled drop-in blobs in the plaintext for that reason, though it'd still be bigger than normal...
Add Comment