[...]Is there no way to just tick "set FPS: 8" somewhere in the software you're using?[...]
Yes - there's a config setting for it. Personally I think we should keep the animations at their full rate if possible, and use the config to lower them. It offers a lot more scope for adjusting and editing in future, and also will be useful for other future Fonline projects which may not wish to replicate the original sprite look so closely. There are however some problems with the frame skip, mentioned below.
These lines here will adjust the displayed frames:
# Simulation time-lapse graphic 3d models.
# Number of frames per second.
# If 0 - off, the animation will be played as smooth as possible
# When you turn on the optimal value - 10.
Animation3dFPS=0
# Smooth transitions in 3d graphics, the time in milliseconds.
# Applies only if Animation3dFPS = 0.
Animation3dSmoothTime =250
What I think Karpov has done is to use the sprites as reference frames for keyframes, divided across a higher framerate. The frames in between are generated by the software's own
tweening.
Little frame sequence example :|R--R--R--R--R--R--R--R--]R = Reference frame / Keyframe, where the model has been matched to the position of an existing sprite.
- = in-between frames, which move in a linear manner between the keyframes on either side. These are generated automatically. For example if R1 has the arm at 90º and R2 has the arm at 120º, the arm will be placed at 100º and 110º in the two in-between frames.
In the example above, there are 24 frames, of which 8 will correspond to existing Fallout sprites. A potential problem with using the "frame skip" option in the settings is that the frames it displays may not be the actual reference frames, but the ones inbetween.
If you think of this (24 frames) :|R--R--R--R--R--R--R--R--]We want it to skip like this :|RxxRxxRxxRxxRxxRxxRxxRxx]Then it would show almost exactly as the original sprites did.
A problem is if it skips like this :|xx-xx-xx-xx-xx-xx-xx-xx-]Then you end up with none of the original frames, but instead all the ones which are "not quite" the same. Additionally, because they're automatically generated, they probably look a bit weird.
If the total number of frames is not exactly divisible by the target frame number, things end up much worse. A target framerate of 8 or 12fps is likely to work much better with 24fps than with 25fps for example. It's a similar problem to what you get when trying to process video footage between PAL and NTSC, with the 25fps and 29.97fps.
I think what he's trying to do now is to manually correct the positions in the in-between frames. Due to the linear processing of the tweening (i.e. the "90º, 100º, 110º, 120º" example above) you will end up with quite an unnatural looking animation. It may be that something like "90º, 97º, 114º, 120º" (with an shallower ease-in and ease-out, and steep middle) would look much more effective. Of course, those adjustments are on every limb in 3 dimensions, so it's not quite as easy as I've described it.
Anyway, I'm actually happy with the animations as they are, at any fps they're shown at.
[edit] Karpov explained quicker and more concisely than me
Anyway, I see what the problem is that he's describing - that the position of the model will "slide" from hex to hex at full fps, regardless of what fps the legs are moving at.