Is this Timing Code sound?
Blitz3D Forums/Blitz3D Programming/Is this Timing Code sound?
| ||
| This timing code seems to work perfectly but I want to verify what is going on here. The code within Update_Game is run at 120 fps but everything is rendered at the full speed possible right? Also does this look right? And is anyone else doing something similar in their 3D timing code? Const FPS = 100 Local dt# = 1.0 / FPS Local period=1000/FPS Local time=MilliSecs()-period While Not KeyHit(1) Cls Repeat elapsed=MilliSecs()-time Until elapsed ticks=elapsed/period tween#=Float(elapsed Mod period)/Float(period) For k=1 To ticks time=time+period If k=ticks Then CaptureWorld Update_Game(dt) UpdateWorld Next RenderWorld tween Wend Function Update_Game(dt#) ;Multiply all physics by dt vel = vel + acc * dt pos = pos + vel * dt End Function |
| ||
| Looks to me like you've got locked game code at 120fps and render when you can... no idea why you've got that tween stuff going on, look like that's not going to be doing anything because you're halting the whole loop if the computer gets ahead of the specified frame rate. [edit]Actually you've got that capture world stuff in there too... Oh %£$% knows what's going on then! |
| ||
| LMAO @ Rob! When I change the FPS to say 40, it still stays really smooth. It SEEMS to be exactly what I need because although I ported over the Gaffer RK4 stuff, this here is MUCH easier to implement imo and possibly even gives better results. |
| ||
| I just fix the game logic at about 120 updates per second and render whenever it can, that way the max frame rate is 120, which is quite fast enough for anyone to be honest, then you don't need to arse with capture worlds and tweens and all that jazz. Anyone who moans that the frame rate maxes out at 120 deserves to be locked in a burning car and pushed off a cliff frankly. |
| ||
| Well it's really smooth with the core running at 100fps and the render running wild. I think I'm gonna leave it there for now I guess. What I want to do it just get past the timing part. Establish a good method and stick with it. Something that will run fine on most decent computers. I'm not catering to granny who still has a 386SX with a green screen haha. Now I have to rework the exhaust variables because the new timing method screwed everything! Getting the frame delta and using that directly just makes everything stutter too much. Plus there's no use in doing all the physics 500+ times a second and multiplying by the frame delta when you can just lock the physics loop at 100 and let the renderer go nuts. The latter is definitely smoother. EDIT: Ha! I fired a missile and the timing code made it stay in mid air. I saw it and was like WTF is that a bogey!? I didn't put bogies in yet.... |
| ||
| You shouldn't really precalculate how many updates you're going to do and do them in a fixed loop, because updates are not going to consistently take the exact same time in a real world situation, and you're going to make yourself very susceptible to what GreyAlien refers to as jitter with this method. If you don't use an accumulator and a variable sized loop, you're going to need to implement some kind of "anti-jitter" code to counteract it. You probably don't notice this on your system are you're able to render at 120FPS, but when you can't render at 120FPS and you're having to update multiple times between a single render, this is going to cause you problems. |
| ||
| Actually, is there a right way to handle it when the render FPS drops below the physics FPS? If you take more physics loops you also have to lower the dt accordingly to keep everything in sync. Gabriel, I think you're referring to the occasional stutter. Which you won't see at all because of how CaptureWorld works. It interpolates the position of the objects, and that my friend is combating that jitter you're refering to. If the render fps falls below the physics fps then you're going to have a uniform choppiness. These people probably need to update their graphics cards or computer... |
| ||
| What'd I miss? |
   |