16
Final Fantasy IV Research & Development / Re: Zeromus Graphic Replacement
« on: October 27, 2015, 06:51:14 PM »
He's 4bpp, so it's treated as one 16 entry palette.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
17
Final Fantasy IV Research & Development / Re: Monster defense percentages
« on: October 25, 2015, 10:01:37 AM »
Making sure I understand this bug. For the 3 physical defense bytes, the first and third bytes are used properly (base and multiplier) but the middle byte for evasion/percentage is erroneously left at zero? And the same pattern occurs for the 3 magical defense bytes?
When reading battle algorithms documents before, I got the impression that more of the values were treated as zero, but I now think that is wrong.
When reading battle algorithms documents before, I got the impression that more of the values were treated as zero, but I now think that is wrong.
18
Final Fantasy IV Research & Development / Re: Do PC spells use MP in autobattles?
« on: October 24, 2015, 07:47:10 PM »
A tiny bit of rust removed... It appears that in one of the spell routines, it checks the auto-battle bit as one of a few reasons to skip the MP-using section of code. Along with checking if it's a monster casting, and some other mystery byte at $355D I have not yet identified.
$388B appears to simply have a copy of the 0x20 bit from the encounter flags byte, which is auto-battle.
Thanks for the moral support!
Code: [Select]
03:CE46 AD 8B 38 LDA $388B
03:CE49 D0 30 BNE $30
$388B appears to simply have a copy of the 0x20 bit from the encounter flags byte, which is auto-battle.
Thanks for the moral support!
19
Final Fantasy IV Research & Development / Re: Zeromus Graphic Replacement
« on: October 24, 2015, 07:14:08 PM »
I know it wasn't on purpose, that's part of why it was funny. I know what you mean though. That page has really helped me make some of my breakthroughs figuring out spell animations and other graphics-related code, but it's definitely not very clear.
20
Final Fantasy IV Research & Development / Re: Zeromus Graphic Replacement
« on: October 24, 2015, 03:10:19 PM »I don't come from a programming background, so most of what I say should be generally understandable
hahaha coming from a programmer background, that was an awesome dig
21
Final Fantasy IV Research & Development / Do PC spells use MP in autobattles?
« on: October 24, 2015, 03:06:40 PM »
Do PC spells use MP in autobattles? It seems they must not, because the scripts would stall out if spells could not be cast to kill or trigger monster AI reflex scripts. Also, in Tellah vs Golbez, Tellah casts Meteo and he never has the 99 MP necessary. So does anyone know if that is true about autobattles?
I took a major hiatus and am trying to get back into my project, and I am super rusty. Appreciate the help!
I took a major hiatus and am trying to get back into my project, and I am super rusty. Appreciate the help!
22
Final Fantasy IV Research & Development / Re: Grimoire LD's Notes, Patches, and Hacks (Pointer Table to Event ID Routines)
« on: March 19, 2015, 08:32:39 AM »Can anyone think of any events that use the "move camera up one space then down again" instruction?
This one is used in some events that really want to shake the screen for effect. I think when the Enterprise is crash landing in the underground, maybe the Leviathan... It it usually combined with the horizontal screen shake rumble.
23
Final Fantasy IV Research & Development / Re: Japanese Title Screen
« on: March 19, 2015, 08:24:19 AM »
Allow me to add another item that is relevant here. I would split this out from the graphic data in your list, in case it helps dealing with it separately.
Title Screen Layout Table, FF2 US 1.1 (no header): $46000-467FF
These are 2-byte entries which already in the hardware format for background sprite layout. 32 columns by 32 rows, although I think only the first 28 rows are visible. Format:
I haven't looked for the code yet, but I would imagine that in the US version the graphics and layout table are copied to video memory and a couple of registers are set to point at them, and that's about it for drawing a full screen of graphics with this data. I don't have the Japanese ROM at my disposal, but it would have to have at least 2 background layers, and at least 2 (possibly more) layout tables because the Final Fantasy text in the front and back layers use different sprites. These might not have a full 32x32 set; they could composite some smaller subset tables like is done in the prologue text scrolling screen with the castle.
It shouldn't be too hard to find the assembly that loads this data into the video memory and sets up the background layers in the US version, but I don't have the Japanese ROM, so I can only speculate there. But one speculation that I can add with reasonable confidence is that, based on my findings with the palette blinking/rotating effects for other areas of the game, it is likely that the palette rotation effect is applied in an interrupt routine. A custom interrupt will probably be installed somewhere during screen setup, and that will handle the palette effects, possibly also fading from black if that occurs. So the interrupt routine in the US version will have to be modified/replaced in addition to the screen setup code.
Title Screen Layout Table, FF2 US 1.1 (no header): $46000-467FF
These are 2-byte entries which already in the hardware format for background sprite layout. 32 columns by 32 rows, although I think only the first 28 rows are visible. Format:
Code: [Select]
Note these two bytes are in reverse order when in the ROM.
vhopppcc cccccccc
v = vertical flip
h = horiz flip
o = priority
p = palette
c = character number (aka sprite index)
I haven't looked for the code yet, but I would imagine that in the US version the graphics and layout table are copied to video memory and a couple of registers are set to point at them, and that's about it for drawing a full screen of graphics with this data. I don't have the Japanese ROM at my disposal, but it would have to have at least 2 background layers, and at least 2 (possibly more) layout tables because the Final Fantasy text in the front and back layers use different sprites. These might not have a full 32x32 set; they could composite some smaller subset tables like is done in the prologue text scrolling screen with the castle.
It shouldn't be too hard to find the assembly that loads this data into the video memory and sets up the background layers in the US version, but I don't have the Japanese ROM, so I can only speculate there. But one speculation that I can add with reasonable confidence is that, based on my findings with the palette blinking/rotating effects for other areas of the game, it is likely that the palette rotation effect is applied in an interrupt routine. A custom interrupt will probably be installed somewhere during screen setup, and that will handle the palette effects, possibly also fading from black if that occurs. So the interrupt routine in the US version will have to be modified/replaced in addition to the screen setup code.
24
Final Fantasy IV Research & Development / Re: Japanese Title Screen
« on: March 16, 2015, 08:57:34 AM »
What range of bytes did you copy over?
I don't know about the Japanese version, but the US version has a set of graphic sprites and a table that describes the tile layout for the entire screen in a straightforward grid. Looking at your shots of the graphics, I wonder if this is not the case with the Japanese version. I'll also have to look at a video of the title screen again, to see the different phases I seem to remember that the US version doesn't use.
Edit: I see why yours is corrupt looking. The table I mentioned that the US version uses is at 46000 (unheadered) which is where graphics are in the screenshot you provided of YYCHR. So the US code is loading garbage there, and randomish sprites display. As JCE3000GT indicated, the Japanese version does have multiple layers, at least for the text (not sure about the crystal). Each of those would be BG layers, and the US only has 1, conveniently in the hardware format for the whole screen.
So it would certainly be doable to get that title screen in the US rom, but probably not without getting the assembly for it too, and that might not be a simple paste if it doesn't fit in the same place in the US version.
I don't know about the Japanese version, but the US version has a set of graphic sprites and a table that describes the tile layout for the entire screen in a straightforward grid. Looking at your shots of the graphics, I wonder if this is not the case with the Japanese version. I'll also have to look at a video of the title screen again, to see the different phases I seem to remember that the US version doesn't use.
Edit: I see why yours is corrupt looking. The table I mentioned that the US version uses is at 46000 (unheadered) which is where graphics are in the screenshot you provided of YYCHR. So the US code is loading garbage there, and randomish sprites display. As JCE3000GT indicated, the Japanese version does have multiple layers, at least for the text (not sure about the crystal). Each of those would be BG layers, and the US only has 1, conveniently in the hardware format for the whole screen.
So it would certainly be doable to get that title screen in the US rom, but probably not without getting the assembly for it too, and that might not be a simple paste if it doesn't fit in the same place in the US version.
25
Final Fantasy IV Research & Development / Re: Japanese Title Screen
« on: March 09, 2015, 07:15:06 PM »
In the US version, the title (and slow-scrolling prologue) screen graphics/layout/palettes start at 0x44200 in the headered ROM, and the giant block of FF's I assume Grimoire is referring to is 0x438B9 UN-headered, so immediately Before that, rather than after?
The title screen layout table (aka tile positioning) data is at 0x46200....at least in the US version... so I don't think the FFs are for that.
Of course I know zero about the Japanese version.
The title screen layout table (aka tile positioning) data is at 0x46200....at least in the US version... so I don't think the FFs are for that.
Of course I know zero about the Japanese version.
26
Final Fantasy IV Research & Development / Re: Chillyfeez's Mods, hacks, research notes, etc.
« on: March 06, 2015, 07:52:34 PM »
I feel like I have heard mention of using unused char/monster record bytes a few times from you and/or Grimoire, though I could be wrong. But perhaps one could use that area for quite a lot of additional battle-only values per slot if one was to run out of space in the $80-long areas.
27
Final Fantasy IV Research & Development / Re: Chillyfeez's Mods, hacks, research notes, etc.
« on: March 06, 2015, 01:54:42 PM »Are you talking about the timers at 7E2A07?Sure am.
The current version of my User Options patch makes use of some normally unused character stat byte... like 2043,x or something.Well, that'd do it. I wonder how many hacks use the same unused stat byte. Are unused RAM areas known, assuming there are any?
28
Final Fantasy IV Research & Development / Re: Chillyfeez's Mods, hacks, research notes, etc.
« on: March 06, 2015, 09:09:58 AM »... Now here's where the brainstorm really gets good... Instead of [current HP][space][three space wide percentage], we could do [current HP][four space wide meter].
Using the wealth of empty space for numbers and letters leftover from the Japanese editions, we could make 8 new "letters" - a single, right-aligned vertical line (one pixel wide), two pixels wide... All the way up to an 8-pixel full box.
I was just going to suggest an ATB bar too! Would this use the 2nd control timer .. what I call the "master control timer"? That value technically decreases to zero over time starting from a varying value; how would you calculate an increasing percentage from it?
29
Final Fantasy IV Research & Development / Re: Chillyfeez's Mods, hacks, research notes, etc.
« on: March 05, 2015, 05:13:54 PM »
Well I whipped this up before I saw the wayback machine link. Maybe somebody will enjoy it. I don't have an account on RHDN, so I'll try to upload it here.
It's a command line tool for Windows, no GUI. Takes any number of IPS paths as arguments, and displays the file offset ranges and filenames for any conflicts.
It's a command line tool for Windows, no GUI. Takes any number of IPS paths as arguments, and displays the file offset ranges and filenames for any conflicts.
30
Final Fantasy IV Research & Development / Re: Chillyfeez's Mods, hacks, research notes, etc.
« on: March 05, 2015, 12:05:13 PM »I plan to list avalanche and JCE3000GT as hackers on this project, as well as myself.
Very kind of you, though I don't think I really helped any. I was amused to see the difference between my new (large) identifier on that site and JCE3000GT's. (Deservedly so)
The need for some unused space for assembly got me thinking. Is there a tool that can detect whether a set of patches conflict with each other? Detecting logical problems would not be doable, but it should be possible to check if they modify the same existing code or reuse the same unused space. I suppose it would just be detecting an overlap in the range of bytes an IPS modifies.