Tool: Rom Versioning

[Full Metal]

[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.
​

[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:

1. No need to worry about offsets. Refer to things by their names!
2. The program takes care to insert things where they can fit, and where they can be properly utilized.
3. The program will fix any missing pointers and redirect pointers from old data to new data.
4. Reduce wasted freespace to nearly zero.
5. 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.

I plan to add a directory to this called 'resources', which will be empty, initially.
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

Guide:

Guide:

Fixed in Version [x]
Researching as of [date]
Relevant [Report]

• Potential bug in older version. [Report]

 

[Akiba]

[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:
​

Oh... Well I've kind of done this about a month ago... Of course, it's always open to improve.

Open source. Use my code as a starter. (It's VB.NET, though, because I've kind of made a permanent switch to it for all programs concerning hacking tools.)

https://www.pokecommunity.com/threads/301809

By the way, your program is really heavy on the filesize.​

 

[Alexander Nicholi]

This looks nice and very useful, though I'm puzzled how you'd implement it.

 

[MrElephant]

I couldnt get any of it to work I will attach links of what is going on with the program.

I cant even test the program. It just crashes as soon as I try to open it...

Maybe it doesnt work on 7. Did you make this for xp or earlier computer?

Links to what I am seeing... Maybe it is just my computer?

https://oi42.tinypic.com/2yx1w8x.jpg

 

[Full Metal]

This looks nice and very useful, though I'm puzzled how you'd implement it.

I'm working on that right now. Currently I'm re-designing the GUI to use WPF instead of Winforms for an easier way of sharing common GUI elements that are linked to the project management.

I couldnt get any of it to work I will attach links of what is going on with the program.

I cant even test the program. It just crashes as soon as I try to open it...

Maybe it doesnt work on 7. Did you make this for xp or earlier computer?

Links to what I am seeing... Maybe it is just my computer?

https://oi42.tinypic.com/2yx1w8x.jpg

Looking at the error in the console window, do you have 'gba.dll' in the local folder? If so, do you have any other gba.dll's in your path environmnet? Which version did you download? It looks like you got the version 0.2 because I can see that you have the command-line "RegisterProject" program, which is an old version. Actually, did you mix-and-match versions of the download? Don't do that.

Oh... Well I've kind of done this about a month ago... Of course, it's always open to improve.

Open source. Use my code as a starter. (It's VB.NET, though, because I've kind of made a permanent switch to it for all programs concerning hacking tools.)

https://www.pokecommunity.com/threads/301809

By the way, your program is really heavy on the filesize.

Sorry, but VB.NET is absolutely one-hundred-percent disgusting in every way I can imagine. A few less kilobytes in program size ( in my opinion ) does not warrant using a horrid language that needs to vanish ( along with java ).

I've noticed the large file-size myself. The jump occurs when the GUI program is added, I'm not really sure what's up with that. I may just need to pass some optimization configuration options in the release build, but who knows. It might be the icon I included, which has all common sizes up until 512x512 and has alpha transparency. That actually probably is it, now that I think about it.

I saw your program, and tbh I have absolutely no clue how it's pertinent to GBA hacking, just that it's a general-purpose versioning software that uses a bindiff method. While our programs do share the versioning concept ( albeit, that's all that mine does right now ) the overall purpose of my program is a bit larger. Also, 401kb isn't exactly large. It still takes < a minute to download, which is really the only time you really should worry about file-sizes.

 

[Akiba]

I'm working on that right now. Currently I'm re-designing the GUI to use WPF instead of Winforms for an easier way of sharing common GUI elements that are linked to the project management.



Looking at the error in the console window, do you have 'gba.dll' in the local folder? If so, do you have any other gba.dll's in your path environmnet? Which version did you download? It looks like you got the version 0.2 because I can see that you have the command-line "RegisterProject" program, which is an old version. Actually, did you mix-and-match versions of the download? Don't do that.



Sorry, but VB.NET is absolutely one-hundred-percent disgusting in every way I can imagine. A few less kilobytes in program size ( in my opinion ) does not warrant using a horrid language that needs to vanish ( along with java ).

I've noticed the large file-size myself. The jump occurs when the GUI program is added, I'm not really sure what's up with that. I may just need to pass some optimization configuration options in the release build, but who knows. It might be the icon I included, which has all common sizes up until 512x512 and has alpha transparency. That actually probably is it, now that I think about it.

I saw your program, and tbh I have absolutely no clue how it's pertinent to GBA hacking, just that it's a general-purpose versioning software that uses a bindiff method. While our programs do share the versioning concept ( albeit, that's all that mine does right now ) the overall purpose of my program is a bit larger. Also, 401kb isn't exactly large. It still takes < a minute to download, which is really the only time you really should worry about file-sizes.

I actually agree in that VB.NET is disgusting... But as I always say, you have to put up with it for the sake of beginners. I'd much rather just do everything in C++. You are probably the same.

Spoiler:

By the way, I completely agree with you in that Java is horrible. In every way possible. Its concept is flawed.

When I checked the unzipped filesize, it was almost 10 MB, so that's what I was concerned about. People today want minimalist software for seemingly small tasks.

 

[A Sunny Moo]

That is, of course, implying that C++ doesn't have its own downfalls. Compatability and having to install proprietary software to get any of it to work is a disaster.
Sometimes, its easier to have a program that can be used across multiple platforms.
Of course, since most rom editing tools are .exe, it would be implied that rom hacking would be done on Windows (and in that case, you would have your C++ updated)

anyway, back on topic, I think that this idea is very nice. I'm keeping my eye out for updates.

 

[MrElephant]

I tried more than one version after I couldnt get the first one working.

 

[Full Metal]

I actually agree in that VB.NET is disgusting... But as I always say, you have to put up with it for the sake of beginners. I'd much rather just do everything in C++. You are probably the same.

Spoiler:

By the way, I completely agree with you in that Java is horrible. In every way possible. Its concept is flawed.

When I checked the unzipped filesize, it was almost 10 MB, so that's what I was concerned about. People today want minimalist software for seemingly small tasks.

After removing the icon, and rebuilding the project, it was 4.9 MB.
I also had an icon in GBA.dll, it's filesize was reduced to < 22.5 KB ( compared to 525.kb ).
But really dude, nobody ever looks at disk-size for their programs anymore. That's a thing of the 90's that rieks of hdd's that used fat-ribbons, and a GB of disk space was considered grandeur.

Also, the concept behind Java is absolutely brilliant. It's implementation is crappy though, it's clunky, and just generally not well executed in my own experience. And what does your code have to do with beginners??? Any one who is using your program will likely not care what language it was written in, nor will the language have an impact on a users ability to use a program short of not having support for it.

That is, of course, implying that C++ doesn't have its own downfalls. Compatability and having to install proprietary software to get any of it to work is a disaster.
Sometimes, its easier to have a program that can be used across multiple platforms.
Of course, since most rom editing tools are .exe, it would be implied that rom hacking would be done on Windows (and in that case, you would have your C++ updated)

anyway, back on topic, I think that this idea is very nice. I'm keeping my eye out for updates.

C++ takes a lot more time than would C# or Python. If I were to use any other language, it would be Python.
However, most machines will have .NET runtime installed, linux and apple have mono, so it's all good.
And considering that on average, hard drives are 100's of GB large, even 10 MB is laughable.
And you can't blame a language for proprietary software. It's the programmer's job to make sure and make using the software is easy. If your software uses gtk+ runtime, you better link to a gtk+ installer, or include it with yours. Also, you don't update your C++. You can update your VCRT which is Microsoft's C++ .NET hybrid freak of nature that I'm legitimately scared to touch with a 9-yard stick, but for the most part libstdc++ rarely updates and if it does the dll is small enough you can package with your app or compile it into your app.







































ANYWAYS.

this is the closest thing I have to a spec I have for how the plugin framework will be. Suggestions? Also, I'm about to make a git for this so that people can follow code-progress.