Frame Limiting & Render Tweening
Blitz3D Forums/Blitz3D Programming/Frame Limiting & Render Tweening
| ||
| Looking through searches and the Archives, I notice pretty much all frame-limiting stuff is linked to 3D animations and using the 'tween' parameter of rendering. I wonder if it's still relevant and necessary for my little project. Basically, I am using static meshes and very simple, absolute movement, which is why I really ought to limit the framerate. How should I go about this and do I really need to consider 'tween'ing? |
| ||
| ..I see no reason why not use tweening...there is no harm and it doesnt make your code any complicated as it is, while providing same speed regardless computer you are going to run your application on.. |
| ||
| Alright, thanks. It does appear a little complicated when I see some of the examples, but I'm gonna try out RifRaf's single function thingy. http://www.blitzbasic.com/codearcs/codearcs.php?code=2434 |
| ||
| There is also the "official" transcript from Mark's source: http://www.blitzbasic.com/codearcs/codearcs.php?code=9 But RifRaf's look more easy to implement. One thing worth commenting is that this tweening code can screw up your collisions. For a long time I've been complaining about Blitz3D collisions being flickery (objects would flicker when in direct contact against each other); it wasn't the collisions fault, it was the frame tweening. Some frames it would UpdateWorld, so the objects would get in their rightful place, some frames it wouldn't, and so the objects in direct contact would pierce eachother. That is what caused the flickering. So it's worth mentioning. It can also conflict with other constant-speed-dependant algorithms: http://blitzbasic.com/Community/posts.php?topic=35570 The best thing about the Tweening algorithm, like Naughty said, is that it not only limits frames but also skips them when necessary. So, theoretically, slower computers would also run the game at the same speed. The thing is, sometimes it's much easier to just use the internal CreateTimer() and WaitTimer() commands. It limits the frames and frees the CPU whenever it needs to wait time. After knowing it frees CPU and not just wastes it, I started looking at these commands with different eyes; and they work very well, as you can see here. The frame limiting Pongo uses is just the WaitTimer; and see the difference it makes. Of course, there is no frame skipping. |
| ||
| Tweening imo is the best route. Simple and effective. I would never use waittimer on a game to regulate the framerate. |
| ||
| There's always mine: http://www.blitzbasic.co.nz/codearcs/codearcs.php?code=1497 |
| ||
| Heh, thanks, John but yours was one of the 'complicated' ones, that seemed a little o-t-t for what I actually wanted. |
| ||
| if it help's some body... when i first read some about frame tweening i missunderstood many fact's. The first one is that for me, frames per second was renderworld's per second and the variable name confused me a little. Some day i understood that constant fps means GameUpdates and not render world's. At first, i evade as much as posible frametweening as i don't understood it in any way. Today i agree with that is not much overhead. We only have to have a function UpdateGame, and, if we want a second function with all the stuff needed before Flip (as display text, the BarGraph in my code, and the like). I recomend to use it as a skeleton, becasuse sooner or later we will be fighting with diferents behaviors of the same code in diferent machines. I did some little modifications of the original frame tweeining code (most of the lines modifided are marked). The code adds a bar graph of what is going with frame tweening. There's nothing new, only a bar braph to see what is happening. (I do a graph because seems to me that graphical represetation is better than numbers changing continously) The graph shows: RenderWorlds per second (Red), UpdateGames per second (white) and a third bar with the acumulated time in a second of: UpdateGame, RenderWorld and UpdateWorld's. the idea is to see how they are distributed in one second, so we can see if the most cosuming time is one or other or if they are equally distributed. the program creates some boxes and with the left/right cursor key we can focus the camera to all in front (that's the worst case for RenderWorld) and if we turn the camera 180 degrees, as few boxes are rendered, the RenderWorld increases. The thing is that UpdateGame is constant. there's a forth graph with TrisRendered() to see how the affect the overall of render world. as i said, hope that help some one. Juan (and hope you understand me, english is not my native language..) |
| ||
| Thanks very much, Charrua, that really helps and your initial experience of tweening seemed very much like my own. |
| ||
| You can always use Delta Timing too. That way you shouldn't really need to limit your framerate (except if you want to enable other applications to run too, or else your program will suck up to 100% of your CPU). You can see it in more detail here: http://web.archive.org/web/20050319160429/www.blitzcoder.com/cgi-bin/articles/show_article.pl?f=gamemorduun03212002.html And there is also an easy to understand delta timing version inside the "Comets" demo source, in the Trial version of Particle Candy. |
| ||
| Yeah I've worked with Delta-timing for most things like movement until now. If it's a viable alternative to asll this tweening malarkey, I'm much more comfortable with it :D |
| ||
| Sure thing, it's another way to approach the same problem of frame skipping. Some people prefer Tweening, others Delta Timing. So you could combine WaitTimer() (or make it optional for the user) and limit the frames to a certain FPS, and use that same FPS for the "Target_FPS" that Delta Time uses, so your game doesn't go up to 360 FPS on monster machines, but still keeps the same speed at lower-end cpus. |
| ||
Well my Delta-timing is pretty much an application of the following idea:Global StartLoopTime=Millisecs() .... ;Somewhere in the update loop MoveEntity Entity,0,0,Speed#*DeltaTime#() .... Function DeltaTime#() Local Elapsed#=(Millisecs()-StartLoopTime) Return (Elapsed# * 0.001) So that regardless of FPS, movement is always at a rate of distance / Actual time. |
| ||
| so how would u get the EXACT FPS? & how would that be used to calculate the movement speed? And can u maybe show a small example? ~DS~ |
| ||
This doesn't use FPS, but it calculates the elapsed millisecs every loop, and uses that:old = millisecs() ;store start time repeat now = Millisecs() ;time now elapsed# = now - old ;difference between 'now' and previous 'now' old = now ;store previous 'now' moveentity cube, 0, 0, elapsed * 0.01 ;usage until keyhit(1) |
   |