This might sound....noobie
How is it when I have a timer set at 1000 ticks a second it will achieve this rate when vsync is off on dxdraw but when vsync is on, the interval is still set to 1000 but runs at the refrsh rate (in my case 75 a second)?
I thought the screen was refreshed at this rate, why is the timer itself firing at different speeds? How can dxdraw/refresh rate have an effect on the timing of the timer/application?
Vsync makes graphics render same rate as your monitor to reduce flickering. Most of the games use framerates of 50, 60 or 75. What is needed interval for those can be count as 1000 / fps. Trying to render faster than 75fps does not make any difference to human eye, instead puts a heavier stress on graphics card and timer possibly to cpu aswell (if it doesn't utilize sleep or similar OS help).
I understand that, I have my own reasons for wanting it, but, why should the timer be reducing its tick events based on what the graphic card is doing?
Well that's the way TDXTimer was built. There are other ways of making game loops that can operate even without any millisecond limits for thousands of loops within second. Generally 30-40 fps already for physics and collisions aswell is enough to accomplish anything.
Offtopic: But out of curiosity, what is your program about?
Well I am not using tdxtimer, I am using threadedtimer
The game is pong, but as I sussed out from the outset, any frame based game will have problems with lower cpu/gcard power., So i always try in time based.
This has me ina problem because if I use NO vsync I haev set to 5 interval, I get 200 fps (since it is only pong) and time based ensures i get correct speed.
because of this DELTATIME is LOW, meaning the ball never comes close to not colliding. When vsync is ON, the limit is 16.6ms (16-17) deltatime and at the fastest ball speed of 1500 Pixels a second, the ball sometimes misses collision detection. Capping at lower than 16.6 will result in unfair advantage and lower speed for those using 60 fps with vsync.
Now if EVERYONES monitor was 100 hz, that would be deltatime of 10 and ebven capped at 15 (incase of slow down or pauses) the collision detection always works.
pong is a bad example since it is not cpu intensive, but you get my point. And time based movement with a 60 hz refresh causes probs when dealing with very fast moving sprites. That is why i want to update the positonal adn collision data as much as possible but only render when necessary, something i am unable to do
How do you avoid this problem when using time mased movement, or would you just stuff it and go frame based
ok, here is the cut of it....
In full screen mode WITH vsync the ball seems to always move at correct speed
In window mode WITH vsync it won't
Code:deltaTime := timegettime - lastTime ; lastTime := timegettime;
Interesting. I also have a question re vSync. In full screen mode, the fps changes directly to the screen refresh rate. If refresh rate is 75 the fps will also be 75 etc.
But, when using vSync, do I set the timer interval to 0 or do I set it to for example 1000 div 200? Will this have any effect? Anyway my movement is time-based so it should be the same on all pc's when using vSync?
Wake up from the dream and live your life to the full
mine is also time based and you will see, like me that you will have larger deltatimes in window mode...it just dosnt make sense to me!
I set to 200-1000 ticks/sec in my timer, which is probably overkill with time based movement and everything, but some people use realtime....It is a good question and I hope someone can answer that for us too.
I have been doing some tests and it seems I was partly mistaken. Deltatime and the timer itself ticking are not changing (I still fail to understadn why the timer is forced to 75 ticks a second when I set to vynyc but...)
The problem now is: In window mode time based with vsync, the ball is not running right speed if I cap the deltatime to say 17 (then I force it to have 17). In fullscreen mode, the ball jerks more but still matches the speed that was set....
I am thinking simply, that fullscreen mode means my game is able to run much faster but I cant be sure....I will send a demo some time i guess
From my experience fullscreen and window should be equally fast, but in fullscreen the difference is often in lower resolution or bitrate. Windowed mode uses bitrate of desktop and it cannot be overriden.
If you plan going realtime style (might also apply frame way), there is at least 2 options:
- Vector based collision:
Creates a line from old position to new position and checks for intersections to collide. On complex landscapes needs optimizations like quadtrees or other to be fast enough.
- Limited speed:
Lets say lagcount for this frame is 80ms. Assume it is known that game runs smoothly if lagcount stays at 50ms.. so it would split the tick into 30ms and 50ms. Generally physics count much faster than graphics code. Draw graphics separately after physics loops are finished, so do not include drawing code in loop below:
[pascal]procedure GameTick(LagCount: integer);
begin
while LagCount>50 do begin
GameTick(50); dec(LagCount,50);
end;
// Process game events here, and LagCount will never exceed 50ms...
end;[/pascal]
Posting Permissions
Reply With Quote
Bookmarks