So first off, big shout-out for everyone who got a gameplay hack turned in on time for FEE3. Y’all are awesome and your content is about to be shown off by some really cool LPers.
I’m still working on the promised
dsa v.2.x.y and I’m really liking the progress I’m making so far - my vision is coming together, the latest iteration of an idea that’s been stuck in my head for literally over 15 years, since even before I knew anything about Fire Emblem. By the time the show is underway I am expecting to have a public release out and hopefully some kind of promotional video to include in the actual FEE3 showcase.
With that said, I thought I’d take a moment to hype up the project and tackle some “”“Frequently Asked”"" Questions. Also in this thread I’ll be posting progress updates, teasers etc.; and when public releases start I’ll be updating this OP with links.
What Is DSA?
DSA stands for Data Structure Assembler.
It’s analogous to EA (Event Assembler), but more general-purpose in intent and design. I’m making it to be a true “everything editor” from the ground up, with a more powerful language raws system (internally these files are either
type description files or
structgroup description files) that gives types to data and names to values, and a plugin system for things that can’t be handled in EA style.
What can I do with it and how does it work?
In short, everything you can do with the ROM. In theory.
The general look of your file should be familiar: there are “labels” that indicate the start of chunks of data, and then the data mostly is presented as a sequence of “struct” lines (for example, in event code there is one line per event opcode; but a struct could also represent for example a row of a Nightmare table). But there are a bunch more neat features on top of this, and also you don’t need to mess around with a preprocessor to do useful things (and in fact I am not including one for now).
The plugin system allows DSA to extract compressed data and convert file formats (
filter plugins), as well as to present the data in other ways or just toss data into separate files (
interpreter plugins). You can chain filters together and dump the converted data in a file - the current version under development can already take apart FE7 portrait array data and produce PNGs.
Even more than that - DSA is intended as a fully general-purpose tool, beyond hacking or even ROMs into editing whatever binary files. If it has some concept of a pointer to somewhere else in the data, DSA is for you. You just need the right types/structgroups/filters/interpreters.
Why would I use this over other tools?
Depends on the tool.
As compared to things like Nightmare/Nightmare 2 or nmm2csv/c2ea in conjunction with EA, you would use DSA because it’s a one-stop shop that replaces all of that.
As compared to graphical tools, you would use DSA for mostly the same reasons that you would use EA, if EA could do them. Graphical tools that insert stuff directly into the ROM are nice and friendly enough, but when something goes wrong it can be hard to track down the problem yourself, and you probably don’t have a very organized system for backing up your ROM. Keeping a set of readable text files with your changes lets you rebuild from scratch whenever you need to, and it also lets you use a version control system more effectively.
As compared to EA, you would use DSA because it can do those things.
(This is the part where I bash on EA a bit. It feels kinda bad doing this because honestly NintenLord did an amazing job with the project - the “language raws” system resulted from him taking a suggestion of mine and going above and beyond, to the point where I was smacking my head and wondering why I hadn’t thought of it. But it’s been years now, and progress marches ever onward…)
When you disassemble from the ROM, the output automatically fills in “enumeration” names that would normally only be available via macros (i.e., only during assembly), and puts labels on important ROM addresses. So you have a head-start on modifying existing data because you can clearly see what everything is.
The disassembly language is more powerful; it’s not based on assuming the presence of an event ID code. So you can easily use it to take apart table data that you would otherwise describe with .NMMs - and in fact, basic
ea2dsaconversion tools are provided. But of course, it also lets you represent things that Nightmare doesn’t understand, like pointers and custom data types.
The plugin system means you can go beyond the sorts of editing you’re used to doing with EA and into the “everything editor” realm, except instead of relying on
#incextcalling other programs you can use Python code that runs in the same process and is custom-built for purpose. (I also have in mind a system for caching per-file assembly results so you don’t have to wait around every rebuild for all your images to re-convert.)
Oh, and have you ever read the EA license? It’s honestly kind of a mess. I’m putting a lot more thought into the DSA license. I want to avoid any potential confusion or fighting down the road.
How do I start using it on my existing projects?
Simple. I think/hope.
Proper installation instructions will be provided with the release, but basically you will need to
pip install two packages -
dsa-extras - into your Python
virtualenv sandbox (or your actual Python installation, I guess, if you like to live dangerously), and then run a command that
dsa-extras provides to notify
dsa of the added available extras.
To migrate your EA files and other such content, the recommended approach is:
Build your ROM as before, with the old tools.
Use DSA to disassemble the built ROM.
Use the resulting disassembled files going forward.
If you need help with this, let me know and I’ll see what I can do for you.
What is the current version and where do I get it?
By my reckoning, the appropriate version number for the in-development version as I make this edit is (update:)
2.8.226+125, and this release will probably be numbered as somewhere in
+y part refers to commits/changes to the
What are these
The stuff that makes DSA work specifically with GBAFE, basically.
Because DSA is designed as a fully general-purpose tool that I want to be able to show off to people in a professional context, and not have to dance around the topic of ROM hacking, things that are FE- or even GBA-specific have been shuffled off into a separate project. Sorry for adding the extra step. I promise I am trying to make this as smooth as possible.
dsa-extras project is separately licensed. It mostly consists of data that can be licensed under a permissive Creative Commons license (still thinking about this), and I’m willing to put the plugins under WTFPL just to not have to think about it.
dsa itself is more restrictively licensed, for a variety of personal reasons.
How can I help make DSA even more awesome?
If you make or maintain a graphical tool for FE hacking, it would be amazing of you to design it to (or at least add the option) output data for DSA to assemble, rather than editing the ROM directly. Also, you can contribute content for
dsa-extras (as long as you’re ok with the licensing).