Poll: What should be prioritized (multiple choices allowed)
This poll is closed.
Events 6.82% 3 6.82%
Monster Graphics 6.82% 3 6.82%
Maps (FF6LE clone) 6.82% 3 6.82%
Sprites (characters) 4.55% 2 4.55%
Monster AI 11.36% 5 11.36%
Strings / Dialogues / Names 6.82% 3 6.82%
Spell data 9.09% 4 9.09%
Item data 6.82% 3 6.82%
Monster Data 13.64% 6 13.64%
Chest data 6.82% 3 6.82%
Animations data 0% 0 0%
Tilesets / Tiles Graphics 0% 0 0%
Shop Data 4.55% 2 4.55%
Monster Formation / Packs 9.09% 4 9.09%
Other misc data (see easy stuff) 6.82% 3 6.82%
Total 44 vote(s) 100%
* You voted for this item. Show Results

Users browsing this thread: 1 Guest(s)
FF6AE

#11
Posts: 61
Threads: 2
Thanks Received: 12
Thanks Given: 15
Joined: Nov 2009
Reputation: 6
Status
Atma
With Monster AI scripts, you just have one pointer table to look up and see where they start (of course you have to run until you hit the second FF after that to know where it ended). Also, each command has a fixed length in bytes, from one to 4, and there's a table for that also. The command is the first byte, and there's no change-of-context to worry about; if it's F1 = target type here, then it's F1 = target type there. It's relatively straightforward, but yes, variable in length which is of course harder than something like Shop data or something which is just straight up fixed numbers of bytes.

On the other hand, Event scripts are a real bugbear. You have a lot of different issues. First off, there is no central lookup table for events. They can be called from Tile Triggers (most common), NPCs (also fairly common), other events (subroutines), hard coded assembly when using certain items (tent, anyone?), and map entrance events (which, when coded correctly, have to have various branches for any changes you may have made to the map-specific temporary event bits).

And there's nothing stopping one event from starting in the middle of another one. That can happen, and I'm pretty sure it does in at least one case.

To make matters worse, event commands are not fixed in length. MOST of them are, but some of them are not. For the ones that are not, you don't know until you read some of the parameters for the command. Which means you can't just arbitrarily read a few bytes ahead and reliably know the commands. If you've tried to write a disassebler for the SNES's processor, you know what a pain the REP/SEP tracking can be, and how easy it is to get incorrect results. The event code is the same way.

Oh yeah, and event code is chock-full of context switches. That's because some of its commands actually spawn a whole other script. Not just one other script, either. There's a script for character event queues, which most people know. There's also a vehicle script, which tells it how to move the airship (or Terra sprite, or bird, or whatever) or a camera pretending to be an airship over the world map. It can also load other maps, but it uses a different byte to do so. Then there's another script, which is rarely used but simulates walking on the world map as a character (this is distinct from non-world-map walking a la the charcater event queue).

To fully handle events properly, you have to, at a minimum, know how to detect all of the above issues. And oh yeah, one other thing: Sometimes an event (or branch within an event) will start off in one of these odd contexts. This is why my event dump has a few hard-coded points where it just had to 'know' that it's in a different context, and if you get an older copy of that dump you'll see that I missed a few before I figured that out.

Seriously, it would almost be easier to pass the whole event system through a separate lookup table (that is, recode it so that instead of addresses you just get an index to a pointer table). It would add a lot of bulk, yes, but it would be so so much easier to maintain.
  Find
Quote  

#12
Posts: 3,561
Threads: 261
Thanks Received: 636
Thanks Given: 254
Joined: Oct 2011
Reputation: 58
Status
Faith
(05-06-2016, 03:05 AM)Imzogelmo Wrote: On the other hand, Event scripts are a real bugbear. You have a lot of different issues. First off, there is no central lookup table for events. They can be called from Tile Triggers (most common), NPCs (also fairly common), other events (subroutines), hard coded assembly when using certain items (tent, anyone?), and map entrance events (which, when coded correctly, have to have various branches for any changes you may have made to the map-specific temporary event bits).

Yeah event calls reorganization (NPC data or event triggers) would be a puzzle but not impossible. Some of those calls as you said are directly called from ASM (tent, chest messages, etc...). If in an event editor you edit event X in the middle of the event code, not only you got to reorganize (pack) all events following (and those calls to events) but there are the conditional branching as well in all those events to reorganize. Pretty much a nightmare compared to AI scripts packing / free space optimization. Zone Doctor has implemented an event editor but event in the latest stable release (3.8.4) using it can lead to entire event blocks being corrupted. There are workarounds I've heard but I never bothered using it, I prefer sticking to hex editing.
  Find
Quote  

#13
Posts: 61
Threads: 2
Thanks Received: 12
Thanks Given: 15
Joined: Nov 2009
Reputation: 6
Status
Atma
(05-06-2016, 03:05 AM)Imzogelmo Wrote: Seriously, it would almost be easier to pass the whole event system through a separate lookup table (that is, recode it so that instead of addresses you just get an index to a pointer table). It would add a lot of bulk, yes, but it would be so so much easier to maintain.

This is what I'd suggest if a community project were taken on. Just give each event an index. No longer worry about where it lands; the whole thing can be relocated and the indexes need not change. I think the overhead of a pointer table would be worth it, and besides, the structural data that calls it (NPC struct, map struct, tile trigger struct) could shrink each entry from 3 bytes to 2, which would more than make up for the pointer table in absolute terms.

Seems like a win-win to me.
  Find
Quote  

#14
Posts: 3,561
Threads: 261
Thanks Received: 636
Thanks Given: 254
Joined: Oct 2011
Reputation: 58
Status
Faith
(05-06-2016, 09:45 PM)Imzogelmo Wrote: I think the overhead of a pointer table would be worth it, and besides, the structural data that calls it (NPC struct, map struct, tile trigger struct) could shrink each entry from 3 bytes to 2, which would more than make up for the pointer table in absolute terms.

I can see some advantage to use a pointer table for reordering purpose of an event editor. If your event at CB/7900 once packed free up 10 bytes after its FE, you just go through all the table and you do if pointer > CB/7900; pointer -= 0x0A.  You still have to do the same with all B2, B6, C0-CF commands concerned but it's a step in the right direction if I understand correctly. This example concern only code packing / optimization which is not a mandatory thing. I think an event editor should disallow expanding events directly in $CA-$CC if the editor does not perform optimization in those banks because of the little free space in ending of $CC, some of it being used by FF3usME and patches.

Also a pointer table could allow an event to land directly in expanded ROM (or other ROM free space), removing the need of a B2 call in $CA-$CC.
  Find
Quote  

#15
Posts: 61
Threads: 2
Thanks Received: 12
Thanks Given: 15
Joined: Nov 2009
Reputation: 6
Status
Atma
(05-07-2016, 02:59 PM)Madsiur Wrote: I can see some advantage to use a pointer table for reordering purpose of an event editor. If your event at CB/7900 once packed free up 10 bytes after its FE, you just go through all the table and you do if pointer > CB/7900; pointer -= 0x0A.  You still have to do the same with all B2, B6, C0-CF commands concerned but it's a step in the right direction if I understand correctly. This example concern only code packing / optimization which is not a mandatory thing. I think an event editor should disallow expanding events directly in $CA-$CC if the editor does not perform optimization in those banks because of the little free space in ending of $CC, some of it being used by FF3usME and patches.

Also a pointer table could allow an event to land directly in expanded ROM (or other ROM free space), removing the need of a B2 call in $CA-$CC.
You make good points there. Being able to re-order events could lead to byte savings with the $Cx commands in particular, and patches or hacks could benefit from having related events close together. This is not to say that it would be really any easier mathematically because of the way events can call one another or branch into one another, but my point is that event $3125 would stay event $3125 no matter its address, and whatever event extraction/insertion tool that is created would, just like an assembler, be able to tokenize the events by number and fix the references.

Medium-term needs, I'd suggest clearing any non-event bytes out of $CC-$CD, which the original code can handle no problem. A long-term, even more massive overhaul would require changing how the event loading commands themselves work in order to subsume more than 4 banks, which would then have no reason to stay in their current location anyway.
  Find
Quote  

#16
Posts: 3,561
Threads: 261
Thanks Received: 636
Thanks Given: 254
Joined: Oct 2011
Reputation: 58
Status
Faith
This project is not dead:


Completion %

- Dialogue & all game text editor (all languages): 80% *
- Font editor: 95% *
- Monster data editor, including steals, drops, metamorph packs, control, rage and sketch commands: 75% *
- Item data: 95% *
- Wallpaper editor: 35%
- GFX Editor (monster & portraits): 50% *
- Text parsing, character Tables (U) & (E): 100%
- Editor reusable controls, structure problems resolved, WPF learning and stuff that made me lost time: 75%-90%

* Beta version once these completed!

I'm also updating the (E) ROM map as I go. More than this is know but I rather double check before filling the wiki. The (U) ROM map has different findings for now, mostly discovered by Everything, Drakkhen and me. The ultimate goal is to have every findings on the 3 ROM maps in same format but for now it is what it is.

I've also updated FF6AE source code (2013 winform version), so if you want to see noob coding, take a peek! I was an ultra novice at the time, and I'm still not an expert coder today :/

I've also uploaded other FF6 / SNES utilities source code that are relevant.
  Find
Quote  
[-] The following 1 user says Thank You to madsiur for this post:
  • Robo Jesus (01-02-2018)

#17
Posts: 4
Threads: 1
Thanks Received: 0
Thanks Given: 3
Joined: May 2016
Reputation: 0
Status
None
Just out of curiousity, is this project dead?
  Find
Quote  

#18
Posts: 2,187
Threads: 89
Thanks Received: 236
Thanks Given: 248
Joined: Aug 2009
Reputation: 40
Status
Nattak\'d
Definitely not dead, just that Madsiur has no time to work on it in some time, but I know he plans to get back to it someday when time is more available.


We are born, live, die and then do the same thing over again.
Quote  

#19
Posts: 3,561
Threads: 261
Thanks Received: 636
Thanks Given: 254
Joined: Oct 2011
Reputation: 58
Status
Faith
(10-03-2017, 11:10 AM)Deus Wrote: Just out of curiousity, is this project dead?

Not dead but development is slow. I need to catch up with school first before continuing. I have other tasks too and I work part time.
  Find
Quote  

#20
Posts: 2
Threads: 1
Thanks Received: 0
Thanks Given: 3
Joined: Jan 2018
Reputation: 0
Status
None
How's this project going? I'm very excited for it, but am also ready to continue waiting.
  Find
Quote  



Forum Jump:

Users browsing this thread: 1 Guest(s)


Theme by Madsiur2017Custom Graphics by JamesWhite