How to smooth graphics
Road Runner

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!

1 
2#include "game.h"
3 
4volatile int speed;
5void counter()
6{
7speed++;
8}
9END_OF_FUNCTION(counter);
10LOCK_FUNCTION(counter);
11LOCK_VARIABLE(speed);
12int main(void)
13{
14allegro_init();
15install_timer();
16install_int_ex(counter, BPS_TO_TIMER(60));
17set_color_depth(32);
18set_gfx_mode(GFX_AUTODETECT_FULLSCREEN, 640,480,0,0);
19install_keyboard();
20BITMAP* ship = load_bitmap("ship1.bmp", NULL);
21BITMAP* buffer = create_bitmap(640,480);
22blit(ship,screen,y,x,0,0,640,480);
23while (!key[KEY_ESC])
24{
25while(speed > 0)
26{
27if (key[KEY_UP])
28{
29y--;
30y--;
31}
32if (key[KEY_DOWN])
33{
34y++;
35y++;
36}
37if (key[KEY_RIGHT])
38{
39x++;
40x++;
41}
42if (key[KEY_LEFT])
43{
44x--;
45x--;
46}
47speed--;
48}
49clear_to_color(buffer, makecol(0,0,0));
50blit(ship,buffer,0,0,x,y,640,480);
51vsync();
52blit(buffer,screen,0,0,0,0,640,480);
53while(speed <= 0)
54 ;
55}
56readkey();
57destroy_bitmap(ship);
58}
59END_OF_MAIN()

BAF

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.

Road Runner

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

Albin Engström

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

Richard Phipps

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.

Kauhiz

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?

OICW

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.

Road Runner

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.

Kauhiz
Quote:

I need to sync the game's logic rate with the refresh rate of the computer that the game will be running on,

Err... No you don't.

OICW

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

Albin Engström

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

Kikaru

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

Kauhiz
Quote:

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.

Quote:

i never recall refusing to show my code

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

Simon Parzer

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

Albin Engström

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.

KnightWhoSaysNi

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 
7class DeltaTimer
8{
9public:
10 DeltaTimer();
11 ~DeltaTimer();
12 
13 void ResetClock();
14 
15 float GetElapsedTime();
16 float GetSecs();
17 
18 float GetMsecs();
19 
20 int GetFPS();
21 
22private:
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 
3DeltaTimer::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 
14DeltaTimer::~DeltaTimer()
15{
16 timeEndPeriod(1);
17}
18 
19void 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
28 acounter++;
29 if (acounter >= 10)
30 acounter = 0;
31 array[acounter] = elapsedTime;
32 float temp;
33 for (int i = 0; i < 10; i++)
34 temp += array<i>;
35 elapsedTime = temp / 10;
36 
37}
38 
39float DeltaTimer::GetElapsedTime()
40{
41 return elapsedTime;
42}
43 
44float DeltaTimer::GetSecs()
45{
46 return elapsedTime;
47}
48 
49float DeltaTimer::GetMsecs()
50{
51 return elapsedTime * 1000;
52}
53 
54int DeltaTimer::GetFPS()
55{
56 return fps;
57}

Here is how it is used basically:

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

Kauhiz
Quote:

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

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

Quote:

fluctuates???

Changes over time. Use a dictionary.

Quote:

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.

Albin Engström

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

Kauhiz
Quote:

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

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

Evert
Quote:

i have a feeling it wont clear things up...

That's an understatement.

Quote:

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.

Also, please learn to use quote tags.

Albin Engström

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

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.

Richard Phipps

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

Kauhiz
Quote:

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

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

You're not the only one.

Edit2: Added one thing.

Evert
Quote:

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?

Road Runner

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?

Paul whoknows
Quote:

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

Albin Engström

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

GullRaDriel

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 )

Kauhiz

I'd like to hear your reply, Albin. :)

Albin Engström

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

Kauhiz said:

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

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

Evert said:

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

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

Evert said:

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

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?

GullRaDriel said:

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

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

Dustin Dettmer

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.

Evert
Quote:

How would i know?

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

Quote:

i'm not trying to be offensive by questioning whenever or not allegro is perfect or something,

It most definately isn't.

Quote:

the reason i asked about this problem was because i had no clues left of what might be the problem..

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.

Quote:

i'm not really good at English so i guess i can get missunderstood alot..

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

Quote:

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

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?

Quote:

but you say that there's no other choice right?

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.

Quote:

I'm a newbie so i guess you would get kinda angry when i question allegros functionality.

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.

Quote:

Questioning everything is important.

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

Kauhiz
Quote:

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.

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.

Quote:

AND i used quote tags :), i'm a quick learner...

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

Richard Phipps

Quote:

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.

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.

Albin Engström
Evert said:

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.

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

Evert said:

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

Thank you :).

Evert said:

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?

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

Evert said:

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.

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.

Evert said:

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.

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

Evert said:

Not accepting everything at face value and being critical are important qualities

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

Kauhiz said:

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.

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.

Kauhiz said:

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

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

Richard Phipps said:

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.

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

:)

Kauhiz
Quote:

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

Evert
Quote:

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?

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.

HardTranceFan

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

Kauhiz

I'm not sure, but I there isrequest_refresh_rate

HardTranceFan

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

Kauhiz

D'oh, why didn't I post that ::)

Albin Engström

[..i thought i answered this already!? :'(]

Kauhiz said:

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

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

Evert said:

Yes, since 85 does not divide 1000.

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

Evert said:

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.

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? :P

Kauhiz
Quote:

Well if you mean that i should use the same logic rate as screen refreshrate and use delta time

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.

Quote:

if the program would go down to lets say like 10fps a lot of things wouldn't work right?

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

Quote:

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

Is it possible to use google or wikipedia or something? :P

kikabo
Quote:

if the program would go down to lets say like 10fps a lot of things wouldn't work right?

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();
}

Evert
Quote:

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?

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.

Road Runner
Dustin Dettmer said:

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

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

Paul whoknows
Quote:

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.

Albin Engström
Kauhiz said:

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.

hmm.

Kauhiz said:

I'll be amazed if you manage to get the fps below 50 on any reasonable system rendering any reasonable effects .

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

Kauhiz said:

Is it possible to use google or wikipedia or something?

yes it is.. good idea. - -

kikabo said:

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();
}

Evert said:

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.

ok. i'll do that.

thanks! :)

Audric

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

Kauhiz
Albin Engström said:

hmm.

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.

kikabo

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

Kauhiz
Quote:

I like to work in units of (current_refresh_rate)/common_refresh_rate

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

Albin Engström
Kauhiz said:

Quote:

Albin Engström said:
hmm.

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.

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 :P
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?

Kauhiz
Quote:

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?

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

OICW

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.

kikabo

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.

Albin Engström
Kauhiz said:

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

Hehe :P.. 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 - -)..

OICW said:

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.

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

kikabo said:

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.

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

Richard Phipps

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.

FuriousOrange

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"}591251

Audric

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.

OICW

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.

Tobias Dammers

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.

OICW

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.

Audric

591252

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.

Kauhiz
Quote:

well, i think it's necessary for bullets to be able to acheave such speeds, it's about feeling

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.

OICW

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.

Paul whoknows

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

Audric

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.

OICW

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.

FuriousOrange

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

Tobias Dammers

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.

Matthew Dalrymple

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"}98d27599548301c3caf1d69166a63e68.jpg

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 :P

kikabo

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

OICW

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.

Audric

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)

OICW

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.

Richard Phipps

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

Albin Engström

hmmm

Thread #589993. Printed from Allegro.cc