Quote: "DirectX locking system "
Do you mean locking vertex/index buffers ? Doing that alot is something that is not reccomended for efficiency reasons. Locking and unlocking vert/indice buffers is an expensive operation, just something to keep in mind, perhaps a profile to see if you are actually getting an advantage from it would be a good idea. When I say profile, I dont mean FPS with locking versus FPS without, you would need to take into account time elapsed per lock/unlock operation, and other things like that, the time that your cpu spends calculating is the important thing.
That said, im sure that you would see some increase in speed, the operations may be expensive in terms of cpu processing, but not doing it at all is probably more expensive lol (of course, throwing it all at the GPU and saying "you do it" would be faster again lol)
The above was part of the reason I settled on doing most of my work on the GPU, you take the need to lock and unlock vertex buffers out of the equation, increasing efficiency and removing one of the fixed function bottlenecks. The rest of the reason was due to efficiency of GPU vs CPU for this kind of calculation(with GPU's winning hands down), and my own personal preference of course lol, as there will be no fixed functions pipeline in the future(dx10+ has none, its all programmable) I figured now is as good a time as any to learn lol
Quote: "That method WORKS with GDK. But now doesnt do a thing to DBPro"
Unfortunately thats correct, the dbGetObject() command is only available in GDK, it returns a pointer to the sObject, which is basically the DBO structure of the object(have a look at DBOData.h to see the actual data you can get at with the sObject pointer) I dont know DBPro well enough to say if there is an alternative way to get at that data from DBPro itself, but I would assume you would be able to get at the object's internals somehow.
The other option would be to have your code setup in such a way, probably using pre-processor directives, to compile one way for DBPro and another for GDK(you probably already have something similar by the sounds of it). You could have the compiler use the commands that work for GDK when its being compiled for GDK, and the others when its being compiled for DBPro...
The pre-processor conditionals would be one easy way to get it implemented, though you would probably have to refactor your code slightly, another would be to wrap the commands in your own "blitzterrain" version in seperate headers, so, one include for GDK, one for DBPro... they both have the same functions by name(BT_SetObjectMask() for example would be named the same in both includes, but its implementation would be different in each include) but depending on if you are compiling for GDK or DBPro would determine which of the 2 includes to use(again a simple pre-processor directive could be used to determine which to include).
If it ain't broke.... DONT FIX IT !!!