Sorry your browser is not supported!

Lo, back these many moons ago, I ventured to experiment with DB, and found it most supremely pleasing. ( http://www.geocities.com/Athens/5168/coding/db.html )

Then I discovered the gimbal lock (which later was solved by causing the roll/pitch/yaw commands to use quaternions).

In my pride, before the fix, I thought to create a library that would permit conversions from euler angles to quaternions, and hence create three new functions, quat_roll, quat_pitch, quat_yaw.

I found that there were great things that stood in my way. Though my memory fails me, I believe these were they.

DLLs could not be called (this one I know, has since fallen).
Arrays could not be redimensioned.
Arrays could not hold arrays.
Arrays could not be defined within routines.
Arrays could not be returned anonymously from routines.
No mesh deformations (height of mesh elements defined in a 2d array).

And in the face of these foes, I fled. I found another community, and I help there now instead.

I return now to ask the simple question: have these issues been routed, or are they still with us?

DLLs could not be called (this one I know, has since fallen).
Can do

Arrays could not be redimensioned.
??

Arrays could not hold arrays.
Types available in DB Pro

Arrays could not be defined within routines.
??

Arrays could not be returned anonymously from routines.
Arrays are global

No mesh deformations (height of mesh elements defined in a 2d array).
I think the clever people round here use Memblocks, which probably also fix a lot of the other stuff you mentioned.

So, if arrays are global, I'm guessing you still can't create a library of functions that will create arbitrary-sized arrays?

You'd have to define the arrays in advance in your main code.

That's the way it was when I last looked, anyway. There was a workaround where you could re-DIM the array to the size you wanted within your function, but that didn't solve the main problem, that the array still needed to be defined before calling the function, and the function needed to know the name of the array. This made stuff like passing a 3x3 euler-matrix to an array and getting a 4x4 quaternion array back was impossible. You couldn't even write a function to copy one array to another - had to do it inline wherever you did it.

More importantly, it ruins the whole point of writing libraries (not DLLs, but external files containing DB routines): to me, libraries are meant to be completely portable things that don't require you to know anything about their internals. Having to define a bunch of arrays before you can include a library that uses them completely breaks that transparency.

Types sound like they might make a big difference. There was no way to easily copy arrays - you had to loop through them and copy them element-by-element. Has a way of copying types been introduced in DB pro? And maybe a way of defining them in an included library file, instead of the main code? Or are types global, too?

Is there any online documentation on types, so I can learn more?

DLLs can now be called

Arrays can now be redimensioned with "UNDIM"

Arrays can hold arrays, I guess you mean ... "print array1(array2(1))"

Arrays can be defined within subroutines and functions, but are global, so yes, if you wanted a library of functions, the arrays defined in them would be accessable from the main code.

??? Sorry I don't know, but I think the other guy answered your question.

Yes, you can do mesh deformations and manipulate other media by using memblocks, although I don't know how.


There is also now a DBPro, which has a lot of advancements and if alot more professional than DB.