Sorry your browser is not supported!

Hey all, I'm not sure if this has been done, I assume it has somewhere, but Ive seen alot of thread where people have brought up the fact that in its default state, DarkGDK's syncrate is stuck to the monitor's refresh rate, usually 60.

I was playing around with some of the commands in DarkGDK 7.3(im not sure if they are in earlier versions or not) specifically :



and I noticed that when I called either command with the "int iVSyncOn" parameter set to 0, aswell as having :



in the code above the SetDisplayModeVSync call, would result in my syncrate, and this my FPS becoming uncapped...

There is a good and bad side to this, the good is that you can have your FPS as high as your machine can handle it(look at the screeny below to see an out of control cube rotating at 5400ish frames per second)... the Bad side is that you need to programatically control the speed of your code execution in a manner that is independant of the machine speed, so that it executes at the same speed on all machines, or as close is possible.

Here are some screenies :

Plain rotating cubes going hell for leather :





This is a scene with Shader Water, and Blend/Bump Map Shader Terrain, aswell as 7 lights floating around(using a sin curve) connected to spheres.



As you can see the FPS is well over 60 in all of those examples and they were all written in pure DarkGDK, those the first 2 have the extra overhead of some windows API calls as they are actually inside an MDI window

The FPS display in those examples is just a simple :
dbScreenFPS();
just before the dbSync() at the bottom of the main loop, and a dbText to spit it out on screen.

Hope this helps someone who didnt know how to uncap their FPS.

AFAIK the possibility to break the FPS limit is new in the 7.3 version.

I don't get why anyone would want fps that high... human reaction times make it pointless as input except for pro gamers, and obviously the monitor cant update the frame any faster than the refresh rate, even if the eye could see things that quickly, which I don't think it can.

Your right keeza, the human eye can only see around 120 frames per second anything more than that the brain cant pickup fast enough.

The point isnt really that you can have 5000 odd frames per second, its that you can run through you main loop 5000 times per second while you are calling dbsync() ..

That might mean that you can do alot more calculations before you bog the system down ?

And you are right, the human eye wouldnt get any benefit from a frame rate of over a hundred or so, and a monitor cant display any more frames per second that its physically capable of, but the machine can calculate more.. ive timed alot of my code before and the biggest holdup usually is the sync call to draw everything, although I am aware that there are workarounds to only call the sync command when needed or on a timer, I think this might be easier, just thought i'd share anyway.

I bet its soooo smoooth. would another good use be precision timers? a rate that fast could probaly allow for very accurate timing most probaly.

This capability has been there for ALL the versions that have had the "dbSetDisplayModeAntialias()" function.

Before then people would just disable the Vsync within the video card driver and use "dbSyncRate ( 0 );"

The big problem with disabling the V sync is that the game will suffer from screen image tearing, so one should never release a game under this mode.

The only use this mode can be useful for is to see how much unused capability still exists in the game code as referenced to the machine that you are testing the code on.
All my code development is done on a machine that I consider the minimum that my projects should be able to run on (sempron 2800+ - 754 pin, with a HD4350 or faster).
If I can optimize my code to produce faster than 60FPS then I know I can add more features or better quality features as the minimum level.