On Thursday, 22 February 2007 at 11:34, The Watermelon wrote:
> On 2/22/07, Christian Ohm <[EMAIL PROTECTED]> wrote:
> >
> >What about (pseudocode)
> >
> >{
> >       current_ticks = SDL_GetTicks()
> >       frame_ticks = current_ticks - last_ticks;
> >       actual_ticks = rate_ticks - frame_ticks;
> >       if (actual_ticks > 0)
> >               SDL_Delay(target_ticks - actual_ticks);
> >       last_ticks = current_ticks;
> >}
> >
> >The framecount here is useless, as there's no use in waiting even longer
> >if you haven't met the previous deadline. Then add an actual framerate
> >counter in a way that SDL_GetTicks only get called once per frame.
> >
> >Also the delay should be completely disabled when vsync is active, else
> >it'll only add more useless waiting.
> 
> this is supposed to be used for keeping constant renderer
> framerate,currently the gameloop becomes busy if you fail to reach the
> limits.
> 
> besides,you can rarely have time left with that ideal caculation measure in
> wz,unless you set your framerate limits to <10 fps,or you'll never get to
> that line.

To me that sounds like it works as it is supposed to. If the system is
not fast enough to reach the desired frame rate, don't delay, as every
delay will make it even slower.

> >Well, the delay is only meant to be called when there is time per frame
> >left, so if current_ticks is larger than one frame in the target frame
> >rate, the game runs too slow and you don't delay.
> >
> >Now you add a delay of one targetted frame duration each frame, so you
> >can't ever reach that rate.
> >
> >I tested the original code, an immediate return and your variant. The
> >first two both had roughly the same frame rate, yours was a bit slower
> >(23 fps vs. 17 fps, or 10 fps vs. 8 fps with more units shown, both at
> >1526x1174, the first scene at 640x480 is 30 fps vs. 20 fps, all with
> >vsync on. With vsync off the first scene is 35 fps vs. 23 fps (640x480
> >again).
> >
> >Have you actually looked at the framerate with your changes? If you do
> >not reach the target frame rate it's no surprise when the game runs at
> >100%, and at less when you add unconditional delays.
> 
> 
> well maybe it's my fault to mingle the gameframerate and renderer frame
> rate,but why should you make the loop even busier when the mainloop already
> becomes slower than expected?
> 
> the logics behind this framerate thing in wz is severely broken(though maybe
> it was already like this in 1.10 source code...),basically you have to
> update all units/ai/game mechanics number of SDL framerate times just in
> order to keep a constant client renderer framerate according to this
> function,this also gives the player with the highest so-called 'framerate' a
> unfair advantage since his units are more responsive and his projectiles are
> more likely to hit than other players'...

Well, the game logic (physics, ai, etc.) should run at a constant rate
like 10/s, completely independent of graphics performance. I don't know
what Warzone does, looks like it runs the game logic once per frame.

-- 
I wonder if I should put myself in ESCROW!!

_______________________________________________
Warzone-dev mailing list
[email protected]
https://mail.gna.org/listinfo/warzone-dev

Reply via email to