NTSC/JP Xenoblade 60fps and other mods

One More Try · 08-22-2017, 02:57 AM **#11**

Took my first look at the JP code. It is a bit different, which means I can't just change my addresses to a new offset. However, it's likely easier to make a 60fps code for the JP version. For example, you don't need to adjust the run speed at all. So I'll casually work on it with the intent of only releasing one version.

As for progress on the English code, it has basically come to testing what I have, which is a slow, meticulous process. The changes aren't that important either, mostly just 60 fps cutscenes, and I don't feel like you notice it too much. If anyone has any requests for the 60 fps code or if they saw something that could be improved, let me know.

**Kurausukun** · 08-22-2017, 11:59 AM **#12**

Wow, that's kind of interesting. If 60fps cutscenes work, or even if we have to settle for them being 30fps but correctly timed, then I'm pretty satisfied. Of course, my CPU isn't good enough to maintain full speed in battles, but that can be fixed. Anyway, you mentioned things like waterfalls being moving textures, so it sounds like it would be impossible to make those run in 60fps. Anyway, as far as I remember, the only other thing that wasn't working was 60fps menus, but I don't remember if we determined that was impossible or not.

One More Try · 08-22-2017, 05:46 PM **#13**

Waterfalls were fixed in the latest code by stopping the moving texture every other frame. They look alright. I don't think there's much to be gained from 60fps menus, so I was going to leave it alone. I would have to slow down the cursor and, I think, correct character animations in the equip menu.

**Kurausukun** · 08-22-2017, 08:49 PM **#14**

I'm sure they look fine, I was just saying that I can't imagine a way to animate them at the right speed and also have them "change" 60 times per second. Unless there's some code that states how far the textures move, and you could modify that to half and then let it run at 60fps, but that sounds like a ton of work and is probably not worth it. And the menus seem to be a similar case. Again, it's not a big deal, but you asked for requests, so in a perfect world, that's what I would like, but I'm totally fine if that doesn't quite make it in. The work you've done on this is already amazing.

One More Try · (This post was last modified: 08-23-2017, 05:20 PM by One More Try.)

Thanks for the request. If I knew where the animation values were for the equipment screen, I might be more eager to do it. So far all I can do is scale the character models up/down lol.

Oh ok, right. I actually did find the Waterfall Texture offsets and was able to halve the distance they change each frame. The problem was that on key frames (probably where the offset/transform resets back to 0) they load custom values over 3 frames while resetting it, rather than calculating those offsets. With 60 fps that means there's new frames placed between the custom value frames that weren't there before. I had no idea how to deal with that and I tried to switch back to 30 fps waterfalls for those key frames, but that didn't look right at all. If I worked hard, I could maybe figure out a fix for one waterfall, but it's pointless as it would only apply to one specific waterfall.

If you're interested you can look at them with the stable, non-beta code in the original post. Just use one of the below:

Waterfall Codes: (Show Spoiler)

The JP mods went really quick. It should be equivalent to the ENG beta code now, but I'll have to play through the game a bit.

/edit JP mod is now up to date with the latest experimental changes and running great. I think it runs better than the English version. I'm going to fix text speed for ENG/JP and move the optional camera fixes over to JP next.

**Kurausukun** · 08-24-2017, 05:40 PM **#16**

Ah, okay. I didn't know the waterfalls were programmed so detailed. Makes sense now. Good to hear the JP mods went well. I'll just look forward to the text speed fix, and I'll probably be satisfied with that.

One More Try · (This post was last modified: 08-25-2017, 08:59 AM by One More Try.)

I think Text fixes are finished. I noticed the instant text display option didn't affect cutscenes, so I made an optional code to make that instant too.

I found the animation speed of the menus, it was a common value being used rather oddly.

/edit Because I found the speed of the equipment screen character animation, I was able to look at the movie animation speeds. There's just one frame counter that determines everything. If I pause the counter every other frame, the movies run at half speed (correct speed at 60fps), but that's pointless because you're pausing the animation. Unfortunately, you can't just halve the value because the counting function uses integers. In various places the integer is converted to a float, and halving the value of the float does slow the animation properly, but I don't think you can get it such that everything works right.

**Kurausukun** · 08-25-2017, 05:44 PM **#18**

Ugh, float->integer and vice versa is always a nightmare. Close but no cigar. But hey, thanks for trying.

**gamemasterplc** · 08-25-2017, 09:47 PM **#19**

float to int is the smaller nightmare which can be done in 1 instruction called fctiwz

One More Try · (This post was last modified: 08-25-2017, 11:42 PM by One More Try.)

Wow. I had an odd idea that got it surprisingly close to 60fps movies. I paused the counter every other frame, like before, but when it wrote to a float I checked the counter and increased the float by 0.5 if it was paused. This effectively caused the floats to count up by 0.5 every frame. Anything checking the counter as an integer just sees it get paused every other frame, without further modifications. I wasn't sure what would happen, but apparently all the scene timings (like camera switches) work off the integer and don't need anything more than to be staggered. All the animations work off the floats and do need the 0.5s. The only problems are some visual glitches. Check it out if you want to:

MovieTest: (Show Spoiler)

The reason the code is so long is because I had to copy and paste 7 lines of code every time the counter changes to a float. I don't know if I can use a " bla " branch to just write the code once and continually link to it. Not sure about those.