|
This thread is locked; no one can reply to it. |
1
2
|
Separating Logic from Drawing |
AMCerasoli
Member #11,955
May 2010
|
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; )...
|
blargmob
Member #8,356
February 2007
|
AMCERASOLI said: 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. --- |
AMCerasoli
Member #11,955
May 2010
|
Oh sorry I made two mistakes there... I was writing too fast. 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 BTW I'm going to read about the timestep thing. thanks
|
Dario ff
Member #10,065
August 2008
|
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 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. |
AMCerasoli
Member #11,955
May 2010
|
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...
|
X-G
Member #856
December 2000
|
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. -- |
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. Agui GUI API -> https://github.com/jmasterx/Agui |
AMCerasoli
Member #11,955
May 2010
|
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!
|
X-G
Member #856
December 2000
|
AMCERASOLI said: 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. -- |
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). -- |
X-G
Member #856
December 2000
|
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. -- |
AMCerasoli
Member #11,955
May 2010
|
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... 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
|
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
|
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. |
X-G
Member #856
December 2000
|
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. -- |
Dario ff
Member #10,065
August 2008
|
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. |
X-G
Member #856
December 2000
|
Interpolation of what? Anything that manipulates the state of your game is logic. -- |
Dario ff
Member #10,065
August 2008
|
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. |
Arthur Kalliokoski
Second in Command
February 2005
|
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
|
Arthur Kalliokoski said: That seems wrong to me. Well... why? TranslatorHack 2010, a human translation chain in a.cc. |
X-G
Member #856
December 2000
|
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. -- |
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. -- |
Arthur Kalliokoski
Second in Command
February 2005
|
Quote: Well... why? 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
|
Arthur Kalliokoski said: 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. |
|
1
2
|