Real FPS Value

Well, all of us know the standard framework for blitz3d Games (with mark's tweening code).

I just wonder how many real fps updates we should do.

For example, i have in my house a 120hz monitor. So i set FPS to any value, and i get 120FPS refresh rate. But the speed of the game is determined by the FPS value. If i have lot of objects, setting FPS to high values drops the refresh rate to 100 or less.

So, what is a good value for FPS Update rate for a really complex environment (physics dll, 20 players, trimesh collision, multiplayer, visual effect, sound effects...)?

I have now 60FPS. The problem is if i set less than this, i need to speed up movements, giving sometimes stability problems in players (vehicles).

Some Comments?

You NEED to make all movement Framerate dependent (well, IMHO only). If this once works, there's only one thing left:
check if the users VSYNC works. If it works and if you can measure the user true Sync Rate, you should use that rate (or that rate divided by 2, 3 or 4) (although basicly you don't care about the rate, just sync the game with it to prevent cutting off half frames), but still as fast as you can.
When it turns out that VSYNC doesn't work on a users machine, use FLIP instead. It WILL cut frames, but at least it will run at all.

; measure time between two VWAITs
vwait
t1=millisecs()
vwait
t2=millisecs()

if (t2-t1)<3
 ; users VSYNC seems not to work, or maybe he has a 500 Hz Screen o_O
 flipmode=1 ; we will use Flip true
else
 flipmode=0 ; we will use Vwait:flip false
endif

;and in the game loop

if flipmode =1
 flip 1
else
 vwait
 flip 0
endif

Meanwhile you'll measure the time one frame takes in your game, and use this value as a generic movement multiplyer.

Prior the mainloop:
t=millisecs()-17 ; to initialize timer calculation (to prevent division by zero)

while not keydown(1) ; then inside the Game Loop:
 t_old=t
 t=millisecs()
 mainspeed#=float(t-t_old) / 16.67
 ...
 ; and for the movement of things:
 if keydown(200) then moveentity player,0,0,1.0*mainspeed#
 ...
 ;and finally adjust animation speed to the current framerate:
 UpdateWorld(mainspeed#)
 Renderworld
 if flipmode =1
  flip 1
 else
  vwait
  flip 0
 endif
wend

But with this method you won't use Tweening, BTW.

Well, thanks for the reply. My problem is not of that kind. I set the number of frames per second that the updateworld occurs, so i know the speed of the movement prior to the compilation.

For example: I set 60fps, so i know the speed is 10, if i set the fps to 50, i set the speed to 12.

The question is... what is a good number for the "number of updateworlds per second"? I think i must calculate the time an update (frame) takes, so this value should be less than the total frames per second. Ehh, perhaps this is the solution... wow!

Jfk, can I just get this right?

Are you saying that we don't actually have to use tweening; that by your method the program runs just as fast as it can, and UpdateWorld(mainspeed#) takes care of all the entity animating speeds? (As long as 'manual MoveEntity type commands are adjusted as shown?)

For example at 30 fps my little man will cycle through 30 walking frames per second, but at 60 fps he will _still_ cycle through 30 walking frames per second?

Well you learn something new everyday.

I didn't even know UpdateWorld had a parameter lol

I tried delta timing over tweening before and got major differences in movement speed between flip false and flip true so I stuck to tweening.

I probably had something wrong in there so I'll check it again and maybe use the UpdateWorld parameter to adjust animation speed like you say.

Yes, updateworld takes a parameter and it works nicely. The only problem is that you never exactly know the duration of the NEXT frame, so when the fps drops from one frame to the next from 120 to 10, animation and movement will jump a little. ALthough, usually this method is used to find the best average fps on a users machine. And a level should be designed in a way that the rate won't drop down that much.

Many people prefere tweening over delta, but there is one serious problem when you have a fixed Refresh rate: the rate may be not compatible with the physical rate. this will result in cut off frames. The hardware shows the first half of the screen of the old frame, and the lower part of the new frame since you used to FLIP without to sync it with Vwait.

well, with higher rates, 100 Hz and more, this may be not so obvious.