Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » How to smooth graphics

This thread is locked; no one can reply to it. rss feed Print
 1   2   3   4 
How to smooth graphics
kikabo
Member #3,679
July 2003
avatar

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
Member #4,798
July 2004

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.

---
It's Ridge Racer! RIIIIIDGE RAAAAACER!

Albin Engström
Member #8,110
December 2006
avatar

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
Member #4,798
July 2004

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!

---
It's Ridge Racer! RIIIIIDGE RAAAAACER!

OICW
Member #4,069
November 2003
avatar

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.

[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"

kikabo
Member #3,679
July 2003
avatar

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
Member #8,110
December 2006
avatar

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
Member #1,632
November 2001
avatar

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
Member #7,305
June 2006
avatar

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
Member #907
January 2001

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
Member #4,069
November 2003
avatar

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.

[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"

Tobias Dammers
Member #2,604
August 2002
avatar

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.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

OICW
Member #4,069
November 2003
avatar

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.

[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"

Audric
Member #907
January 2001

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
Member #4,798
July 2004

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.

---
It's Ridge Racer! RIIIIIDGE RAAAAACER!

OICW
Member #4,069
November 2003
avatar

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.

[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"

Paul whoknows
Member #5,081
September 2004
avatar

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

____

"The unlimited potential has been replaced by the concrete reality of what I programmed today." - Jordan Mechner.

Audric
Member #907
January 2001

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
Member #4,069
November 2003
avatar

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.

[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"

FuriousOrange
Member #7,305
June 2006
avatar

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

Tobias Dammers
Member #2,604
August 2002
avatar

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.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Matthew Dalrymple
Member #7,922
October 2006
avatar

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

=-----===-----===-----=
I like signatures that only the signer would understand. Inside jokes are always the best, because they exclude everyone else.

kikabo
Member #3,679
July 2003
avatar

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
Member #4,069
November 2003
avatar

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.

[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"

Audric
Member #907
January 2001

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)

 1   2   3   4 


Go to: