Sorry your browser is not supported!

Using the dbSetGlobalObjectCreationMode command certainly seems to add to the frame rate especially when using 3000+ objects but does anyone know why using the command seems to increase the exit time for a DGDK application from about 1 second to 40+ seconds?

hit the windows.h call _exit(0) if you have to - Quite sloppy - but - when you want STOP NOW - that works halfway decent

I ran a couple of tests using dbSetGlobalObjectCreationMode I noticed the exact time delay you mentioned in shutting down but I saw no increase in frame rate ( I had about 3000 spheres ).
I did activate the Task Manager and when dbSetGlobalObjectCreationMode is active and the program shuts down the CPU is very busy, possibly garbage collecting?

Do you have any documentation on this command I was unable to locate any

Codger

@Codger

Thanks for running some tests. I'm using the 3DWS 'Industrial complex' level in the tests which currently has over 3270 objects. A lot of these are various model meshes or clones of such, not simple primitives, so maybe that's making a difference. Currently I see an increase of about 7 fps by using this command. Not huge but useful with a level that is already pushing the engine regarding fps.

Like you I see my application exe taking about 50%+ cpu during the exiting phase.



Again, undocumented in DGDK but DBPro has the following:



It does indicate it's graphics card dependant so not everyone may benefit. I'm currently running a Gainward 7800GS+ (which is actually the 7900 gpu running on AGP).

I may be missing something here, but by sharing vertex buffers I'd have thought that would have made cleaning up afterwards actually faster not slower!

I have a silly theory about this linked to the number of objects "ceiling" and "High Object Count" etc.

If Objects are managed less than stellar - and the Global Option you mention now needs to managed a vertex buffer "sharing" cross reference table of sorts to handle it - I could definately see the rendering as faster - as the meshes would be used closer to how DirectX handles them - a mesh can be used anywhere where - over and over in one scene FRAME (and potentially not the next quite easily) but trying to "Clean These Up" Properly might be a linked-list-traversing nightmare.

sometimes in my own code - even though I take a lot of care to avoid memleaks, proper init and shut down etc... there comes a time for the "HALT" statement - which I translate as "Get Out Now, Forget Clean Up - Let the OS release the memory in one fell swoop - I'm leaving!"

I THINK because TGC owns the DarkGDK WinMain - there may be some sort of "If user code bombs, quits... whatever, its a child process... so lets let it go bye bye and then do our own clean up"

This is just a theory - but I think thats why no matter what you do - the WAITING at shutdown is worse than normal using this option.

Though it looks like its a really good option to use less the delayed "kill" thing.

I also notice big delays when I had a scene going with a lot of objects. Even killing it via the Debug+Stop All is slower (even looks froze for multiple minutes on occasion). Hence why I tie this to the object count "management less than stellar" theory.

Overall though - I like DarkGDK - you just need to learn the do's and don'ts the hard way.