Nioreh wrote:Best thing is obviously to have all calculations be done from 2 different set of constants that would result in the same behavior in both worlds. But that can become quite messy, take up room and/or be slower if not hard coding constants in calculations.
I don't think this is ideal either. It's another compromise. It can solve the "different rate" problem, but introduces a new "different behaviour" problem.
The specific height and lengths of jumps will be different, and the arc passes through a different set of discrete points. A bullet moving farther per frame will do less collision tests against the things it is moving past. Etc. These are all behavioural changes that need to be tuned and tested, and IMO testing is the single biggest task in game development.
Every solution to this is a tradeoff between different kinds of problems. What's ideal depends on which problems affect your particular game the most, but for a lot of action games this is a rock and a hard place. For a menu driven RPG, on the other hand, all of these solutions might be "fine".
...though maybe worth reiterating: doubling every fifth frame to convert PAL to NTSC is a lot
less of a problem than skipping every sixth frame to convert NTSC to PAL, at least for interactive things. There's a big
difference between missing a whole frame of being able to hit that jump/attack button, and having 2 frames to do it. (However, I think both are an acceptable technique for music conversion.)