Patch 1015

Mar 23, 2008 at 3:20 PM
I uploaded patch 1015 for all to preview.

Change Notes:
  • Updated PhysX assembly to properly support unmanaged resource. I was not aware previously that C++/CLI destructors actually compile into Dispose() methods. Now all physics objects inherit from IDisposable and require manual disposing. This change also affected QSGame/Scene/SampleScene. They all properly dispose of the physics resources now.
  • Included JigLibX physics backend. This is about 90% feature complete compared to the PhysX backend. The only omissions are tri-meshes and some of the getters for actor, like mass/density. This is important for those not wanting to use a native library, want Xbox support, or just don't want to install the PhysX system software. Be warned however that the performance difference is quite large for busy scenes!
  • Since the JigLibX backend is functional, the Xbox version now compiles and runs again! The Xbox project/solution files are updated and should compile/deploy/run successfully.

To switch between PhysX/JigLibX, you will need to modify the configuration.xml file in the QuickStart project, and rebuild the project.

The configuration.xml file defaults to JigLibX:

    <!--<manager value="QuickStart.Physics.PhysX.PhysXPhysicsManager, QuickStart.Physics.PhysX" />-->
    <manager value="QuickStart.Physics.JigLibX.JigLibXPhysicsManager, QuickStart.Physics.JigLibX" />

To use PhysX, just move the XML comment to the other line:

    <manager value="QuickStart.Physics.PhysX.PhysXPhysicsManager, QuickStart.Physics.PhysX" />
    <!--<manager value="QuickStart.Physics.JigLibX.JigLibXPhysicsManager, QuickStart.Physics.JigLibX" />-->
Coordinator
Mar 23, 2008 at 3:56 PM
Very cool to see work getting done again Shaw. Thank you.

I won't be back in town until tomorrow, after work I can do a review if you need. Not sure if I'll be as thorough as Sturm though. :)

I'm hoping tomorrow or Tuesday to get the input polling system ready for review.
Mar 23, 2008 at 5:10 PM
I just wanted to get this posted up on the site. I've had the JigLibX backend done for weeks now, I just didn't have the time to clean it up. I also found the memory error in the PhysX assembly, so everything should be cleaning up now as long as Dispose is called on the physics objects.

My focus now is on the scene manager implementation, and the threading implementation. I want get a prototype of a task-based multi-threading system implemented soon to see how it works out. It'll be nice to have your input polling code in, as that would be a good test to see how well the new system will work.
Coordinator
Mar 23, 2008 at 6:45 PM
Pending the scene manager implementation and entity heirarchy I will likely clean and finish up the camera system. I'd like the system to work through messages as much as possible so anything that needs a camera doesn't require it as a dependency.

For example the rendering system needs the current camera, game play will likely need it, scene editor will need it, etc. Those systems shouldn't require a dependancy on it. For example the scene editor could simply instanciate a camera of scene editor type through a message, and then send it any movements required. As I've done before, I'll assure you I've done this type of thing, and that it works great. I'll be able to prototype something simple for review before I go through with an entire system though.
Coordinator
Mar 27, 2008 at 4:23 AM
Shaw I'm having some issues compiling the JigLibX code. Here is the error:

Error 5 'QuickStart.QSActivator' does not contain a definition for 'CreateBaseManager' C:\Users\Nic\Documents\Visual Studio 2005\Projects\QuickStart Engine v0.19\framework\code\Common\Configutation\ConfigurationManager.cs 157

I cannot find CreateBaseManager in QSActivator, are you sure it made it into the patch?
Mar 27, 2008 at 12:53 PM
Either rename QSActivator.CreateInstance to QSActivator.CreateBaseManager, or change the two references in ConfigurationManager.cs to QSActivator.CreateBaseManager to QSActivator.CreateInstance. At this point, I really do not care. cpc yet again fucks up a merge/patch/commit.
Coordinator
Mar 27, 2008 at 2:54 PM
Edited Mar 27, 2008 at 2:54 PM
It'll all be over soon. :) cpc that is.
Coordinator
Mar 29, 2008 at 4:25 AM
Edited Mar 29, 2008 at 5:07 AM
My initial impression is.....holy crap JigLibX is slow compared to PhysX. Granted, PhysX is a professional system written by a very smart team of programmers and mathmaticians. But the difference is huge. It looks like about 1/4 as many cubes, possibly less, and I'm getting 1/4th the framerate as well. So 1/16th the performance of PhysX. On top of that, no bouncing? Strange. I guess the heightfield could be much less efficient as well, but I wouldn't think that would affect the framerate before collisions much.

I'll edit this post with the code review soon.

-----------------------------------------------

  • I know this is preliminary, but we should definitely comment what we can for future developers that may need to debug physics issues.
  • Missing brackets for 'if' statement inside of JigLibXActor constructor in JigLibXActor.cs.
  • Empty while loop in EndFrame() in JigLibXScene.cs?

Other than that, looks good for now. Should I integrate and commit this even with the lower framerate? It will allow 360 coding (assuming everything else works), but if I'm getting 60fps on my top-end machine, I'd hate to see this on a 4-year old computer like the one I used to run XNA on.

Actually, I'll let you commit it after your review of my review :). You should try and commit this in the next 24 hours so I can integrate your changes with mine before I submit the entire input system up for review.
Mar 29, 2008 at 2:09 PM
There definitely is a difference in the amount of time/effort put into PhysX vs. JigLibX. I'm sure PhysX uses much more sophisticated spatial partitioning, broad-phase collision, and narrow-phase collision algorithms than JigLibX, but you also have to remember that PhysX is a highly tuned library that is very much optimized for its target hardware (be in Intel x86, Xenon, or Cell), while JigLibX relies on the pathetic .NET code generator.


  • I know this is preliminary, but we should definitely comment what we can for future developers that may need to debug physics issues.


I agree, I'll try to comment the code more in addition to the XML comments.


Missing brackets for 'if' statement inside of JigLibXActor constructor in JigLibXActor.cs.


Yeah, yeah. :)


Empty while loop in EndFrame() in JigLibXScene.cs


This is actually a busy-wait loop that stalls the caller until the current frame is done processing (on another thread). I should replace these with proper synchronization locks, though.
Mar 29, 2008 at 3:27 PM
Alright, I committed it. I added some additional comments to the code. I also added proper synchronization handles to the JigLibX implementation to get rid of the busy-wait loop. I also eliminated some memory problems and the JigLibX implementation seems to run a bit faster now.
Mar 29, 2008 at 4:04 PM
I updated the local JigLibX sources with the latest sources on the JigLibX web site and committed again. The engine code was not touched in this commit.
Coordinator
Mar 30, 2008 at 4:30 AM
Very cool. I will try and upload a patch tonight after I merge with the new source.