Full Metal
C(++) Developer.
- 810
- Posts
- 16
- Years
- Age 28
- In my mind.
- Seen Aug 19, 2018
[a id]top[/a id]ROM Versioning
Take me to the current download![a id]desc[/a id]What is it?
ROM Versioning is a software written to ( initially ) serve one purpose: easy backups. As it stands currently, it features project / rom management, and a simple GUI for one-way backups. This means you can start using it today, in preparation for future releases. The main program interface is really simple. You have a tree-view following this structure:
Game Code
+- Version Number
--+- Project Name
----+- Patches
You register a ROM ( .gba file ) which then allows you to register projects for that ROM & version. When registering a ROM, a copy of it is made in a local folder for the sake of organization and structure that makes sense ( The directory structure matches the tree-view structure ). Then, you update your projects ( makes a patch ). It should be noted however, that all of your prior patches are applied before considering the current state of the project's ROM file for an updated patch -- hence the "Versioning" part.
Game Code
+- Version Number
--+- Project Name
----+- Patches
You register a ROM ( .gba file ) which then allows you to register projects for that ROM & version. When registering a ROM, a copy of it is made in a local folder for the sake of organization and structure that makes sense ( The directory structure matches the tree-view structure ). Then, you update your projects ( makes a patch ). It should be noted however, that all of your prior patches are applied before considering the current state of the project's ROM file for an updated patch -- hence the "Versioning" part.
[a id]todo[/a id]What isn't implemented ( yet )
- An install-able service that will watch your project ROM's for any changes and automatically update them with patches. While I currently have one designed, coded and compiled into the "gba.dll" I have yet to be able to test it because I'm using Windows XP 64 bit which seems to be incompatible with .NET 4.5 things being ran as a service.
- A rollback feature. This will be easy to implement. I just haven't yet.
- A release builder. There is one included, it's just not yet into the GUI.
- A utility to apply releases for playing. No progress on this yet.
[a id]future[/a id]Where I'd like to see this Go
There are a couple of problems that seem to arise with hacking in the GBA realm no matter what. These primarily are: offset tracking, and freespace utilization. Seeing as this is a backup / release / project managing / organization utility, I see this as a perfect opportunity to create a solution to many problems. Every hack as different "resources" per se. Stop for a second and step back from traditional ROM hacking. Rather than modify the ROM directly, why not build data ( your maps, sprites, and so forth ) and then insert your data all at once. This allows you to do a few things:
- No need to worry about offsets. Refer to things by their names!
- The program takes care to insert things where they can fit, and where they can be properly utilized.
- The program will fix any missing pointers and redirect pointers from old data to new data.
- Reduce wasted freespace to nearly zero.
- In the chance that you need to do a rollback on your project, your work can still be spared!
[a id]buthow[/a id]How I plan for this to work
In your project's directory, there are two initial files:
- rom.gba - this is what is used when updating your projects
- project.json - the storage of all your patches, and other critical data. Don't touch this, please.
The user can install plugins. These plugins will be configured to handle different resource types, which can come in different file formats. The general notation for this will be:
filename.resource_type.file_type
eg:
bulbasaur.lgsprite.png
Would be a png file that should be inserted as an lz77 compressed sprite ( and the palette as well ).
The plugin would be responsible for requesting the location of any other resources, compiling the resources into a raw hex dump, and then giving it to the linker. What this will do is allow the program to find free space for all the resources ( based on their compiled size ) then return these locations for cross-referencing and what not. Resources with the fewest dependencies ( external references ) will be considered first in the search for free space. This separates the editing of data ( maps / scripts / images ) from the compiling / inserting / linking of data ( unlz.gba / hex editor / etc ), and also creates a significantly fewer amount of headaches for hackers. ( Not to mention conflicts that normally arise from collaborations wouldn't happen as often and would be easier to resolve as the data would be in files rather than in the ROM itself which would require repointing, relocating, finding, editing, re-inserting, and so forth. )
Another potential feature I would like to include is dropbox or some other syncing service support built in, but I'm not holding my breath on that one.
[a id]help[/a id]I would like to help!
While I do have version 1.0 out, and it is functional, I have done very minimal bug-testing on it. If you find a bug, or the program crashes for whatever reason, please let me know about it. Things like what you were doing, how you did it, any involved files, etc are all crucial details that can help. If you copy the error and paste that into a spoiler on here, that is also helpful.
Feedback! I absolutely love feedback, and yours is definitely of interest to me. Tell me what you think about this project, and what you would like to see.
Plugins! If you're interested in developing a plugin, contact me and once there's a decent amount of interest in it, I'll start developing a finalized framework for this. The software is written in C# targeting .NET 4.5 framework -- feel free to ask for the source. I haven't bothered opening a repository or git for it yet, though.
[a id]downloads[/a id]Downloads!
You can always check here for the most recent releases, as it will be more up to date than this thread, but I will also try to keep an up-to-date index on this thread.
[a id]current_download[/a id]
- [a id]down1.0[/a id]Version 1.0 - The GUI is capable of doing all except one job ( release building ) of the prior console programs, JSON parsing weight is greatly reduced by separating the ROM info from the ROM itself, and removed compression because of difficult bugs. May or may not re-introduce. [link.]
- [a id]down0.2[/a id]Version 0.2 - A few console programs, but the GUI is introduced. Still slow, and uses compression. [link.]
- [a id]down0.1[/a id]Version 0.1 - All console programs, a little confusing, very slow, but works consistently -- tested thoroughly, and has compression. [link.]
[a id]bugs[/a id]Current Bugs
Last edited:
