Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / FPS Locked to 60?

Author
Message
tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 16th Aug 2007 07:24
Hi,

Can someone please explain to me why my FPS for this simple program is capped to 60? I have even forced V-Sync off in my drivers.

Using PIX I saw that there are 100+ SetRenderStates. If I remove the dbSync() I get an average frame time of 1ms, which equates to 1000fps, but obviously dbSync() is needed if I want to display anything. dbSync() seems to take forever, even though I used dbSyncRate( 0 ).

Thanks in advance.

#include "DarkGDK.h"

void DarkGDK( void ) {
dbSetDisplayMode( 320, 240, 32 );
dbSyncOn( );
dbSyncRate( 0 );

char szFPS[ 32 ];
while( LoopGDK( ) ) {
if( dbEscapeKey( ) ) {
break;
}

dbCLS( );

sprintf( szFPS, "fps: %d", dbScreenFPS( ) );
dbText( 0, 0, szFPS );

dbSync( );
}
}
psx
17
Years of Service
User Offline
Joined: 16th Apr 2007
Location:
Posted: 16th Aug 2007 08:56
You should first try the ForumSearch to find out if this topic already discussed. And it was.
The answer is that this is a bug in DGDK.
It locks the FPS to your monitor's refresh rate.
James Bondo
18
Years of Service
User Offline
Joined: 12th Nov 2006
Location: Denmark
Posted: 16th Aug 2007 17:21
I can get serveral 100s fps on DGDK.NET by forcing V-Sync off.

Using Dark GDK.NET
tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 16th Aug 2007 17:59
@psx
Your answer doesn't agree with James Bondos. Also, I can set my monitor's refresh rate to 59, 60, or 75. Changing it to any of these has no effect.

@James Bondo
Can you describe how? Am I missing something?
CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 16th Aug 2007 19:26
I thought I remembered hearing that it being an lcd monitor vs a crt had something to do with it - although I could be completely imagining that...

My DBP plugins page is now hosted [href]here[/href]
James Bondo
18
Years of Service
User Offline
Joined: 12th Nov 2006
Location: Denmark
Posted: 17th Aug 2007 10:17
My monitor is LCD running at 60Hz.

Its quite some time ago i tested it. As far as i remember, i made a program to test the speed og the .NET interop layer because i had some serious slowdowns after converting some DBPro code to DGDK.NET. So i needed a controlled test and i made an empty program and i exceeded the 60fps by serveral lenghts.

http://forum.thegamecreators.com/?m=forum_view&t=95496&b=22

Using Dark GDK.NET
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 22nd Aug 2007 21:12 Edited at: 16th Sep 2007 17:36
Ok, so you're stuck at 60fps. I understand this is not desired, but I'd suspect you are still at least enjoying code that runs WAY fast while the screen isn't being rendered right? I'm not meaning to sound sound smart - its just I understand that the sync() call is where all the DarkGDK/DirectX stuff does its thing - and for whatever reason you've hit the glass ceiling - but 6-fps [edit] I meant 60 FPS[/edit] is not bad at all providing the other code is still whipping along each loop.

...that is... I'm hoping you have plenty of available CPU to do actual game code without losing your 60fps anytime soon.

Best of luck. (I want to convert Iron Infantry but this could be a showstopper. I won't start the conversion unless I know I'll reap speed benefits... (After writing fairly optimized code of course) Though there should be speed increase even with a bit-o-slop I would think compared to DBPro native.

tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 22nd Aug 2007 21:31
Hi,

Actually it's quite the contrary. The rest of the code gets stuck waiting on the dbSync() call to do it's work, and therefore ends up running capped at 60fps which is not desirable.

I don't know what DarkGDK could possibily be doing to take so long, either it's not in immediate mode or it's wasting time on purpose. In either case, I wish it wasn't.

I'm open to hear if theres some code or setting I missed, but until then I'm not satsified with the performance of dbSync().
Daggeth
17
Years of Service
User Offline
Joined: 3rd May 2007
Location:
Posted: 22nd Aug 2007 23:18
tparkin is correct, after your code is done executing, it calls the dbSync() command, and the sync command waits (to ensure a 60FPS cap) and then the rest of your code can go along.. now, what you *can* do is remove dbSync() from the main command loop and call it once every few iterations of your main code. This would allow you to run your non-rendering code (say pathfinding, physics etc) very much so faster... but I see no point in doing that.

60 FPS is more than your eye can handle anyway and you have a huge buffer before your CPU starts impacting game performance.
James Bondo
18
Years of Service
User Offline
Joined: 12th Nov 2006
Location: Denmark
Posted: 23rd Aug 2007 01:48
This just popped in my head.

Couldnt you just make a seperate thread that did nothing but call dbSync()?
The main thread would do all the work, while the other thread just synced as fast as it could, 60fps (or the other way around).

Using Dark GDK.NET
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 23rd Aug 2007 02:42
That is a great idea to try for anyone willing to give it a go. I've done multi-thread coding myself but not in C++. Only in FreePascal.

The only possible hiccup is that no where have I read DarkGDK as being threadsafe.


This MIGHT Mean that it would choke terribly if you did this without syncronization.

Basically, I've been able to make SOME things that shouldn't work with multi-threading work and sometimes its impossible.

Plausable #1
The trick MIGHT BE to Make the SYNC thread set a Global Boolean to TRUE whenever it knows its ABOUT That Time to Call Sync Again. then your main loop would set another Global as OK GO. Then your main program would loop on Sleep until a third Variable from the sync side said All done.
You need separate variables for each step so there is minimal "collision" otherwise you need Serialization code.

More Plausible #2:
Multi-threading is great but it has overhead. Your CPU executes more commands then you think inorder to switch tasks - and it does this constantly. Put Old MS-DOS on a Pentium 4 and see what speed really is! Anyways, the idea of looping and only syncing when 16.6 milliseconds has passed (or more) makes more sense and gives your CPU more time to work on your game versus taskswitching. Also, this method would help on a superfast machine and on a slower machine would act like it wasn't even implemented because every loop it would have been enough time for another sync anyways.

I'd go with this method. 100 FPS is sweet.. but the whole human eye thing.... besides - If you get 200 FPS... you need to consider adding more stuff to your game anyways!




jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 9th Sep 2007 04:23
Hey, I just located the option in my NVIDEA Setup to toggle a flag that forces the sync rate to stay locked at 60 or not. It WARNS about Tearing as if my monitor will actually rip. My tests showed it was a pretty good increase in FPS (if I wasn't bogged in CPU stufvf for other things) It jumped to 340FPS ina test cube demo thing - I never got that high before! (That was in DarkGDK) DarkBasic Pro gave like 202 or something max - same test - a cube and a FPS display.

Ravenal
17
Years of Service
User Offline
Joined: 18th Sep 2007
Location:
Posted: 22nd Sep 2007 01:57
I still have this 60FPS and It drives me nuts when DBP can go up to 320+ with the exact same code.... GDK or DBP...
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 22nd Sep 2007 05:43
Dude - Are you full screen or in a window? Other than a video card setting which I think you are aware of - the only other 60fps locker I know of is running in a window with the regular windows UI versus using full screen. Windows pretty much sticks to the VSync Rate of the monitor.

Login to post a reply

Server time is: 2024-11-19 16:35:53
Your offset time is: 2024-11-19 16:35:53