Constant Game Speed independent of Variable FPS

[r0ber7]

Is it a virtual camera, everything moves left using an offset variable when the camera pans right for example?

Yes. Objects have their x & y position in the world. object screen drawing position = (object world position - camera position). So on the one hand I'm interpolating the camera position, on the other hand I'm interpolating any moving objects. Camera position is an int, and so is everything else I use for drawing.

Vsync is set to "let the program determine" in my nVidia screen, and project options of max fps -1 & 60 both give the same result.

Thanks for the comments, I'll figure it out eventually.

[Slydog]

@r0ber7

You *may* want to try converting your camera position 'ints' to 'floats'. (And perhaps your object positions too)
Do all math and updates to those using floats also.
Then, you will be able to handle sub/fraction pixel movement smoothly.

When I implemented my 'kinetic scroll' algorithm to mimic iPhone's scrolling, it would only work with floats, or else it would be very jerky when it was at a fraction of an int speeds.

But, if your speed is say 2 constantly, and you're still getting jerkiness, then I suppose you may have another problem somewhere.

[kanonet]

But if you do your camera etc. in float you may get the same camera shivering that we know from 3D.
When you add a number that are really different in size like 0.1 vs 1000 etc. then you get float inaccuracy...

[Slydog]

@kanonet

All the calculations and updates are done to a float variable, then converted by GLB to an int when used for a position.  But I suspect that's not what you're questioning.

I'm not too sure what you mean by "camera shivering that we know from 3D".
In my game my 3D camera is positioned using my tween / easing library. 
When it gets to its destination (smoothly), it stops and remains fixed, no 'shivering'.
My tween library *sets* the camera position each frame (it knows where the camera should be), it doesn't just add an offset value to the current position, so this may have something to do with it.

I also don't know what you were leading to regarding float inaccuracy.
In that if you keep incrementing a position variable by a floating value, eventually it will drift away from what you are expecting?  Or because '0.1' and '1000.0' are far apart . . . and . . . dang, still don't know what you were inferring.  I guess without an example situation (not code) I may not.

I understand the nature of floats, I just can't readily come up with a situation where they could be a problem (with positioning specifically).  (But mind you, in my programming career, I sure had run ins with float inaccuracy bugs! ha)

[Cool, my '777'th post!  Dang, now I can't make any new posts or I will ruin it!]

[bigsofty]

TBH if the problem was a float to int conversion, then I would expect to see constant shivering. not just intermediate shivering.

I use this system in 3D, so I interpolate between vectors, which are all floats, this may be why I dont get the same problems. I would not like to use ints internally though, even for 2D, as the interpolation relies on the fact that it can use sub-pixel accuracy when calculating the next point on the screen, for really slow moving objects for example.

For example it has enough time to render 10 frames and it only has to move a sprite 4 pixels. It will try and increment each frame 0.4 pixels. You would loose the interpolation accuracy if using ints. The same would be true of the camera.

This still may not me the problem though as there are other factors that could be producing this effect. Rober7, if you could provide a simple cut-down example of the problem, I would take a small look if you like?

[r0ber7]

Hmm... yeeesss...

Ok. So, I have to use ints. This is because of the z_project lib I use. If I use floats I'll get tiny errors when scaling on different screens, which looks as if the screen has been "sliced up". I don't think that using ints is the cause of the problem anyway, because (in the name of science!) I did change all position related variables to floats this afternoon, and it was still jittery. Intermediate indeed, bigsofty. I have another idea now: put the camera movements inside the draw() function. I know, this is cheating a bit, but hey, might work.

Maybe if that doesn't work I'll post some code here. Thanks for all the suggestions you guys. I suspect this has something to do with internal game specifics rather than the actual gameloop code though, so I feel bad for derailing the thread.

[Hemlos]

If its not your code, Im willing to bet your camera is out of opengl's boundary limits.
The size of the opengl world is -32000 to 32000 in each dimension, if you go further it causes problems.

http://www.glbasic.com/forum/index.php?topic=3904.msg28557#msg28557

I suspect this is your problem because you are using integer for 3d coordinates.
You should use floats in the 3d world, otherwise(ints) you are wasting precious 3d space.

64000.0 total opengl world width would be 64km wide.
Build all objects relative to 1 xyz position=1 meter. eg 0.5 would be a half meter.

Furthermore, the best way to setup a camera in opengl is move the world, not the camera.
In your case, alternatively, you can make grids and shift the grids and the camera relative to 000 xyz when the camera goes too far.

[Wampus]

Ok. So, I have to use ints. This is because of the z_project lib I use. If I use floats I'll get tiny errors when scaling on different screens, which looks as if the screen has been "sliced up". I don't think that using ints is the cause of the problem anyway, because (in the name of science!) I did change all position related variables to floats this afternoon, and it was still jittery. Intermediate indeed, bigsofty. I have another idea now: put the camera movements inside the draw() function. I know, this is cheating a bit, but hey, might work.

Tiny errors when scaling causing sliced up look? Hmm, you know that sounds like a sprite extrusion issue. Here is a thread about a similar problem (or the same problem) and solutions: http://www.glbasic.com/forum/index.php?topic=5057.0. Confused me a lot tbw.