Allegro.cc - Online Community

Allegro.cc Forums » Game Design & Concepts » Separating Logic from Drawing

This thread is locked; no one can reply to it. rss feed Print
 1   2 
Separating Logic from Drawing
Arthur Kalliokoski
Second in Command
February 2005
avatar

Dario ff said:

Even if the logic is at 30FPS, you can draw it smoothly at 120FPS.

The only way Trump is going to be involved in a landslide is if the land surrounding the White House collapses into the Earth's core. -- bamccaig

Dario ff
Member #10,065
August 2008
avatar

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.

TranslatorHack 2010, a human translation chain in a.cc.
My games: [GiftCraft] - [Blocky Rhythm[SH2011]] - [Elven Revolution] - [Dune Smasher!]

imaxcs
Member #4,036
November 2003

imaxcs said:

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).

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)

Elias said:

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).

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

Elias
Member #358
May 2000

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.

--
"Either help out or stop whining" - Evert

AMCerasoli
Member #11,955
May 2010
avatar

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

X-G said:

You'd just be wasting cycles drawing what you've already drawn again

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?

Dario ff
Member #10,065
August 2008
avatar

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.

TranslatorHack 2010, a human translation chain in a.cc.
My games: [GiftCraft] - [Blocky Rhythm[SH2011]] - [Elven Revolution] - [Dune Smasher!]

X-G
Member #856
December 2000
avatar

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"}603146

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.

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散!悪霊退散!怨霊、物の怪、困った時は ドーマン!セーマン!ドーマン!セーマン! 直ぐに呼びましょう陰陽師レッツゴー!

Arthur Kalliokoski
Second in Command
February 2005
avatar

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.

The only way Trump is going to be involved in a landslide is if the land surrounding the White House collapses into the Earth's core. -- bamccaig

X-G
Member #856
December 2000
avatar

Pretty much that.

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散!悪霊退散!怨霊、物の怪、困った時は ドーマン!セーマン!ドーマン!セーマン! 直ぐに呼びましょう陰陽師レッツゴー!

gnolam
Member #2,030
March 2002
avatar

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

--
Move to the Democratic People's Republic of Vivendi Universal (formerly known as Sweden) - officially democracy- and privacy-free since 2008-06-18!

X-G
Member #856
December 2000
avatar

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. :P

EDIT: Updated infographic.

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散!悪霊退散!怨霊、物の怪、困った時は ドーマン!セーマン!ドーマン!セーマン! 直ぐに呼びましょう陰陽師レッツゴー!

Dario ff
Member #10,065
August 2008
avatar

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.

TranslatorHack 2010, a human translation chain in a.cc.
My games: [GiftCraft] - [Blocky Rhythm[SH2011]] - [Elven Revolution] - [Dune Smasher!]

X-G
Member #856
December 2000
avatar

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.

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散!悪霊退散!怨霊、物の怪、困った時は ドーマン!セーマン!ドーマン!セーマン! 直ぐに呼びましょう陰陽師レッツゴー!

Dario ff
Member #10,065
August 2008
avatar

X-G said:

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.

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.

TranslatorHack 2010, a human translation chain in a.cc.
My games: [GiftCraft] - [Blocky Rhythm[SH2011]] - [Elven Revolution] - [Dune Smasher!]

AMCerasoli
Member #11,955
May 2010
avatar

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...

#SelectExpand
1 2if(redraw && al_is_event_queue_empty(event_queue)) { // DRAWING 120 FPS 3redraw = false; 4 5// So instead of draw here, I would split this in other step 6 7if(real_drawing == 60){ 8// Reall draw here... 9real_drawing = 0; 10 11} 12real_drawing ++;

So... What do you think? ;D

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...

 1   2 


Go to: