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!

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

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

Quote:

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"

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

Quote:

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

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.

[My website][CppReference][Pixelate][Allegators worldwide][Who's online]"Final Fantasy XIV, I feel that anything I could say will be repeating myself, so I'm just gonna express my feelings with a strangled noise from the back of my throat. Graaarghhhh..." - Yahtzee"Uhm... this is a.cc. Did you honestly think this thread WOULDN'T be derailed and ruined?" - BAF"You can discuss it, you can dislike it, you can disagree with it, but that's all what you can do with it"

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.

[My website][CppReference][Pixelate][Allegators worldwide][Who's online]"Final Fantasy XIV, I feel that anything I could say will be repeating myself, so I'm just gonna express my feelings with a strangled noise from the back of my throat. Graaarghhhh..." - Yahtzee"Uhm... this is a.cc. Did you honestly think this thread WOULDN'T be derailed and ruined?" - BAF"You can discuss it, you can dislike it, you can disagree with it, but that's all what you can do with it"

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

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

Quote:

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

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

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.

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

1

#ifndef TIMER_H

2

#define TIMER_H

3

4

#include <allegro.h>

5

#include <winalleg.h>

6

7

class DeltaTimer

8

{

9

public:

10

DeltaTimer();

11

~DeltaTimer();

12

13

void ResetClock();

14

15

float GetElapsedTime();

16

float GetSecs();

17

18

float GetMsecs();

19

20

int GetFPS();

21

22

private:

23

long startTime;

24

long resetTime;

25

long currentTime;

26

27

float elapsedTime;

28

29

int fps;

30

31

// For average time of last 10 frames, Can be removed.

32

float array[10];

33

int acounter;

34

};

35

36

#endif

DeltaTimer.cpp

1

#include "DeltaTimer.h"

2

3

DeltaTimer::DeltaTimer()

4

{

5

timeBeginPeriod(1);

6

resetTime = timeGetTime();

7

8

// Can be removed

9

for(int i =0; i <10; i++)

10

array<i> =0;

11

acounter =0;

12

}

13

14

DeltaTimer::~DeltaTimer()

15

{

16

timeEndPeriod(1);

17

}

18

19

void DeltaTimer::ResetClock()

20

{

21

currentTime = timeGetTime();

22

elapsedTime =float(currentTime - resetTime)/1000.0;

23

resetTime = currentTime;

24

fps =int(1/ elapsedTime);

25

26

// Calculate average time, if below is removed elapsed time will

27

// just be the time of the last frame instead of the average of the last 10 frames

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.

You lost me here...

Quote:

quote myself: "in other posts" ^^.

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

I don't really understand why you tell me it's irrelevant as you brought it up

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

Quote:

i said "one might suggest this has something to do with allegro"

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.

Quote:

examples of programs you may have that has this issue, >the allegro example files<.

why does objects sometimes "jump" backwards like 5 pixels so fast it's almost a half frame.. cause that's what it looks like.

Post smallest code sample that demonstrates problem.

Quote:

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

Code?

Quote:

"one might suggest this has something to do with allegro" which is far from actually saying that i know it's allegro's fault.

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.

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.

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

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

Quote:

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.

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.

Quote:

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.

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.

Quote:

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

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.

Quote:

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

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

Quote:

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.

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.

Evert said:

Also, please learn to use quote tags.

Agreed.

Edit:

Quote:

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

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

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.

Quote:

I don't need a code, you probably have a couple of great examples on your computer. >"\allegro\examples"<.. . they have the same issues..

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

Quote:

try to identify the small.. lags that sometimes appear.. i suggest the buffering examples.

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.

Quote:

although the triplebuffering example is worthless.

How so?

Quote:

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.

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?