Explain this to me (Delphix etc and timers)....

[seiferalmasy]

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?

[User137]

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).

[seiferalmasy]

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?

[User137]

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? :wink:

[seiferalmasy]

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

[seiferalmasy]

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:(


deltaTime := timegettime - lastTime ;
lastTime := timegettime;

[Wizard]

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?

[seiferalmasy]

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.

[seiferalmasy]

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

[User137]

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:

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;

[seiferalmasy]

well I poorly organised this thread, but I would greatly liek to know why vsync can make my timer seemingly slow down to the refresh rate (when i thought only render was affected)

[User137]

Well I am not using tdxtimer, I am using threadedtimer
What is threadedtimer? Maybe its source code reveals something that relates to refresh rate locking? If not, it might have something to do with operating system doing that for threads... no idea.

Whether or not your timer locks to fps depends on timer. They are all unique.

Some choices:
- Application.onIdle event
- TTimer
- Custom thread
- Manually created timer component
- Timer components provided with delphi game libraries
- While loop
...

Personally i use either manually created or TTimer.

[seiferalmasy]

yes, I have gone into it now and have found that its a waste of time trying to update faster than the refresh anyway....it just doesnt work very flush adn runs like a snail. The reason it changes speed is indeed because it is on the same thread. So, the vsync affects the overall timer speed:)

That out of the way my problem is now catering for time based movement at very fast pixel moves at a deltatime of 17ms (which would be the minimum at 60Hz)

At this speed, each sprite is skipping 26 pixels (1500*(17/1000) ) at each frame (enough to miss the object it is supposed to collide with)

I have looked over what you wrote adn what a few people have wrote, but sadly, I just don't understand fully the logic behind catering for this kind of scenario.


I will look further into it, and if need be supply a demo so that maybe someone can show me the light hahaha But, I have tried to do this in delphix but failed. This would be so so so much easier on a piece of fixed hardware...if only:)

:lol:

This is the kind of shoddy code I am working with (works great in non vsync mode though since deltatime is usually low on all computers)>> :oops:




deltaTime := timegettime - lastTime ;


if (Deltatime>15)then
begin
deltatime:= 15; //undesireable since those with 60Hz refresh (17 deltatime) will have an unfair advantage.
end;

lastTime := timegettime;
dx:=deltatime/1000;

I have now just extended the paddle by 5 pixels width, this will make sure it isnt possible for the ball to pass through at deltatimes of even 20 but it is a sloppy fix it has to be said