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
AMCerasoli
Member #11,955
May 2010
avatar

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.

c1.gif

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

blargmob
Member #8,356
February 2007
avatar

gift

gif

Quote:

because otherwise the logic wouldn't be synchronized with the collisions, right?

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.

---
"No amount of prayer would have produced the computers you use to spread your nonsense." Arthur Kalliokoski

AMCerasoli
Member #11,955
May 2010
avatar

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

Me said:

because otherwise the logic wouldn't be synchronized with the collisions, right?

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

Me said:

gift

You can consider it a gift if you want ;D;D

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

Dario ff
Member #10,065
August 2008
avatar

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:

Quote:

Delta Time Approach
Pros: Can achieve the best looking framerates, less processor intensive.
Cons: Difficult to program and get accurate.
Fixed Logic Rate Approach
Pros: Much easier than Delta Time to program and get accurate.
Cons: Cannot render framerates above its maximum limit, more processor intensive.

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

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

Quote:

PixelShips Retro, one of my games in the Depot, runs a 30 FPS fixed framerate and uses the interpolation system I came up with, thus even if it only runs 30 FPS internally, it can look like it's going ANY framerate perfectly smoothly. ;)

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

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

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) ;D

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

X-G
Member #856
December 2000
avatar

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

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

jmasterx
Member #11,410
October 2009

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.

AMCerasoli
Member #11,955
May 2010
avatar

X-G said:

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

jmasterx said:

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.

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

imaxcs
Member #4,036
November 2003

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

X-G
Member #856
December 2000
avatar

But remember that your logic is running at the maximum velocity of you computer

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

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

Elias
Member #358
May 2000

imaxcs said:

So basically, you should do logic-updates as often as possible

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

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

X-G
Member #856
December 2000
avatar

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.

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

AMCerasoli
Member #11,955
May 2010
avatar

imaxcs said:

The whole reason for these methods is to make the game run the same speed on all hardware!

That's what I'm saying...

imaxcs said:

So basically, you should do logic-updates as often as possible

Wrong...

Elias said:

It would mean that the game's logic works differently on a faster CPU

I agree...

X-G said:

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

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

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.

Arthur Kalliokoski
Second in Command
February 2005
avatar

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.

They all watch too much MSNBC... they get ideas.

Dario ff
Member #10,065
August 2008
avatar

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.

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

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.

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

Dario ff
Member #10,065
August 2008
avatar

X-G said:

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.

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

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

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

Dario ff
Member #10,065
August 2008
avatar

Let me quote again Kris Asick's example:

Quote:

PixelShips Retro, one of my games in the Depot, runs a 30 FPS fixed framerate and uses the interpolation system I came up with, thus even if it only runs 30 FPS internally, it can look like it's going ANY framerate perfectly smoothly. ;)

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.

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

Arthur Kalliokoski
Second in Command
February 2005
avatar

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.

They all watch too much MSNBC... they get ideas.

Dario ff
Member #10,065
August 2008
avatar

That seems wrong to me.

Well... why? :P

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

Dario ff said:

You just interpolate the objects across the screen, like most 3D engines do.

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.

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

Elias
Member #358
May 2000

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.

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

Arthur Kalliokoski
Second in Command
February 2005
avatar

Quote:

Well... why? :P

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.

They all watch too much MSNBC... they get ideas.

Dario ff
Member #10,065
August 2008
avatar

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.

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

 1   2 


Go to: