SyntaxBomb - Indie Coders

Quote from: Hezkore on July 05, 2019, 16:36:27
I haven't looked at the code (annoying on mobile), but it doesn't have to work like that Derron. (maybe his code does though)
But if you keep a steady "delay" between updates; you will end up with a smooth update rate.
And then just keep rendering VSynced.

So how do you handle "/setmaxfps 30" or whatever might be feasable on older computers? Also there are machines with "vsync" not working properly - so do not rely on that (which is why some people used "TTimer"-intervals).
Also it is clear that "it doesn't have to work like that" - I just wrote about what the poster had as "code in use".

Also of importance with this kind of coupled and vsync-linked logic/render approach is ...

Quote from: Hezkore on July 05, 2019, 16:36:27
What I personally don't like about delta timing values like movements and such is that if the user has a very large "lag spike" the value will end up very large.
And then the object might jump so far that it goes across the entire screen, messing up some triggers or collision along the way.
You can work around that, of course, but I feel like it's a lot of work... compared to something like a locked update rate.

This is why you split updating from rendering ...
You could update your physics 200 times a second to solve your "paper thin wall VS bullet" problem.
Or you just check more closely (move the bullet not "one step per update" but "10 micro-steps per update"). That way you won't miss such stuff.

Of course this is only useful if that entity has a "can colllide"-flag - without you can skip the additional cpu workload.

Quote from: sphinx on July 05, 2019, 17:57:08

Quote
Deltatiming has to do with the movement of stuff.

X = X + speed * deltaTime

Believe it or not but that's exactly what I am trying to avoid with my game!!
Far from the headache of reviewing and adding delta timing to all update methods of the game, it will ruin some of the game working!!
I do not know how to explain it but it doesn't worth it for me

Try to explain, delta-timing can NOT ruin some of your game logic - except you did it wrong (eg did not split logic from drawing/rendering).

Also in most cases (moving objects) you will have a "Type" having a "Move()" or "Update()" method - add your delta-timer-logic there once and all extending types will inherit from it. There is no reason to "avoid" it.



Only reason not to use delta-timing is on specified hardware - if you programmed for some old computer or arcade machine (where you eg lock to interrupts).

bye
Ron

I think you misunderstand.
I'm not saying you should rely on VSync, I'm saying the opposite really. (that was the issue to begin with)
I'm saying you can update the game at a steady rate and keep rendering VSynced or unlocked.
You'll generally want to use VSync though, cause there's no need to render more frames than your screen can render anyways.
And you can use a fixed update rate (separate from rendering) and still get very smooth gameplay.
Keep in mind that games like Battlefield and a lot of other games run at 30 updates per second.
But they update things related to the rendering and positioning as the scene is rendered.
Giving you a fixed update rate with smooth positioning and animations which will work on any monitor HZ.

I have 30 "logic updates" and 60 renders per second too. And if vsync is enabled, these 60fps become "refresh rate"fps.

Sorry for having misunderstood you regarding vsync.


So back to "why split update/render":
- allows to have flexible "render rates"
- allows to have (more or less) constant "logic updates"
- allows to define speeds/velocity in "per second" rather than "per hertz"
- allows for slow-downs or "speed-ups"
- allows to run without even rendering something pretty easily


bye
Ron

True words.
Listen to this man. ^

Hi.. Im just testing something..