Delta timing - What to Change and What to Leave?
Blitz3D Forums/Blitz3D Programming/Delta timing - What to Change and What to Leave?
| ||
| I'm having a mental block when it comes to adding Frame Limiting to my game. I'm using Delta Timing, and I'm having a problem remembering which things should be affected by my frame limitting and which shouldn't. What I have at the moment : * Movement IS affected ( multiplied ) by Speed Factor. * Animation Speed IS affected ( multiplied ) by Speed Factor. * Velocity IS NOT affected by speed factor. ( I'm affecting movement, so I'd be doing it twice if I affected velocity ) * Lifespan ( for Particles ) IS affected ( divided ) by Speed Factor. ( To ensure that the effects look exactly the same. ) I've been working so many hours, I'm looking at this now and I have no idea if this is close or way off or right or wrong or anything. |
| ||
| Yeah that looks just about right, Sybixsus. I know a lot of folks will say different, but I think render tweening is better. I'm making a golf game and there's no way to get consistency with deltatime for stuff like this as far as I can see. Also, it's nicer to be able to forget about all the dt stuff...... |
| ||
| Thanks. It was starting to look wrong, and since I only have a very fast dev machine to test on, I can't really get it to slow down and see how it's working. I have used delta time before, albeit with a slightly simpler game, but I've always found it worked well for me, and unfortunately, render tweening is always ever-so-slightly jerky for me. It is going to be quite a lot of work now implementing delta time, so I will take this opportunity to give it another go. Maybe I've learned something since last time that will enable me to avoid that little bit of jerkiness. I know it's my fault because SkidRacer's Skid Marks demo ( which I'm sure was using render tweening ) was sooooooo smooth even on my old machine at high res. Thanks again for the confirmation, and for persuading me to give render tweening one more go. |
| ||
| Anything where time is a factor |
| ||
| Well time is a factor in velocity too, but I can only affect either movement or velocity or I'll be doubling the effect of the limit, no? |
| ||
| Yeah I think you are right, Sybixsus. My recommendation to you is to take a look at Si's demo that comes with B3D (little 'it's a me, Mario' type bloke running around a castle). That has render tweening, so just rip that apart. No idea why it hasn't worked smoothly for u previously. Testing schemes: Assuming everything is synched to the monitor, you can test your current stuff by changing monitor refresh rate. Delta time works fine for a lot of things, and I must admit I never tried any of the 'smoothed' delta time stuff people have spoke of, but I found it a bit jerky. The one drawback I know of to be aware of with render tweening is that if you want an object to 'teleport' i.e: you place it instantly at a new position far away, the tweens will be unwelcome, tho perhaps you can hide it? Why the hell can't PC's come with standardised monitor refresh rates? |
| ||
| the thing I don't like about render tweening is that the game logic sometimes has to be skipped to keep it at a constant frame rate. (If it renders at 600fps and the game logic runs at 60fps then the "game logic loop" will be missed out every 10 render loops, which could result in a small delay between a key press and its action, and possibly even miss the key press completely - KeyDown() in particular) but don't quote me on that. |
| ||
| Chris- the game logic is never missed- it can't be missed because it runs every loop with no conditional jump. In the vast majority of cases 25fps game logic is more than enough and the worst that can happen is you don't get a frame rendered for every logic loop. If your machine can't handle 25fps logic, say (gfx aside), then the game will begin to slow down (i.e: objects move slower, not just jerkiness), but gfx rendering is more likely to be the bottleneck. Like I say, try the demo that comes with B3D and see how it runs on yours. |
| ||
| RAM, thats not how it works... the "conditional jump" in render tweening is the For..Next loop itself. The game logic loop looks like this: For k = 1 to Ticks ;game logic here Next When Ticks is less than 1 then it skips the game logic and just renders the scene. |
| ||
| Yep sorry I see what you're getting at now Chris. Let's see who can punch a key for less than 1/25th of a second! |
| ||
| Well I've implemented render tweening in my game now, in place of delta timing, and there are a few visual artifacts occasionally, so I must have some "teleporting" issues to take care of that I hadn't noticed. They shouldn't be too much trouble. It seems pretty smooth at the moment. Not as smooth as with no timing at all ( well it wouldn't be, would it? ) but it's as smooth as delta timing and was very simple to implement. So I'm pretty happy with it for this game. The lack of a logic update isn't going to present any problem in my game, as I hardly ever use keydown() and when I do, it's just going to be ever so slightly slower at a point that no one would care about. So thanks for the tip, RAM, I think you just saved me a lot of time adding delta timing to all my code. |
| ||
| You could always remove the tweening part of the code. Just let it render as fast as it can and limit the game logic to the specified fps. That should get rid of the visual artifacts and "teleporting" issues. Just comment out the CaptureWorld stuff and remove the tween parameter from the RenderWorld command. |
   |