This didnt always use to be a problem in dgdk, only with later directx's has this come along. So their original tests are accurate. To not use DGDK just because you cant see a framerate above 60 is.. well, daft to use the nice word.
Take the word of long term programmers - you can create faster code with c++/dgdk than you can dbp. Its just that simple. As for the little test they gave: bare in mind to begin with that you are, by default, running in debugging mode with a debugger attached to your program. Their is a noticiable rise in fps for compiling a release build with the code optimisation setting switched to "speed"
Though to be honest I have no idea why they wrote their test code like that. The main reason DGDK is so much faster is that you have many more options in HOW you write your code - you have more power and more flexibility. The burden is on YOU to write FAST code however - you've got the tools, you just need to know how to do it.
A much faster way to write the same program they used in c++ is:
#include "DarkGDK.h"
void DarkGDK ( void )
{
dbSyncOn();
dbSyncRate(0);
dbMakeObjectCube(1, 10);
char szFPS[256] = "";
register int a, b, c;
int d;
while (!dbEscapeKey()) {
dbRotateObject(1, dbObjectAngleX(1) + 0.1f, dbObjectAngleY (1) + 0.1f, dbObjectAngleZ(1) + 0.1f);
for (a = 0; a < 100; a++)
{
for (b = 0; b < 100; b++)
{
for (c = 0; c < 100; c++)
{
d = rand();
}
}
}
sprintf_s(szFPS, 256, "Fps: %d", dbScreenFPS());
dbText(0, 0, szFPS);
dbSync();
}
}
This gives me 27 fps in debug mode. The slowdown here is the thousands of calls to "rand" (or originally dbRand) per frame. Its not the quickest calculation and thousands of times per frame is excessive! But still, using the flexibility of c++ to write that program in a slightly different way as shown above has already near doubled the speed.
Thats why dgdk is better.
