RomRaider

We need to start talking again.


I've started reworking the GUI fro scratch to include the notion of "Tuning Entities". A Tuning Entity is something like a stock ECU editor, UTEC, Hyrda etc. I'm busy completing the UTEC implementation and hope once completed we can include the ROM editing RomRaider currently supports.


Alpha quality interface. In no way is this complete, or representative of my hacking abilities.

The "getTableData" method doesn't sit well with me... As shown above it seems like the TuningEntity consumer would walk the TreeNode hierarchy, get a table name from a node, then ask the TuningEntity for the table data...

Will the TreeNode objects returned by getJTreeNodeStructure be objects of a type that you define? I mean, will you have a "public class Table extends TreeNode" somewhere? If so, then you can add a getTableData method on your own TreeNode implementation. Then the code that uses TuningEntity would walk the TreeNode hierarchy and just ask a node for its data.

Also, I'd suggest making a TableData class, even if for now it consists only of a getData method that returns a double[][]. It just seems like a good idea to decouple the "table data" concept from the underlying data type.

NSFW pretty much sums up what I was going say.

I don't currently have anything constructive to say about the interface itself yet (need to think about it some more), but can we please stay clear of the ancient and slow Vector class (and Hashtable for that matter), and also keep the package names all lowercase.

Other then that, how does this fit in with the work Jared has been doing? Is this doubling up on what he may have already done?

I don't think anyone knows except for him, thats why I'm stirring the pot

EDIT: Vectors hashes and other data types are up for defining. Lowercase packages I agree on, I wanted something in svn that screams don't dare touch me yet.

Table Data decoupling: For example, in my UTEC code I've got a DataManager class that has a few static entities to keep in place the current set of maps I'm modifying. (also a few static places for data listeners). This map data is encapsulated in a MapData data type which stores data and produces a Utec friendly map StringBuffer with the needed checksums applied, used lated to upload to the Utec over the serial port.


TreeNodes: Yes, these are custom objects in the tree, I dont really care who asks for table data, either coordinated by the TreeNode object or by an available getMapData(String name) method its all about the same work. What I had envisioned was..

1) User selects between the ROM and UTEC tuning entities.

2) Menus are populated with the tuning entities relevant needed functionality. For example, the ROM tuning entity has no need for a "quer for map #1" over serial port option.

3) User loads set hierarchy of maps that either pertain to an entire ROM or Utec map set. If doing *online* tuning, like over the serial port to the UTEC we want to reduce the amount of chatter. If doing map tuning really over the internet, we should strive for the same reduction of data initially requested (maybe online tuning is a pipe dream, but it would be nice if our application acted in such a way as to facilitate such functionality). Maybe maps of 1-2 levels deep would be initially loaded. A subset of map information queried over the serial port to the Utec, or a subset of data queried through sax (I'm not sure how RomRaider works now).

4) TuningEntity consumer is notified that there are new relevant nodes for the map data pulled. Tuning entity asks for the current node set from the Tuning Entity and displays. A TreeNode has methods available to query for table data, update data, and information on the dimensionality of the data its targeting. 1D/2D/3D dimensionality data would be used to dictate its image used in the JTree.

5) User selects a node, TuningEntity consumer asks node for its data, data is returned, consumer displays data as either a checkbox, JTable, or 3D Opengl table.

6) Data is changed, user selects save, TreeNodes data is updated and the underlying tuning entity in scope gets this data and either updates a ROM file, or talks to the Utec about data changes, or writes Utec data to a map text file.

What I deem as an acceptable implementation changes with the hour. lol

Thoughts? I'd really like to hear from Jared on all this.

I have a big problem with TreeNodes in the current implementation and how they proliferate like crazy. It simply doesn't scale - you need a huge amount of memory just to read less than one MB of map data because it converts all the map data to TreeNodes. Look at what happens now when you load a number of ECU images at the same time.

We should not load map data into Java objects until we are actually displaying the data. This means either passing around references to the raw data to the objects displaying it or just passing in the raw data to the map for conversion.

Some thought should be given to "undo" functionality since that is a common feature request, but as long as store undo info as raw data the amount of memory used by it should be small.

It sounds like this is pretty much how Tgui's "TunerEntity" idea could work reading post 13929 again (btw, anyone else wish phpBB would display post #s?).

No, I never said map data would be included in each tree node. I said each tree node would know how to access its corresponding tuning entity for the data it targets. Be it a query to the Utec or and XPATH query into whatever target in the XML which targets a point in a ROM. Kind of along the idea of the alpha interface with the getTableData(String tableName), ask for it when its needed.

I suggest that each Tuning Entity have a persist method that would commit the map changes and also an undo method that could refer to a finite list of past changes and undo them. Each commited change could be stored in some sort of history object with data on what table was changed, and the data prior to such change.

EDIT: Ohhhh I see now. Ok, when I was talking about prefetching data you were worried about memory usage. I get it Thats a later on idea if we decided to do things over the net. Who knows for now.

I thought I mentioned that.

I'll prototype up something. Not hearing too much opposition. Good suggestions were made and I'll incorporate them.

Well, the new GUI is coming along well. About 30% there but with results to show. The picture you see below shows UTEC map data loaded.

BTW, Those are JTables with custom renderers.

Yet another shot

Looking good.. I see you're still using JInternalFrames in an MDI interface..?

I thought it best to try to copy whats already there. Will make it easier to ensure I include all functionality (well, maybe all). I've already got the code to have a non MDI photochop like interface I can add later.

Once I'm at a stable state I'll need your help with the RomRaider functionality side. That is, if you got the time. We need to code against the tuning entity interface.