I finally had time to play a bit more win dgsdk this week and I came across some fairly straightforward problems as well as a couple of API limitations, so I thought I'd drop them here for the developers perusal.
First the bugs:
1) If I invoke dbSetDisplayMode() (regardless of the parameters, even if app remains windowed), loading .X files stops loading the meshes textures automatically.
E.g. the code
dbLoadObject( "miko.x", 1 );
displays a textured miko with no dbSetDisplayMode(), and a "white" miko if dbSetDisplayMode() has been previously been called (no other changes in the code).
In the later case I need to do
dbLoadObject( "miko.x", 1 );
dbLoadImage( "miko.TGA" , 1 , 0 );
dbTextureObject( 1, 1 );
to get a textured miko.
2) If you ALT-TAB a full screen application and the ALT-TAB back, the application is dead: you just get a back screen, per-frame background cleaning is no longer working (text is written over text) and all the models are gone. Must properly restore DX surfaces and context on ALT-TAB.
3) Object frame counts seem to be screwed up. Calling dbTotalObjectFrames() gives unexplicably high results, forcing you to find acceptable values for dbSetObjectSpeed() and dbSetObjectFrame() by trial and error.
4) Mentioned proviously by me: You can't get CPU shadows on a Radeon 9200 using dgsdk (tried dbpro 5.8 samples, same there and GPU shadows also don't work). These are available on this very same hardware using virtually all other engines (i.e. it's not a hardware or drivers limitation).
5) I believe someone has mentioned this already but while the precompiled version of the FX sample works like a charm, if you recompile the sample all effects except for bubble.fx crash the app, and even bubble does nothing (i.e. it won't crash but you don't see the mesh onscreen either).
API Limitations:
1) The only way you can obtain (i.e. read-back) an object's orientation seems to be through dbObjectAngle* functions: This sounds unecessarily limiting because you have to keep doing maths when the engine is sure to have thin info in vector/matrix format internally. There should exist either as:
a) something like dbObjectFacing* to get the fwd vector directly
b) better: the hidden dbGetObjectWorldMatrix() (see DarkSDKBasic3D.h) function should be extended allow one to get a full object's matrix, not just a limb in an object's
c) most orthogonal: there should exist a 3DMATHS function that loads a matrix with an object's matrix, something like
dbSetObjectMatrix4( int Matrix4, int iObjectID )
2) This is a "good to have" rather than a must have, but including quaternion support in GD would be great. We can always use D3DXQUATERNION but a native solution integrating in 3DMATHS is always cleaner.
3) I mentioned it elsewhere, but we need an AVAILABILITY EXPRESSION to detect the non-existance of shadows in the hardware so that we can revert to a blob on the floor hack.
I would have posted this to the DarkGameSDK bugs thread but since my posts for some reason never appear in the latest post or bump a thread timestamp up, no one would even read this. I don't know if this odd forum behaviour is due to my posts still needing approval or not (neither the moderators nor the forum support people seem to know for sure).
Incidently, I'm sure that joining the Masonry is easier than getting posting clearence in this forum... I've been posting for over a month inc. answering other people's questions and I'm _still_ penned.
