I like the idea of fixed logic and it's what I'm doing also although I haven't decided on a frequency yet. 120 seems reasonable, although even more reasonable would be a flexible fixed-rate whereby you make sure your logic runs at an even multiple of the display Hz rate. If my display is 60Hz I'd go with a 120, 180 or 240hz logic. But if my display is 85hz I'd go with a 130 or 215hz logic. If your logic evenly divides into the display hz then it is likely to be much more accurate each frame.
But what that does then imply is that you can't design for a single fixed rate. Say if you fix your rate at 120hz then you know exactly what numbers to use to make objects move a given distance in a given time, for example, because it's like working with a reliable constant-speed machine. But if you flex your logic rate depending on the display hz you don't get that benefit. So what I'm doing is having a design-time hz rate that I choose, say 120hz, and then the logic rate is based on a multiple of the display hz, and then I tween between the design rate and the logic rate to determine where the object should be in a given logic frame. This is my own invention, I think ;-)
I think a higher hz rate is okay for most 2d games unless you are doing lots of physics or computation each frame in which case your target spec has to be higher. I think you can get away with a lower logic hz if you use tweening but that also makes your code more complex - but at least then there is a chance it will run on a lower spec. So what I'm doing is tweening between a design-time fixed hz rate to get to the dynamic-fixed logic rate, and then tweening from the dynamic-fixed logic rate to the display hz. I also predict what the logic time will be in the future when a frame is finished rendering and will be actually flipped, so that when it does flip I am showing more exact current state.
I'm surprised we haven't seen Jake (GreyAlien) posting in this thread yet ;-)
But what that does then imply is that you can't design for a single fixed rate. Say if you fix your rate at 120hz then you know exactly what numbers to use to make objects move a given distance in a given time, for example, because it's like working with a reliable constant-speed machine. But if you flex your logic rate depending on the display hz you don't get that benefit. So what I'm doing is having a design-time hz rate that I choose, say 120hz, and then the logic rate is based on a multiple of the display hz, and then I tween between the design rate and the logic rate to determine where the object should be in a given logic frame. This is my own invention, I think ;-)
I think a higher hz rate is okay for most 2d games unless you are doing lots of physics or computation each frame in which case your target spec has to be higher. I think you can get away with a lower logic hz if you use tweening but that also makes your code more complex - but at least then there is a chance it will run on a lower spec. So what I'm doing is tweening between a design-time fixed hz rate to get to the dynamic-fixed logic rate, and then tweening from the dynamic-fixed logic rate to the display hz. I also predict what the logic time will be in the future when a frame is finished rendering and will be actually flipped, so that when it does flip I am showing more exact current state.
I'm surprised we haven't seen Jake (GreyAlien) posting in this thread yet ;-)