Frame rate independent movement (again!) This one is really weird!

Started by
14 comments, last by zedd_ 22 years, 1 month ago
Thank you for helping me out!

I know.. maybe I should''ve told you about going offscreen.
The difference in speed from left to right is probably(experimenting with different values)

Must be the timing then..
Because when I log it''s new X-coord every frame, it is of the "jerkyness" as when drawing on screen.

Hmmm..could be the drawing as you say.. maybe I''ll try moving a pixels or something instead.
And I''m gonna try QueryPerformanceCounter.

You can change in XP/Win2k so DX uses another update Hz instead of the standard 60 Hz.
Check http://www.3dfiles.com
Can''t remember the apps name though.. but browse the utils there.
Advertisement
Thanks for the link, I didn''t much like being limited to 60Hz.

If you haven''t already found a solution or had any more ideas, then you might want to try commenting out your text drawing code. I have no idea how much difference it would make, but I suppose it''s just about possible that it''s causing a flicker. Don''t really know how it could though. I''m just trying to think of anything that might affect it (and I noticed that the text flickers even when the bitmap is totally stable, but that might just be because the FPS is constantly changing - I don''t really know).

John B
The best thing about the internet is the way people with no experience or qualifications can pretend to be completely superior to other people who have no experience or qualifications.
Oh, my fault! (again)

It''s my shitty text function.
Just slams out text via Win32API. Sucks bigtime
Was just for displaying the framerate.
Have tried with and without the text on.

Think I''m gonna try experimenting some more with the code...
This is a common problem. The main reasons are:

- The timeGetTime() (the best you can do with windows95/98) can be chronically imprecise ;
- The process time (drawing + code loop) is not constant.

Considering that you use this value in a multiplication (velx = 128 * dSecondsPassed the irregularity is also multiplied. The “waiting loop” (while(timeGetTime()-time>delay) is never a good solution particularly if your “process time only” (without drawing) increases.

Solutions:
The first one is to use a smoothing function. As I’m almost nil in math I will tell you to ask the question in the “math & physic” thread. The other one is about buffering values of fps, make an average of those values and finally use it as a constant elapsed time. The solution in real life has to be a bit more sophisticated, of course.


DworD
DworD
you are not doing framerate independent movement. you are doing framerate dependent movement that scales to the framerate. instead you should look into fixed time steps (do a search here or flipcode). dont use timegetTime() use QueryPerformenceCounter(). finnally, if you framerate is below a certain threshhold it dont matter what you do, it will be choppy.
To meassure time in millisecond, why not use the most simple GetTickCount()???
that is what the genius in Blizzard did in their super game StarCraft.

IMHO, if u are going to make RTS game,moving jerkyly is not a critical problem.
Blizzard guys never use ddraw blitter to blit their graphic in SC, they used their own software blitter,they did dirty rectangle, worked at offscreen buffer, and then blit any updated region from offscreen to primary buffer, that''s all, simple enuff?? so, if u see carefully, u will find that, SC characters also move jerky even in PIII. but who care? will you mind ur SCV run so jerky while 12 zealots is going to crash ur base? sometime players are so excited and no time to see how their zealots move.

happy game programming

Martin

ps: I know the SC secret thru reverse engineering it using SoftICE 4.0. if u know asm and softice, u can prove it urself, set breakpoint at PeekMessage(...) to get the main game loop, and then.... good luck





This topic is closed to new replies.

Advertisement