Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Fake Physics - Play around with different placements of commands :]

Author
Message
skull driveshaft
16
Years of Service
User Offline
Joined: 4th Jan 2008
Location:
Posted: 19th Jan 2008 09:37
Like many before me, I have been banging my head on the keyboard at times trying to figure out what the collision commands in DGDK are really doing - and which commands can be used in conjunction, and which ones just slam your logic down.

Here is something I wrote while trying to understand what in the world these blasted commands are doing.

You will notice that there are quite a few commands in the declarations of DGDK that are not documented at all.



The other mystery for me is dbSync() - It took me some time to find the right placement for it - I would still like some suggestions on how to optimize this code to make it execute smoother.

why doesn't it work the way I want it to!
tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 19th Jan 2008 19:39 Edited at: 19th Jan 2008 19:40
Hi,

Thanks for sharing your tests, it's pretty neat!

I've made some changes which improve the performance:

Replace your main loop with this:


The problem was you were calling dbSync() 2 (or maybe 3) times during one loop. Each time you call dbSync() it will redraw the screen. You only want to this (at most) one time. Sometimes when you need to do more processing you will only call dbSync() once every 2-3 frames but a general rule of thumb is to call it at the end of your main loop.

Edit: Also I should mention that I added a for loop to process every object in one loop. The reasoning for this is so that when the screen gets redrawn (dbSync()) the user will see the effects of collision on ALL objects not just one. Previously it would look like it was running slower than it actually was because each redraw only one object was showing it's effects of collision. I hope that made sense.

Hope this helps.
Pixel Perfect
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 20th Jan 2008 00:54
Great demo skull driveshaft!

No matter how good your code is, someone will improve on it
skull driveshaft
16
Years of Service
User Offline
Joined: 4th Jan 2008
Location:
Posted: 20th Jan 2008 10:58
Quote: "Hi,

Thanks for sharing your tests, it's pretty neat!

I've made some changes which improve the performance:

Replace your main loop with this:"


Thanks to tparkin for the insight - I made some changes, and here is what I came up with



Notice that I have thrown in another sphere for greater effect.

The other thing that I came across was that using other objects, like a box, cube, cone, pyramid, plain, cylinder, or triangle, the visual appearance was not great at all.

Using the ShowObjectBounds function illustrates why the collision is not really working that well.

I removed the AutomaticObjectCollision from the first 2 Spheres - they are not going anywhere, so don't require the code, you will notice that if you do put it in, it moves the placement of the second object to ensure overlapping does not occur.

I added the SetObjectAmbient to each object as well, I don't know if that has an effect on the FPS at all.

And thanks to Pixel Perfect

why doesn't it work the way I want it to!

Login to post a reply

Server time is: 2024-09-29 09:19:43
Your offset time is: 2024-09-29 09:19:43