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 / Back to low frame rates

Author
Message
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 14th Jul 2008 21:20
I just ran a test on my work machine using a utility I (re)found on my machine. It can be located at

http://www.ozone3d.net/gpu_caps_viewer/

It gives me the ability to test my FPS with and without VSYNC turned on. With it on I get the usual 60-61 FPS while (re)drawing a rotating toroid. If I turn off VSYNC I get well over 700 FPS. I don't suppose GDK allows for turning off the VSYNC.

And before everyone thinks I've got OCD over this, let me explain my concern. Some of you may have looked at the test phase of the Arkanoid clone I've been working on. Eventually I'll have to start looking at collisions between the ball and the capsules. Depending on the speed of the ball, which can be variable depending on game level and power-ups/downs, a low frame rate means the ball has to skip displaying a greater number of pixels. This could mean that the collision isn't detected until the ball is either well inside the capsule, which makes for poor bounce realism, or the ball is past and through the capsule without registering a collision. Either way, it's not desirable.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Mahoney
16
Years of Service
User Offline
Joined: 14th Apr 2008
Location: The Interwebs
Posted: 14th Jul 2008 21:24
You can force it off in the driver control panel. I've heard from others that this will take away the limit.
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 14th Jul 2008 21:27
But how do I control that on someone else's machine on which my game might be installed?

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Mahoney
16
Years of Service
User Offline
Joined: 14th Apr 2008
Location: The Interwebs
Posted: 14th Jul 2008 22:13
As far as I know, that's beyond the control of the GDK. You might be able to with raw DX code. But, you'd have to ask Jason or someone else who knows DX about that.
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 15th Jul 2008 11:39
If a persons machine is not powerful enough to run your game at the rate of the Screen Vertical Sync (with VSNC enabled), then disabling VSNC will do nothing to help.
That machine will still be too slow.
It will not run any faster.
Phoenix73
16
Years of Service
User Offline
Joined: 27th May 2008
Location: Australia
Posted: 15th Jul 2008 16:07
I agree with sydbod. Perhaps you should look at predicting the collision based on vector maths or ray casting or something. That way you won't miss a collision if the frame rate drops.
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 15th Jul 2008 17:18
Quote: "I agree with sydbod. Perhaps you should look at predicting the collision based on vector maths or ray casting or something. That way you won't miss a collision if the frame rate drops."


Catch 22, that. Having to add the additional checks is only going to add to the computational overhead and thus impact the frame rate even more. I've got a 2.1 Gig processor. It shouldn't be having problems keeping up with 2D graphics.

The main question is, if I can't use dbSync to guarantee a consistent frame rate, then how to I not only code for non-syncable workstations, how do I test the code with only two workstations?

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 16th Jul 2008 08:41 Edited at: 16th Jul 2008 08:45
Quote: "The main question is, if I can't use dbSync to guarantee a consistent frame rate, then how to I not only code for non-syncable workstations, how do I test the code with only two workstations?"


That has been a question that I have not seen answered to my satisfaction either.

What I am now looking at is to have a check in my game code that keeps a look at the instant CPU usage that the game is running at on a frame by frame basis.
This way the code can see when it is about to run too slow and can adjust itself accordingly (decrease detail or whatever).


Should you be interested, here is a code demonstration of the CPU usage monitoring routine and where it would couple into a game.
It is basically material from another persons work, that I chopped down to its simplest form to make it easy to use.




It will compile and run easily for testing.

This following part will cause a divide by zero error if the game loop runs too fast so it will require a little modification to make sure that does not happen.
Phoenix73
16
Years of Service
User Offline
Joined: 27th May 2008
Location: Australia
Posted: 16th Jul 2008 12:08
I think that the vector math collision could be implemented INSTEAD of sprite collision - hence it would not be additional overhead. You could just use the redraw loop to update the sprite positions based on vector calculations and the elapsed time. You might even be able to put the calculation routine in its own thread. I am thinking of something like this for my own game so I can use all my cores and double my available processing power. Using only one thread is effectively only using half the power of a modern computer.
Phoenix73
16
Years of Service
User Offline
Joined: 27th May 2008
Location: Australia
Posted: 17th Jul 2008 04:48
To quote myself:

Quote: "You might even be able to put the calculation routine in its own thread."


I decided to put a demo together to test this theory. I have written a quick multi-threaded demo that simulates simple collision detection in one thread and leaves the object redraw and keyboard input in another thread.

Here is the code:



Basically what this code does is create a thousand cubes, spins them around randomly and detects (very simply) if they are touching one another, in which case they are randomly moved.

If you run the code as-is it is in multi-threaded mode. For comparison of this code running in a single thread, just comment out the line:

#define MULTITHREAD

You should see at least about a 15% increase in frame rate on any hyperthreaded Pentium 4 and about a 30-40% increase on any dual or quad core CPU.

Although this is a simplified example, it does prove my point that there is more CPU power to be gained by employing threading and moving the collision etc to its own thread.

As this pure mathematical calculation does not utilize any of the DarkGDK functions, there should not be any thread safety issues.
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 17th Jul 2008 10:20
Hi Phoenix73, Just a quick question as I have never even looked at multithreading.
Your code fragment is worth its weight in gold.....thanks.

Quick question, the way you have it set in the code it looks as if the "RecalculateSpheres()" function will not be run the first time through the game loop but will run fine from then on through successive loops.

Should it not be:
//hEvent1 = CreateEvent( NULL, FALSE, TRUE, NULL );
//hEvent2 = CreateEvent( NULL, FALSE, FALSE, NULL );
hEvent1 = CreateEvent( NULL, FALSE, FALSE, NULL );
hEvent2 = CreateEvent( NULL, FALSE, TRUE, NULL );

Or am I miss-reading something?
This is interesting stuff....thanks
Phoenix73
16
Years of Service
User Offline
Joined: 27th May 2008
Location: Australia
Posted: 17th Jul 2008 10:29
You are probably right sydbod - I don't normally do threading in C++ (I use C# all day).
Phoenix73
16
Years of Service
User Offline
Joined: 27th May 2008
Location: Australia
Posted: 18th Jul 2008 03:24
I just killed off all the extra processes on my computers and found that there is actually a bigger gain in frame rate using the multi-threaded version of the code.

Extra processes do not affect the frame rate of the single-threaded code as they are only using one core and extra processes are pushed onto the alternate core.

Now it seems that on the Hyper Threaded Pentium 4's I am seeing over 35% frame rate gain and on the Core 2 Duo I am seeing an increase of over 80%.

Obviously this gain will be dependent upon how CPU intensive the collision and tracking routines are, but this does show that most modern CPU's have a lot to offer games programmers once we leverage multi-threading.
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 18th Jul 2008 19:06
Also of interest, after running your test sample in multi threaded mode and single threaded mode, on a single core CPU, there appears to be an insignificant speed penalty running the threaded version of the code.

It has convinced me that I should rewrite my code in coarse multithreaded form no matter what CPU the code will run under.
Will probably only require 4 threads for what I am trying.
Phoenix73
16
Years of Service
User Offline
Joined: 27th May 2008
Location: Australia
Posted: 18th Jul 2008 19:35 Edited at: 18th Jul 2008 19:40
The reason that there is only a small performance penalty on a single core CPU is because threads are much more efficient than processes - they are more lightweight and have less overheads. With the chips coming out soon, any single threaded program will suffer a massive penalty.

Login to post a reply

Server time is: 2024-09-30 03:27:36
Your offset time is: 2024-09-30 03:27:36