By time or by frame
If you cap the framerate, do it somewhere around 100. To test that speed (presuming you don''t get that many FPS on your computer), just fake the time step value of 0.01 instead of whatever the real value is. The game will run in slow motion (or fast if you would normally get more FPS), but you''ll be able to see how floating error any other factors effect your game at higher ''framerates'' (smaller times between updates really).
Why not do both? Allow the rendering to go as fast as possible, but fix the logic framrate to something small, like 30 logic frames / second. This gains the advantages of both -- rendering will scale relatively well, while keeping the physics predictable.
The disadvantage of this system is not it''s accuracy; a fixed framerate is plenty accurate. It''s that you will have to stay one logic frame ahead of what you are presenting, so that you can smoothly interpolate between the current and next frame. This may seem a bit odd at first, but it is not complicated at all.
Setting the logic framerate to 30 frames/sec should barely be noticeable to the player. After all, the best human typists can''t type over 20 words a second, so the biggest logic bottleneck is human input.
The disadvantage of this system is not it''s accuracy; a fixed framerate is plenty accurate. It''s that you will have to stay one logic frame ahead of what you are presenting, so that you can smoothly interpolate between the current and next frame. This may seem a bit odd at first, but it is not complicated at all.
Setting the logic framerate to 30 frames/sec should barely be noticeable to the player. After all, the best human typists can''t type over 20 words a second, so the biggest logic bottleneck is human input.
Time-based is the best way to go now, so that there will speed cohesion on different machines but, the rendering does have to go as fast as possible, otherwise people who have been able to spend money on expensive graphics cards and processors will gain no benefit from their expenditure.
By allowing the rendering to go as fast as possible all movements on screen will have to be interpolated with the framerate at any given moment. e.g. if a character has to move 64 pixels in 1 second and you are allowing the program to update the render every frame then the character will move only one pixel per frame at 64 FPS and 2 pixels per frame at 32 FPS.
The equation for this is simple :
DistanceToMove / TimeToMove / FPS = MovementPerFrame.
This equation must be calculated every frame when the frame rate is changing every frame as we are suggesting here.
By allowing the rendering to go as fast as possible all movements on screen will have to be interpolated with the framerate at any given moment. e.g. if a character has to move 64 pixels in 1 second and you are allowing the program to update the render every frame then the character will move only one pixel per frame at 64 FPS and 2 pixels per frame at 32 FPS.
The equation for this is simple :
DistanceToMove / TimeToMove / FPS = MovementPerFrame.
This equation must be calculated every frame when the frame rate is changing every frame as we are suggesting here.
you can always use a rough timer, spaced every 60th a second, or whatever is your targeted FPS, but still keep a normal time-based movements, since those timers aren''t very accurate. On fast machines, they''ll still keep the time between updates roughly = 60 Hz. On slow machines, the timer won''t be able to keep up with 60 fps, but it won''t matter, since you are doing time-based movement anyway. That will reduce the load on fast processors as well, since they won''t update at insane framerates.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement