Sorry your browser is not supported!

The technique used to check for collisions can really drag down your framerate. The fact that you ALWAYS have to loop through all of the current collisions is very slow. In my Janger game, I just want to check the collisions of game pieces against the table for playing velocity related sound effects for example. It would be very nice not to have to run the while loop with the

while (phy get collision data( ) = 1)


command, but rather just check discreet collisions myself. It brings the framerate in my game from 400+fps down to 90-120fps just running the while loop for collision data and nothing else. Not executing the collision while loop the framerate stays up at 400+. This is still of course an acceptable framerate but means that there is a lot less room for adding in additional graphics effects. And not to mention it seems to throw the framerate all over the place depending on how many objects are touching. (but of course I'm doing framerate throttling to keep the framerate constant. But I have a lot less to work with, it could be dramatically improved with a better design...)

Why not allow the programmer to be able to ask for specific collision data (like Newton Dynamics allows you to). I can't imagine that Ageia doesn't allow for this sort of faster approach.

If I wanted to add in all sorts of other background objects in my Janger game which I don't care about checking collisions on, because of the way your system is setup (the while loop, checking every collision every frame) it forces the while loop to run much longer and it drags the framerate down to a crawl.

Please give us more options here.

Thanks,
-=VRMan=-

I agree, alot of the commands in DP 'work' but have no practical use in a game enviroment, and this definently needs to be looked at.

If you need to check for seperate collisions try to use the "DBP Collision DLL v2.0" ( http://forum.thegamecreators.com/?m=forum_view&t=74762&b=5 )!
(You probably use them already, because you all are longer familiar with DB-Pro than I'm!)

I used it in my game for the DP-Software-Mode-Comp, because the original DP-Collision-System was not aviable in the DBPro-DP-Demo!

It worked very well I must admit! (The reason why my game was sooo slow is, that I used the normal "Text"-Commands from DB-Pro, I changed that to "D3D-Text"-Commands and it runs now about 50% faster!)

I hope they put something like that into DP, so that you can use it without the need of additional DLLs!

(Good luck for you two, if you take part in the Hardware-mode-Comp!)


Hoozer

I'm using sparkys dll but the collision meshes don't get updated every loop, and updating them manually is rather slow, so it's impractical for many objects.

Because my (simple) game used only primitives, I didn't know this fact! (I will keep that in mind, thanks for the info!)


Hoozer

Here is another suggestion for an improvement to DarkPhysics:

The command:

phy set auto fixed timing

is great (and should be used in almost every DP program people make) in that it will keep your simulation running at the same simulation rate no matter what the framerate. But it becomes obvious that you are using the internal DBPro 'Screen FPS()' to adjust the timing ( 1.0/Screen FPS() ). Unfortunately (screen fps was designed in an optimized manner in regards to displaying it on the screen) screen fps only updates it's value every second or maybe it's every two seconds at times. So the phy set auto fixed timing works but when your framerate drops from say 400 to 70 (God forbid hehheh) it takes a literal 1000ms for the timing of the physics system to adjust. This of course ruins the whole point of the command and makes your simulation jolt forward at blinding speed for a whole second or two (which is a very noticable long time).

Now I know you can adjust the timing values yourself using an elapsed time calculation (that's what I do) and still get this benefit correctly, but why doesn't Dark Physics do this internally to make phy set auto fixed timing a very useful command?

Just trying to help improve an already excellent product

Best regards,
-=VRMan=-