I'm looking to get a little help or ideas on some design aspects of my WIP utility TextAngel. In a bit of a novel approach, this program aims to both dump and insert using the same interface. I found that if I had enough information to get the text out, that same information is usually enough to get the text back in. That holds true for most supported cases. I offer Atlas compatible dumping output in the event you need to go beyond what my program can handle insertion wise. Sometimes a novel approach is novel only because everybody else thought it was too stupid to bother with! And for every successful idea, there are many failed ones. I hope that is not the case here!
Here are some screenshots and an overview of how the utility is currently laid out:http://transcorp.parodius.com/forum/YaBB.pl?num=1273690996
Software design wise, I have an input, a pipeline, and an output. Then I simply have descriptor attributes about each to determine exactly what to do with it in the pipeline, and helper objects to do the work. The idea here is when you are dumping, you assemble all source
pointers and encoded text strings into a standardized data structure. When you insert, you would assemble all destination
pointers and decoded hex strings into that same standardized data structure. Then you can post process in any variety of ways to transform, order, and process before you sent it over to the final output stage. In the output stage, you handle outputting to text files, inserting into ROM etc. The output stage is somewhat simple because it's just going to traverse the data structure and insert pointers and strings per what's defined there.
The first question one might ask me is what kind of data structure are we talking about here and how it can serve both dumping and inserting needs? That's a good question and one of the main design issues I'm looking for assistance on.
I'm sure I may need to collect more information later, but this is what I have now which works for most of my test cases thus far.StringInfo Object:
StringStart - Starting location from data file
StringEnd - Ending location from data file
Text - Text String
Hex - Hex Encoded Representation of String
EncodedByteLength - Original byte length when dumping (assumes post processing will alter 'Hex' property.PointerInfo Object:
Format - A PointerFormat structure with all associated parameters describing the format of this pointer.
PointerLocation - The location the pointer was taken from for dumping. The location it should be written to for insertion.
PointerValue - The pointer value itself.
Note: Methods are immaterial here and not listed. The issue at hand is with data structure/representation only.
Now, I just tie them together and make an associative array out of it. Each entry has a pointer and associated string and all information we need to do a variety of things with them before output. So, the standardized data structure is the associative array.Questions:
1. Does this approach make sense to anybody else? I am a solid mechanical coder, but I have never been great at software design.
2. If the approach doesn't sound like one a retarded monkey would take, does anyone have any better ideas for a standardized data structure? Mine feels a bit off to me.
3. I seemed to back myself into a bit of a wall if I attempt to do something a bit more complicated. For example, the pointer tree method, even with just two layers, assumes you'd have a 'master' pointer table with every pointer pointing to smaller pointer tables with pointers to strings. How do I represent this? Well, with my seemingly naive design, I would simply have a list of pointers (that do not have string info) with each pointing to it's own associative string/pointer pair array. That doesn't sound too horrible at first until I think about adding more layers, and how cumbersome it will become to navigate. It seems to point to a problem in my data structure.
Any feedback or ideas would be helpful.