New Feature Preview Topic (Happy Anniversary GS TLA Editor!)

Continued from the old topic

Happy 1st year anniversary, GS TLA Editor!

Exactly 1 year ago today the first version of the editor was released. To celebrate, I'm revealing the big new feature for version 0.3 that I hinted about a while back.

The way some of GS TLA's data is arranged is very peculiar, yet very helpful at the same time. At the end of the ROM file there is a large array containing various types of data ranging from graphics, to the games code itself. The new feature of the editor will allow you to browse through all of this data.

It's still in very early stages of development, so it will likely be improved before version 0.3 is released.


Viewing a palette for a map


A tileset, eventually you'll be able to load palettes with them so they aren't just black & white.


A menu graphic


A graphic for one of the Pierrot classes attacks. Despite not knowing what this was the data browser managed to identify at as being compressed, and decompressed it for us, how nice of it. Using the image viewing mode we can see the actual graphic.


Using the Hex option (which will eventually be a full fledged hex editor) on the data browser we see some unidentified data here. To the untrained eye it just looks like a bunch of gibberish, but to me this looks a lot like map data, and that makes sense considering what it's surrounded by. The interesting thing though, is that the editor couldn't identify it as map data which means it isn't actually used in the game at all. Mmm... I do believe the unidentified data below it looks a lot like palette, and tileset data that isn't used at all either. Looks like despite having a map viewer, we still haven't seen all of the maps hidden away in TLA's data.



Also you may notice a value on the top bar of the editor, "1159.57Kb" or something around there. You may have also noticed that this was present in v0.2, but always read "0Kb" Well, now that the automatic repointing system (which assists in the editing of compressed data, ensuring it doesn't accidentally overwrite other data in the game) is finished and working, it keeps track of the amount of empty space in the ROM it has to work with. Golden Sun TLA in fact has 1159.57Kb of detectable empty space to work with, in contrast the original Golden Sun only has 67.36Kb.

Wow, very nice Atrius! Your programming skills are simply amazing.
All this data is very interesting to view even if it isn't possible to edit it yet. Unused maps, palettes, sprites, who knows what lays hidden in Golden Sun...
Can't wait for 0.3!

That awesome. I can't wait to see what can be done once this all editable.

@Atrius: That picture you said wasn't used? That particular piece of artwork IS used. It's the card from the Perriot's Frost Card Psynergy.

Is it? I never actually used the Pierrot class...

Now that Jamie says, it is the Frost Card psynergy graphic I think.
In game it doesn't look that way if I reckon correctly...Or does it?
I never used much the Pierrot classes, only at the beginning to fight the chestbeaters so I'm not really sure.

It is surrounded by graphics for other attack animations.

Excellent work, great to see your still making great progress, you
willing to share any more secrets on what you been working on for this
historic day hehehe

+ Over 9000 thumbs up for this topic

I believe I've worked all the bugs out of text editing. It'll still complain about letter combinations the compression tables in the game don't like, which is really annoying sometimes. I imagine it would make doing any type of translation work extremely difficult. It may be a while before those compression tables can be rewritten.

I've located how playable characters battle sprites are set.

I'm currently working on an LZ77 compression algorithm that I should be able to alter to work with some of the compression schemes the game uses.

THe LZ77 compression algorithm you're working on... will it allow us to change those graphics and sprites as well?

:DDDDDDDDDDDDDDDDDDDD

Interesting to note though, the "hand" selector and the up-down arrows for djinn stat bonuses are compressed for the field view, but uncompressed for the status screen and the djinn release/set stat check in battle. I was quite surprised to notice this when I changed the uncompressed graphic...

oh wow, very impressive Atrius. I am looking forward to the release =D

Wow, very wonderful Atrius. Please promise us that you will never stop working on the editor until it is done, please!

Have a nice day.

I'm Really excited for text editing. Then when I edit my game I don't Have a bunch of new endgame spells called ???. Thank you very much for all your hard work Atrius.

Charon the Ferryman wrote:

THe LZ77 compression algorithm you're working on... will it allow us to change those graphics and sprites as well?

:DDDDDDDDDDDDDDDDDDDD

Interesting to note though, the "hand" selector and the up-down arrows for djinn stat bonuses are compressed for the field view, but uncompressed for the status screen and the djinn release/set stat check in battle. I was quite surprised to notice this when I changed the uncompressed graphic...

Well... The LZ77 compression algorithm isn't much use on it's own, actually it's not even much of a compression algorithm at all the way I decided to format the output, It actually makes the data take up more space. The thing is though that I can take that output, and quickly & easily convert it into several of the compression schemes the game uses (while actually taking advantage of the space saving aspect of the compression formats in the process mind you), of which there are several. I've counted 8 different compression schemes so far (Including the one for text, and 3 specifically for graphics, not that they don't sometimes use the other schemes too). One of those I've just recently discovered when I found the backgrounds for battle, it's the only one I haven't written a decompression algorithm for yet. I can compress things into 4 of those schemes now, including the one for text, one of the sprite compression schemes (I have a second one figured out well enough that I could use it, I just need to get around to writing the code), and two of the more widely used all purpose ones.

The ones I haven't fully figured out backward & forward yet are rarely used, aside from the one for item/ability icons.


Err... I suppose I ought to actually answer the question you asked at some point. Yes, yes it will.

Awesome. Will importing new graphics be part of version three, or a future version? Because I really can't fork over $500 dollars for Photoshop and I don't like going to mysterious websites for illegal software either

YOU DIDN'T SEE THAT XD

It probably won't make it into v0.3.

You know, it would be really useful if you could make the editor WINE (Windows Emulator) compatible... thing is, the program works, but since it needs to get all this information from the rom and the editor bg folder, the layout, it just appears black

Possibly make a version in which the text is Times New Roman and the graphics are stored in the program rather than pulled out of the game and the editor bg folder? It would probably then work in WINE.

I can't use it. If it worked in WINE, that would be great, but that would require it not using DirectX...

It works fine in WINE except that no graphics pop up. I've been able to use menu options by clicking where they would be.

I think it would work if the graphics were stored in the program, like Advance Map (which works fine in WINE).

It doesn't work in WINE on my Mac...

Well that's because it's a Mac. Jaunty rules.

Does it simply not open in WINE? Or do you see the splash? Because I get the splash and a black window which I can use the menu for simply because I remembered where the menu happened to be.

It starts to load the program, with the backgrounds and everything, then says something about an error and shuts down.

You might want to post that error in the error report thread. It might be useful for Atrius... somehow. It might be something to do with either you computer's setup (plugins and drivers and... OH JOY!) or with the fact you may be using an older version of WINE that for some reason or another isn't compatable.

Again, I get it to load but it's black, even though the buttons work, so it's most likely a graphical failure that would be easy to fix.

I did that already on the old forum. I think it might be DirectX related.

Charon the Ferryman wrote:

You know, it would be really useful if you could make the editor WINE (Windows Emulator) compatible... thing is, the program works, but since it needs to get all this information from the rom and the editor bg folder, the layout, it just appears black

Possibly make a version in which the text is Times New Roman and the graphics are stored in the program rather than pulled out of the game and the editor bg folder? It would probably then work in WINE.

Um... The editor doesn't have a ROM to get information out of until you load one, and it displays the interface before that. The only thing it loads from the ROM is the font for compatibility with language versions of the game that don't use a standard Roman font. Not only that, but the editor bg folder is entirely optional, it's only there so you can customize the background image if you so choose. If you deleted it you would just get a plain black background, but the interface would still be there, all of it's graphics are stored in the editor.

Besides all of that, if the editor can't load that information from the ROM, how could it load anything else from it?