Jump to content


Photo

Tweening Vs Delta Time Vs Other


  • This topic is locked This topic is locked
53 replies to this topic

#1 GearGOD

GearGOD

    Deus Verus

  • GMC Member
  • 2153 posts

Posted 12 September 2006 - 02:34 AM

So since the dark ages GM games have been limited to 30 fps. 60 if you design your game to do that. 60 is all fine and well, but there's the little problem that you're doubling your minimal speed threshold and thus doubling the chances that some weaker computer won't be able to keep up with the 60 fps - at which point the gameplay will slow down even though 30fps should also be perfectly playable.
The real problem is 'how do I keep motion looking constant at variable framerates' and room speed should really be set to 9999. There are two commonly implemented solutions to this problem: delta time, and one I shall call tweening because that's what I knew it as all my life.

Delta time is the worse looking out of the two and also the harder to implement in the long run. It works as follows:
a global clock tracks the instantaneous framerate of the game.
it divides the desired framerate clock time by this instantaneous rate to produce a coefficient that describes how many times faster or slower the game is running than the clock speed at which it is supposed to.
all moving objects then multiply their speeds by this coefficient in order to appear to move at the same speed on screen
Simple, yes? No. You can't just multiply the object's speed because then it will forget it's original speed. That means you need to keep two variables for speed. Then we have hspeed and vspeed, same problem. Motion add - needs to be rewriten with delta time in mind. Acceleration? Same thing. And after you've done all that, it will look rather jittery if the framerate changes too much over too short a period of time. If you pause the game (while say, moving the window) then the clocked fps will drop to almost zero and when unpaused, all the objects will try to compensate for this by approaching very high speeds (thus you get an explosion of sorts after moving the window around). An example of this, along with some other stuff can be found here

The second, tweening, is much more fun. In theory it should be both easier to implement, and much cleaner looking. The idea of it is to sepperate to run the game logic and graphics at two different clocks. The logic is forced to a constant say, 30 fps. And the graphics are floating taking up as much of the remaining time as possible. On each logic update, the x,y,xprevious, yprevious of all objects are updated. The drawing then uses this to draw the objects between it's current and previous location based on how far along it is to the next logic cycle. This means that if I ran a game using it with the logic locked to 5fps and made a ball chase the mouse, I would see it very smoothly glide over to the mouse position (sort of like more_towards_point) but it would only react to the mouse position at 5fps meaning that if i moved it constantly, it would move towards where I started moving it.
Implementing it goes as follows:
all references to the objects position in the draw event go from x and y to xprevious+dx*tween, yprevious*dy*tween, where dx and dy are the difference between the current and previous locations (thus at tween=0 the object is at the previous location and at tween=1, the current)
a global clock turns off automatic drawing
in the step event of the global clock, we run a while loop and repeat it as many times as possible until it has run for the duration of one logic frame (1/30 seconds usually). Esentially all this while loop does is lag the game just enough to make it run at 30 fps. Pointless huh? Not really. Inside the while loop, we continuously calculate how far along we are from the next logic update and pass it on to a global tween value between 0 and 1, and keep re-drawing the room. This will allow for a lot more than 30 rendering updates per second while the step events and everything else remains locked at 30. It's a wonderful method and you'll find an example of it here (test 0)
The problem? Take a look at the graphics clock. 100 fps? 80? GM alone can do that scene at 2000 on my computer. It turns out that screen_redraw is an extremely slow command. Not acceptable.

At this point I decided to try a slighly different approach with tweening. Instead of a while loop delaying the logic updates to 30 fps, I thought why not run a clock at 30 fps and every time it ticks, tell all the objects to update their locations (thus limiting logic updates to that speed once again) while in their draw event they do pretty much what they did before. It worked, I was now running the demo at around 2000fps but couldn't help notice the occasional jitter in the movement of the objects. What's going on - I'm still not entirely sure. I believe it's because the logic clock isn't synched to the graphics clock in this scenario and you can have small differences. This effect becomes really obvious if you reduce room speed to 30 fps (press space) and see that the ball appears to move at perhaps 15. The reason is that the the logic clock and GMs event clock are triggering at different times and when they don't coincide, the reaction is delayed by up to a full frame.
A demo of this is in the same file you downloaded above. It's called test1.

I'm posting here to show two working methods to people (the first and the second of these. The second one should be perfect for smaller games that don't mind the speed drop). And in hopes that someone knows other ways to approach this or how to get around the jitteryness in the last example.
Although seriously, this is something that's in there by default with most game engines. Why has Mark overlooked it for so long when implementing it so crazily simple at engine level.

Edited by xot, 13 April 2008 - 06:23 AM.
** Old Experts Topic **

  • 0
Engineers are not programmers. Stop thinking that you can save a few bucks by writing code yourself instead of hiring a programmer. Your code sucks.

#2 metalhead1023

metalhead1023

    GMC's only emo kid

  • New Member
  • 612 posts

Posted 12 September 2006 - 04:25 AM

eww calculating speed for delta seems easy but in that example its way hard. I personaly would never go that route

Edited by metalhead1023, 12 September 2006 - 04:35 AM.

  • 0

#3 link0007

link0007

    GMC Member

  • New Member
  • 298 posts

Posted 12 September 2006 - 03:02 PM

well delta time reminds me too much about physics :D never go along that way...
tweening sounds pretty decent... but there has to be a way to synch the clocks... as you know I'm not much of an expert, but isn't there a way to combine those two clocks? it would make it synched I think.
dunno though, 'cause like you say, you obviously need two clocks to count both the code-fps, and the visual-fps... but then again, doesn't the code-fps affect the visual-fps? gamemaker is object oriented, but not in fps, or is it? can 2 objects have different fps?
  • 0

#4 FredFredrickson

FredFredrickson

    Artist

  • Global Moderators
  • 9225 posts
  • Version:GM:Studio

Posted 12 September 2006 - 03:39 PM

Pretty interesting read GearGOD, I will be looking forward to trying out your test files when I get home from work.

At first I thought this might be a discussion about 3D animation (since tweening is an animation technique, and that's the context I'm most familiar with), but still handy.

I'd be interested to see how much of a difference this can make in the overall performance of a more complex game. What kind of lag effects would it generate if every second the calculations take too long to do?

eww calculating speed for delta seems easy but in that example its way hard. I personaly would never go that route

<{POST_SNAPBACK}>

This is the Expert discussion forum after all... :D
  • 0

#5 Scooternew

Scooternew

    GMC Member

  • New Member
  • 1325 posts

Posted 13 September 2006 - 03:49 AM

I personally like delta timing, and use it in one of my games. It seems simple enough at its roots.
  • 0

#6 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7522 posts
  • Version:GM:Studio

Posted 13 September 2006 - 12:45 PM

It worked, I was now running the demo at around 2000fps but couldn't help notice the occasional jitter in the movement of the objects.

What is occasional for you was continous for me, at least for the object that moves with the mouse. And that was running at 3000 fps.

In your second method, tween is calculated at the begin step event. This has two effects:

1. The tween calculated in the first step is very low because the begin step immediately follows the step event;
2. The tween calculated for the movement in the current step is largely based on the time it spent to execute the previous step.

While 1) should be nowhere near noticable (it only lasts a single step), 2) means that the movement correction is based on a step where the completion time of that step may have been different. At 3000 fps in test 1, the jitter disappears for me completely if I move the system timing to the end step event.

At 30 fps the objects jump to their positions rather than move there, but this is little surprise because the draw events are still executed at the room speed that cannot beat the card's refresh rate.
  • 0

#7 GearGOD

GearGOD

    Deus Verus

  • GMC Member
  • 2153 posts

Posted 13 September 2006 - 01:44 PM

But of course! Thank you. I have no idea what possessed me into having it done at begin step. Thank you for pointing that out.
The jumping around at 30 fps is due to the fact that the timer activating global.tick isn't running syncrhnously with GM's timing mechanism. This means that not every GM frame will be considered a 'tick' frame. I'm not yet sure how to deal with this but it's a big issue since the reason for the whole thing is to run consistently at any framerate; you can't assume it will be over 100 or whatever threshold this starts looking nice at.

Edited by GearGOD, 13 September 2006 - 01:50 PM.

  • 0
Engineers are not programmers. Stop thinking that you can save a few bucks by writing code yourself instead of hiring a programmer. Your code sucks.

#8 link0007

link0007

    GMC Member

  • New Member
  • 298 posts

Posted 13 September 2006 - 04:17 PM

?
I don't get it here: what would be the difference between the begin-step, and the end-step? the difference is... well, one step :angry:
  • 0

#9 Rebound->

Rebound->

    GMC Member

  • New Member
  • 152 posts

Posted 13 September 2006 - 08:07 PM

It may be a small difference, but it's enough. The order of execution is important.
  • 0

Inforticle - The Free Informative Article Directory
Bullfee - The New and Innovative Online Store

#10 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7522 posts
  • Version:GM:Studio

Posted 13 September 2006 - 11:15 PM

The jumping around at 30 fps is due to the fact that the timer activating global.tick isn't running syncrhnously with GM's timing mechanism. This means that not every GM frame will be considered a 'tick' frame. I'm not yet sure how to deal with this but it's a big issue since the reason for the whole thing is to run consistently at any framerate; you can't assume it will be over 100 or whatever threshold this starts looking nice at.

<{POST_SNAPBACK}>

So you need to compensate for missed ticks in the next step which more or less leads you back to delta time.

I don't get it here: what would be the difference between the begin-step, and the end-step? the difference is... well, one step :D

<{POST_SNAPBACK}>

No, it isn't. End step makes a better place to measure how long the current step took than begin step (part of the time includes all events executed after the end step event in the last step).

Edit: One possible way to avoid the use of delta time where the room speed cannot keep up with the clock frame (which is the key issue here) is actually quite straightforward.

Your tweening method only registers whether the current step needs to execute a single tick. But every once in a while you just need to execute those extra ticks within the step that were missed in previous steps.

To do this you need to check the amount of ticks that have been executed against the total amount of ticks that should have been executed since the start of the room to maintain the clock speed.

Changing around a few things, for o_system_clock change the create event to read this:

hrt_init()
hrt_set_resolution(10000)
global.tween = 1
global.ticks = 1
global.totalticks = 0
start_time = hrt_time_now()
frameRate = 30
frameTime = (1/frameRate)*10000

And the end step event to read this:

// Add the ticks executed in the last step to the total tick counter
global.totalticks+=global.ticks

time_spent=hrt_time_now()-start_time;

hdiff =time_spent-global.totalticks*frameTime;
global.tween = hdiff/frameTime;
// As we may spend more than one tick per step, tween may now exceed 1
//if global.tween>1 then global.tween = 1

// Ticks to perform in current step (floored)
global.ticks=time_spent div (frameRate*global.totalticks)

The above code keeps the delta frame loss and corrects it every once in a while when the integer division floors it to more than one step.

Now you need to change at least object3's step event to execute the correct amount of ticks:

repeat global.ticks
 {
   xp = x
   yp = y
   x+=hsp
   dx = (x-xp)
   dy = (y-yp)
 }

The o_ball object is a problem here and also exposes the main drawback of this method: any code that compensates the object movements needs to be executed n times depending on the amount of ticks to spend. This goes well for simple movement like object3, but not as well for user input such as o_ball or for other objects where movement is heavily dependent on other instances.

The method seems better in track of the clock speed (see object3), but admittedly I haven't quite worked around the flickering of o_ball yet.

Another drawback is that this solution tries to compensate lost frames by, in the very worst case, multiplying it's workload by the amount of ticks to process. If your speed loss was a result of overload already, this can work out as a cascade effect unless numbers of instances or processes are cleared along the way.

Edited by Smarty, 14 September 2006 - 09:13 AM.

  • 0

#11 bendodge

bendodge

    File Host

  • GMC Member
  • 1237 posts

Posted 15 September 2006 - 06:51 PM

I think someone would have said this if it worked, but I'll say it just in case. I haven't tried it, but it seems logical.

Have 2 variables for speed: one that is the absolute speed, and then the actual speed is the absolute speed divided by the framerate. Alarms would be multiplied by the frame rate.
  • 0
The government can't save you.
Time does not negate impossibility.

#12 Schreib

Schreib

    Valen Shadowbreath

  • GMC Member
  • 1458 posts
  • Version:Unknown

Posted 15 September 2006 - 09:47 PM

That won't really work if the frame rate drops to a very slow rate. I believe tweening is a better method. Game logic at first; graphics for the remaining time of processability.
  • 0
~ Tiefling | DeviantART gallery See my spacescapes!
GM Obfuscator | Protect your games from prying eyes. Get it now!
Motto: Noli turbare axiomates meos!

#13 Pyroguy

Pyroguy

    GMC Member

  • New Member
  • 136 posts

Posted 17 September 2006 - 02:35 AM

Delta time can have its advantages; it can make pausing or slow-motion MUCH easier, because delta time programming acts as a framework for it, but tweening is easier to implement, especially if you have large parts of a game already programmed. No one has really mentioned the effect each method has on user input! Tweening, if performed by executing blocks of code over again, will take in new inputs and use them in calculations, leading to control that a player doesn't have visual representation of. If you do tweening instead by carrying over variables from one tick to another in the same frame, you will end up making the player lose control until a graphical frame comes up, making them susceptible to "crashing" into things in the game without being able to help it. Delta time makes a lag effect, which can make you move really far by tapping a key just as a graphical frame is rendered, but also causes enemies to move really far.

Delta time, however, can cause severe muck-ups with objects moving very large amounts of distance at a time (which some engines can't handle without bugs, and others get overloaded trying to figure exact positions, making the next frames take longer and longer). One way to solve this is to make a delta time rate "cap"; basically, just a statement that keeps the motion modifier under a certain amount, so that physics code or whatnot does not go haywire trying to move an object at a bajillion pixels per frame. In effect it disables the delta time when actual frame rates drop SEVERELY, leading to motion that is slower than it should be, but as a precaution to prevent the game from crashing.

Tweening can have the exact same problem, but even worse, because (with the implementation of Smarty's idea) with a frame drop, more and more run throughs of the code are added per frame to make up for the slow graphical frame rate. You would want to put a cap on tweening tick rates as well, not letting more than 10 "ticks" per frame of the code. Overloads in tweening would be much more likely to cause infinite loops than in delta time because you are running through all the code again until it can match the "real time", and then drawing a graphical frame; not just increasing the load on physics calculations.

Edited by Pyroguy, 17 September 2006 - 02:50 AM.

  • 0

#14 GearGOD

GearGOD

    Deus Verus

  • GMC Member
  • 2153 posts

Posted 18 September 2006 - 06:12 AM

Sorry for not replying faster, had some stuff to deal with.
The obvious optimization is to stop repeating and use integration to calculate the final displacement. We also know that the maximum legitimate number of ticks is 2 as long as the framerate is above or equal to the desired logic update rate.
Dealing with direct user input remains fun though. Perhaps it's best to just use delta time for those special cases.
  • 0
Engineers are not programmers. Stop thinking that you can save a few bucks by writing code yourself instead of hiring a programmer. Your code sucks.

#15 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7522 posts
  • Version:GM:Studio

Posted 18 September 2006 - 10:31 AM

User input may severely suffer from tweening. But I think a combination is needed between this tweening method and a per-process tick. You can minimize the step execution time by spreading the processes across several steps.

For example, I don't think it is always necessary to have user input readouts every step. At the default room speed, nobody can change direction 30 times per second. This is a process you may execute only once every even step, while you take up another process in the odd step.

Another issue with tweening would be the collision event. Trying to make up for a tick in the method I described will cause the system to miss a collision. To check for collisions made in the traversed path, you need the move_contact commands, but those aren't very specific - you can only check for solid instances or for all instances (I've already submitted a request for one that allows to choose an object to check for). You also need to make up for the remainder of the path after collision. Alternatively, you can use collision_line, but it won't do precise collision checking between two sprites.

It sounds like you need a lot of extra processing power just to guarantee a continuous frame rate.
  • 0

#16 link0007

link0007

    GMC Member

  • New Member
  • 298 posts

Posted 18 September 2006 - 01:24 PM

Well, in race games, or fighting games, you obviously need the 30fps input. Don't forget this is Game Maker and Game Maker games are often race games, or platformers where you need quick fingers to do wall taps at the right time. So obviously user-input is very inportant. Maybe if you make 3 (or more) logical timers, one for physics, one for misc variables (score and stuff), one for input, one for graphics, one for sound etc. you'll get about the desired "smooth" effect, but only with a couple of more timers. But that might slow it down a bit though :S
  • 0

#17 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7522 posts
  • Version:GM:Studio

Posted 21 September 2006 - 08:12 AM

Well, in race games, or fighting games, you obviously need the 30fps input. Don't forget this is Game Maker and Game Maker games are often race games, or platformers where you need quick fingers to do wall taps at the right time.

I must say I haven't seen a lot of racing games here lately. But do you really need 30fps input for a double tap? I don't think so. How many are able to do a double tap in 1/15 of a second?

I've written a little test to see the influence of timed (alarm) controls on the input of a small game. It's just to see how controls in an alarm as opposed to a step event influence the game.

Timed Controls

Press F1 to see the controls. I know that the type if game influences the experiment, but I still feel that at 15 reads per second the controls respond well enough to play this game (4 at 60 fps). It's still even playable at 10 (6 at 60 fps).

Of course, controls aren't always the most processor-heavy part of a game (not in this one anyway) but to me it shows it may be spread over several steps as opposed to one. If you do that too for other processes that don't need to be executed every single step (pathfinding, for example) - with the use of timelines, you can spread scripts more evenly over a period of time, ultimately saving processing time.
  • 0

#18 TwistyWristy

TwistyWristy

    GMC Member

  • New Member
  • 693 posts

Posted 21 September 2006 - 09:28 AM

Very interesting, Smarty.

As soon as I saw what you were doing, I had the idea to add a 'balancing' variable to the speed, that takes the room speed and step amount into account.
The formula needs a bit of tweaking, but it works well and gives a little more controlabillity to the user.

TwistyWristy

P.S.

I know this is just a test, but this is just a note for if anyone wanted to implement this in games.
In order to keep everything well-timed you would either have to maintain a rock-steady framerate, or use a timer dll like GearGOD.
I've used the alarms to control speeds before, and you'll get different results on different computers.
Even worse than different speeds is if your fps drops to 0 for a split second; the entire timing can be thrown off, because the alarm now registers '0' and will no longer go off.

TwistyWristy

Edited by TwistyWristy, 21 September 2006 - 10:06 AM.

  • 0

#19 >Leroy222<

>Leroy222<

    GMC Member

  • New Member
  • 473 posts

Posted 01 October 2006 - 07:34 AM

I tried using your tweening dll, GearGod. It worked ok, but you should make the system_clock turn vsync off, or youll only get 2fps on the graphics clock.

EDIT: made a small discovery, when u use a lighting engine, you must put the update code in with the code for redrawing the screen, or itll lag behind everything else.

The end effect is really nice!

Edited by >Leroy222<, 01 October 2006 - 07:41 AM.

  • 0

#20 RandomYakc

RandomYakc

    GMC Member

  • New Member
  • 125 posts

Posted 05 October 2006 - 09:56 PM

I don't exactly know how you would do this well, but while using the tween method,what if instead of going straight toward the destination, you would use some sort of pre-calculated motion_add so that there isn't a straight line to the destination each "frame"?

What I mean by pre-calculated is that the added motion isn't the vector to the destination divided by the time in between two "frames", but some motion that if used for 2 or 4 or 8 frames, would position the object exactly at the destination using the destination position and the object's position, direction, and velocity. I really can't think of the formula to do this right now, but I think it would look quite a bit nicer and not be much slower.
  • 0

#21 dislekcia

dislekcia

    GMC Member

  • New Member
  • 35 posts

Posted 13 October 2006 - 09:09 PM

I don't see what the issue is with delta-timing, besides the fact that GearGod's definition of it is dreadfully incorrect ;)

So far every single delta-time implementation I've come across in console development has had nothing to do with instantaneous framerates or scaling fixed-speed motion according to a desired output. All delta-time means is that you measure how long (in real time, so you need an accurate timer) each frame takes to execute. Once you have this delta value, you simply use that to move things around in your game...

Yes, this means that you need positional calculations that are based on timed values, so you store speed in pixels per second (for instance). Provided you know where an object is at the beginning of a frame, what state it's in (ie: if it's being accelerated and how fast it's moving in which directions) and how long the frame has taken to update, you can position the object with 100% accuracy.

I use this technique in my own networked GM game, Monochrome (see sig) and it works perfectly. It can be running at 20 FPS on one machine and 45 FPS on another and they'll keep in sync and display the correct positions just fine.

BTW: The speed "adjustment" multiplying that GearGod mentions for his definition of delta time implementations is typically used in tweening solutions to estimate percieved framerate. Whenever you tween a value that's not being sampled regularly enough, you have to compensate for previous sampling inaccuracies, this means that in the short term you're constantly messing with how much tweening is being done between logical ticks to try and smooth things out. To me, that seems far more complex.

-D
  • 0

#22 GearGOD

GearGOD

    Deus Verus

  • GMC Member
  • 2153 posts

Posted 19 October 2006 - 10:40 AM

Consider this: I shoot a slow-moving missile at an ai player who will try to avoid it. At that moment there's a hickup with my computer as some background task takes over the cpu for several seconds. Once the game is alive again, your time-based solution will have already placed the rocket at several seconds worth down it's track, and the ai player shifted along a straight line given his last velocity. This is undesired. This is not seen in good games. This is inevitable with a time-based solution. The other downside is that a time-based solution is not deterministic, which is also not desired. Both of these are overcome with an approach like tweening.

Instantanous framerates and coefficients are in effect the same thing as your solution and the only reason I introduced them is to make integration as seamless as possible.
  • 0
Engineers are not programmers. Stop thinking that you can save a few bucks by writing code yourself instead of hiring a programmer. Your code sucks.

#23 dislekcia

dislekcia

    GMC Member

  • New Member
  • 35 posts

Posted 19 October 2006 - 12:23 PM

Consider this: I shoot a slow-moving missile at an ai player who will try to avoid it. At that moment there's a hickup with my computer as some background task takes over the cpu for several seconds. Once the game is alive again, your time-based solution will have already placed the rocket at several seconds worth down it's track, and the ai player shifted along a straight line given his last velocity. This is undesired. This is not seen in good games. This is inevitable with a time-based solution. The other downside is that a time-based solution is not deterministic, which is also not desired. Both of these are overcome with an approach like tweening.

Instantanous framerates and coefficients are in effect the same thing as your solution and the only reason I introduced them is to make integration as seamless as possible.

<{POST_SNAPBACK}>


I'm afraid you're mistaken. Adding a predictable timing system and discrete timestamps to a series of events is one of the best ways to make them behave deterministically.

Let's expand on your scenario a little: Some other task occurs in the background and eats resources, you're going to lose frames when that happens, accept that. Now the question becomes what do you do with those lost frames. The key to all that is simply examining your delta each frame and checking to see what events are now needed, different circumstances require different ways of dealing with the problem...

If you're running a single player game locally and you get a framerate hitch, it's ok to simply slow the game down and let it "catch up" with what's going on. Using delta time, all you need to do to achieve this is clamp your delta to some maximum value (1/20 seconds, for instance) and the game will run at a logical 20 fps minimum, even if it's actually running at 15 fps for a while. In your scenario all that happens is the game treats the next frame as though it didn't have to wait 2 seconds for it. Maybe the user notices the slowdown, maybe not. You still can't do anything about them noticing the pause, that's outside your control.

The other approach to a framerate hitch is to check to see if your delta is large enough to mean any logical events/processing are going to be missed if we treat this amount of time as a single frame. The actual implementation of this on a per-object basis depends on the situation: In a multiplayer situation you can't "slow down" the game to erase the frame-hitch, instead you simply step through impeding messages/events according to their timestamps; In a single player game you could make a logical framerate of 60fps function fine with a delta of 1/45 by simply processing one "extra" logical step per frame, the trick is not to process the full delta but allocate it across the logical steps.

Your AI example can be handled very easily by simply having the AI check to see if it should have "thought" about where to go a couple of times during that looooong delta. It can even accurately grab info about the objects it should be avoiding during the extra long processing time because it can predict where they're going to be (they're deterministic, after all).

All I'm saying is that the key to using delta-time properly is good design. Build your positional calcs to always recalc from a known starting position and time. Take missed events into account. Propagate delta-changes throughout the entire system, don't simply think that the approach is about syncing screen output to logical state, it's not. Delta-time allows for rock-solid determinism because it's an entire engine paradigm (one which I've implemented in GM very easily, BTW).

Tweening is about massaging logical data to display nicely onscreen. From a calculation level, I've always found that seperation of implementation much more annoying to handle. Tweening would deal with your framerate hitch scenario by averaging out the motion of the object over several frames after the slowdown, that works fine, but plays havok with your logical position of the AI (for instance). Unless you make logical positioning of AI objects hook into the tweened position, in which case you're simply doing a very strange, single-case delta-time implementation. Of course that's going to be a major headache :P

-D
  • 0

#24 GearGOD

GearGOD

    Deus Verus

  • GMC Member
  • 2153 posts

Posted 19 October 2006 - 12:40 PM

You know, I would love if you presented a simple example of what you see as a solid delta-time implementation because on the one hand you say it's simple, and on the other, you propose clamping (which is a hack imo), compensation, and prediction; all on a per-instance basis. I don't see how all that can happen 'simply'.

Tweening is about massaging logical data to display nicely onscreen. From a calculation level, I've always found that seperation of implementation much more annoying to handle. Tweening would deal with your framerate hitch scenario by averaging out the motion of the object over several frames after the slowdown, that works fine, but plays havok with your logical position of the AI (for instance). Unless you make logical positioning of AI objects hook into the tweened position, in which case you're simply doing a very strange, single-case delta-time implementation. Of course that's going to be a major headache

Any loss of 'accuracy' with tweening is limited to a single logic tick and thus, it will never look bad regardless of how long you had things on pause for, or how badly the framerate fluctuates.
  • 0
Engineers are not programmers. Stop thinking that you can save a few bucks by writing code yourself instead of hiring a programmer. Your code sucks.

#25 dislekcia

dislekcia

    GMC Member

  • New Member
  • 35 posts

Posted 19 October 2006 - 01:19 PM

Alright. A simple implementation relies on known positions and functions to give you extrapolated positions after plugging in a certain value for delta.

Then at the beginning of every step, all you need to do is calculate a global delta time. In this calculation step, you have the option of massaging delta if you need to: Clamp it if it's too long, rip it apart into several logical steps (and use event_perform() to simulate an extra step event in all delta-enabled objects), whatever you need to do to delta, do it here.

Objects then use that global delta to go about their business in the world, yes you're still linking framerate to logical rate, but this time it doesn't matter when a logical event happens as it's simply flagged with a timestamp and left up to delta-processing to determine when objects should begin processing it.

Plug in some gameplay rules and you've got a simple delta implementation. If you don't believe that it can be that simple: Download and play Monochrome, it's got bots, replays, pausing, fast-forwarding, etc. All using that simple delta-model.

In return, I'd love to see a simple tweening implementation idea from you :P. You're already barking up the wrong tree thinking that tweening is only between logical steps and doesn't take past states into account. Any tweened motion will take multiple frames across multiple steps after a serious framerate hitch. Have you got a working tweened game yet? Personally I hate implementing tweening, it's always nasty.

-D
  • 0

#26 GearGOD

GearGOD

    Deus Verus

  • GMC Member
  • 2153 posts

Posted 19 October 2006 - 01:39 PM

In return, I'd love to see a simple tweening implementation idea from you . You're already barking up the wrong tree thinking that tweening is only between logical steps and doesn't take past states into account. Any tweened motion will take multiple frames across multiple steps after a serious framerate hitch.

Had you taken the time to actually read through the thread, you would find links to examples and explanations to associated problems/solutions. I really question your understanding of tweening as it involves rendering between the 'previous' and 'current' logic states, thus any possible error is going to be of sub-step proportions regardless of fluctuation - invisible.

I'll be waiting to see an example editable showing the most basic implementation of your concept, I'm convinced that it will require major changes to an existing game.
  • 0
Engineers are not programmers. Stop thinking that you can save a few bucks by writing code yourself instead of hiring a programmer. Your code sucks.

#27 dislekcia

dislekcia

    GMC Member

  • New Member
  • 35 posts

Posted 19 October 2006 - 02:12 PM

Had you taken the time to actually read through the thread, you would find links to examples and explanations to associated problems/solutions. I really question your understanding of tweening as it involves rendering between the 'previous' and 'current' logic states, thus any possible error is going to be of sub-step proportions regardless of fluctuation - invisible.

I'll be waiting to see an example editable showing the most basic implementation of your concept, I'm convinced that it will require major changes to an existing game.

<{POST_SNAPBACK}>


I did indeed read the entire thread, back when I first replied. Which is why I said that many of the problems people were having was due to a strange definition of what the delta-time approach really is: People were using a quasi-delta + tweening method of thinking.

A lot of the tweening problems that have been raised in this thread (multiple logic states per frame, jitter due to framerate not being a multiple of logic rate, sampling jitter, etc) are all solvable with a mutli-logic-state approach to tweening.

Feel free to remain convinced that you need to make major changes to an existing game if you want to move it over to a delta-time model, you do :P. However, delta-time doesn't require seperate logic and frame rates, something which GM is not really built to handle. You need to make changes to an existing game for both tweening and delta-models, you're moving from a framerate dependant system to a (hopefully) framerate independant one... The former asks you to establish seperate logic and non-logic steps in GM, the latter asks you to have a central time-processing object. Both require changes to how objects are positioned.

They're both a lot of work. You'd have to have a reasonably serious project to even really consider framerate independance worthwhile, for me it was needed for MP, so I built the game around it from the word go.

-D
  • 0

#28 bendodge

bendodge

    File Host

  • GMC Member
  • 1237 posts

Posted 19 October 2006 - 03:00 PM

Is it really worth slowing the game down with so many calculations to try and keep the speed constant? It seems to me that Mark has chosen the best way, besides having the motion internally detached from framerate.
  • 0
The government can't save you.
Time does not negate impossibility.

#29 GearGOD

GearGOD

    Deus Verus

  • GMC Member
  • 2153 posts

Posted 19 October 2006 - 03:05 PM

Mark has actually chosen pretty much the worst way. Today all games are expected to run as fast as they possibly can while staying smooth. Anything below 60fps is just plain nasty.

dislekcia: If it's not too much bother, do try to get an example out; I'm very curious.
  • 0
Engineers are not programmers. Stop thinking that you can save a few bucks by writing code yourself instead of hiring a programmer. Your code sucks.

#30 FredFredrickson

FredFredrickson

    Artist

  • Global Moderators
  • 9225 posts
  • Version:GM:Studio

Posted 19 October 2006 - 03:42 PM

Considering Game Maker's roots as an animation program, it's understandable to me why GM uses the current system that it does, for timing purposes. It'd be great to see a change in the future though, since you are right, all modern games run as fast as possible in order to stay smooth.
  • 0

#31 dislekcia

dislekcia

    GMC Member

  • New Member
  • 35 posts

Posted 19 October 2006 - 04:59 PM

Is it really worth slowing the game down with so many calculations to try and keep the speed constant? It seems to me that Mark has chosen the best way, besides having the motion internally detached from framerate.

<{POST_SNAPBACK}>


Actually the delta-time stuff isn't slow at all. Monochrome spends way more time on the fake 3D "buildings" and the GM effects that I haven't replaced yet than on object repositioning...

-D
  • 0

#32 Pogo708

Pogo708

    GMC Member

  • New Member
  • 107 posts

Posted 20 October 2006 - 07:54 PM

I can't look at the other examples in the thread, and this seems to be what dislekcia is talking about, but in the multiplayer game I'm currently working on I've got a delta time system that works perfectly. Here's the basic code that it uses:

Initialization:
global.starttime = current_time;
global.timepassed = 0;
global.dt = 0;

Update (Called every Begin Step):
global.lastframe = global.timepassed;
global.timepassed = current_time - global.starttime;
global.dt = (global.timepassed - global.lastframe) / 30;

Then you simply multiply all position and acceleration calculations by global.dt, set the room speed to 9999, and it works perfectly. I haven't ran into any of the problems GearGOD is talking about yet either, but maybe I'm not far enough into development for those to arise.

Here's an example of how to use it, if anyone wants to:
hsp += 2 * global.dt;
vsp += 2 * global.dt;
x += hsp * global.dt;
y += vsp * global.dt;

Where hsp and vsp are your own variables to control the horizontal and vertical speeds. If it runs too fast or too slow, change the 30 in the update script around until you get a normal speed.
  • 0

#33 Potnop

Potnop

    GMC Member

  • GMC Member
  • 3103 posts

Posted 21 October 2006 - 09:34 AM

Well I guess I used something similar to delta time stuff in the game Super Crew in my Sig. I haven't uploaded an update in a while, although I am working on it still. It's up for Downlaod and stuff if anyone wants to see. I made it so the Player can go into super speed mode, but instead of making him move fast, I made it so the world around him is slowed down so its easier to control and stuff, and it's WAAAY cooler. I have a variable called global.bulletTime. When it's 1, the gmae goes at normal speed, and when it's .5 for example, the game world is going half the speed. The framerate is kept the same, only the motion is different, so it's all smooth. I don't think I'll actually use this system to speed up time or anything, cuz that would cause a whole lot of new glitches to be fixed, and I have no reason to do this. And what's cool is that if the player is using his power, he actually moves at the same speed as when the game is going at normal speed. He has a built in selfSpeed variable by which all motion is multiplied instead of global.bulletTime. So if the power is activated selfSpeed still equals 1. But if I decide to add a bullet time effect or soemthing, the player's selfSpeed equals global.bulletTime. I can also make machineguns used by the player fire at the slower real world rate. And as an added cool effect I have it so the sound frequency is slowed down. Anyway, I will upload a more recent version soon, cuz it has a lot more cool stuff, and the current link might even be broken by now, I hope not if soem of U guys wanna DL it. I'll fix it soon if it is. I did have to have to different speed varaibles though, I made one be SPEED, VSPEED, HSPEED, and stuff, and that's the actual speed. Then speed, vspeed, and hspeed just equal SPEED*global.bulletTime. It was pretty complicated to get it all to work, and even still there are some slight glitches every now and then. It's not exactly the Delta Timing described here because each frame is redrawn aand stuff exactly the way GM normally does it only I added the bullet time thing, and I didin't use it to make gameplay smoother at lower framrates.

Anyway, that was long, but I really wanna know how in a diferent game I'm making called Colonial Commando, how to do frameskipping and stuff. I guess the stuff being discussed here about tweening is pretty much what I wanna know how to do correctly and stuff. I just want this game to run smoothly on slower comps and stuff, and in Multiplayer I wanna have it so all positions are correct even though people's framerates might be different. I pretty much wanna do what Monochrome achived with that. Would controlling all player positions server side be one good idea to do that too? Like have the player push a key and that is sent to the server and it moves the payer and sendsits position to the clients. Then when the player lets go the Server stops changing the PLayer's position. Or soemthing liek that? When Halo lags on me sometimes, I notice that all the other players keep moving in the directions they were moving before the "lag" started. So I guess in Halo the Server just saves the direction the players are moving in and stuff at a particular point in time and updates it that way. That gets extremely annoying when it lags but yeah. I don't wanna go off topic too much tho.
  • 0
Vegeta! What does the scouter say about his powerlevel?!? It's ovER 9000!!!!!
I ownt read da script, script reads me.


Link To The Super Crew Topic / Link To Colonial Commando Topic
Platform Pathfinding Example Download it here!
Editable Early Version Level Editor(Nice @$$ stuff, check it out) Download it here!

#34 Alex

Alex

    3lite Member

  • New Member
  • 3098 posts

Posted 22 October 2006 - 04:14 AM

How about low frame rates? How do you deal with those? Do you slow the game down or attempt to use somthing like frameskip to keep the speeds the same?

A problem i've notice with frameskip methods is, if the frame rate drops too low the character could basically teleport through walls, bugging up the whole game unless you implemented somthing to calculate collisions based on the frame rate which could get ugly, and player movement isn't the only thing to watch out for.

Edited by /\lex, 22 October 2006 - 09:14 AM.

  • 0

#35 dislekcia

dislekcia

    GMC Member

  • New Member
  • 35 posts

Posted 22 October 2006 - 02:02 PM

How about low frame rates? How do you deal with those? Do you slow the game down or attempt to use somthing like frameskip to keep the speeds the same?

A problem i've notice with frameskip methods is, if the frame rate drops too low the character could basically teleport through walls, bugging up the whole game unless you implemented somthing to calculate collisions based on the frame rate which could get ugly, and player movement isn't the only thing to watch out for.

<{POST_SNAPBACK}>


Monochrome deals with that case on the server by detecting if a delta goes above a certain maximum value and either running an extra collision cycle on all moving objects if it's a once-off spike, or clamping the delta and giving the system time to catch up if it's a longer slowdown.

Players can still end up going through walls in certain circumstances if they get dropped from the server, but only if they don't get an original position update to re-extrapolate from. And usually in that case the game is unsalvageable anyway, so it quits before they are placed in a non-colliding position on the other side of a wall.

-D
  • 0

#36 Potnop

Potnop

    GMC Member

  • GMC Member
  • 3103 posts

Posted 24 February 2007 - 08:45 PM

OK I played monochrome. It's kinda fun... Maybe make more maps? It ran nicely though. Is the top number the framerate, cuz it in the 200's mostly. Not bad...

And I'm trying to put in something into my game like this. Who so far has a really good way of doing this.

I remember playing Hover Tank and I think that had tweening or somehting... THe game ran very smoothly even on a slow computer, while it looked like the logic itself was extremely slow. It was nice and playable, but on the slow computer I had to wait for ever to get my next objective and stuff, while on a fast computer it all worked very nicely... So maybe if he did the messages and stuff based more on frames passed it would be better...

I think it would be pointless for me to design this my self though. If someone else has a very nicely working way then I want to see it. I want to concentrate on other things in my game and not deal with th headaches of starting from scratch on this.
  • 0
Vegeta! What does the scouter say about his powerlevel?!? It's ovER 9000!!!!!
I ownt read da script, script reads me.


Link To The Super Crew Topic / Link To Colonial Commando Topic
Platform Pathfinding Example Download it here!
Editable Early Version Level Editor(Nice @$$ stuff, check it out) Download it here!

#37 Potnop

Potnop

    GMC Member

  • GMC Member
  • 3103 posts

Posted 11 May 2007 - 01:57 AM

OK this topic hasn't been replied to in very long and I'm trying to make my own delta time engine. I need my game to stay in sync with other games when playing online.

I started making my platform engine and it worked kinda alright. Then I realized that it would need to calculate all in between positions, not only what its next position needs to be depending on the FPS. Without calculating in between positions, collisions wouldn't be detected correctly with bullets and items and stuff, most importantly bullets. Walls are easy to do no matter what because I use the same thing I used for making bullets not go through walls at high speeds, and walls are always stationary.

But it got very complicated when I realized I need to have moving objects detect all their positions and stuff.

I did some reading on gamedev.net and I didn't find stuff exactly on delta time. But they talked about integration and stuff. If you took calculus or physics AP or whatever, you know that integrating a velocity function gives the position of an object at a point in time. This could be very useful for detecting positions and stuff at a point in time. The way I was trying to do it is by moving the object little by little in a for loop which got really complicated. But by integrating a velocity function it would be easier to detect positions and collisions. The article talked about how to code the integration.

I only read about this integration thing just now before posting this, so I haven't tried anything yet. This should be open to discussion some more.

I wonder if I should just make a new experts topic on this or continue the discussion in a topic that says that delta time is a worse method than tweening, which I don't think so.

Edited by Potnop, 11 May 2007 - 01:58 AM.

  • 0
Vegeta! What does the scouter say about his powerlevel?!? It's ovER 9000!!!!!
I ownt read da script, script reads me.


Link To The Super Crew Topic / Link To Colonial Commando Topic
Platform Pathfinding Example Download it here!
Editable Early Version Level Editor(Nice @$$ stuff, check it out) Download it here!

#38 EricDB

EricDB

    Eric Burgess

  • GMC Elder
  • 920 posts
  • Version:GM8

Posted 11 May 2007 - 04:20 PM

I see two major downsides to both of these approaches, and probably to any other scheme for decoupling display from logic:

1. You have to run GML code for each and every object instance during each and every display frame. For a game with many instances, it can make quite a difference to move code out of a per-step event, either by using GM's built-in functionality, or putting it into a slower Alarm event. I would think that always having that much GML running every frame would put a serious clamp on the kinds of speed or smoothness gains you could realize. Your game would probably need very few instances and very complex logic to benefit much.

2. Related to #1, you can no longer use the particle system as a lightweight substitute for object instances, since there are no hooks to insert your tweening or delta-time code. A particle system is going to update in discrete, equal steps. It should be fairly straightforward to add a real-valued delta parameter for the part_system_update function, but it's not there now, and who knows if or when Mark will consider it a worthwhile enhancement.

I wonder if some kind of prediction in the display code could achieve a tweening-like effect without requiring code for every display frame. You can set up velocity and acceleration vectors using built-in GM functions for speed and gravity. Setting them appropriately after every logic step might allow GM to internally (thus quickly) handle the tweening. Of course, there's no angular speed variable, so anything that needs to spin won't be able to be handled that way. It's probably not practical, but it's an interesting thought.
  • 0

#39 Yourself

Yourself

    The Ultimate Pronoun

  • GMC Elder
  • 7352 posts
  • Version:Unknown

Posted 11 May 2007 - 04:49 PM

A particle system is going to update in discrete, equal steps. It should be fairly straightforward to add a real-valued delta parameter for the part_system_update function, but it's not there now, and who knows if or when Mark will consider it a worthwhile enhancement.


A possible work around is to simply update it as many times as possible according to how much time has passed since it was last updated. You could design the particle system to be updated maybe 60 times/second and update it multiple times at once if you need to. It'll be slower than just having some delta time functionality built in, but it's probably the best we can do for now.
  • 0

#40 Potnop

Potnop

    GMC Member

  • GMC Member
  • 3103 posts

Posted 12 May 2007 - 03:24 AM

Or I could just not use the particle system. But it really does help nicely for simple objects...

Anyway I'm gonna see about that integration thing. I'm gonna make a simple engine that detects collisions with moving objects and stuff and see if it detects those collisions.
  • 0
Vegeta! What does the scouter say about his powerlevel?!? It's ovER 9000!!!!!
I ownt read da script, script reads me.


Link To The Super Crew Topic / Link To Colonial Commando Topic
Platform Pathfinding Example Download it here!
Editable Early Version Level Editor(Nice @$$ stuff, check it out) Download it here!

#41 pinguinpanic

pinguinpanic

    GMC Member

  • New Member
  • 790 posts

Posted 17 May 2007 - 12:31 PM

Delta time all the way, I don't see what's that hard about it and it only requires a small bit of scripts and you can't use some of the build in things of gamemaker (patricles/some variables), which I prefer not to use anyway, an example of vertical movement using deltatime:
deltatime=(current_time-prevtime)/33.3
prevtime=current_time
// Calculated the deltatime, you can set it global and use it at other objects.

if place_free(x,y+verspeed*deltatime) //Now simply multiply by deltatime!
{
    y+=verspeed*deltatime
}
else
{
    var i;
    i=0
    while(!place_free(x,y+i))
    {
        if verspeed>0
        {
            i-=1
        }
        else
        {
            i+=1
        }
    }
    y+=i
    verspeed=0
}
Creates really smooth movement in high fps but still good enough at low fps.

In comparison with deltatime tweening is very crappy as in deltatime collision checking and more are way more precise.
  • 0

#42 Gamer3D

Gamer3D

    Human* me = this;

  • GMC Member
  • 1819 posts
  • Version:GM:Studio

Posted 17 May 2007 - 09:40 PM

Delta time's disadvantage is that each movement will be bigger than with tweening. This may make, for example, a character jump through a wall at low FPS.
  • 0
Fast Priority Queues - Game Maker's priority queues are O(n). Mine do everything that Game Maker's do, but in O(log n) time.
Dual-Quaternion Skinning - Modifying vertexes in GM is slow. This simple vertex shader does the job both quickly and well.

#43 dark_master4

dark_master4

    GMC Member

  • GMC Member
  • 1232 posts
  • Version:GM:Studio

Posted 19 May 2007 - 01:21 AM

So if I get it right, what people here want is to have a clean FPS for user input and anything that the CPU/GPU can handle for the graphics... I wonder why nobody came in with frame skipping.

It's 100% simple to implement, won't damage user input, gives out the same visual effect as delta timing, gives time to the CPU for more code to run.

While reading, I was thinking that Tweening was the best solution (And is the one you see in Diablo II (I think)) but has to be limited so that the game doesn't crash because of infinite loops.

On the other side, Delta Time requires a different approach on collision checking since you may come to move at really high speeds. Again, it has already been said, you need a limit.

Finally, coming back with frame skipping... It can acheive the work of both methods, and is simpler to implement.

Edit: Again, even with frame skipping, you need to impose a limit. You have to accept one way or another that a really slow computer will run at slower framerate. That is, if the reason that the computer is slow is the weak CPU. You could even set the minimum FPS wanted.

Edited by dark_master4, 19 May 2007 - 01:23 AM.

  • 0

My YoYoGames Marketplace (Has scripts, shaders and poker chips)


GM:Studio
Desktop Intel i5-4440 3.1ghz, 8gb RAM, NVIDIA GeForce GTX 770 2gb
Laptop AMD Athlon x64 2.1ghz, 4gb RAM, 256mb shared VRAM


#44 Potnop

Potnop

    GMC Member

  • GMC Member
  • 3103 posts

Posted 19 May 2007 - 07:16 AM

Frame Skipping wouldn't be too perfect since it would still slow down because of logic stuff sometimes. Delta Time in a way skips frames already but calculates stuff that needed to happen in between.

And making things not go through walls at low FPS's is pretty easy if they are stationary. It's only hard to detect collisions with moving objects like a player and a bullet. For walls do a type of collision_line check that sees if from current position to last position if there's a collision with a solid.

How would you guys detect collisions for moving objects? I was thinking and I came up with a very bad way that moves an object little by little in one step. It would be a for loop and move the thing over by the speed its going at. Like a speed of 4 at 1 FPS would move it over by 4 30/4 or 60/4 times. For the fractional leftover it would just move it over by the remaining amount.

And at every part of the movement it checks if there was a collision with another thing. And you'd have to do that for every moving object...

Edited by Potnop, 19 May 2007 - 07:20 AM.

  • 0
Vegeta! What does the scouter say about his powerlevel?!? It's ovER 9000!!!!!
I ownt read da script, script reads me.


Link To The Super Crew Topic / Link To Colonial Commando Topic
Platform Pathfinding Example Download it here!
Editable Early Version Level Editor(Nice @$$ stuff, check it out) Download it here!

#45 dark_master4

dark_master4

    GMC Member

  • GMC Member
  • 1232 posts
  • Version:GM:Studio

Posted 19 May 2007 - 06:31 PM

To detect collisions between 2 really fast moving objects, you have to give up on precision to get more speed of execution. If you begin calculating every possible position of all objects in room, you'll get a huge lag at about 5 bullets in the level at the same time. I found a way that is better than this, but didn't take the time to implement it. It's simple to describe, but a little hard to implement if you don't have a collision_line system already in place, but a bit easy if you already have it.

It is: check for collision between collision_line you made. Visual:
Posted Image
This way, you can't be extremely accurate but at least it will run fast. You could add complexity to check where in the line they collide, but that would again eat up processing time.

*Frame skipping all the way*
  • 0

My YoYoGames Marketplace (Has scripts, shaders and poker chips)


GM:Studio
Desktop Intel i5-4440 3.1ghz, 8gb RAM, NVIDIA GeForce GTX 770 2gb
Laptop AMD Athlon x64 2.1ghz, 4gb RAM, 256mb shared VRAM


#46 Potnop

Potnop

    GMC Member

  • GMC Member
  • 3103 posts

Posted 20 May 2007 - 05:56 AM

How do you do frame skipping then? What I really want is a good way to keep games online in sync.
  • 0
Vegeta! What does the scouter say about his powerlevel?!? It's ovER 9000!!!!!
I ownt read da script, script reads me.


Link To The Super Crew Topic / Link To Colonial Commando Topic
Platform Pathfinding Example Download it here!
Editable Early Version Level Editor(Nice @$$ stuff, check it out) Download it here!

#47 dark_master4

dark_master4

    GMC Member

  • GMC Member
  • 1232 posts
  • Version:GM:Studio

Posted 20 May 2007 - 03:13 PM

Well, the base of frameskipping is rather easy:
set_automatic_draw(fps>room_speed*0.75)
There, you get a simple frame skipping. But there are other things to take into account... Like if the computer can't get it to run at desired speed at all, even while not drawing... Then it would require a little bit more code. I'd say that:

Creation code:
a=0
for (a=0;a<room_speed;a+=1)
  {framerate_archive[a]=room_speed}
framerate_total=sqr(room_speed)
framerate_mean=room_speed
i=0
Then, step event:
framerate_total-=framerate_archive[i]
framerate_archive[i]=fps
framerate_total+=framerate_archive[i]
framerate_mean=framerate_total/room_speed
i+=1
while i>=room_speed {i-=room_speed}
set_automatic_draw(fps>framerate_mean*0.75)
So now that should do it for a frame skipper. It now keeps track of last (room_speed) frames and use that as a marker to know if frames need to be skipped or not. I'm not sure of the second one's practical use though, I didn't test it.

There is one last option for frame skipping: User set frame skipping. That is where user says "Skip 1 frame, then draw the other, then skip 1 frame, then draw." So that would be frameskipping of 1. I guess you all know how to implement that one since it's expert forum after all! :wacko:

Edit:
As for keeping online games in sync, use something similar to TOD servers (Time Of Day). Host writes number of frames passed since start of the game, clients read this and use any possible mean to get to that frame number (even if not drawing them) the quickest possible way.

Frame skipping is one, your version of delta timing is one and tweening is one.

Edited by dark_master4, 20 May 2007 - 05:17 PM.

  • 0

My YoYoGames Marketplace (Has scripts, shaders and poker chips)


GM:Studio
Desktop Intel i5-4440 3.1ghz, 8gb RAM, NVIDIA GeForce GTX 770 2gb
Laptop AMD Athlon x64 2.1ghz, 4gb RAM, 256mb shared VRAM


#48 Gamer3D

Gamer3D

    Human* me = this;

  • GMC Member
  • 1819 posts
  • Version:GM:Studio

Posted 21 May 2007 - 04:28 AM

As I used delta time, I needed a way to prevent movement through walls. Because my engine does not use GM collisions (I coded the whole thing), I decided that I would have it divide the movement into many small steps (each step is small enough to avoid errors)
  • 0
Fast Priority Queues - Game Maker's priority queues are O(n). Mine do everything that Game Maker's do, but in O(log n) time.
Dual-Quaternion Skinning - Modifying vertexes in GM is slow. This simple vertex shader does the job both quickly and well.

#49 Potnop

Potnop

    GMC Member

  • GMC Member
  • 3103 posts

Posted 21 May 2007 - 07:03 AM

Yea that's what I did too. How did you do collisisons between moving objects suhc as a bullet and a person.
  • 0
Vegeta! What does the scouter say about his powerlevel?!? It's ovER 9000!!!!!
I ownt read da script, script reads me.


Link To The Super Crew Topic / Link To Colonial Commando Topic
Platform Pathfinding Example Download it here!
Editable Early Version Level Editor(Nice @$$ stuff, check it out) Download it here!

#50 Gamer3D

Gamer3D

    Human* me = this;

  • GMC Member
  • 1819 posts
  • Version:GM:Studio

Posted 21 May 2007 - 04:05 PM

The time for a collision between two circles of radii r1 and r2, which have start positions of x1 and u1, and end positions of x2 and u2, respectively, is given by the formula:

t = (-2u1u1 + 2u2u1 + 2x2u1 - 2v1v1 + 2x1x1 + 2y1y1 + 2v1v2 - 2u2x1 - 2x1x2 - 2v2y1 + 2v1y2 - 2y1y2 - sqrt(sqr(2u1u1 - 2u2u1 - 2x2u1 + 2v1v1 - 2x1x1 - 2y1y1 - 2v1v2 + 2u2x1 + 2x1x2 + 2v2y1 - 2v1y2 + 2y1y2) - 4 * (-r1r1 - 2r2r1 - r2r2 + u1u1 + v1v1 + x1x1 + y1y1 - 2u1x1 - 2v1y1) * (u1u1 - 2u2u1 + 2x1u1 - 2x2u1 + u2u2 + v1v1 + v2v2 + x1x1 + x2x2 + y1y1 + y2y2 - 2v1v2 - 2u2x1 + 2u2x2 - 2x1x2 + 2v1y1 - 2v2y1 - 2v1y2 + 2v2y2 - 2y1y2))) / (2 * (u1u1 - 2u2u1 + 2x1u1 - 2x2u1 + u2u2 + v1v1 + v2v2 + x1x1 + x2x2 + y1y1 + y2y2 - 2v1v2 - 2u2x1 + 2u2x2 - 2x1x2 + 2v1y1 - 2v2y1 - 2v1y2 + 2v2y2 - 2y1y2))
With an alternate case of:
t = (-2u1u1 + 2u2u1 + 2x2u1 - 2v1v1 + 2x1x1 + 2y1y1 + 2v1v2 - 2u2x1 - 2x1x2 - 2v2y1 + 2v1y2 - 2y1y2 + sqrt(sqr(2u1u1 - 2u2u1 - 2x2u1 + 2v1v1 - 2x1x1 - 2y1y1 - 2v1v2 + 2u2x1 + 2x1x2 + 2v2y1 - 2v1y2 + 2y1y2) - 4 * (-r1r1 - 2r2r1 - r2r2 + u1u1 + v1v1 + x1x1 + y1y1 - 2u1x1 - 2v1y1) * (u1u1 - 2u2u1 + 2x1u1 - 2x2u1 + u2u2 + v1v1 + v2v2 + x1x1 + x2x2 + y1y1 + y2y2 - 2v1v2 - 2u2x1 + 2u2x2 - 2x1x2 + 2v1y1 - 2v2y1 - 2v1y2 + 2v2y2 - 2y1y2))) / (2 * (u1u1 - 2u2u1 + 2x1u1 - 2x2u1 + u2u2 + v1v1 + v2v2 + x1x1 + x2x2 + y1y1 + y2y2 - 2v1v2 - 2u2x1 + 2u2x2 - 2x1x2 + 2v1y1 - 2v2y1 - 2v1y2 + 2v2y2 - 2y1y2))

To get the position of the collision, use the smallest time. The x position is given by x + t * (x2 - x1). The y position is given by y + t * (y2 - y1).

Edited by Gamer3D, 21 May 2007 - 04:06 PM.

  • 0
Fast Priority Queues - Game Maker's priority queues are O(n). Mine do everything that Game Maker's do, but in O(log n) time.
Dual-Quaternion Skinning - Modifying vertexes in GM is slow. This simple vertex shader does the job both quickly and well.