11 March 2016 - Forum Rules
Started by Chaos Rush, July 06, 2016, 08:07:10 PM
Quote from: KingMike on August 17, 2016, 09:07:54 PMDon'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.)
Quote from: KingMike on August 18, 2016, 02:18:45 AMReading back from VRAM? Could that cause slowdown/noticeable loading time?
Quote from: Reiska on August 18, 2016, 04:51:21 PMAs 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
QuoteEDIT - 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'.
Quote from: Chaos Rush on August 18, 2016, 06:55:26 PMWould 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)
Quote from: Rodimus Primal on August 18, 2016, 09:07:34 PMI 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.
Quote from: Chaos Rush on August 18, 2016, 06:55:26 PMWould 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.
Quote from: KillerBob on August 18, 2016, 10:38:52 PMDon'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.
Quote from: Chaos Rush on August 18, 2016, 11:10:50 PMNow that I know how that those messages are commands, I have already fixed them for v1.1, to "Front" and "Back":
Quote from: linkncb16 on August 19, 2016, 07:29:29 AMOkay 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??
Quote from: Chaos Rush on August 19, 2016, 10:39:53 AMThere'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.
Page created in 0.060 seconds with 20 queries.