I've made some subtle but important changes to the D3D_Mesh, D3D_MeshManaged and D3D_MeshManager classes, relating particularly to ownership.

D3D_MeshManaged represents a living instance of D3D_Mesh - it is Owned by D3D_Mesh.... since MeshManaged contains NO DEVICE-DEPENDANT RESOURCES, it is immune to release / restore events.
D3D_Mesh is a Reference object - it also keeps a list of D3D_MeshManaged objects, so that we can unload a given D3D_Mesh and all its instances without affecting anything else.
D3D_MeshManager keeps a list of D3D_Mesh instances, and methods to manage them.

Basically this means that the resource management is a little more intelligent - for example when we want to throw out the current 'game level' and load a new one, we're not forced to release everything we have, only what we no longer need. This speeds up 'level transitions'.

Our 'mesh instancing' technique is still quite naiive, in the near future I would like to investigate using Vertex Shaders to implement gpu-based instancing.

We declare a special vertex format whose components come from 2 Streams.
The first stream contains the geometry components that we would normally be using.
The second stream contains 2 components - Position, and Combined Transform Matrix, for each Instance we wish to render.

This means we can render all instances with a single call, and with no cpu loops required.
I can only imagine that will make a HUGE difference for levels that are heavily reliant on static meshes.

Posted on 2008-09-24 06:33:14 by Homer
Well I let that go long enough.
I was waiting for someone to complain about my assertion, disregarding the geometry stream, that we need to send two vertex components per instance - position and combined tranform - LOL!
The combined transform contains the position data - hehehe :P
How many vertex components does the stream require?
Posted on 2008-10-05 05:07:13 by Homer
I've been reworking the various components of my "NetEngine", removing unnecessary complexity in its base classes and generally cleaning it up for public release. I must admit I am a little disappointed that I could not submit this object in our most recent public release, but I felt it was not mature enough for general consumption, so it has sat on the back burner waiting until I found the time.

Removing unnecessary complexity was important both in terms of execution speed and making it easier to understand - and has allowed me to add support for UDP broadcasting, so the NetEngine truly deserves its name as it supports asynchronous networking with multiple application protocol handlers over multiple transport protocols.

The next thing to do is to clean up the "front end", which is the main interface for most users.
Then I will need to carefully document everything, and finally, NetEngine can go public :)
Posted on 2008-10-11 21:48:27 by Homer