[Rodimus Primal]

Sweet Jesus! Glad you've finally got the translation completed. This game need the TLC you've been able to bring to it.

[immortal142]

I can't wait to try this out, I wish someone would do this with FF5.

[Bregalad]

Don't you need for a fairly large amount of RAM to use LZ encodings? (I know the traditional is a 4KB window but that's a ton of space an NES game is not likely to have). (FF1 used only a small part of the SRAM for actually saving a game but it still used most of the rest of that space for other stuff I think.)

Not if you're compressing graphics, you can read back from VRAM. For any other use, yes, LZ77 is problematic on NES. 4k is an entiere tileset by the way, so the window is probably smaller - I don't remember my program automatically finds the optimal window size using brute force (i.e. compress data with different window sizes and keep the smaller data).

[KingMike]

Reading back from VRAM? Could that cause slowdown/noticeable loading time?

[Bregalad]

Reading back from VRAM? Could that cause slowdown/noticeable loading time?

Yes, just like any form of compression.

[Reiska]

As a heads-up: the battle windows have some minor graphical glitches in puNES.  Looks fine in nestopia though.  Not sure what's up with that, I'm not an emulator expert, but.

The new script looks great

EDIT - Typo report: in the conversation with Sara in the Djinn cave, the lead party member says "Looks like we have choice..." - it appears that a "no" got dropped.  Also, in her B button chatter, there's a missing 'c' in 'susceptible'.

[Chaos Rush]

As a heads-up: the battle windows have some minor graphical glitches in puNES.  Looks fine in nestopia though.  Not sure what's up with that, I'm not an emulator expert, but.

The new script looks great

Would it be possible to take some screenshots? I'm assuming it has to do with overscan since some emulators have an option to crop the borders of the screen since some NES games dump garbage data there. I expanded the battle windows to those areas as I figured it should be fine as long as no text is displayed there, and FF3 doesn't dump garbage data on the borders. The emulators I use are FCEUX on PC and FCEUGX on Wii and they both look fine.

EDIT - Typo report: in the conversation with Sara in the Djinn cave, the lead party member says "Looks like we have choice..." - it appears that a "no" got dropped.  Also, in her B button chatter, there's a missing 'c' in 'susceptible'.

Thanks for pointing these out! I will admit that it the script might have been rushed (sorry ), because I really wanted to get this over with before I go back to school.

Some time next week I'll release v1.1 which will fix these typo's and a couple other typo's I found. If I have time I'll try and get the B-Button dash working too, as well as release my text editor (but keep in mind I have a full-time job during the summer so I can't get it out right away)

EDIT: The issue I'm running into with the B-Button dash is that there isn't enough space in the PRG bank that the default game's walking routine is located in. I've tried doing bank switching but the way the routine is set-up doesn't allow enough bytes to do that without corrupting another routine that's right next to it (luckily I didn't run into that problem when modifying the message loading routine, otherwise this whole project would have been impossible lol). My only option would be to do a jump to another offset within that bank, but there doesn't seem to be any free space available...

[mikeprado30]

Thanks a lot for releasing this renewed script for this great game, Chaos Rush!

Actually I'm into Dragon Warrior saga, but I hope one of my next games will be this one once again!  Brings me great memories from my Hi-School days when I beat this game 

[Rodimus Primal]

Would it be possible to take some screenshots? I'm assuming it has to do with overscan since some emulators have an option to crop the borders of the screen since some NES games dump garbage data there. I expanded the battle windows to those areas as I figured it should be fine as long as no text is displayed there, and FF3 doesn't dump garbage data on the borders. The emulators I use are FCEUX on PC and FCEUGX on Wii and they both look fine.
Thanks for pointing these out! I will admit that it the script might have been rushed (sorry ), because I really wanted to get this over with before I go back to school.

Some time next week I'll release v1.1 which will fix these typo's and a couple other typo's I found. If I have time I'll try and get the B-Button dash working too, as well as release my text editor (but keep in mind I have a full-time job during the summer so I can't get it out right away)

I think at this point don't rush a new release since folks will he reporting typos. It will give you time to get that B Button dash working anyway. Believe me, I know how busy real life can get.

[Chaos Rush]

I think at this point don't rush a new release since folks will he reporting typos. It will give you time to get that B Button dash working anyway. Believe me, I know how busy real life can get.

Alrighty then! I just don't like the thought of over a hundred people already (according to the RHDN page, 105 people have downloaded this patch) encountering typo's, but I pretty much had to rush this because it was really important to me to get it out before school starts again, because I have no idea how much I would have been able to work on this once school starts (had I not finished this before summer) because I'm going into university, and there's just gonna be some big changes in my life coming up.

Of course I'll be busy, but it doesn't take much to just open up my text editor, fix some typo's, and release a new patch. Anyhow I'll take your suggestion and wait a little longer for a v1.1 release.

Thank you all for your support!

[KillerBob]

Would it be possible to take some screenshots? I'm assuming it has to do with overscan since some emulators have an option to crop the borders of the screen since some NES games dump garbage data there. I expanded the battle windows to those areas as I figured it should be fine as long as no text is displayed there, and FF3 doesn't dump garbage data on the borders. The emulators I use are FCEUX on PC and FCEUGX on Wii and they both look fine.

Don't know if this is the kind of glitchy graphics Reiska encountered?



This is in Nestopia btw. I only checked the beginning cavern of the game and what is odd about it, is that I think I could only trigger it in the very first battle of the game. It happens when you switch rows, the glitchy message push the character names off screen before they take action. The character names in my example are AAAA... BBB... and so forth, so not part of the glitchy graphics in case you wondered.

[Chaos Rush]

Don't know if this is the kind of glitchy graphics Reiska encountered?



This is in Nestopia btw. I only checked the beginning cavern of the game and what is odd about it, is that I think I could only trigger it in the very first battle of the game. It happens when you switch rows, the glitchy message push the character names off screen before they take action. The character names in my example are AAAA... BBB... and so forth, so not part of the glitchy graphics in case you wondered.

Oh, I see what the problem is. All battle messages are located in the same text bank, so for those two particular messages I wasn't sure if they were commands or not, because their indexes are lower than the Attack command, which I assumed would be the first one . They break the five-character command limit, causing glitches:

I didn't even know you could change rows mid-battle, lol. The commands in Japanese are ぜんしん and こうたい for "Advance" and "Retreat", respectively; and because I wasn't sure how those two message indexes were used, I simply translated those words and hoped it would work in whatever context it appears in.

Turns out the same issue occurs when you move up a row:


 Now that I know how that those messages are commands, I have already fixed them for v1.1, to "Front" and "Back":

[KillerBob]

Now that I know how that those messages are commands, I have already fixed them for v1.1, to "Front" and "Back":

Nice, glad I could help. Also, congratulations for finishing this! Looking forward to check it out seriously.

[Chaos Rush]

I've worked out a fully functioning B-Button dash that is properly disabled when somebody is following you. It will be implemented in v1.1, but for those of you that want it early, make these byte changes:

0xFCDEB: 4C A6 FF
0xFFFB6: AD 0B 60 C9 00 D0 08 A9 01 85 34 24 20 50 02 E6 34 60

I was able to do it without resorting to convoluted bank switching shenanigans, as it turns out the MMC5 mapper patch freed up some space in the bank that the walking routine is located in!

[linkncb16]

Okay I am super curious, how did you make this possible?! If all you were able to edit was in Hex, how in the world were you able to program something entirely new into the game??

[Chaos Rush]

Okay I am super curious, how did you make this possible?! If all you were able to edit was in Hex, how in the world were you able to program something entirely new into the game??

There's a FFIII ROM map on DataCrystal, which lists the offset that controls the walking speed in towns and dungeons. Working off of that, I used FCEUX's debugger to place a breakpoint on that offset and looked at the surrounding code, then wrote ASM code using an opode chart to manipulate the RAM values as needed. The game's original code writes 01 to RAM offset 0x34, while my code first checks if someone is following you by checking the byte at RAM offset 0x600B, then checks the byte at 0x20 to see if you're holding the B-Button, and if you are, then write 02 to 0x34. If you aren't holding the B-Button or if someone is following you, then it will write 01 to 0x34.

[Reiska]

The glitch I saw is different from the one described:

[reyvgm]

Thanks for this. Looks and feels really well done.

[Rodimus Primal]

There's a FFIII ROM map on DataCrystal, which lists the offset that controls the walking speed in towns and dungeons. Working off of that, I used FCEUX's debugger to place a breakpoint on that offset and looked at the surrounding code, then wrote ASM code using an opode chart to manipulate the RAM values as needed. The game's original code writes 01 to RAM offset 0x34, while my code first checks if someone is following you by checking the byte at RAM offset 0x600B, then checks the byte at 0x20 to see if you're holding the B-Button, and if you are, then write 02 to 0x34. If you aren't holding the B-Button or if someone is following you, then it will write 01 to 0x34.

Interesting. So it fixes the talking issue with the function. Nice. Since you've fixed this and hopefully the Change Rows bug, perhaps it would be best to release the 1.1 update.

[A.D.R.I.A.N]

Chaos Rush, i have a question for you:
Does the item upgrade trick is still here?, just wondering.