+- FF6 Hacking (https://www.ff6hacking.com/forums)
+-- Forum: Discussion Forums (https://www.ff6hacking.com/forums/forum-5.html)
+--- Forum: Magitek Research Facility (https://www.ff6hacking.com/forums/forum-9.html)
+--- Thread: Update On Browser Progress (/thread-2878.html)
RE: Update On Browser Progress - Tenkarider - 07-08-2015
Whoa! you can rise the camera so high to the point you can see the map as an infinite rectangle that repeats the map structure over and over
RE: Update On Browser Progress - sleepydude - 07-08-2015
Hehe, yeah that's a cool effect. Math is fun (and hard).
RE: Update On Browser Progress - sleepydude - 07-13-2015
Hehe, connected up the town / dungeon maps to the world map. Still no walking around, just the airship but you can fly into other towns by just flying over them (you have to overshoot them quite a lot, it's not particularly easy, just doable). I think that technically makes this a playable game. A terribly boring, really buggy, and completely pointless game but a game none the less. I'll call it Final Fantasy Mad World for now since it's just filled with characters pointlessly running around.
http://ff3.herokuapp.com/
RE: Update On Browser Progress - madsiur - 07-15-2015
(07-13-2015, 05:40 PM)sleepydude Wrote: Hehe, connected up the town / dungeon maps to the world map.
I like seeing progress on this project. Can we expect a similar loading time in the final product when entering or exiting a town or is there place for optimization?
RE: Update On Browser Progress - sleepydude - 07-15-2015
There's plenty of room for optimization. At the moment, it's still requesting map data from the server, which rips and assembles it. It would be nice to store the formatted data in a database, but I'm guessing I'd probably be crossing several legal lines there, which I probably already am. So what I'll probably do is leave it up to people to upload there own copy of the ROM and just store everything in the browser which should speed things up considerably and make everything nice and legal (of course it'll also mean a rewrite of a few hundred lines of code, but oh well). Since the ROM is so small I can store it in local storage on the user's computer too, so you wouldn't have to upload it every time.
Really it seems like that's something I'll have to do anyway since things like the event code and text jump around so much, it'd be way to much to be making requests to the server every time you open a dialog.
Speaking of the event code, does anyone know how the conditionals work? Also what does command 3D - create object xx mean?
RE: Update On Browser Progress - madsiur - 07-16-2015
(07-15-2015, 11:38 PM)sleepydude Wrote: Speaking of the event code, does anyone know how the conditionals work? Also what does command 3D - create object xx mean?
Command $3D is for creating NPC ($00 to $2D). $00 to $0F is for characters NPC$ while $10 to $2D is for regular ones. NPCs require to be "created" with that event code in order to appear on screen with command $41 (show object). Now I'm not 100% sure all NPCs need to have a command $3D in the code but a lot of them have it. It's also possible to create an NPC with no NPC data with command $3D but you have to attribute graphics and palette with other event commands.
Conditionals work as follow: you can test event bytes with conditionals && or ||. You can test up to 8 conditions (2 bytes each). You can test if an event byte is set by changing the MSB (AND $8000), otherwise it will check if it's clear. The last 3 bytes of the command is the address to jump to if the test succeed.
This is explained in FF3info.txt:
Code:
C0-CF Conditionals:
If MSB of bit to test is 0, the bit will be compared to 0, else it will be compared to 1.
[In a nutshell, if(tx & 0x8000) -> if(*tx); if(!(tx & 0x8000)) -> if(!(*tx))]
If result of all comparisons is true, jump will occur; otherwise, execution will occur at the next command.
Each condition to test (the bit value) is 2 bytes--the address to jump to is 3 bytes, and is added to $CA0000.
C0-C7: $C0B2C8, C8-CF: $C0B32D
C0 t1 addr if(t1) jump; else continue;
C1 t1 t2 addr if(t1 || t2) jump; else continue;
C2 t1 t2 t3 addr if(t1 || t2 || t3) jump; else continue;
C3 t1 t2 t3 t4 addr if(t1 || t2 || t3 || t4) jump; else continue;
C4 t1 t2 t3 t4 t5 addr if(t1 || t2 || t3 || t4 || t5) jump; else continue;
C5 t1 t2 t3 t4 t5 t6 addr if(t1 || t2 || t3 || t4 || t5 || t6) jump; else continue;
C6 t1 t2 t3 t4 t5 t6 t7 addr if(t1 || t2 || t3 || t4 || t5 || t6 || t7) jump; else continue;
C7 t1 t2 t3 t4 t5 t6 t7 t8 addr if(t1 || t2 || t3 || t4 || t5 || t6 || t7 || t8) jump; else continue;
C8 t1 addr if(t1) jump; else continue;
C9 t1 t2 addr if(t1 && t2) jump; else continue;
CA t1 t2 t3 addr if(t1 && t2 && t3) jump; else continue;
CB t1 t2 t3 t4 addr if(t1 && t2 && t3 && t4) jump; else continue;
CC t1 t2 t3 t4 t5 addr if(t1 && t2 && t3 && t4 && t5) jump; else continue;
CD t1 t2 t3 t4 t5 t6 addr if(t1 && t2 && t3 && t4 && t5 && t6) jump; else continue;
CE t1 t2 t3 t4 t5 t6 t7 addr if(t1 && t2 && t3 && t4 && t5 && t6 && t7) jump; else continue;
CF t1 t2 t3 t4 t5 t6 t7 t8 addr if(t1 && t2 && t3 && t4 && t5 && t6 && t7 && t8) jump; else continue;RE: Update On Browser Progress - sleepydude - 07-16-2015
Thanks actually helps a lot, but I guess I'm still a bit confused on what I'm testing with a conditional.
So if I had something like "CO XX XX YY YY YY" I'd be grabbing the byte (I'm guessing from the RAM or SRAM) at location XX XX (is that added to 1E80?) and just checking if 0x8000 is set? That seems like a waste of bits, so I'm guessing there's more to it? Is the location broken up into xxxyyyyy yyyyyyyy or something in order to specify which bit you're checking?
RE: Update On Browser Progress - madsiur - 07-16-2015
I guess I wasn't 100% clean in my explanation. Here's an existing example:
C1 90 80 8E 00 8B D6 01
If ($1E80($090) [$1E92, bit 0] is set) or ($1E80($08E) [$1E91, bit 6] is clear), branch to $CBD68B.
Yes, the parameter event bits are calculated from $1E80.
RE: Update On Browser Progress - sleepydude - 07-16-2015
Ahh... so it's the number of BITS past 1E80, not a byte pointer. That makes sense, thanks.
RE: Update On Browser Progress - madsiur - 07-16-2015
(07-16-2015, 06:25 PM)sleepydude Wrote: Ahh... so it's the number of BITS past 1E80, not a byte pointer.
Yeah sorry I don't know why I used "byte" instead of "bit". I'm kinda rusty with events.