Bunch of random improvements in my branch

[binary1230]

Hey guys,

I love this tool and have been hacking on it in my own fork. There's a few pull requests open if you want them but after I did those I've also been (not that carefully, for now) throwing lots of improvements in my fork sort of sloppily.

To name a few:
ux stuff: progress bar support for long loading tasks, remember last project file and auto open it, some validation, csv import of labels
Integrated from the other fork and improved/sped up a bit the usage log and memory map import. Added ability to add comments to labels for documentation.

I also found a bug in asar revealed by diztinguish's (correct) generated asm that I submitted a patch for RPGHacker/asar#171

I'm using diztinguish and kind of modifying as I go for a fairly ambitious disassembly project that's been going well.

My informal side goal is to make it so diztinguish can be sort of a browsable 'source of truth' for looking at the whole rom, with the exported disassembly being as one-way read-only as possible. (I.e. if things are discovered about variables, offsets, constants, etc, the workflow is: you update in diztinguish and re-export, never needing to touch the generated asm by hand).

My question is, is anyone here working on any larger changes to diztinguish, i.e. should I try coordinating for larger architectural changes before I just run off doing random stuff with the fork? If so, I'd be happy to be a bit more careful and repackage what I've done in some sane pull requests. Otherwise I'll probably just keep checking stuff directly into master on my fork.

Alternatively, I'd be happy to jump in as a maintainer, maybe we get another release going and tested.

Cc @Dotsarecool @VitorVilela7 @KonKeyHD and fork authors @gocha just to see if anyone has any strong opinions on any of this.

Thanks all

[IsoFrieze]

I haven't touched this project in forever so you are free to do whatever you'd like. I'd be happy to give you collaborator status as well since you're actively working on changes while working on projects of yours.
It would also be nice to have someone who actually knows how git/GitHub works managing the repo, heh.

[binary1230]

Sure @Dotsarecool, if you're ok with that, happy to work on the main repo.

In my fork currently, I'm finishing out converting the save format to XML, though the main table section is a custom block of text encoded heavily to save space. End result is a fully ASCII save format that tries to be text merge friendly. The idea being you can get multiple people working out of the same save file and then have a decent chance merging it back together after.

It required me to take a lot of the classes like Data and Project and turn them into normal non static classes, so that change will be fairly heavy if brought back to the main fork. It does open up some interesting doors though, now you can instantiate multiple project files which can lead to things like multiple windows, comparing and merging two documents, labels, etc.

[binary1230]

Oh and the save format is about 1.5MB uncompressed in mergable form. I was thinking about having that be the default format, though, I'm sure running it through zlib like we currently do would greatly compress the filesize, at the expense of human mergability

[binary1230]

Alright and..... I kinda went way off the deep end and basically refactored most of the code base to try and get some model/view/controller type stuff going on, to make it easier to later do things like have multiple windows, undo/redo, stuff like that. I've been having a little too much fun with this :)

I have a bit of a zany pipe dream I'm playing with to take the usage data out of bsnes and pipe it live into distinguish, and possibly from multiple clients simultaneously. The idea might be that you can get a group of friends doing a playthrough of a game, have their emulators stream the data back to diztinguish, and basically you get a team of people whose goal it is to try and cover as much usage of the game as possible.

I'm basically done with all that and just testing now, should have that wrapped up next couple days. the XML serializer is pretty cool because, with the exception of the main data table, everything else is just serialized based on any attributes of a class that are public. So, it should be really easy to add new functionality or storing data in there, and you get the load/save functionality without having to explicitly code anything.

[binary1230]

I'm going to close this issue out and start a new listing the steps for getting a 2.0 release going.

I have a refactoring just about complete in my fork that moves us much closer to a model/view/controller type situation, will make it easier to write some tests and multiple views of the same data. The intention here will be to make it easier to do things like the graphics data viewer, overall layout map, etc. And then make all of it pretty extensible.

Maybe someday the guts of this can have tighter integration with stuff like bsnes, asar, etc for making this a one-stop tool for all romhacking stuff. Would also be easy now to setup extensions, might be cool to patch in some open-source game-specific tools that already exist.