Same speed on all machines and Tweening

BlitzMax Forums/BlitzMax Beginners Area/Same speed on all machines and Tweening

christian223(Posted 2008) [#1]
This is the first time i do something like this, i am in the middle of the development of my game and just now i am trying to make sure that the game runs fine on all machines, i have been trying to learn about this subject and it seems overwhelming, so, i found this code about fixed step logic and tweening on the code archives, if i apply this, my game will run ok on all other machines?, will i encounter problems with it as i go further in the development?, would i need to also do delta timing or something like it?, do i need to consider something else?, thanks a lot for your help.

This is the link to the code i found:
http://www.blitzmax.com/codearcs/codearcs.php?code=2039


Gabriel(Posted 2008) [#2]
Yes, that's all you need.


QuickSilva(Posted 2008) [#3]
Just a question. When using fixed rate logic what benefits does it have over delta timing? Are you still required to add to all variables as in delta timing? i.e. x+1*delta or does fixed rate logic bypass this?

I suppose what I`m saying is is it worth using over delta timing?

Jason.


JazzieB(Posted 2008) [#4]
There is no need for delta to be applied to a game controlled by fixed rate logic. By it's very nature you know that the game will run, at say, 200 updates per second, so you update all your variables with an appropriate amount each update.

Of course, if you're trying to add this logic to a game that you've already started, you will have to adjust your update values for each variable. As with any timing method, it's better to start with your preferred frame limited technique in place.

Also, that 200 updates per second may seem a little high, but it's a typical speed for this type of logic for smooth game-play. I use either 200 or 250 updates per second in my own projects. Remember you're only updating logic during an update cycle (no drawing), so most games will be able to cope quite easily.


Shagwana(Posted 2008) [#5]
Using a fixed rate logic removes the need to do +(delta*var) in the logic loop.

How ever, using a fixed rate logic, means you need to figure out how to tween between the last logic frame and the new logic frame to make the display.


christian223(Posted 2008) [#6]
Thanks a lot. Another question, what is the best or standard way to separate drawing from logic?, right now i have each object draw when it updates its logic, how should i separate them?, thanks.


Trader3564(Posted 2008) [#7]
Hey, sorry to pop in but im probably as new as christian223 when it comes to gameloops.
i used this code also http://www.blitzmax.com/codearcs/codearcs.php?code=2039

having put all my drawing stuff in the render group, and all the login in the update group. i wonder, what is the tweening for?? i know what it does, but because i have fixed my UPDATE_FREQUENCY on 50 it doesnt really use the tweening, only when i go very low, to lets say <10 it uses tweening, but whats the point of that???? i fix it on 50?! so why did this guy build the tweening in?

To me its like:
UPDATE_FREQUENCY =50
if UPDATE_FREQUENCY  <10 then
'do lots of complicated stuff, which i could as well just rip out of it
end if



JazzieB(Posted 2008) [#8]
How ever, using a fixed rate logic, means you need to figure out how to tween between the last logic frame and the new logic frame to make the display.

It's not necessary at all. Just draw everything at whatever position they are currently at. If you're using a high rate (e.g. 200 updates per second or more), using tweening for the display is going to make little visual difference to the player. Tweening and/or delta only come into it when the updates per second are less than the refresh rate of the display.

However, some people like to combine the two methods to give the smoothest possible experience, but I think it's a lot of effort for little gain. Only the programmer is going to notice any difference becaise they are looking for it. The casual gamer will be too involved in the game to notice any difference - as long as the game looks and feels smooth.

Thanks a lot. Another question, what is the best or standard way to separate drawing from logic?, right now i have each object draw when it updates its logic, how should i separate them?, thanks.

Each of your objects needs to have separate Update and Draw methods. In terms of the coding, the following is a little program I wrote when I first started experimenting with this. It's probably the simplest way of doing things, but will serve as a good starting point.


Hope it helps.


Czar Flavius(Posted 2008) [#9]
What if the computer is not fast enough to run at frequency 50? At a guess


Trader3564(Posted 2008) [#10]
indeed. i was wonderng that as well. see you would then force it to run at 200, it can barely finish that, leaving only room for 1 visual frame update, putting the whole tweening aside.


JazzieB(Posted 2008) [#11]
What if the computer is not fast enough to run at frequency 50?

If a computer can't update logic at 50 times a second, then it's nothing more than a glorified calculator. Basically, it would have to be a seriously slow computer if it can't. The logic cycle should take anywhere from less than a millisecond to a few milliseconds, depending on the amount of work being done. It's the actual rendering that takes time.

My current project's logic cycle takes anywhere between 0 and 1 millisecond, with the rendering on my system taking between 2-3 millisecs. I have the logic updating at 200 times per second and the game runs just fine on all of the systems in my sig, plus a slower, 6 year old PC that I also test stuff out on.


Trader3564(Posted 2008) [#12]
but still, the example given here http://www.blitzmax.com/codearcs/codearcs.php?code=2039, there tweening will only work if your updates per second are low. It wont have any effect when you just run 50 or more updates per second. or wait... maybe im missing out. Because it is TIMEBASED, that meens you wont go any faster or slower even tough the UPS are more or less... am i right? included with some interpolation just for low UPS. right?


JazzieB(Posted 2008) [#13]
Tweening does smooth things out if your logic is running at a relatively low speed. However, what I would ask is why would you want to update your game at 10 updates per second in the first place? Even 8 bit computers managed more than that!

Basically, the higher the updates per second you use, the less need there is for additional tweening. If your game logic has so much work to do that 200 times per second is not feasible, then introduce some tweening as well to help matters along visually.

Having said that, tweening is a little more advanced that straight forward fixed rate logic, so as you're only just getting to grips with this timing business, I would recommend you start with the simplest version first, and then try to include tweening into your projects at a later date - if you find a need to actually use it.


MGE(Posted 2008) [#14]
I think tweening is way over rated for 2d games. Fixed rate logic that renders as often as possible or time based delta logic makes more sense for 2d games. Also, ask yourselves why you would ever want your game logic to update faster than the monitor's refresh rate. (Updating logic 200 or more times per second for instance.)

Like it or not, on slower under powered computers you're going to get a performance hit anyway you look at it. It makes more sense to recognize that in code and simply lock your frame to 15, 20 or 30fps on those machines.


JazzieB(Posted 2008) [#15]
There is a reason why I use 200 or more updates per second. The nearer you get to the actual refresh rate of the monitor, the jerkier it looks! I've experimented with this and concluded that 200 or even 250 updates per second yields the best results. I'm not the only person around here that has reached this conclusion in past discussions.

The higher your game logic the more evenly spread the number of logic updates per screen updates you get, so the smoother things look over a number of different monitor refresh rates. And there's the problem for modern PC games ... the refresh rate of the monitor.

If you were to force a user to use a refresh rate of 60hz on their display so that your game would work with a logic update cycle of 60 updates per second, you would see jerks as some frames would see 1 update and others would then see 2 or 0! With a higher logic update speed you get more updates per frame, so although you still get a different number of them, the overall visual experience is a lot smoother.

You need to have a high rate to allow for the different display frequencies you can get. CRT monitors can run anywhere between 60 to 120hz (maybe higher). We nor your customers all have one of these new-fangled TFTs that only work at 60 or 75hz.

"Slower under powered" computers are not included in my target market, nor are they going to run anything created in BlitzMax.


MGE(Posted 2008) [#16]
Popcap game design framework locks their logic at 100 times a second for instance. I understand your thinking, but in reality 99% of your target market will probably have a monitor refresh of 120hz or less.


christian223(Posted 2008) [#17]
Thanks JazzieB, that helps. Now, another question, how should i go about when i have lots of different types than draw different sprites?, how can i "link" each sprite with its corresponding object?, again, thanks a lot for your help.


Trader3564(Posted 2008) [#18]
i have a 60hz laptop here.


JazzieB(Posted 2008) [#19]
The refresh rate of the monitor is irrelevant here. I only brought it up as an example of why it's better to run your game logic at a high rate, which is it gives you much smoother game-play regardless of what a user has their display set at.

For the type of games that PopCap produces, 100 updates a second is plenty. I use 200/250 updates per second as my games tend to be more action than puzzle, so benefit from a higher logic rate.

@Christian223, for each of your game objects you need an Update() Function and a Draw() Function. You main game loop will then have an Update() Function that calls each of the Update() Functions of your game objects, and a similar Render() Function that calls all the Draw() Functions of your objects. So you would have something like this...

Type TGameObject
  Function Update()
    ' update logic for ALL instance of this game object
  EndFunction

  Function Draw()
    ' draw ALL instance of this game object
  EndFunction
EndType

' main program

Function Update()
  TGameObject.Update
EndFunction

Function Render()
  Cls
  TGameObject.Draw
  Flip
EndFunction

The above obviously does not include the main loop, as I've already provided an example of that. Hope it helps.


ImaginaryHuman(Posted 2008) [#20]
I like the idea of fixed logic and it's what I'm doing also although I haven't decided on a frequency yet. 120 seems reasonable, although even more reasonable would be a flexible fixed-rate whereby you make sure your logic runs at an even multiple of the display Hz rate. If my display is 60Hz I'd go with a 120, 180 or 240hz logic. But if my display is 85hz I'd go with a 130 or 215hz logic. If your logic evenly divides into the display hz then it is likely to be much more accurate each frame.

But what that does then imply is that you can't design for a single fixed rate. Say if you fix your rate at 120hz then you know exactly what numbers to use to make objects move a given distance in a given time, for example, because it's like working with a reliable constant-speed machine. But if you flex your logic rate depending on the display hz you don't get that benefit. So what I'm doing is having a design-time hz rate that I choose, say 120hz, and then the logic rate is based on a multiple of the display hz, and then I tween between the design rate and the logic rate to determine where the object should be in a given logic frame. This is my own invention, I think ;-)

I think a higher hz rate is okay for most 2d games unless you are doing lots of physics or computation each frame in which case your target spec has to be higher. I think you can get away with a lower logic hz if you use tweening but that also makes your code more complex - but at least then there is a chance it will run on a lower spec. So what I'm doing is tweening between a design-time fixed hz rate to get to the dynamic-fixed logic rate, and then tweening from the dynamic-fixed logic rate to the display hz. I also predict what the logic time will be in the future when a frame is finished rendering and will be actually flipped, so that when it does flip I am showing more exact current state.

I'm surprised we haven't seen Jake (GreyAlien) posting in this thread yet ;-)


christian223(Posted 2008) [#21]
Of course! thanks!, i was allready thinking on how to get completely new types that stored each a png image :P, it was a really simple solution in the end, thanks a lot.


JazzieB(Posted 2008) [#22]
I'm surprised we haven't seen Jake (GreyAlien) posting in this thread yet ;-)

Me too. Jake actually uses an advanced system in his framework that is mostly fixed rate logic, but does also include some tweening and jitter correction (for when those pesky background processes get in the way). I personally don't feel a need for all the tweening, but Jake is something of a perfectionist (only kidding ;o) ).

I don't actually own Jake's framework, but I'm sure he's designed his framework to be as flexible as possible for every game type. My games, so far, have had no real need for anything more than simple fixed rate logic. I always adjust the timing scheme depending on what's best for the project in mind.


MGE(Posted 2008) [#23]
" I use 200/250 updates per second as my games tend to be more action than puzzle, so benefit from a higher logic rate."

I did some testing with using a very high logic rate in my own code. Some of my demos update 100's or 1000's of objects per loop.

Good points: Yes, it pretty much wiped out the need for any jitter correction code!! Nice!! The animation was smooth.

Bad Points: Bumped up cpu requirements alot. Pretty much took my older systems out of the target spec loop.

If targeting newer systems, I would probably go with the high freq game logic. But if you want to target a wide variety of old/new machines, I would use a much lower logic rate or switch to using delta time.


Grey Alien(Posted 2008) [#24]
Was away all weekend doing Aikido.

Jake is something of a perfectionist
Actually this *is* true ;-) But I'm trying to temper it somewhat in order to increase my output.

Yeah I use 200Hz logic which is separate from the drawing code. I don't use any tweening on the drawing code, I simply draw the objects at the coords left after the logic finishes. Yes my framework uses fixed rate logic but then also has a delta component for the fractions of logic frames - so if the logic decide it needs to do 3.2 iterations, it does 3 with Delta at 1, and one with Delta at 0.2. This is a bit like doing the tweening on the Logic instead of the drawing. This method DID produce smoother results than just plain fixed rate logic. The jitter correction I added about a year latter also helped for ultimate smoothness on some machines (plenty are never smooth due to too many background tasks). BUT I guess if you have some physics sim that 100% relies on a Delta of 1 each time, the method wouldn't be suitable. I have found it fine for all my games so far though (works for action and casual games).

Most of the time 200Hz is fine and most PCs can handle it, but it any really complex logic occurs (e.g. lots of particles to be moved), then a few older PCs may struggle. Therefore I was considering dropping to 120Hz for my next game because it's twice 60Hz which most TFT screens are set at (or used to be, but now I understand some are higher). The only thing is if the 120Hz logic was slightly out of phase with the 60Hz display it may look odd (weird jerks or something), so perhaps it IS better to go higher and to a number that cannot divide equally into the display Hz. Also 200Hz is easy to work stuff out in (e.g. 1/5th of a second) whereas 120Hz is not so easy...


ImaginaryHuman(Posted 2008) [#25]
MGE, wouldn't you have a perfect sync of logic rate and monitor rate if you just made the fixed rate logic run at an exact multiple of the framerate, rather than just trying to run it at a high resolution in the hope that it will be `close` to being synchronized?

Jake, if you are adding a delta to your fixed rate so that it's not always the same step each time, that means physics engines will not work with it? Also how do you figure that if the logic runs, say, twice ever graphics frame, locked into the same loop as the rendering to force 2 updates per graphics update, how would that conceivable ever appear to have any lag? Surely it would be perfectly synchronized.


Grey Alien(Posted 2008) [#26]
IH: Yeah I said it *may* not work great with physics engines, but it really depends on what you are doing with the engine and how it is written. I plugged SSwifts into my framework and it was fine for example. As for the other issue, I was talking out my ass it seems - I was thinking of an issue a while back where Flip -1 was supposed to be in sync with vsync in windowed mode (and it was) but it was out of phase and so you had this big fixed horizontal tear moving on the screen.


MGE(Posted 2008) [#27]
"MGE, wouldn't you have a perfect sync of logic rate and monitor rate if you just made the fixed rate logic run at an exact multiple of the framerate, rather than just trying to run it at a high resolution in the hope that it will be `close` to being synchronized?"

Tough for me to answer that one, I'm still new at the idea of using a high logic rate. Seems like there are 3 variables of interest:

logic rate, frame rate, monitor refresh rate.

And then there's pitfalls to watch out for if vsync is locked on/off from the end user side. Logic rate should be something considered during design time not changed at run time, or am I wrong there?


Gabriel(Posted 2008) [#28]
There's no "*may*" about it, and it doesn't depend on what you're doing with it, or how it's written. If you try to do integration ( and if you know of a physics engine which doesn't, then please mention it, because I don't know any ) with a variable timestep, you will get unpredictable, unstable results which will lead to serious physics errors.

Doing almost fixed logic is like having an almost-vegetarian ham sandwich because the bread, butter, mayo and lettuce are all vegetarian. The whole purpose of fixed-rate logic is to ensure that your logic is *always* run with a fixed timestep, in order that the physics can be reliable and stable. There's no near, you either do or don't.

Take that fixed step away and what you have is delta timing. Delta timing which is decoupled from the rendering for a higher update frequency, but still delta timing. Delta timing is, of course, smoother than fixed rate logic *without* tweening, because fixed rate logic is not supposed to be smooth. Fixed rate logic is not about smooth visual updates, it's about consistent behaviour across machines. That's why it's almost always combined with tweening.


Czar Flavius(Posted 2008) [#29]
Is there a way to make realtime games that just work at a normal speed without having to do anything complicated?


Gabriel(Posted 2008) [#30]
Well your question gives me the impression that you think tweening and deltatiming are complicated, in which case, no, probably not. I don't personally think either one is complicated, although precisely which one is more complicated will depend on your game choice as well as personal taste. In general, delta timing requires less work up-front, and then you have to remember to multiply everything, whereas tweening requires no changes to game code, but does require more work up-front.

The only simpler option is to create a timer and just update and render when that timer ticks, but it doesn't solve the problem of machines which can't maintain the desired framerate, as the other solutions are intended to do. In other words, it only slows fast machines down, it doesn't stop slow machines being slow.


ImaginaryHuman(Posted 2008) [#31]
Grey Alien, actually I found that a Flip -1 still does that to me on my machine... it will give you a 60Hz refresh rate, for example, but it won't be sync'd to the vertical blank perfectly so you can get tearing. Flip 1 works perfectly though. It seems as though Flip -1 does some kind of artificial timer rather than wired into the display refresh, meaning it runs a the screen Hz rate but can be up to, for example 16 millseconds offset from when the screen actually flips. Flip 1 syncs to the vblank which is better.

MGE: "And then there's pitfalls to watch out for if vsync is locked on/off from the end user side. Logic rate should be something considered during design time not changed at run time, or am I wrong there?"

Well, I think if you are trying to choose one logic rate for all displays and framerates you are going to experience some out-of-sync logic updates, unless you do some tweening like GA does. What I'm suggesting is to make your logic Hz an exact multiple of the display Hz, e.g. 60hz display does logic at 60 or 120 or 180hz. Then you make darn sure that you do an exact integer number of logic updates per frame, ie 1 2 or 3. Of course, still decoupled from the framerate, but synchronized with the `Flip 1`. Then you ideally don't need to tween.

The only drawback then is that at *runtime* you have to adjust your logic hz rate, which means if you want to take advantage of designing your physics/logic based on a known timerate, that goes out the window. This is why I `invented` the idea of having a `design rate`, some fictional hz rate that I design for, and then this is tweened to the exact position it would be at the logic rate. Then the logic can run at an exact multiple of the display hz which I am guessing is ideal, compared to trying to make your logic hz so incredibly high that there's a reduced gap between the display hz and the logic moire. Also then you don't need a really high logic rate (although it helps with some collision detection).

Gabriel I agree although I would say it's possible to get your fixed rate to be smoothly in-sync with the display hz.

Czar, you can get really simple and just do a Flip -1 or Flip 1 and open a screen with 60 as the Hz rate and then just assume it will always run at full speed but it won't necessarily be able to all the time and when it doesn't your game will go into slow-motion. The idea of timing systems is to keep objects moving and animating at the same speed all the time regardless of whether the display can draw every step.


QuickSilva(Posted 2008) [#32]
I`m having the same trouble myself. What would be really helpful is if someone could simply explan both techniques using very basic psuedo code. I`m sure that both techniques are easier than they appear but the code that most people post makes things look more complex then they need to be.

I would really like to add some sort of timing code to my game but I also want to have a good grasp as to what it is doing instead of simply copy\pasting someone elses method.

Jason.


christian223(Posted 2008) [#33]
I still dont get how all this refresh rates, vsync, fps work together, but i could impelent the fixed step technique and tween on my code without much problems, so i am using it, even though i dont quite understand it, you can do it too, i would invest too much time if i try to understand it and i prefer to advance quickly in my project, so why not implement it and be done with it?.

In my case, when i use Flip 0 the tween gets ruined somehow, if i use flip -1 or 1 there is no problem and i notice no difference at all. I have set the step frequency update to 150 per sec, and i tested it in two computers, it seems to be a good choice since i get perfect movement, for now at least.


ImaginaryHuman(Posted 2008) [#34]
Delta timing:

Do...
Check what the current time is in Millisecs()
Subtract it from the time that you got when you checked in the previous loop
Calculate a scale factor based on how much time passed, so for example if you design for 60fps then divide the elapsed time by 16.67 which will give you a number around 1.0, +/- the fluctuation.
Multiply this scale factor by everything in your game to do with movement or change - ie how much you add to object positions, how fast it accelerates, how quickly the anim frames change, etc
Render your graphics based on the new updated positions.
Loop

When the framerate is below 60 the scale factor will be above 1.0 and your objects will `jump` further/faster each loop to compensate.

When the framerate is above 60 the scale factor will shrink below 1.0 and your objects will move/change in smaller steps.

Delta timing focusses on making your code adapt to the changing availability of processing time, based on increases and decreases in things happening on your computer and in the game itself. But because it is adaptive it means you're also at the mercy of circumstances which isn't ideal.

It works well on low-spec computers because if there isn't enough time to do everything at an ideal speed, even the logic, you can still get an impression of constant movement rates for all objects even if you see them jumping a bit. With delta timing the logic itself can be executed less often which is a plus. You ideally want the least amount of processing time for the smoothest framerate. But delta does have a drawback - it doesn't work with physics math. Physics requires that there be an exact linear time step between each frame otherwise this `error` magnifies and things can explode/become unstable. So it partly depends how you do your logic as to whether it's going to work for you.

Fixed Rate Logic:

Decide on a Hertz rate at which your logic will run e.g. every 8 millisecs (about 120 Hz).
Set an accumulator counter to 0 once outside your main loop.
Measure how many milliseconds have passed since the previous time you checked (previous loop).
Add that to the accumulator counter.
If the accumulator counter is >= 8 then do your logic.
If you just did the logic, subtract 8 from the accumulator counter.
Do your graphics rendering once before coming back to check the time again.
Loop

If there it time left after doing 1 logic update and 1 graphics render, it will either go to the logic again or to another graphics update. Logic has higher priority than rendering. One downside here is while the logic is operating the graphics cannot and vice versa. The graphics might block the logic. Ideally you want to do logic in parallel to graphics, like with threads.

Obviously if you happened to have lots of time spare and tried to do a render pass again you'll be rendering the same object positions as last time - which is not only a waste but won't show any visual change. This is where tweening comes in.

To tween you are taking the most recently generated fixed-rate-logic step and you're now adding delta timing to it, ie how much time has passed since the last logic update, converted into a scale factor, multiplied by how far each object moves per logic update, so that when you render the objects will gradually progress toward the position they would be at when the next real logic update happens. You can either do the tweening by taking the logic data and making a copy of it at the same time as doing the multiplication and then rendering based on that, or you can implementing the multiplication tweening into the actual rendering code.

Then when you have lots of extra time spare the framerate can go way up and you will see more detailed/refined movements, and if it drops due to lots of logic needing to be done then at least the objects still move and change at a constant rate.

Fixed rate logic is kind of like being able to get the benefits of delta timing - ie adapt to the changes in processing time - but in a way that makes your code appear to not to have to change very much. It gives you some extra consistency and simplicity.

Having a fixed rate has the drawback that the logic has to consume as much time as it needs regardless of framerate, which overall may consume more processing time than delta timing. If you try to make things move smoothly across a wide range of display Hz rates then you have to consider that a logic Hz or 61fps with a display Hz of 60fps is going to mean that occasionally you will be a whole frame off from where you should be. People get around this by increasing the logic rate to give it more `resolution`, so that for example at 120Hz you won't ever be more than half a frame off, or at 240Hz you wouldn't be more than 1/4 of a frame off, but hey that's still 4 milliseconds. And the higher you put the logic the more processing time it consumes, which is bad if you do lots of logic and automatically has less processing time available for graphics etc on lower-end machines. If your low end machine can run okay with logic at 60hz but the framerate drops to 30 when you put your logic at 120hz then that's a problem.

The solution is to combine fixed rate and delta using tweening, so that you then don't have to run the logic rate higher in a vain attempt to narrow the error gap. Even if your logic was at 1000Hz there may be still 1 millisecond error in where objects should be - although people might not notice. Driving up the logic rate is a very cpu intensive way of trying to achieve better accuracy. Instead you use a lot less cpu time by having a lower logic hz, even 60Hz would be fine, and then tweening/delta to make up for the remaining difference. That gives you the benefits of fixed rate and delta combined - better for the low-end, better for physics, better for consistency.

One drawback of fixed rate is that if you fix the rate to be the same for a number of display hz rates you will get a different `moire` offset effect based on the combination of the hz rates (ie logic against display, and also you have to factor in the graphics update hz rate). That's whay I suggest you try making a different fixed rate based on an exact multiple of the display hz because then you should get no such error effect. Upping the logic hz rate isn't an ideal way to deal with it. But if you do that you lose predictable design-time benefits of a single fixed rate, which is why you'll then need to consider a separate `design hz` which will have to be tweened to the logic hz. At least, that's my theory.

This seems to be pretty much the state of the art so far, at least published on the net. But I think there are some flaws in all these approaches which begs for an entirely new way of doing it. It's kind of like saying, okay delta does some good things and some bad things, so we want to add something else to make it better, so we add fixed rate which does some good things and some bad things, so we add tweening which does some good things and some bad things, etc etc... endlessly searching. If you were to start out with the ideal system right off the bat you wouldn't need to keep adapting and adding stuff to try to correct problems, which only create more problems.


QuickSilva(Posted 2008) [#35]
ImaginaryHuman:
Thanks for taking the time to write that, it has helped me a lot.

Greatly appreciated :)

Jason.


ImaginaryHuman(Posted 2008) [#36]
You're welcome. One thing I didn't mention is in the department of collision detection, if you have faster moving objects you don't want them to be able to move entirely past another object from one frame to the next or they will never collide. That is a problem with delta timing. Also increasing the fixed rate logic timing reduces that problem a lot and actually can give you much finer grained collision detection for faster moving objects.

Ideally if you're doing some advanced collision detection you'll also use extrapolation or estimation of the total `swept` movement path to see if that entire path of movement collided with an object, but it's harder to do.

Timing schemes are really trying to adapt to variations in how much computation you do, particularly if there isn't enough time to do all your logic and then all your graphics. Usually you let the graphics have less time if the logic needs more, which reduces the visible frame update rate. Some would debate, though, as to whether it's ideal to move objects at an equal speed if you're not even able to see the smooth movement due to not enough frame updates. You can focus on a fixed rate graphics update and a variable rate logic if you want to, somewhat more like the delta timing system.

Where the display hz comes in is really to do with what hz rate you design for and how that translates to verticle blank refreshes, etc. Fixed rate logic may not adapt well to being able to choose multiple screen modes with different hz rates, since if the display hz does not divide evenly (integer) into the logic hz then now you start to have some fluctuation. Delta timing may be better at adapting to different display rates. Ideally though you want both fixed rate logic plus delta timing plus accurate adaptation to the display hz.


Torrente(Posted 2008) [#37]
In terms of the coding, the following is a little program I wrote when I first started experimenting with this. It's probably the simplest way of doing things, but will serve as a good starting point.


I'm not sure what I'm supposed to see here. When I keep the original code, the yellow bar is choppy and looks terrible. When I comment out the While and Wend lines, keeping what was in between, it runs beautifully.


JazzieB(Posted 2008) [#38]
It will be choppy for the first few seconds. This is actually quite normal. But it should smooth out after that.

Also, it won't be 100% smooth as you're not syncing with the display, but an internal logic rate instead. During an actual game, this little jitter won't really be noticed because you'll be concentrating on the game rather than how smooth it looks (or at least the player will). You're specifically looking at how smooth it is, so you will notice it's not perfect.

It looks smooth when you comment out the While..Wend lines because you're then syncing with the display hz of the monitor. By doing so, you've taken out the timing code so it will now run at different speeds on different systems/display settings.


christian223(Posted 2008) [#39]
I implented the code i posted before, but i notice that the sprites tremble a little bit when they move, i wanted to ask what would be the posible causes for this to happen?.

I use flip 1, update frequency 200, and refresh rate 60, any ideas?. Thanks.


ImaginaryHuman(Posted 2008) [#40]
If 60 is not the hz rate of your display you might get out of sync. Other applications can steal CPU time. And there might be other reasons for it. I noticed a tremble every few seconds with other fixed rate systems.


Grey Alien(Posted 2008) [#41]
christian223: Are you drawing them at Integer coords instead of floating point coords?


christian223(Posted 2008) [#42]
Thanks both.

I use floats for the coords, and i changed the hz to my display and no change.

The thing is i notice it only in the silouette of the sprite, but not inside. I got a sprite with the shape of a box with a face inside it, and i dont notice the trembling in the face, but on the sides of the box. The trembling is minimal, but i notice it.


Grey Alien(Posted 2008) [#43]
could be that you need to defringe the sprite. Check the forum for that word and you'll find an app that removes a dodgy alpha outline caused by photoshop. I use it ALL the time.


christian223(Posted 2008) [#44]
Thanks, i did a search on it but thats not the issue, i think its because i use a very low resolution, and its very easy to notice the "jump" between pixels, if i use higher resolutions or biger sprites its not easy to notice it, i guess im beign a perfectionist, i think its the way it works actually, nothing abnormal, thanks anyway.


Grey Alien(Posted 2008) [#45]
If you are using floating point you shouldn't see a jump between pixels though, unless you are not drawing with AlphaBlend and haven't loaded the images in with filtering on I guess...


christian223(Posted 2008) [#46]
SetBlend(Alphablend) fixed the problem, what a difference, thanks a lot Mr Alien.