The problem is that the speed of the animation depends on the cpu & graphics card, and i don''t want that. I''m using a high resolution timer but that only solves the problem partial because if i enable VSYNC the animation slows down and i don''t want that either. I want the animation to have a constant speed. I read somewhere that if you want a smooth & constant animation you should use multithreaded applications (one thread for the rendering part & one for the animation part). I tryied that and it worked fine but when i enable vsync the animation speed still suffers a slow down and i don''t know why. If someone can help me with an advise i would really appreciate it.

Hmm, VSYNC usually locks the frame rate at 60.0fps or 120.0fps, I don''t see how that could be slow when using time-based movement. What does it look like; is it jerky, or just slow?

You can also try using the multimedia timer. Sometimes the hi-res timer can act wierd on my computer (ie make animations look a bit jumpy). timeGetTime() seemed to fix those problems.

What do you mean with smooth & constant?
For animation, the position/whatever of objects is a function of some variable. This variable can be time or frame.

frame: NewPos = InitialPosition + displacement*CurrentFrame;
time : NewPos = InitialPosition + displacement*CurrentTime;

If you use the frame approach, you'll need some kind of syncronization before each frame to make it smooth. If the hardware can't keep up it'll be slow... (ex: videos, console games, GP3)

With time, you'll be interpolating the positions independently of your hardware capabilities and movement can fluctuate. If the hardware can't keep up it'll be jerky, otherwise you won't probably notice. (ex: most PC games)

[edit]
Abou vsync: if you use frame based movement and the refresh rate isn't a multiple of the fps you're targeting, movement will propably be uneven. With time you don't need extra care.


[edited by - t0y on July 7, 2002 3:02:45 PM]

Let''s get something straight first.

Smooth animation is 30 frames per second or above. Although
some would argue it is 60 or above. It doesn''t really matter.
What''s important is that there''s an upper limit.

Prefer time-based physics over frame-based physics. It''s
much easier that way. The program is also more scalable.

If your program is slower than 30 fps on a particular
combination of CPU & Graphics Card, there''s nothing much
you can do about that. Well, maybe optimize your code better
but there''s a limit to that. The animation will be jerky.

If your program is faster than 30 fps, then great, you''re all
set. Faster hardware will produce more fps, but the animation
will be smooth regardless.

The moral is that the physics of your world should be the same
regardless of what the fps is.

Kami no Itte ga ore ni zettai naru!

quote:

---

Original post by tangentz

Kami no Itte ga ore ni zettai naru!

---

Sorry this is way OT, but I''m learning Japanese, and I''m curious as to whether I understand your sig. I think it means something like ''God''s method is absolute''? How''d I do?

quote:

---

Original post by Sibbo2001
Sorry this is way OT, but I'm learning Japanese, and I'm curious as to whether I understand your sig. I think it means something like 'God's method is absolute'? How'd I do?

---

No, not even close. OK, I'll give you the "God" part.

I'll give you a hint. It originated from a Japanese anime
called "Hikaru no Go".

[edited by - tangentz on July 7, 2002 4:09:49 PM]

Thanks for your help!
I still don''t get it right. I''ve got the same problem.
If anywone could look at the code and tell me what i''m doing wrong i''d really appreciate it.
The entire VC++ project is here: www.infocib.ase.ro/~entity/ball.zip