Chrono Trigger Commented Events

[HydroChronic]

Hey Guys,

I've started looking through some of the more complex Event code and have started commenting the existing code.  I am just wondering if this kind of project has been approached by anyone else.  I ask because some of the memory addresses which are referenced are un-named and don't appear in the Memory Map.  I don't want to go re-inventing the wheel if I don't have to.

Also, if no one has tried to do this, would anyone be interested in looking at the comments that I end up filling in?

J

[FaustWolf]

Sounds awesome. You'll have to see if either Vehek, Mauron, or justin3009 have done this yet. If not, this would be an excellent service to the community.

[Mauron]

I haven't done anything like this, and I certainly would be interested in seeing what you do.

Good luck.

[Agent 12]

It's a good idea, there's been many times that I've thought about doing this.  Only problem is the comments are stored in the .proj file that TF products (well...i'm pretty sure they are).

I remember when i first started doing CE I was commenting like CraZY cause i thought it was being stored in the ROM (yea...i was an idiot back then).  So for the longest time i thought other people who were loading up the rom in TF were seeing my comments.  Turns out I was wrong cause we were only sharing the IPS, not the .proj folder  . 

Anyways it's a great idea though i've found that the way that game does certain events is WAY over complicated than what any hacker would do.  I think it's cause their events were tool assisted......um maybe an example would help:

I've found that many times when the game loads an enemy it sets pretty much EVERY value it can....for example sprite priority, speed, movement properties stuff like that.  most of those properties aren't even used and you can usually get by with just loading the sprite.  Why would the developers add this extra code?  I'm guessing they probably had some sort of tool that loads up a map, and they can just like...drag and drop the enemies onto the map.  And dragging/dropping would set all those properties for that enemy.

So if I were you I would comment, like....cutscenes which were probably closer to being coded line by line then other parts of the game.  Things like loading objects and battles were probably automated and for our purposes it's probably better to check out the how-to thread.

--JP

[HydroChronic]

What would be the best way to distribute what I've done once I get to that point?

I ask because I've already hit a bunch of memory locations which I'm not clear on what they are referencing.  It may be that they are used to communicate state between locations, or some other more specific use.  I'm hoping that someone more familiar with the game systems will be able to fill in what I am missing.

I've also put together a spreadsheet of information surrounding the Location Tilesets and the Pallets they work with.  I plan on doing the Overworld Tilesets and Pallets as well, but haven't gotten to it yet.  Again, not sure if someone else has already done this.

Jsondag2 - I'll try to isolate the portions i end up commenting.

[Geiger]

I think it's cause their events were tool assisted.

Actually, almost all signs indicate that very little in the game was tool-assisted (code after gotos, code pointing into the middle of other commands, etc).  It would seem that even as of v2.0, Flux was a more capable materials editing system than the original developers had access to.  Another point to remember is the game was released in 1995.  Think of the sort of computers and software available at the time.

The current comments system will be obsoleted in a later version of Temporal Flux.  I already have plans and some code towards this end, but I'm not sure if it will make it into the next release.  It will still be able read the older style comments, so feel free to continue on with this project.

[HydroChronic]

Ah, ok.  So don't isolate sections I comment... got it.

I totally agree that, from what I've seen, most of the game was coded by hand.  Clearly done by multiple programmers due to style differences such as always including End/Return statements or simply using Gotos.  There is also a lot of evidence of programming practices from the time, ie. lots of complex spaghetti code.  But, in the developer's defense, these were likely influenced by the systems and hardware they had access to.

So in order to distribute my progress I just need to zip the .proj folder?

[ZeaLitY]

Yeah. And I think we'll just unzip the folder to the ROM's folder and make sure the ROM name / folder name.proj are the same.

[Agent 12]

I think it's cause their events were tool assisted.

Actually, almost all signs indicate that very little in the game was tool-assisted (code after gotos, code pointing into the middle of other commands, etc).  It would seem that even as of v2.0, Flux was a more capable materials editing system than the original developers had access to.  Another point to remember is the game was released in 1995.  Think of the sort of computers and software available at the time.

Yea sorry my wording was  a little strong.  I definitely think most of it was written by hand, but I do think that they had some sort of way to Add enemy objects automatically.  Just cause of the reasons stated above. All of the actual interacting between objects and cutscenes, battles has hints of being written by hand but the "startup/load" has looks like it was automated.

By the way I totally agree that they didn't have a anything close TF-like for editing every aspect of the game as easily as we do

--JP

Edit:  Thinking more about what Geiger said about it being relieased 1995....I'm actually probably wrong here atleast with the "drag and drop", I do stand by they weren't doing enemy loading line by line like we do but they could have had some sort of macro like thing to load up all the unnecessary properties.   Also Hydro, make sure you clear out the "backups" of the rom if you have them in the proj file before zipping it up. 

[HydroChronic]

Hey Guys,

I've finished the {000} - Load Screen and {1B1} - Title Screen.  I'm posting what I've done for these so I can get feedback early and make any adjustments or corrections that people catch.

So let me know what you think.



[attachment deleted by admin]

[HydroChronic]

Hey,

I've continued going through the Events by Location from the beginning of the game.  I have been doing tests on commands which I don't completely understand and have been coming up with good results.  But I am confused as to the differences between End, Break and Return.

From my programming background I would assume that End completely ends all execution, Return would return to the calling line of code and I figured that Break would be used for some sort of Debugging, but this doesn't seem to be the case.  Can someone clear up what Break is used for?

Thanks.

[Geiger]

I am confused as to the differences between End, Break and Return.

The three basically differ only by what happens on subsequent calls to that function.  Return will start back over at the beginning.  Break picks up on the command immediately following it.  End will always return to itself, keeping the function from being run again.