I've just been toying around with a simple program which moves a space ship around the screen. My problem is that the movement of the ship is fairly smooth on my laptop computer, but when I run it on any of my desktop computers the movement becomes very jittery, and if this were a real game (which I intend to make it into), it would be hardly playable. Here's my code (I've attached the exe file). I've read many of the posts about this on here and haven't really found anything that helped. Help would be great!

You will tend to get better help if you use [code][/code] tags around your code (click Help where you type in your post for more info).

Also, what are the specifications of the desktops that it was jerky on? It might (I'm not sure on this) be that vsync() in there.

Sorry, I didn't know about the code tag until you pointed it out. One of the desktops is 32bit 800,600, 85hz and the other is identical except that it's running at 1024,768 resolution. On my laptop if I remove the vsync(); then it the movement starts getting jittery as well, but not nearly as severe as on the two desktops. On the desktops the movement vibrates back and forth quite like a power toothbrush (excuse my silly example).

This is a problem i have to, but i've heard there's nothing you can do about it, apparently it becomes less visible using better buffering modes. i use triple buffering . the thing you call "jitter" (if we think about the same thing) is indeed very annoying.. as i don't se many games other than allegro games with this problem(i haven't noticed it before), one might suggest this has something to do with allegro... maybe it's something we (the newbies) do wrong, or maybe it's something we can't do anything about, i'd be happy if the first suggestion was true.. the other thing that comes in mind is that you use float values when moving the ship like 1000 times per second the ship moves down(0.0012) and right(0.0012) as the ship will be drawn at pixel coordinates this may look like the ship is... "vibrating back and forth quite like a power toothbrush".. but this would not look different on different computers so i don't think this is the case... i would love to hear what the allegro gurus have to say about this.. i've asked before but the only answer i can recall was (who cares, you almost can't see it)...

You have a timer running at 60hz and a screen refresh rate of 85hz. Just test making the timer work at 85hz and see if that helps.

The point of the code tags is that that way you can indent your code. Since you edited them in later, the code is still quite ugly. (I don't mean to nag, just pointing that out.)

How would using floats make it jittery? If anything, you should use floats to make the movement appear smoother.

I doubt that. I've never had this problem in anything I've done. The only issue I recall having with jittery movement was timing related. Once I added proper timing, it ran just fine.

Futhermore, you're making quite a leap there, Albin, saying that the problem might be in allegro, seeing how you refused the present the code you were having problems with. No one can really say if it's something you're doing wrong, if you don't show them what exactly it is that you're doing! Besides, how would allegro affect the way you move your sprites?

Well I sometimes observed sprite movement jerky, but it was due the high velocity of that object. It then looked like it was jumping from place to place. The thing you observe is most probably due the bad timing.

I also observed nasty distortion when using double buffer - I was able to see vibrations as the lines were redrawn.

So from what I've been able to gather, I need to sync the game's logic rate with the refresh rate of the computer that the game will be running on, and I should use triple buffering as well. The only problem that I can see is that doing this will make the game run at a different speed on every computer.

Err... No you don't.

It won't, just see the manual, or toy with delta time.

Kauhiz:
Quote #1:How would using floats make it jittery? If anything, you should use floats to make the movement appear smoother.

Well, try moving a sprite in a diagonal direction (i'm not 100% sure it's called diagonal.. i mean moving something alongside both the vertical and horizontal line) with float values and keys.
if the sprite is moved one pixel at a time the movement should(will) appear smooth, but moving it with the keys and by a small amount per millisecond the movement will NOT appear smooth due to the delay between key pressing, i don't know why you don't believe me as this should be obvious, not that i thought about it before i saw it with my own eyes.

Quote #2:I doubt that. I've never had this problem in anything I've done. The only issue I recall having with jittery movement was timing related. Once I added proper timing, it ran just fine.

What is proper timing? i can't see how unproper timing would affect the display in a negative way(in a way it should not be displayed), but then again i'm not that wise..

Quote #3:Futhermore, you're making quite a leap there, Albin, saying that the problem might be in allegro, seeing how you refused the present the code you were having problems with. No one can really say if it's something you're doing wrong, if you don't show them what exactly it is that you're doing! Besides, how would allegro affect the way you move your sprites?

How can i show you something i don't have? and the thing i don't have is knowledge.. as i don't have any idea on what might cause the problem my only option would be to post ALL my codes that i ever wrote in full size, which i thought seemed a bit.. foolish. and i know i wouldn't help. >i never recall refusing to show my code dough, in other posts maybe..:S<. I don't think this is a problem with movement and i don't really understand why you ask me that..

Floats slow down your game, and you can only display whole numbers of pixels. If the number of pixels per loop moved changes per loop, it seems to fuzz and jitter. I know, I tried it once.

I'm not 100% sure what you're getting at, but if I understood correctly, you mean that there will be a delay between the keypress and the movement. If that's what you meant, then that's completely irrelevant to the topic. Delayed != jerky. My point was, that if you use integers, you can only move 0, 1, 2 etc. pixels per frame. If you use floats, you can move smoothly at any speed.

I can. If your logic rate fluctuates, so will the movement of your game objects. It's that simple.

http://www.allegro.cc/forums/thread/589875/647703#target. I believe you were having the same problem.

Forget about the jittery movement.
Just add lots of cool animations and special effects and nobody is ever going to notice.

Kauhiz:
It's hard to explain.. so i've added an attachment , but i have a feeling it wont clear things up...

Quote #1:I can. If your logic rate fluctuates, so will the movement of your game objects. It's that simple.

fluctuates???
but still, that's the way it's sopposed to be. it may be "wrong" but it's right .
why does objects sometimes "jump" backwards like 5 pixels so fast it's almost a half frame.. cause that's what it looks like.

Quote #2:http://www.allegro.cc/forums/thread/589875/647703#target. I believe you were having the same problem.

quote myself: "in other posts" ^^.

Simon Parzer: sorry, can't do . i'm not satisfied with just that.

I am having this problem too. Double buffering seems to be the worst. Tripple buffering isn't working for me so all I can do is page flipping.

I have searched for and seen these threads once before but the only information I can find is to use high resolution (not Allegro's) timers such as QueryPerformance or timeGetTime for windows and to use page flipping or tripple buffering. Using these methods the jitteriness is much less but it is still there.

Here is my timer class. I noticed the timer can be off by quit a bit or is buggy every once in a few hundred calls so is it better to do the average of the last n frames or just the last frame?

DeltaTimer.h

DeltaTimer.cpp

Here is how it is used basically:

while(!done)
{
    Timer.ResetClock();
    object.position = object.position + object.velocity*Timer.GetElapsedTime();
    object.draw();
}

You're right, it didn't. So, what's the difference between the pictures? Why does the first one have arrows in it?

Changes over time. Use a dictionary.

You lost me here...

Again, that's irrelevant. In that thread you had a problem in the movement, but refused to show code. Then you say it's possibly a problem in allegro. I just pointed our that you have no reason to suspect a problem in allegro, so you shouldn't tell someone else that it's allegro's fault.

Ah.. the picture.. if you don't understand (more like realize) what i tried to explain with that pic, things will get even harder :/.
Imagine that a sprite will be placed on a point, let's call it origo..
when the sprite starts to move with the same horizontal and vertical speed (down and rigth for example) the diagonal line must cross the origo, if we split a pixel in a 1000 parts. the starting coordinates has to be 0.000-0.000 and not 0.015-0.000 for example, the sprite will then be rendered in 1-1 2-2 3-3 4-4. if the thing i called "super human effect" in the picture was not to apply the move ment would look more like this. 1-1 2-2 3-4 4-4 (not a realistic example but i think you get the picture...).

Quote: Again, that's irrelevant. In that thread you had a problem in the movement, but refused to show code. Then you say it's possibly a problem in allegro. I just pointed our that you have no reason to suspect a problem in allegro, so you shouldn't tell someone else that it's allegro's fault.

I don't really understand why you tell me it's irrelevant as you brought it up, and i didn't have problem with the movement, i had an unknown problem with the display. and i never said it was allegro's fault, it feels like you're trying to change the words i've spoken.. i said "one might suggest this has something to do with allegro" which is far from actually saying that i know it's allegro's fault.
it was a suggestion, just like "maybe it's something we (the newbies) do wrong".

As for the reason to think it's allegros fault: I've played alot of games made with allegro and some of them has the same issues, others say that they have them too, so: 1: we're all noobs and need to know that special thing that would prevent this thing. 2: Pro's are to ignorant and the problem still lurks in the background.. i don't care which one is right, i just don't want to see the damn thing again. examples of programs you may have that has this issue, >the allegro example files<. i guess a noob made those.. - -

No, I mean where you refused to supply code is irrelevant.

Exactly. That's wrong. I've never had any of these problems with allegro (like I already said), so it's not a problem in allegro, therefore you can not suggest that it has something to do with allegro.

This would suggest it's a problem with your system, not allegro.

That's an understatement.

Post smallest code sample that demonstrates problem.

Code?

No, but you're suggesting it. Rule of thumb: the error is in your code, not library code. Once you've established without a shadow of a doubt that it isn't your code that's wrong, you suggest that it is the library code. It usually does turn out to be user code that is wrong.

Also, please learn to use quote tags.

quote #1: Exactly. That's wrong. I've never had any of these problems with allegro (like I already said), so it's not a problem in allegro, therefore you can not suggest that it has something to do with allegro.

ok, not everyone might consider it a problem, it's not affecting the functionality, but are you sure you just don't notice it?

quote #2:Exactly. That's wrong. I've never had any of these problems with allegro (like I already said), so it's not a problem in allegro, therefore you can not suggest that it has something to do with allegro.

What you're saying sounds like this in my ears (it's text thought):
I AM GOD, if i feel like it works, it works. end of discussion.

quote #3:This would suggest it's a problem with your system, not allegro.

That was my first thought, but as i heard of others experiencing the same problems i started to doubt it more and more, no wait, it may be something wrong with my system, but that means somethings wrong with ALOT of systems. and thats the same thing as there's something wrong with allegro. hey: i made this code but it does not work on any computer, does that mean there's something wrong with the computer or with the code?? .

Oh, and while you where answering me i added some more to my later post.

Evert: my deepest apologies for not knowing how to use quotes.. but i don't have the strength left to learn it right now, been awake the whole night/morning/afternoon - -.

Quote #1:Post smallest code sample that demonstrates problem.

I don't need a code, you probably have a couple of great examples on your computer. >"\allegro\examples"<.. . they have the same issues.. try to identify the small.. lags that sometimes appear.. i suggest the buffering examples. although the triplebuffering example is worthless.

Quote #3:No, but you're suggesting it. Rule of thumb: the error is in your code, not library code. Once you've established without a shadow of a doubt that it isn't your code that's wrong, you suggest that it is the library code. It usually does turn out to be user code that is wrong.

Rule of thumb... i don't like that. :S.
I don't care whenever it's something wrong with allegro or my code, i just want a good explanation for the problem and a possible solution.

I don't know about anyone else, but I'm getting tired of new people who don't want to listen or learn..

I'm 100% sure I've never experienced this problem.

Then you need to have your ears (or eyes) examined . If it works on my system it's not a problem in allegro, because if it was, it wouldn't work on any system. I know how you can get the wrong impression, but I can't really speak for others, nor do I have any statistics on this. I'm sure that most of the allegro community falls under the "works for me" category, though.

Define "ALOT of systems." How many people do you know to have this problem with the allegro examples? You're the only one I know of.

If the code runs perfectly fine on all other computers, there's something wrong with the computer. If the code doesn't work on any computer, there's something wrong with the code.

This is what I was saying -- others don't have this problem. Do you honestly think that if there was an issue like this in allegro, you'd be the first to notice it? (Yes, you could notice bugs, but if it's in everything made with the lib it would be noticed quite quickly).

What!? It's not going to get fixed if it's in your code and you assume it's in the library.

Oh, and about the explanation you posted; is your point that every once in a while one coordinate will increase and the other one won't? If so, then that's hardly a concern; if you're doing 1000 loops/s like in your example, and it goes "off course" in one loop, chances are that the frame won't even get drawn to the screen. Even if it does, it won't be noticeable, and it most certainly will not account for jittery movement.

Agreed.

Edit:

You're not the only one.

Edit2: Added one thing.

Well, that's really your own fault and not a very good excuse. It works like a code tag, except you replace "code" by "quote". Do check the other forum mockup tags while you're at it though.

Ah, ok. So I take it your code works fine then?

Don't see it, but I do see two things you shouldn't be doing yourself: using the retrace simulator to time your code and not calling vsync before blitting the buffer to the screen. Is this a problem with the Allegro example? I don't think so, it's meant to be a small and simple example that shows a specific feature, it is not nescessarily very good for anything else. That said, feel free to post suggestions for improving the examples.
I did notice a problem with the exupdate example: the continuous palette cycling is blocking the input thread from getting input events; adding a rest(1) gets rid of that, but it's something I thought we fixed late in the 4.1 series (so prior to 4.2). I may have to look into that.

How so?

How do you expect to solve a problem if you don't know where the problem is to begin with?

Sorry I haven't posted in a while. I've not made any progress in fixing the problem yet, somebody mentioned delta time, so I think I'll play around with that and start using a high resolution timer, maybe that will help?

Yes, or you can also try Richard Phipps's high resolution timer, is easier and it works well(I am using it in my project).

i spent almost an hour answering.. just to press backspace and go "back".. i'm to pissed of right now, i may answer when i've cooled down. - -

Albin:
Your profile says : "Finished projects: NONE (i'm young so i expect you to understand ^^)."

Please listen to others. Some people were here before your born. Some of the people who have answered you are also allegro developer / maintainer. THEY are right (here and most of the time).

It is while forging that one becomes blacksmith. ( Et c'est en sciant que Léornard De Vinci ;-p )

I'd like to hear your reply, Albin.

As i'm too tired to answer as detailed as i did(would have..) i'll make it short:

How would i know? the only thing i know is that when i run applicitions made with allegro i can see a thing that's bothering me, i don't know if anyone else sees this too, but it's there. i've tried to capture it on video but i doesn't show, and when i say video i don't mean a camera, i mean a program that records the screen. this thing is very small and almost invisible at first, it took me 3 week before i actually saw it.. (although i didn't have much of a screen in the beginning...). i'm not trying to be offensive by questioning whenever or not allegro is perfect or something, the reason i asked about this problem was because i had no clues left of what might be the problem..
i'm not really good at English so i guess i can get missunderstood alot.. .
I have a rule that i should never settle with truth.. if you're wondering why i'm so persistent..

Yes, it does work, it works great, but that little thing is really annoying.

Is it a problem if you know what the problem is? who knows what's the cause of the problem, if you find out, it's not a problem anymore..
I can see the problem, but i don't know the cause nor do i know how to describe it, i guess i could live with it, but i'd rather not. but you say that there's no other choice right?

I do listen to others, even if it seems like i don't, that's why i ask.

I'm a newbie so i guess you would get kinda angry when i question allegros functionality. but i still don't think i did wrong asking those questions...
Questioning everything is important. atleast that's what i think.

well, i replied to a small part aleast, the most important parts. AND i used quote tags , i'm a quick learner...

Haven't read the whole thread, so someone might have answered already.

This code:

volatile int speed;

should be:

volatile int speed = 0;

That should solve a lot of your problems.

Also I would remove the vsync call entirely.

That's why you start by assuming that you screwed up before suggesting someone else did.

It most definately isn't.

Post some of your code that clearly shows the problem. You can say it shows up with the Allegro examples, but as others (and I) have said, they don't see a problem there and as I said there are several things you should be doing differently anyway.

Your English is fine. At least I haven't had a problem with it.

Don't be silly. If a program segfaults if you do X, is that nota problem because you know it will, or should you fix it because a program isn't supposed to crash?

I didn't.
But: if your logic does not update at (an integer multiple of) the screen refresh rate, you will see (quasi)periodic jitters in the output because graphics and game state update at a different frequency (it's basically the same effect as when you hear two freqeuncies that are close but not equal). That cannot be avoided unless you use something like a "delta time" method to synchronise your game, fix the gamespeed depending on the computer it runs on (not normally a good idea) or run your logic rate at an integer multiple of any common refresh rate (35700 Hz should cover 60, 70 and 85 Hz monitors) which is problematic because you need an insanely high timer frequency.

That's not exactly the problem. The problem is the "newbie with attitude," who thinks they know what they're talking about because they've just written "Hello World!"
You're not in that category, but assuming there is a problem with a third-party library before your own code is simply wrong. I've been programming for about fifteen years and I can tell you from experience that when a program of mine screws up, it's usually because of something I did, not because of what others did.

Not accepting everything at face value and being critical are important qualities. Questioning everything is just annoying.

No one's angry at you for asking questions or questioning allegro's functionality (or for anything else for that matter). The point being that most people posting here are speaking from experience. So if you say there's a problem with allegro and you're told that there isn't, it's not that we're guessing there isn't - it's experience. If the issue really was with allegro, no one would deny it, of course, and it would be looked into.

Well, I don't know, you have been here for something like two months...

I run my logic at 240 or 250 times a second. While not perfect it works better with a fixed logic rate than lower values. You could try this too if you don't want to start using delta time.

well, i guess there's something wrong with my computer then.. although this problem only shows up when playing allegro related programs. and as for those things i should be doing differently i already do them differently :/.

Thank you .

hm, i meant that if you know how to fix a problem, it's basibasically a problem any more :/.

Interesting... i use a fixed logic refresh rate of a 1000 loops per second(i've been told this is too much but i have no problem with it on my computer or less capable computers), i use triplebuffering and the screen refresh rate is 85. would it cause this effect?
if i used doublebuffering and sett the screen refresh rate to 100, would it not cause this effect?, but how does the display react if i use the same refresh rate for logic and graphics but calculate for example a ships posipositionlthough i don't think i could write a game this way, without making it the way i don't want it). i'd love to hear more about it.

Hehe ^^, well, i guess it's wrong to assume that there's a problem with a "third-party library" before my own code(and absoabsolutelyn i'm as inexperienced as i am), but i thougth the examples where made by someone who developed allegro and because they had this "problem" i thought(no i didn't, it was more like a very distant ...thing(i can't find the word - -).) that it had something to do with allegro, and i'm not sure it was meant like a problem, more like a thing, yes, a "thing" is a good word for it..

^^' that's how i wanted it to be read..

Great , i felt like someone was angry at me.:'(. They may be speaking from exerexperiencet a simple answer dosedoesn'tesatisfyeven if it's true, i have to hear a detailed explanation before i leave it alone.. the problem is that no one seems to know anything about the "problem" i have, and by seeing how the allegro examples doesn't do it better that my code i had no real thing to go for other than allegro.. and my computer which i actually think is the cause with about a 99% chance... i really don't know what to believe.. i should take a small program and test it on other computers to see if this effect will turn up.

Hehe ^^', well, when i think about it, i acctactuallyrned how to use quote tags upon request a while ago, but it's seams like i forgot about it..
2 months? time goes fast..

Hmm. delta time.. sounds like something from hell..

Not at all. Delta timing basically means that in your logic you multiply values by the change in time (delta means change or difference in physics) since the last loop.

//This:
player.x++;
//changes to this:
player.x += deltaTime * speed;
//where speed is the speed you want you player to move at

I like delta timing, because it has a more "physical" feel to it, if you get what I mean. Anyway, when you do this you just let your logic run freely, without limiting it, and your game will run smoothly on all systems. The only thing you have to do is figure out the delta time. If you want the easy way (IMO), try OpenLayer. It gives you a bunch of other cool stuff as well

Yes, since 85 does not divide 1000.

About delta-time, there is one thing to consider. This is not nescessarily a problem, but if you're varying the timestep, you're affecting the outcome of numerical integration, which means results can be slightly different. I suspect the problem is insignificant for most games and if you have to, there are ways around it and/or better ways to integrate than the fairly standard direct Euler integration. It is something you may want to remember for later on though.

Is there a way to get the screen refresh rate using C or C++?

I'm not sure, but I there isrequest_refresh_rate

Cheers Kauhiz. I followed the link and found get_refresh_rate. I'll check this out later on.

D'oh, why didn't I post that

[..i thought i answered this already!? ]

I know what delta means .. altough i didn't know i could mean change aswell. Well if you mean that i should use the same logic rate as screen refreshrate and use delta time: the reason i don't want to use this delta time thing is that if the program would go down to lets say like 10fps a lot of things wouldn't work right? unless i would have to add a lot of code making it work,, and i can't imagine that code in my head(not that i have sit down and thought about it). i like using a logic loop of 1000. it makes me think clearly, and i have no problem running it on my computer or a less capable one. , hehe, i've been thinking about OpenLayer, but i've been having some problems compiling it .

It wasn't the dividing thing i was unsure of.. but it still answered my question

Last time i wrote the replys i said "I'm having a problem following, i should get some rest and then try to understand again" well, it's seems like i don't understand even with after a good rest.. . there's so many difficult words like.. "numerical integration"?, "varying the timestep"- - and "Euler integration"!

is it possible to convert those word into some more understandable words for me?

No. When you use delta timing, you don't limit the logic rate at all. It can run 10 000 times on one machine and 100 times on another, but both will look the same.

I imagine there would be some problems in such cases, but probably nothing that can't be worked around. If you chose to use OpenLayer like I suggested, I'll be amazed if you manage to get the fps below 50 on any reasonable system rendering any reasonable effects .

Is it possible to use google or wikipedia or something?

You could always add something like this :-

while(! Game::Over() )
{
   dt = Timing::get_dt();

   while(dt > MAX_DT)
   {
      Game::Logic(MAX_DT);
      dt -= MAX_DT;
   }

   Game::Logic(dt);
   Game::Draw();
}

Not really. If you don't know what integration is, I'm not going to be able to explain it in a way that makes it clear in a few words. You'll need to read a mathematics text book for that.

As I said, don't concern yourself with that; if you do run into problems, then would be teh time to remember and look these things up.

Tried both of those, and removing vsync(); just made the problem worse on my laptop.

I should have asked this in my first post (sorry), so here goes...If anyone has encountered the jitter problem before, what exactly did you use to fix the problem????

Just use a high resolution timer, like the one I suggested in my previous post.
Or do a search in these forums and you will find a lot of threads about high resolution timers.

hmm.

hehe, i'd be suprised too . but you never know what might happen..

yes it is.. good idea. - -

while(! Game::Over() )
{
   dt = Timing::get_dt();

   while(dt > MAX_DT)
   {
      Game::Logic(MAX_DT);
      dt -= MAX_DT;
   }

   Game::Logic(dt);
   Game::Draw();
}

ok. i'll do that.

thanks!

The one time I had jittery graphics, I finally realized it was because of a AC DC power suppy which was too close to the back of the monitor...

I'll give you one more example. Suppose you're running your logic at 100 loops/s. This will mean that the delay between loops is roughly 0.01 s.

Now, when you do this with delta timing, you don't limit the logic. For clarity, let's say you're measuring delta time in seconds. If your logic runs 100 times per second, delta time would be 0.01 s. That means you multiply stuff by 0.01.

Then, on another machine, your logic runs 1000 loops/s. Now, the delta time will obviously be 0.001 s. So now you multiply by 0.001.

0.01 * 100 == 0.001 * 1000. So it doesn't matter how fast the game is running, it'll look the same.

I like to work in units of (current_refresh_rate)/common_refresh_rate so that if the user happened to get that refresh rate then dt would usually be 1 for each frame.

This way if you choose speeds for some of you game elements of dt * 1 or dt * 2 etc then for some users those game elements will be moving in whole pixels per frame which is as smooth as you can hope for.

(ed: assuming that you are vsync locked)
(ed2: changed 1 to (common_refresh_rate) duh!)

Yeah, me too (I think this is what OpenLayer does), but I was using seconds in my example for simplicity.

so if a thousand bullets move aagainsta target at 1000pixels per second and the logic rate is at 100 they will move 10 pixels per loop? something tells me i'll meet this kind of problem often(and i'll have to write alot of code to fix it, i can think of a few situations that i could fix thought), so i don't want to try it out :S.. but i can think of some situations where using deltatime is the right thing to do. How do you get over by like this?

I don't really understand the other posts..

Now that i think about it.. i use delta time for my logic loops
This is how i do it:
i store the time between frames and then use the value to run the "logic loop"*"delay between the frames" , and a separate logic loop that runs only one time per frame.

Approved?

The amount of the bullets has nothing to do with anything. Apart from that, yes, except why would your bullets move 1000 pixels a second!? There's absolutely no sense in doing that!

There's a great possibility that they would phase through an oponent causing no harm - considering you would check only if they're inside him.

It sounds like Richards method would work best for you, at that speed your bullets would get 1 logic loop every 4 pixels which isn't too bad if your enemies are large (in terms of pixels).

ed. If your game resolution is low then that does sound a bit too fast for bullets.

Hehe .. well, i think it's necessary for bullets to be able to acheave such speeds, it's about feeling.. i don't like when you have this awesome machinegun and a million aliens moving thowards you, and you bullets move in slowmotion(with a booring sound effect)... it should be like BAM BAM BAM just spitting out a shit load of bullets at a really high speed slaughtering everything. . also, i like small targets :/(i like targets of all sizes too - -)..

yeah. and to me, that's a very big problem.

4 pixel is to much . 2 pixels is to much.. bullets should be able to hit bullets - -. i'm fine with one pixel right now... but i might change my mind and go with 1/4 pixels. hehe, it would be approximately 1.56 screen widths per second... i guess thats enought .

If your bullets are one pixel in size they are too small to be seen properly. The minimum should be 2 x 2 or probably 4 x 4. In that case they can move at 2 pixels per second or 4 pixels per second and still overlap to cause collisions.

I had nothing to do this lunch break so i thought i'd make this picture. It explains why having a bullet move speed of 1000 px is a bad idea. Best to have big heavy alien smashing bullets travelling at 5 px per update than a stealth bullet thats too quick for its own good. Enjoy!

{"name":"591251","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/8\/98d27599548301c3caf1d69166a63e68.jpg","w":846,"h":745,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/8\/98d27599548301c3caf1d69166a63e68"}

Uhm... I may be missing something very obvious with delta-timing, but since you don't enforce a constant "time interval" between updates, don't you HAVE to take into account the fact that this interval can be between 0 ms and +infinity ?

In particular, if something on your computer cause a big performance hit (something like: CD starting to spin, ctrl-alt-del, antivirus or other hungry program), there can easily be a second-long gap.
A fixed-frequency system would compute and say "wow, I need to run logic() 100 times in a row". And it would "catch up" and stay consistent : no player stuck in the wall etc.

I think, for delta-timing, you NEED to build a system that can handle such gaps. If you don't, the game will behave incoherently on slower computers, and randomly on yours.

But that's what is delta time about. Since you can't be sure that the time between frames is the same, you aply delta time. You just meassure the time between two frames and multiply by it all movement done between theese two. Just like in real world.

Audric has a point though. If you use delta time, and frame times can be anywhere between 0 and +inf, then you can't guarantee any maximum distance travelled per frame for any object.
There are 3 basic solutions to the problem:
a) cap both frame time and velocities so that all movements are sufficiently short; call your logic_update several times until you hit the actual delta.
b) subdivide each movement into chunks that are max_dist or shorter, and iterate through them. The upside is that you can still use very simple collision tests; but the downside is that you may end up calling them very often.
c) use a more sophisticated collision detection algorithm, one that takes movement into account.

ad c) like checking whether there's something in the path of the bullet, or if there's possibily, that something will get in there considering the velocities.

See the attachment for an example:
Imagine all three objects (B)ullet (M)an and (C)ar are on the same Y axis, and their movement to process 'in the current logic update' is represented by vectors v1, v2, v3.
For this example, imagine the Car and Man don't collide each other (same team, friendly fire off), but the enemy bullet will stop as soon as it touches either.
Even "on the paper", I can't imagine a single-pass algorithm to solve the issue.

Fixed frequency does not solves such issues (it makes it easier to avoid them), but it has the advantage that the situations are fully replayable : just record the seed of your RNG, and the inputs of each frame.

Again, having a 1px bullet moving at 1000px/s is just pointless. No one will be able to see that. If you want "realistic" (read fast) bullets, just check for collisions along the trajectory rather than against an actual projectile. There's no way this can get screwed up.

Audric: first of all you just check whether the velocity vectors aren't colliding, or more specifically if the vectors from point of origin to point of destination (between the two frames) doesn't collide. If yes, then you have a collision.

Just do it only for fast moving objects - like a bullet which will check other objects if they're in the way. After that you should analyze if there's such a point along the trajectory where the bullet was inside the object.

FuriousOrange, I really like your sketch! do you have more of them?

OICW, my point was not to detect if there was a collision, what collided with what... (and where in space and time)
In my example, the bullet hits the car, about the middle of the time interval.
At the end of this interval, the man reaches about the same spot - and doesn't collide the bullet as it's long gone.

Well at first you must know if something collides. Ussually as a side effect you know what and where it collided. For instace, if you check those two vectors from my previous example whether they collide and the output will be yes, there will be also somewhere information where did they collided - it's in the nature of vector intersection checking.

So if you know that the the vector a and b collides, you'll be also provided with [x][y][z] coordinates. Which is exactly what you're seeking for.

Paul whoknows, i'm sorry to say I don't!

OICW: It's a bit harder than that. For checking 2 moving objects against each other, you need to take their radii into account. The formula goes something like this:

dist(dt) = hypot(x1 - x2 + (v1x - v2x) * dt, y1 - y2 + (v1y - v2y) * dt) - (r1+r2);

and you have to solve the equation for dt where dist == 0; this will give you 0, 1 or 2 solutions. If there are no solutions, there is no collision. If there is one, then the objects hit each other only tangentially, and you can probably consider it a non-collision as well. If there are 2 solutions, then you need to use the smallest non-negative solution. If the solution is larger than your desired maximum dt, then you can ignore it. If both solutions are negative, there is not collision.

If more than 2 objects are involved, you need to check each object pair, and start with the first collision you detect. Forward the simulation to that point, handle the collision, and run all checks against these two objects again. Keep doing this until dt has reached its desired maximum for that frame.

To FuriousOrange and his image:
{"name":"98d27599548301c3caf1d69166a63e68.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/8\/98d27599548301c3caf1d69166a63e68.jpg","w":846,"h":745,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/8\/98d27599548301c3caf1d69166a63e68"}

I'm sorry but I have to give props to FuriousOrange... I CANT STOP LAUGHING. It might just be me at 3:20 in the morning but yeah, I saw that and wow its great.

Sorry to pull off the subject

I haven't read all of the replies since but it sounds like there is confusion between the stated 1000 pixel moves per second and pixel moves per update. 4 @ 250hz = 1000 per sec

Tobias: well ok of course if you need to check huge objects you need to apply some radius (if it's enough). But maybe before some slower solutions for non-circle shapes (which is more common) it's good to check whether it's even possible for them to collide.

Still in delta-time,
Collision is not the only issue, you have to take the whole logic speed/frequency into account:
For exemple, if you have an auto-cannon shooting 1 bullet every 500ms, starting at t0:
If're processing t1 = t0 + 620 ms, you have to spawn one bullet and immediately apply 620ms worth of movement to it, then spawn another and give it only 120ms worth of movement.

If you don't, it will be VERY visible that the shooting frequency is affected by system load : the distance between the projectiles will not be constant.
Somebody knows one open-source game that successfully addresses theses issues ?
I can imagine one system, but it's multi-pass algorithm.. horrible performance hit, at the worst possible moment (when you need to catch up)

Well typically those frames have same dt, only when there's something unexpected there's a gap. But to solve this problem you just either need some external timer, which will tick exactly on time and spawn a bullet. Or you can have a variable which will be incremented by dt and after it gets over some threshold it spawns a bullet, ussually you update the bullet after the spawning phase, so it will actually move as requested.

These delta time issues are all reasons why I prefer the simpler fixed logic rate approach. I know delta time might provide better results when done properly, but it's a difficult way to code for me.

hmmm