Here are some quick how-to's of restoring functions DarkGDK that were broken by TGC. Fixes 1-2 are included in the current download at the top of this thread.
1. dbLoadAnimation()
2. dbPlayObject() and dbLoopObject()
3. dbSetObjectSmoothing()
4. dbLoadObject() - Now load .3DS models in seconds instead of half-hours!
1. dbLoadAnimation() - To include videos (avi, mpg, etc) in your games!
This has never worked in the history of DarkGDK! The reason is because the function dbLoadAnimation() function has no effect, thus rendering the entire animation library useless. This is very easy to fix!
1. Open the
Dark Basic Pro SDK\Shared\Animation\CAnimation.cpp file
2. Go to the function
CoreLoadAnimation().
3. Delete the first line that says
#ifndef DARKSDK_COMPILE, and its matching
#endif.
That's it. Animation (videos/movies) ability is switched on.
2. dbPlayObject() and dbLoopObject() - The ability to have your objects automatically animate at any speed you set.
Automatic object animation functionality was broken just prior to the 2010 release of DarkGDK. You can search the source-code for this comment tag (U75 - 080410) to see how and where it was broken. Basically a function UpdateAnimationCycle() needs to be called every time it syncs, but the call to it was overlooked with the changes.
To fix this:
1. Open
DarkSDKBasic3D.h from the includes folder.
2. Add the prototype:
void UpdateAnimationCycle (void);
Do
this if you're wanting to correct it in the source code:
3. Open
Dark Basic Pro SDK\Shared\Core\DBDLLExtCalls.cpp.
4. Find the function:
SetDBDLLExtCalls().
5. From there, search down for
UpdateAnimationCycle. You'll find it within a block of code that falls within
#ifndef DARKSDK_COMPILE.
6. Go down to the next block of code after the
#else, and just after the
g_Basic3D_PassCoreData is set, add the following line:
g_Basic3D_UpdateAnimationCycle = (RetVoidFunctionPointerPFN) UpdateAnimationCycle;
do
this if you're just doing this within a DarkGDK project, if you don't have the source code:
3. Add this in the main loop just before calling
dbSync().
That's it. Automatic object animations are reinstated.
3. dbSetObjectSmoothing() - This is to create normals for your object so that when the light hits it, the mesh of polygons will appear smooth.
First of all, there are 2 versions of this function. One where you set a
float fAngle, and the other where you set an
int iPercentage. I have no idea why they say you can set an angle, because the source code takes that "angle" and treats it as a percentage. Angles refer to a lower-level scope than this. In fact the prototype of the function that deals with it calls it a
float fAngle, and the function itself calls it a
float fPercentage. So the prototype needs to be corrected there.
So you may as well just delete the fAngle prototype of the
dbSetObjectSmoothing() and use the percentage version only. Or if you'd like to use float fPercentage instead of in iPercentage, then delete the percentage one and correct the angle one to say percentage.
This function
dbSetObjectSmoothing() was broken in the
140306 revision, so it's quite possible this function has never worked (at least reliably) in the history of DarkGDK! The error was in the commenting out a necessary vertex update function, saying it was not needed for changes in normals. Well - yes it is!
1. Open CObjectsC.cpp.
2. Go to the function
SetSmoothing().
3. The last line in the function is a commented-out call to
UpdateVertexDataInMesh ( pObject );. Un-comment-it-out.
4. As an aside, in
SetSmoothing()'s inner function
SmoothNormals(),
dwSharedVertexMax is set to 32. Then a hard
32 is used a little further down to prevent a memory overflow. That hard
32 needs to be replaced with
dwSharedVertexMax. Also in a model I'm testing all this with, it exceeded 31, so I changed the 32 to a 64, which was high enough for it. ...just something to consider. Its purpose is to pre-allocate the maximum amount of memory that may be used for the normals. It's just a local function-wide allocation, it's freed at the end.
If you're not using the source-code, you can call this function manually in your DarkGDK projects:
1. First, add its prototype to your project:
void UpdateVertexDataInMesh(sObject* pObject);
2. After your call to
dbSetObjectSmoothing(),
3. Call the new function with a pointer to your object:
sObject* objectPtr = dbGetObject(objectID);
UpdateVertexDataInMesh(objectPtr);
The loading of .3DS models has been ultra-slow in the EXTREME! 20-60 minutes per model!! This was due to the use of the stdio function strcat() for building a 50MB array, just a few characters at a time. I you've ever opened a .3DS file in a text editor, you know it's a regular text file. What strcat() does ~each time~ it's called is it searches from the beginning of the char* array for a NULL terminator, then copies the source string at the end, thus concatenating the two char* strings into one - in this case to build a very long string, one element at a time.
What I did was crude and quick - just to get it working for practical purposes. But here's how I did it:
1. I opened Conv3DS.cpp.
2. I created this function, and put it near the top of the file:
inline void StringAdd(char*& dest, char* source)
{
dest += strlen(dest);
strcpy(dest, source);
}
3. There are several functions that repeat the following command:
strcat( m_szData, szTemp );
Sometimes instead of szTemp, a direct string is used, but these all take the form:
strcat(m_sdData, [some text string here]);
I did a Find & Replace for
strcat(m_sdData, (you have to include the right number of spaces), and replaced that with
StringAdd( local_m_szData,
So a call like
strcat( m_szData, szTemp );
becomes
StringAdd( local_m_szData, szTemp );
4. At the top of each function where I now call
StringAdd with
local_m_szData, I define
local_m_szData as follows:
char* local_m_szData = m_sdData;
All this does the same function as the strcat() calls, except that the
local_m_szData is a pointer to the last element added rather than the entire beginning. Thus the NULL terminator is always very close instead of tens of millions of bytes away! It's actually practical now to load .3DS models. Although as with .dbo files, high polygon models do take a while to load. But no longer due to wasteful use of text copying commands. Normally I'd prefer the fix to be a little cleaning - I just wanted to do something fast for the time being, just to get it working.
Q: ...you mean computer imagery was still based on the paradigm that the world was flat? Even into the 21st century??? Talk about doing something the hard way!
A: Yep! Back then people would render simple shapes with complex meshes of thousands of flat little triangles. Next to the bottleneck processors they used, it's the main reason why their computers were so slow. In the last days of the religious atmosphere of centralization and trade, corporate dogmas had people believing that flat was faster.
