Frame Limiting?
Blitz3D Forums/Blitz3D Programming/Frame Limiting?
| ||
| I know this has been discussed at length before but would be very interested to know what people use for their frame limiting (game limiting) methods? A lot of people seem to recommend the method used in the castle demo. Is this the one to use? |
| ||
| It is for me. Honestly, there's really not much between render tweening and delta timing for most purposes. I've used both and there's precious little visual difference. I just got into the habit of using render tweening and it's a bit quicker to implement than delta time, so that's what I do. |
| ||
| Sybixsus, I have it working but want to test the actual FPS to see. How do you do that, I've used the following but it shows a very different fps... Framecounter_counter=Framecounter_counter+1 If Framecounter_time=0 Then Framecounter_time=MilliSecs() If Framecounter_time+1001 <MilliSecs() Then Framecounter_framerate=Framecounter_counter Framecounter_counter=0 Framecounter_time=MilliSecs() EndIf Text 1,1,Framecounter_framerate Flip |
| ||
| I was just wondering about this... I usually fall on the delta timing side of things. The method in mark's castle demo can have some very bad results for people with slow pcs (I have experience :P). However, there doesn't seem to be much of a difference between delta timing and render tweening. Render tweening is just automated. I guess the main difference is that using delta timing, you can move an entity, and then perform tests on the entities position and orientation, correcting collision errors, etc. Which leads me to a question - if render tweening is performed by renderworld, then wouldn't collisions be a bit wierd? If tween# was ever greater than 1 then objects would penetrate. This is all hypothetical of course, I'm to lazy to test it. Okay - here's a method that might be pretty good. It's a modification of mark's castle demo timing system:(untested -oh and also this is from a visual blitz template so it might have a few other mods as well.) Const LowestRenderRate=15 Const RenderPeriod=1000/LowestRenderRate Const UPS=60 Const period=1000/UPS Graphics3D 640,480,32,2 time=MilliSecs()-period Repeat m=MilliSecs() 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 If KeyHit(1) End updategame UpdateWorld If (m-MilliSecs)>RenderPeriod Then time=MilliSecs():Exit Next RenderWorld tween Flip Forever Basically, this makes it render at least 15 frames per second. Which prevents a downward spiral on crap computers in which every frame is further apart. |
| ||
| I'll give it a go - but how do I report the ACTUAL FPS onscreen to check that this is working correctly? |
| ||
oh. well, if you're using my example:Text 0,0,1000/(MilliSecs()-m) Forever |
| ||
| Bot Builder, the FPS display shows 100 FPS which is the monitors refresh rate even though I've set the FPS rate to be say 75. Am I being studid or is this type of limiting simply locking the game logic (gameupdate) to the FPS figure not the drawing of the 3d scene? |
| ||
| Try my tutorial at: http://www.blitzcoder.com/cgi-bin/articles/show_article.pl?f=johnblackledge09202003161847.html |
| ||
| John, great, you are right Mark is a genius. Got it all working now, running super smooth. |
| ||
| Why do you want to have a Frame limited ? |
| ||
| So it doesn't behave like keystone cops one second and the matrix the next. |
| ||
| A serious problem I found with render tweening is that since *everything* is updated as fast as the pc can go regardless to the game logic, certain commands will perform in an unexpected way: for example, using the 'positionentity' command with the timer set to 30 fps to move an entity from a visible location to another with a 'fast' pc (let's say a system which can render the game at 60 or 90 fps) will not 'teleport' the entity from the current location to the new one, but will let the user actually *see* the movement from the old location to the new one. For certain games it can be quite annoying. |
| ||
| Yeah in fact I was testing on a lower spec machine (ati 8500) all seemed fine render tweening using the above method at 75 FPS but the same code on my 9700 PRO runs jerkily at 75. Eh???? Help! Maybe delta timing is better... I just don't understand why it jerks. |
| ||
| I once created my own function to do the Frame Limiting dynamically. It does, however, need 2 Global variables. Global FrameTime Global Period Function LimitFrameRate(FPS = 50) If FrameTime = 0 Then Period = 1000 / FPS FrameTime = MilliSecs() EndIf ; Make sure the framerate isn't above the specified setting While (FrameTime + Period) > MilliSecs() Delay 1 Wend FrameTime = MilliSecs() End Function This works for me. All you have to do, is call the routine at the top of your main loop, like this: While Not KeyHit(1) ; Limit the framerate to the specified setting LimitFrameRate() ; The rest of your code comes here: ... Until KeyHit(1) The default framerate is set to 50, but you can change it to whatever you want, just by placing the required framerate between the (): LimitFrameRate(10) Results in a framerate of 10fps. |
| ||
| I'm not sure, but you all seem to have missed the point that Mark's rendertweening code helps to 'spread' animations across the ideal number of frames. So if your character walks from A to B in 30 frames/sec (let's say one step modelled in Milkshape) but the PC can only do 7 frames/sec at that moment for whatever reason, then Marks code smoothes it out and the character gets from A to B as expected - your 7 frames does not cause a lag. |
| ||
| PowerPC603, that "Delay 1" is exactly what I'm trying to achieve. It would appear that the jerkiness was caused by my me calling HideEntity every gameupdate() when I didn't need too. Ooops. |
   |