OK cheers. I will play around with those ideas and see if I can improve it. Many people have trouble seeing what I mean when I show them so it is not too bad
OK cheers. I will play around with those ideas and see if I can improve it. Many people have trouble seeing what I mean when I show them so it is not too bad
The views expressed on this programme are bloody good ones. - Fred Dagg
This part sounds confusing to me, I have never had any problems with unsmooth movement using the timers i've created for Phoenix for instance. What kind of timer do you use and how do you calculate the elapsed time ?Originally Posted by czar
Some example code on how i'm doing it:
(note that this is limited to Pentium 3's and above)Code:var Frequency : Int64; var CurrentTime: Single: var LastTime : Single: var FrameTime : Single: procedure Initialize; begin QueryPerformanceFrequency(Frequency); end; procedure Update; var Time : Int64; begin QueryPerformanceCounter(Time); CurrentTime:= (Time / Frequency); FrameTime:= CurrentTime - LastTime LastTime:= CurrentTime; end; procedure MoveSprite; begin Sprite.X:= Sprite.X + Sprite.Velocity.X * FrameTime; end;
If the framerate varies alot you could average the frame time over a few frames aswell to get even smoother movement.
Amnoxx
Oh, and this code appears to be an approximate replacement for return(random() & 0x01);
Phoenix Wiki
http://www.phoenixlib.net/
Phoenix Forum
http://www.pascalgamedevelopment.com/viewforum.php?f=71
I have been playing around with different variables and the ideas mentioned above and I have figured out that the best movement in my case comes from:
Vsync set, No limited on Max FPS.
OK, excellent guys. I think I will stick with that. I have kept CPU usage to a minimum (1-2% on my machine) in order to prevent the fan coming on in people's laptops.
I am testing this with DanJetX however my concern was not limited to DanjetX because I have also seen it with Omega and DelphiX.
The views expressed on this programme are bloody good ones. - Fred Dagg
czar,
in the latest version of DanJetX (0.75) the timer has a Process procedure
where you can simply stick all your movement without worrying about
frame dependency (no need to multiply by any speed factor or calculate lags).
Let's say the display is configured for 100Hz. Frame 1 is displayed at t=0,01 and frame 2 is displayed at t=0,02.Originally Posted by czar
Now, say you are moving a sprite on the screen, frame 1 has just been drawn and you are drawing frame 2. If you use the system time, you will get a value between 0,01 and 0,02. If you use this value to calculate the position of the sprite, this will be sligthly off, and slightly unpredictable. The right value to use is 0,02 and not the value somewhere between 0,01 and 0,02 because t=0,02 when the frame will be actually shown.
@Dan: Right now I am doing it exatly like Czar does. If I want to use the new timer.process, what do I have to change in the movement?
Just move it let's say 4 to the right instead of move it 4*time_elapsed to the right?
Can this also be used for randoms? When I want my sprite to do something from time to time I use random(round(1000*time_elapsed))=0...Interesting thread this is
Firle
These jerks occurs when a videodriver performs a CPU-GPU syncronization.
You can force the syncronization every frame by reading one pixel from backbuffer or draw something via GDI.
Also sleep(10-30) after D3DDeivce.Present() may help.
All these methods have some FPS cost.
@Mirage - I haven't heard of this before - have you any idea where I could find more info on this? I will google it when I get to work.
The views expressed on this programme are bloody good ones. - Fred Dagg
Video card vendors usally publishing related information on their sites.Originally Posted by czar
http://developer.nvidia.com/page/home.html
Also forums on sites like gamedev.net are good source of information.
Bookmarks