FFIV Cosmetic Changes 2 and Long Range Fix - Finished Repro Cart

[rCadeGaming]

Hi,

I joined this board to ask some questions about Spooniest's translation/hack linked to below.

FFIV Cosmetic Changes 2:
http://www.romhacking.net/hacks/951/


1.  At first, I was having trouble applying the patch.  I didn't think to remove the header first, as it doesn't say to do so the way most translation/hacks specifically recommend, it just says to use the Japanese ROM.  Without removing the header, it wasn't working with a known good dump of the original Japanese ROM.  Then I happened to try it with a ROM that was pre-patched with j2e's translation (which CC2 is based on), and it seemed to work (maybe because it was unheadered), except that the lowercase "f" in text boxes looked off.

Finally, I came to my senses and tried removing the header from the original ROM, and then applying the patch, which worked perfectly.

Anyway, I just wanted to confirm that this is the correct way to do it.  You simply take the raw Japanese ROM, remove the header, and apply the CC2 patch, correct?  Even though it's based on the j2e translation and the original cosmetic changes, you don't need to apply them first; CC2 is a complete stand-alone package, correct?


2.  After getting CC2 working, I applied Dragoon Zero's Long Range Fix patch on top of that.  I was just wondering if there is any problem in doing this; if it's redundant (I don't think so, there's no mention of it in the CC2 readme) or if it will cause any conflicts?


3.  What do you think of the Long Range Fix?  From the description, it sounds like a pretty important thing that should be fixed.  I'm just wondering why this isn't integrated into more translations and hacks.

Long Range Fix:
http://www.romhacking.net/hacks/892/


4.  I'm going to attempt burning the patched ROM to EPROM chips and make a cartridge to play this on my actual SNES.  Don't worry, I'm only making one for personal use, and I will NOT be selling it ever.  Also I'll be using the Super Famicom FFIV cart as the donor cart, so I think it makes this all legal, since I own an original copy.

Anyway, I'm just wondering if there's anything about CC2 (or Long Range Fix) that would cause problems running on actual hardware?

[danke]

Spooniest doesn't have an account here?

[rCadeGaming]

???

When clicking on his name on the CC2 page it says he doesn't.  Also I tried searching the community database and it didn't come up.

No matter, thanks for the link.  I sent him a PM and asked him to take a look at this.

Any info from anyone else who's willing to chime in is welcome as well.

[Spooniest]

Anyway, I just wanted to confirm that this is the correct way to do it.  You simply take the raw Japanese ROM, remove the header, and apply the CC2 patch, correct?  Even though it's based on the j2e translation and the original cosmetic changes, you don't need to apply them first; CC2 is a complete stand-alone package, correct?

This is correct to the best of my knowledge and I forgot to put that in the readme.

2.  After getting CC2 working, I applied Dragoon Zero's Long Range Fix patch on top of that.  I was just wondering if there is any problem in doing this; if it's redundant (I don't think so, there's no mention of it in the CC2 readme) or if it will cause any conflicts?

I don't see why it wouldn't work, but I can't tell without testing it.

3.  What do you think of the Long Range Fix?

If a character is capable of long range attacks (Edge, Cecil and Rosa in the endgame), they either do more damage on the front row (Edge, Cecil) or I never have them use a short range weapon. It's an oversight born out of my playing style.

4.  I'm going to attempt burning the patched ROM to EPROM chips and make a cartridge to play this on my actual SNES.  Don't worry, I'm only making one for personal use, and I will NOT be selling it ever.  Also I'll be using the Super Famicom FFIV cart as the donor cart, so I think it makes this

I wish I could do the same thing. Let  me know if it works, ok?

[DarknessSavior]

???

When clicking on his name on the CC2 page it says he doesn't.  Also I tried searching the community database and it didn't come up.

No matter, thanks for the link.  I sent him a PM and asked him to take a look at this.

Any info from anyone else who's willing to chime in is welcome as well.

This is because he apparently hasn't set up his community profile (the one that shows up when you click his name in the database). But he has a forum account.

~DS

[rCadeGaming]

Thanks for the reply Spoony.

I wish I could do the same thing. Let  me know if it works, ok?

I've got the ROM all ready for burning to eprom chips, just waiting for stuff in the mail.  I'll let you know how it goes.  FFIV is fairly simple to repro, a little more so than V and VI, which I'll be trying next.

[rCadeGaming]

Ok, I finished the repro cart today, and it works very well in the real SNES!   

The only problem that I've noticed is a flickery, stray white pixel, sticking out to the left on the right side of the white border for text boxes, near the bottom right corner.  It always appears on the text boxes when you're talking to someone, not the ones in battle or the x menu or anything.

I don't know if it's a problem with the way the text translation works, if I got something too hot while soldering the EPROM's onto the cart, or if it has to do with the SCART to component transcoder I'm using (haven't had any other problems with it though).  Any ideas?

Other than that it works pretty good from what I've seen, only played it for about half an hour though.  Currently playing Final Fantasy Adventure on the big brick Game Boy, so I'll play through IV on this cart once I'm done that.  I'll try something different than the SCART to component transcoder to see if we can rule that out, and let you know if I find anything else.

[LostTemplar]

You could try it in bsnes. If that stray pixel doesn't appear there, then it's very, very unlikely that it's the translation's fault. If it does appear, then it's the translation for sure (well, if it doesn't happen with the original game).

[rCadeGaming]

I tested my patched ROM in ZSNES, no stray pixel.  Does it matter if I use that instead of ZSNES?

[Azkadellia]

ZSNES is a terrible emulator. It's outdated, uses game specific hacks (meaning fudging accuracy to make a game work), and is horribly inaccurate.

[rCadeGaming]

Ok, tested it the newest BSNES, 091 64-bit "accuracy" build.  No stray pixel.

Is it possible to cause something like this by heating up the EPROM too much with a soldering iron?

[Klarth]

Is it possible to cause something like this by heating up the EPROM too much with a soldering iron?

I'd say the possibility is low if you only have that one subtle side effect.  That's essentially one (or two) screwed up bits out of an entire EPROM.

If you have a device that can dump ROMs via cart, try to dump the ROM you burned and check the integrity vs the original ROM.  At least you can rule out one big variable that way.

[Bregalad]

Are you using a PAL or NTSC Super NES ?

FFIV uses IRQs for changing the scroll value during HBlank (instead of HDMA, which most SNES games uses). I think the translation expanded the size of the box, and this could be where the stray pixel comes from. In other words it also happens on the other versions of the game, but was invisible.
I've played through FF4 with my powepak with my PAL SNES (I played the official translation though) and I don't remember seeing any stray pixels. I could try any other version of the game when I'll get back home and see if they appear.

[rCadeGaming]

Klarth, unfortunately I don't have any ROM dumping devices.

Bregalad, I'm using an NTSC SNES.  Your explanation sounds to be by far the most likely so far.

I tried a different transcoder, as well as just the regular composite cables and the stray pixel is still there, so that rules out the video connection.

Finally, I cut out my EPROMS, and burned and soldered in new ones, which didn't change anything either.  I knew that it probably wouldn't going in, but I decided it would be worth the cost of two chips just to be sure.  Also I did a much neater job of soldering in the new ones, and the PCB looks much neater now.  I got some pics of my pinout rerouting under the EPROMs while they were off as well, if anyone's interested.

-

Are you there Spooniest?  I'll describe the glitch a little better, in case you want to work on it.  The white border of the text box is about three or four pixels thick.  What exactly is happening is that on just one horizontal line of border pixels, the whole border alternates from being in the right place to being offset one to the left one pixel, and this happens only on the right side, near the bottom right corner.  Like this:

Code Select Expand

*white border pixels -blue background

normal:
-----------****
-----------****
-----------****
-----------****
-----------****
-----------****
-----------****
-----------****
-----------****
-----------****
-----------****
***************
***************
***************
***************

offset:
-----------****
-----------****
-----------****
----------****-
-----------****
-----------****
-----------****
-----------****
-----------****
-----------****
-----------****
***************
***************
***************
***************


It alternates between the two states several times per second at varying speeds.  This only happens in the text boxes when talking to people, none of the other menus, and it looks like it lines up with the very bottom of the characters in the fourth row of text.

You'd have to at least put it on a flash cart to test it, because it doesn't show up in ZSNES or BSNES.  If it's not a priority for you, don't worry about it on my account.  It's perfectly playable.

[Bregalad]

I just verified on my PowerPak and the stray pixel does indeed appear. It might even be 2 pixels I'm not sure. Apparently the scroll value is changed just a little too early, and falls a bit before HBlank, screwing up some pixels on the right of the text box.

I'm now absolutely certain this was already in the original (as the translators probably didn't touch the IRQ routine), but it was invisible because the textbox was smaller. This glitch is not visible in BSNES because it doesn't emulate the IRQ timing perfectly. About ZSNES it's lame : Normally the emulation of this IRQ / scroll changing effect is so wrong an entiere line is transparent. There was just so many so-called FF4 screen shots with this glitch on them it pissed me off. Some versions of ZSNES have it artificially fixed if FF4 is detected apparently.

This could be easily fixable by adding one or two "nop" instructions in the IRQ routine.

[rCadeGaming]

I just verified on my PowerPak and the stray pixel does indeed appear. It might even be 2 pixels I'm not sure.

Thanks for testing that!  My picture is pretty sharp with RGB -> component on a flat crt Trinitron, so I'm pretty sure it's one pixel.

Apparently the scroll value is changed just a little too early, and falls a bit before HBlank, screwing up some pixels on the right of the text box.

I kind of understand your explanation in a conceptual way, but why does it flicker instead of staying steady correct or incorrect.  Is there something going on that's running at a little different rate than the refresh rate and it just lines up differently on some frames than others?

This could be easily fixable by adding one or two "nop" instructions in the IRQ routine.

This is currently beyond my ability as I don't know anything about SNES programming, but if you or anyone else is willing to do so I'd be very grateful.

[Bregalad]

Oh the flickering is because of what we usually call "jittering". It is basically what you said, the exact timing on where the HBlank IRQ is triggered is partially random, because the CPU has to terminate the instruction he was currently executing before jumping to the interrupt routine.

[Deathlike2]

3.  What do you think of the Long Range Fix?  From the description, it sounds like a pretty important thing that should be fixed.  I'm just wondering why this isn't integrated into more translations and hacks.

Long Range Fix:
http://www.romhacking.net/hacks/892/

There's quite a bit more stuff that needed to be fixed than just that.
There are many bits that don't get unset in FF4... which is an attests to it being somewhat rushed or unfinished in some areas.
For instance, there is a no-critical hit bug where weapons that have the no-critical hit bit set (all whips, Dwarf Axe, and Ragnarok Sword, to name a few)
will pretty much put the kabash on dishing critical hits ever again. This is also the same reason Rydia never makes critical hits on her return.
A related bug to the long range bit is that an ambidextrous character (Edge) will not have the long range bit set
IF AND ONLY IF the weapon with the long range bit (Boomerang, FullMoon) is put on the left hand. It is set properly on the right hand, but apparently the left hand is forgotten.
Go figure.

Related Note: I like how SkyRender's "translation" for FF6 has a separate fixes patch for this purpose. Ideally, you want to consider this patch as an addon to the translation... not necessarily an integrated part.

[rCadeGaming]

Deathlike, are there any patches available to fix these things?

[Deathlike2]

Deathlike, are there any patches available to fix these things?

Eventually.