Hi all.

I know this kind of thread has being already made, and I already saw them, but I still don't get it.

Basically because I want to create a auto-sufficient class which is going to draw itself and has its own logic...

So I was thinking in create two functions (ex: obj_logic(), obj_draw() ) but my object must handle collision detection too. And I was thinking on this:

I don't know if the gif animation is actually working.

As you can see is a poor representation about what I think is happening when we do separate logic from drawing... The problem comes in, when we start talking about collision detection... As you can see in the image I'm assuming that the FPS = 5, it's just an example... Imagine that the "draw" box is actually moving that way on the screen and if you press it something happens.

Normally when you have a game that runs at FPS=60, this problem wouldn't exist, but if I want to create a software that runs at FPS=1 for example, should I find a way to tell the object to stop its collision detection system right? because otherwise the logic wouldn't be synchronized with the collisions, right?

Or there is another way??

All this is because I was thinking in allowing the program to change the FPS at run time (Just at the start point, is going to still being const float FPS = 5; )...

EDIT: Separating Logic from Drawing Part 2

gif

Collision detection is part of the logic, therefore they are synchronized.

This all depends on whether you want to use fixed or non-fixed timestepping.

Oh sorry I made two mistakes there... I was writing too fast.

I was trying to say: "because otherwise the drawing wouldn't be synchronized with the collisions, right?"

You can consider it a gift if you want

BTW I'm going to read about the timestep thing. thanks

Here's a very useful post from Kris Asick. Make sure to read the replies below as well, since he explains basically which are the different ways you can do the timing:

I'd quote the post here but the paragraphs get messed up.

EDIT: Basically, I would try the approach he mentions here:

Use interpolation for drawing, and a fixed internal timestep for the logic.

Incredible... When I thought that I had a base for making games, this came out... but it's interesting how you actually walk in these things. so timers to draw FPS was the first step... People is also using FPS to refer the logic... should be LPS (Logics per second)

It actually make sense, because I was thinking... Ok this game is able to draw into the screen at 30 FPS but that doesn't mean that is going to look the same at different machines, the logic must have a FPS rate too, at least you are using one FPS timer, both for logic and drawing... which isn't a good idea...

I was reading this article http://gafferongames.com/game-physics/fix-your-timestep/ but the Kris Asick post is clearer...

So what if your rendering is lagging behind? That is the price of only rendering once per frame. What matters is that your logic stays consistent, and collision response is part of logic. Rendering frequency has no impact on that, because rendering should never mutate the state of your world at all. You will never see an inconsistent state on screen; just possibly a somewhat outdated one. And the only solution to that is to draw more often.

The idea of separating logic and drawing is that drawing takes generally much longer than logic. By separating them, we can avoid drawing a frame if it takes too long (eg frame skipping) This way even though the graphics will seem choppy, the music will stay in sync and everything will stay happy.

The problem isn't that my rendering is lagging behind nor if I increase the FPS everything is going to be alright. The problem is that using FPS just for drawing is an incomplete way to create a game. Of course implementing this for tiny games would be stupid...

In an non-perfect world that is fine... But remember that your logic is running at the maximum velocity of you computer, there is no control about how fast your objects physics and other things are working behind the scene, I think that since computers these days almost have the same performance, by just adding a timer for the drawing is fine, but in the future if you run your game in a machine with super speed, your game is going to be unplayable even with the FPS for drawing.

Computers this days have around 3.0Ghz of processing speed, so the different on each machine is very tiny and with a FPS for drawing even more... But if you run your game in a 12.0Ghz with 24 cores, your game even having a FPS for drawing, the logic is going to run so fast, that what you're going to see are jumping scenes and things like that... At least that is what I think.

Yes that is true but I wasn't implementing it "Frame Skipping" , in this tutorial for example isn't implemented http://wiki.allegro.cc/index.php?title=Allegro_5_Tutorial/Timers

Have someone experienced that olds games seems to run faster now? I don't but I'm not a hard video game player... So I don't know... But should be...

The whole reason for these methods is to make the game run the same speed on all hardware!
With the delta-time approach, you multiply your movements and all other time dependent stuff by the time that has elapsed since the last update. Therefore, you can update as often as you'd like and objects still move at the same speed regardless. Only if you update too little, the moving objects start to "jump".
So basically, you should do logic-updates as often as possible, but only draw as often as necessary (20-60 times per second is mostly fine, depending on the game and the screen refresh rate).
I can't comment on the fixed logic rate approach, as I haven't used it anywhere.

Says who? I certainly didn't. That's a remarkably stupid way to do it.

Not necessarily. It would mean that the game's logic works differently on a faster CPU. For many (maybe even most) games you want the game logic to work exactly the same no matter how fast the CPU. If you jump, then the maximum height should be the same and even the trajectory of your body should be exactly the same, you should collide with the same objects, at the same angles and same velocities. The only way to do that is by having a fixed logic rate (e.g. 30 or 60 times a second).

And, of course, if you are doing more logic updates than is necessary for your game to function the way you intended it to, you're just wasting CPU cycles and burning the poor player's laptop battery for no good reason.

Do as many logic updates as you need to. No more.

That's what I'm saying...

Wrong...

I agree...

Uh?... I'm not saying that you are saying what you said that I said you said...

It's just a way to say that is you (or anyone) uses just FPS for drawing, your logic is going to be running in an uncontrolled way on different platforms.

You implement a timer to stop the logic loop when it's "caught up" and let the CPU run other programs or idle for a bit. Then if there's enough time left over you render the scene. If your logic were to take almost all of the available time, then screen updates would be slow and far between, although each frame would be reasonably current when it was drawn. It'd be like walking around and opening your eyes every once in awhile. If the logic's so complicated it can't ever catch up, then the computer is just too slow to play the game.

If you use the same timer for Logic and drawing, it's not going to act differently. The downside is that if the FPS drop for some reason, the logic will be slowed down as well.

Other games just use a timer for the logic(say 60fps), and draw as fast as possible. If the user decides to set V-Sync, the drawing will be stuck at the Monitor's HZ. And yes, there are people that enjoy turning off V-Sync for having 200fps when their monitor's hz can't display it. Tsk.

There's really no universal way to make timing in your game. If it's going to be very physics dependent and the simulations need to be accurate, a fixed internal timestep will be the best option, and doing interpolation when drawing. It'll also be ideal when running a networked game, so the server doesn't screw around with how precise it should be.

EDIT: And to continue Arthur's point above, using the Delta Time approach might allow older computers to run the game, even with a low FPS.

There's absolutely no reason to draw more often than your logic ticks, since nothing has changed between frames. You'd just be wasting cycles drawing what you've already drawn again.

That depends if your drawing is handling the interpolation or not.

Interpolation of what? Anything that manipulates the state of your game is logic.

Let me quote again Kris Asick's example:

Even if the logic is at 30FPS, you can draw it smoothly at 120FPS. You just interpolate the objects across the screen, like most 3D engines do.

You mean the logic keeps a "previous" and "current" variable, updated 30 times a second, and the drawing sequences between those two positions for everything? That seems wrong to me.

Well... why?

But then what you see is inconsistent with what is actually happening. Your rendering bits are inventing a view of the game world which is not true. This is a bad idea. I doubt whether "most 3D engines" do this for objects that are actually important.

It could work like this:

logic time:   0/30      1/30      2/30 
input:       dx=2      dx=-2
logic pos:    x=0       x=2       x=0
vsync time:   0/60 1/60 2/60 3/60 4/60
draw pos:     x=0  x=1  x=2  x=1  x=0

Because I only have one input at each logic tick, I can interpolate to the x=1 position for drawing even though in the logic the object only ever reaches positions 0 and 2.

Suppose a ball was bouncing off the ground, the "smooth interpolation" would show it magically hitting some invisible barrier a couple of times, then resuming upward motion without touching the ground. If it actually ran at 30 fps it wouldn't show it actually hitting the ground either, but it wouldn't show it moving sideways.

In this case, you're assuming the FPS rate is actually lower than the logic?

EDIT: Elias illustrated the idea well. Refer to that for an example.

Well, if the Logic is running at 30 ticks per sec, and the drawing is at 120fps(max hz of the display), then I don't see how the interpolation would skip the frame the ball actually touches the ground. I understand the situation you proposed, but the physics engine just wouldn't process that bounce inbetween the ticks.

Still, I think 30fps might be a bit too low if you need very accurate physics.

Poor wording on my part. X-G and the others are right, only do as much logic-updates as you need. However, CPU-burning aside, more is better to achieve smooth movements and animations (again, not more often than you draw to the screen, as X-G pointed out)

My statements were only intended for the delta-time approach. Fixed logic rate is a whole other story.

I think I see now what Arthur meant...

logic time:   0.00      0.02      0.04 (50 FPS)
input:        dx=-8     dx=8      dx=0
logic pos:    x=8       x=0       x=8
vsync time:   0.000  0.015  0.030  0.045  0.060 (66.7 Hz)
draw pos:     x=8    x=2    x=4    x=8    x=8

Baically, I know the last logic position (e.g. x=8), the velocity (e.g. 8 pixel in 0.02 seconds) and I know the time from the last logic position to my vsync position. If I interpolate like that then in the above case I will then never reach the 0 position.

Wait a minute, Wait a minute.. I'm getting lost here... The FPS IMO should always be lower than the TPS (Ticks per Seconds), otherwise like

But that doesn't means that the TPS can't be also controlled...

What I Think I'm doing by controlling the TPS is save even more processing time, and adding the ability to run my game exactly the same on different platforms...

And can I do that with the Fixed logic rate, right?

I see what you mean Elias. Well, if it's absolutely necessary that you know what's going on in the game logic perfectly, faking that with interpolation isn't going to work well. But I don't really see another solution for that other than Delta Timing. If an accurate physics engine is needed, Delta Timing might cause errors...

And locking the FPS to the logic's ticks will produce the most accurate result obviously, but you can't push the framerate above that.

EDIT: AMCERASOLI, as I said before, there isn't really "THE BEST" way to do timing that would work on every game. Think of what you need.

Absolute accuracy? Lock the FPS to the logic's ticks.
Logic Accuracy, but visually smooth(though it might be incorrect at some situations)? Use the method I posted.
Logic prone to (very) small errors? Delta timing should give you the best FPS it can handle.

That's the only 3 methods I have ever used so far.

Here, I made an infographic for you.

{"name":"603146","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/8\/d8e0e530d0e43af7fb64e4ada6bd5173.png","w":1000,"h":383,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/8\/d8e0e530d0e43af7fb64e4ada6bd5173"}

In all cases rendering is 4x as frequent as logic and the logic is assumed to have a good enough integrator to handle the bounce in one timestep. #1 is what you get if you extrapolate using only the velocity of objects. #2 is what you get if you also take acceleration into account. #3 is what you get if you render "one logic tick behind", and interpolate between the previous frame and the frame before that.

I believe case #3 is the one described by Arthur.

I was going to draw the with a paint program, but I'm too lazy. How did you do that?

[EDIT]

The case where I said it hits invisible barriers is the one with the "Oh God What?" underneath.

Pretty much that.

What a lot of you are describing isn't even interpolation, it's extrapolation.

Case #3 is interpolation. But I did assume the aforementioned dudes really did mean extrapolation since that is what you usually do, if you decide to do it.

EDIT: Updated infographic.

I was talking about case #3. I did understand the situation he described, though your graphic is nice.

I can't really figure out a way of faking the rendering, other than upping the internal framerate so those artifacts happen less often. It would never be completely accurate, as you said, you're just inventing the current object's positions. IMHO, I think that in the situation you describe the ball would have to be very fast to even notice the error. In the lowest speed possible, assuming we're viewing a fixed 2D plane, it'd need to be a bounce with a distance of 1 pixel from the ground, and bouncing 2 pixels away.

It's not really that bad in motion... I would link to a video but Youtube is lagging ATM.

So I guess adding another con, is that very fast moving objects might have artifacts like that. But the logic will be consistent, unlike the possible errors caused by Delta Timing. (Unless there's some perfect way to do Delta Timing, which I would pick immediately then)

Bit off-topic, those graphics are very nice, what did you use to draw them?

EDIT: I think it isn't Youtube but rather Google.

The thing is, if your framerate-versus-speed-of-objects is so good that this kind of artifact becomes unnoticeable, it's also so good that interpolation likewise becomes unnoticeable.

I drew the infographic with Photoshop.

True, though still, I think it can help for some extra FPS. I used this in an old engine of mine, having an internal framerate of 60fps, and a refresh rate of 85hz. Since the objects were pretty slow I didn't notice these kind of problems at all. But I guess as I said before, it mostly depends on the type of game I guess.

Anyway, I think it'd be useful to come down to a consensus on the following. Keep in mind that the objective is being able to render the same game at different framerates.

"The only way to have a totally consistent game(completely equal in logic) and that is visually accurate as well across different systems, is rendering a single frame per logic's tick?"

AFAIK, Delta Timing could cause even a minimal error.
And my method would be inaccurate visually.
But locking the FPS to the logic would make it look at 60fps on a 120hz monitor.

So... could I do something like this?

Would be very easy, but I have learned when something is too much easy in programming very probably what you're doing is wrong...

So... What do you think?

EDIT: Aw forget it I don't know in what was I thinking... Would be something like that... but that code is shity

EDITED AGAIN: No wait A minute... It works...