The function that calls all of these is the "Draw_Frame" function. If we're increasing the frequency at which that is called then we have to reduce the values it manipulates or create a new timer that handles all these "per frame" functions.

Well, my easier way, which isn't what you and obese are doing...mostly... is to just use code that pause values use... basically skip major functions 3 of every 4 frames. I've gotten it working to a large extent already.

Well, my easier way, which isn't what you and obese are doing...mostly... is to just use code that pause values use... basically skip major functions 3 of every 4 frames. I've gotten it working to a large extent already.

More work needed tho.

I think a combination of all of our efforts will be needed to fully realize this project. I'm glad to be a part of it.

Heh. The Turn Timer increase was actually undoing the good the VTimer edit did. Since Turn Timer is based on VTimer it would be fixed when VTimer is and not need any alterations.

The C-Timer is an estimation. You can't divide 34 by 4 and get an integer so I just SHR by 2. It's a fair enough approximation, but things might be imperceptibly slower than they should be. I think this only affects timed statuses anyway and I don't know if anyone would complain about longer-laster barriers.

It will fix everything... including the AI timings and char timings.. Problem is... it also means the slots will then have the same issue they did at 15fps... so that way is a no go Unless you can work something out.

I can't be 100% because I can't get this to record at 60fps... but I'm excited here... because that 1 value might have fixed everything. It is certainly what the main timing function uses.

edit 2.

No... it's fixed the lot [didn't bother recording... realized all i need to do is advance the game using breakpoints haha]. That one value is the main one. You can see how it's used in the function that comes after The porting team must have set on purpose so the menu/camera etc could work at 15fps.

I can't be 100% because I can't get this to record at 60fps... but I'm excited here... because that 1 value might have fixed everything. It is certainly what the main timing function uses.

edit 2.

No... it's fixed the lot. That one value is the main one. You can see how it's used in the function that comes after The porting team must have set on purpose so the menu/camera etc could work at 15fps.

Verified. The camera is clearly running as it would at 15fps, so it's not as smooth as the interpolated one, but this seems to be the best way to go for now.

I've successfully made the battle 60fps (completely finished and fully working). Had to add in my own small hack to make it dupe 3 of 4 frames, but that along with the menu fix I discovered has done it.

I'm happy with the results but also look forward to your interpolated version.

I've successfully made the battle 60fps (completely finished and fully working). Had to add in my own small hack to make it dupe 3 of 4 frames, but that along with the menu fix I discovered has done it.

I'm happy with the results but also look forward to your interpolated version.

*throws confetti* Finally making some real progress on my end. Got held up forever on emerald

Is anyone willing to manually fix models? I'll be doing most of the work, but when I come across some I don't feel like doing they'll go in KNOWN PROBLEMS. If someone else would like to fix those, let me know.

Just when I thought I had seen everything, I am pretty pumped to try this mod. Any plans for 60 fps field/world map?

Yes and no. The method they used to speed down the battle scenes is likely the same thing for the field and world map. So reverting them back to 60fps will be pretty simple (so to speak).

However, at this time I have no plans to interpolate and fix the animations used there. Were I to get some help finishing up the battle side of things...well then maybe we can talk about branching out further. After all, it is likely the field and world map animations are exponentially easier than the battle ones.

So long as i don't have to buy fancy equipment to generate the animations, I also don't mind trying it out. I get the feeling we won't have as many animations as we have enemies. I'm sure a ton use the same animations (lets hope anyway..)

I imagine it is all a matter of quadrupling the number of animation points in kimera, spreading out each instance four frames apart, and improvising the inbetween frames. It's probably a pita but will make everything look much smoother

We need a Google sheet so we can see who is working on what model. My question is how many frames are needed to interpolate and how do look chained animations together? If they look to cut apart then we may need to add a help frame. I hope that this won't be needed, because this would slow down the process.

So long as I don't have to buy fancy equipment to generate the animations, I also don't mind trying it out. I get the feeling we won't have as many animations as we have enemies. I'm sure a ton use the same animations (lets hope anyway..)

Haha... No it's not that easy. Every enemy has his own set of animations. Something between 10 and 14 animations. But fear not Kimera can interpolate animations in a good manner so only fine adjustments needs to be done. However the save button should be your best friend, I have made the experience that 'Crashimera' doesn't like to play animations of battle models for a longer time.

InstructionsExtract your battle.lgp using ULGP (you can extract them wherever)Once that's done copy all the files I uploaded into your newly extracted folder and make sure to overwriteBoot up Kimera. OPEN MODEL, and pick anything ending in **aa.In the lower left corner you'll see "battle animation". At the very bottom you'll see < and >, these let you cycle through the frames of the current animation selected in "battle animation".0 is the idle animation for every enemy. These should all be silky smooth, meaning once you reach the very end of the animation, the difference between that frame and frame 0 should be very, very slight.

As for the rest of the animations, I need people to go through every animation frame of every model by holding the > at the bottom of kimera and make sure they aren't doing anything weird (for example: when enemies do tail whips or flips the model usually collides with itself, anything that should rotate like a wheel usually just stutters back and forth)

Please make sure to document EVERY problem you find in the same manner that I did on the first post (HRAA animation 5 frame 37 for example). If you're good enough with kimera, feel free to fix it on your own. But if you do decide to fix it, please make sure to send me that model's **da file and don't forget to hit SAVE MODEL.

I've already done AAAA through BNAA, but you're more than welcome to check behind me.

I just wanted to clarify, not all animations should be silky smooth during the transition from the final frame to the beginning one. Only ones that are supposed to loop like idle animations and barret's victory pose. Some enemies like zemzelett will have 2 idle animations, so you need to have a sharp eye to find which ones they are.

As for me, I'm spending my day burning my old floor and installing the new one.