Forgot to mention that I've made the CONSOLE a friend of the GameEngine class...

GameEngine EMBEDS a CONSOLE object - and the Console.Init method takes a pOwner parameter, which points to, you guessed it, the GameEngine object which owns it.

The result is that each class has full access to all the methods and all the data-variables of the other class.
I won't have to keep extending my Console.Init method every time I want to manipulate another Engine resource.
They will grow together.
Posted on 2009-08-17 05:11:01 by Homer
In preparation for third person camera mode, I have created a Player object which is derived from D3D_MeshManaged, OA32's 3D mesh instance class.

I've added a fourth (optional) parameter to D3D_MeshManager.CreateInstance method... it allows us to provide our own D3D_MeshManaged OR DERIVED object to the Mesh Manager. I hope that Biterider accepts this change as it allows any future derivations of D3D_MeshManaged to operate universally with the Mesh Manager... saving the user from having to derive a new mesh manager for each new derivation of the mesh-managed class.

I think this is a cleaner solution - I changed the comments to state that it "initializes a new/existing d3d_meshmanaged (or derived) object".

; Method:    D3D_MeshManager.CreateInstance
; Purpose:   Initializes a New/Existing D3D_MeshManaged (or Derived) object
; Arguments: Arg1: -> Reference D3D_Mesh object.
;            Arg2: -> Position matrix.
;            Arg3: -> Rotation matrix.
;            Arg4: -> NULL (typical) or D3D_MeshManaged-derived object
; Return:    eax -> New instance or NULL if failed.

Method D3D_MeshManager.CreateInstance, uses esi, pRefMesh:Pointer, pPosMat:Pointer, pRotMat:Pointer, pUserInstance:Pointer
   SetObject esi
   .if pRefMesh != NULL
     mov eax,pUserInstance
     .if eax==0
       mov pUserInstance,$New (D3D_MeshManaged)
     push eax
     .if eax != NULL
       OCall pRefMesh::D3D_Mesh.Insert, eax
       OCall eax::D3D_MeshManaged.Init, pRefMesh, .pCamera, pPosMat, pRotMat
       DbgWarning "D3D_MeshManager.CreateInstance failed, out of memory"
       OCall esi.ErrorReport, NULL, MMR_OUT_OF_MEMORY
     pop eax
     DbgWarning "D3D_MeshManager.CreateInstance failed, invalid RefMesh"
     OCall esi.ErrorReport, NULL, MMR_INVALID_POINTER

I will go further and state that I believe this logic should be extended to other OA32 public object classes which provide such 'internal object creation' methods.

Posted on 2009-08-20 03:43:31 by Homer
I had a bit of trouble implementing First/Third person camera mode switching, mostly because I insisted apon using 'Mouse PickRay with LookAt' code to drive the camera view in BOTH modes, rather than calculating and applying camera rotation.

Finally, after much screwing around, I decided to draw myself a sketch to illustrate the problem and the solution, as usual, became obvious.

In order to keep the Player Avatar as the object of the camera view WITHOUT specifically 'LookingAt' it, I must overwrite the Position values in the View Matrix according to the change in Position of the Apparent LookAtPoint...
This relies on us either predefining or calculating the LOOKAT DISTANCE (from camera position, to lookat point), and maintaining that distance (or reducing it, depending on whether camera is collision-constrained by world surfaces)...

Another way of thinking about this is that we wish to project the camera position from the Player Position, backwards along MINUS the NEW LookatDirection, by the OLD Lookat Distance, or Less.

This second solution path eliminates the need to calculate a DeltaPos.
Posted on 2009-08-22 23:11:29 by Homer
Yup that worked, I have my third person camera working great, now I want to add a little code to lerp between first and third person modes, basically just scaling the 'lookat distance' by a factor between 0 and 1 :)

Also, I fixed an annoying behaviour that trapped the mouse to the application window when the application is 'frozen' (this is not 'pause' - it is a total 'freeze of the application', such as when the user switched app windows forcefully).

It's probably time to start playing with the physics, but before I do, I'll be working with my beta buddy Biterider to ensure theres no problems building the project in a foreign build environment.

Posted on 2009-08-24 08:55:24 by Homer
Implemented the Lerping effect, it looks good too, now I need to start thinking about driving my player avatar rather than the camera - soon I will no longer be a disembodied camera.
Also, I fixed a problem where the Camera MousePick (and so my MouseLook) would behave oddly if the application was switched to fullscreen mode... the camera was still using the windowed client width/height... basically I needed to call Camera.SetProjection from within GameEngine.SetupScene (or from Restore) and everything was fine.

Yesterday I wanted to discover the Camera's Orientation in WorldSpace, given only the View Matrix.
That turned out to be so easy and I want to mention it just incase someone searches for this.

The INVERSE of the 4x4 View Matrix is in fact a Transformation Matrix describing the Camera entity's orientation and position in WorldSpace.
Its a nice clean Change Of Basis matrix - just rotation and translation, no other stuff.

Since we only care about rotation, we can pretend its a 3x3 matrix, and just grab the elements in the topleft nine cells of the inverse viewmatrix - thats the orientation (as a Mat33).
But since we KNOW that there is ONLY rotation data and no other junk in the topleft 3x3 cells, we can CHEAT.
We don't actually need to find the inverse of the viewmatrix (an expensive operation). Just the Transpose of the topleft Mat33 is what we need (and transposing a matrix is incredibly cheap) :)
So as we read the values from matrix cell mXY, we store it in output matrix mYX :)
Eg, ViewMatrix.m02 -> OutputMatrix.m20
    ViewMatrix.m11 -> OutputMatrix.m11

I tested this by using my player model's rotation matrix as the output matrix.
The result was that, regardless of camera rotation, the player model did not rotate on the screen.
It's not why I wanted to find the camera's worldspace orientation at all, but it was a perfect test.
Posted on 2009-08-25 04:00:34 by Homer

Tried two new World models today.
Found that the Automatic Portal Generator is still not up to scratch, making unnecessary cuts in the Portal Polygons, producing portals which are more complex than they need to be.
This has a dramatic snowball effect on resources which makes it even worse.
I already have a patch bashed out in the form of a new Portal.WeldPolygons method, since I can't eliminate the source of the problem entirely as it is the result the solution path I chose for clipping coplanar polygons against one another.
Posted on 2009-08-25 11:09:29 by Homer

Epiphany - I no longer believe that I need to determine the final Shape of the Portals.
I still need to 'shatter' the original 'giant planar quads' in order to discover portal connectivity, but as soon as I have my connectivity data, I can throw away all the Portal geometry, performing NO clipping operations.
I have stopped working on this area.

The reason why I dont need to know the shapes of the portals?
Each subspace is bounded by a set of Faces, and CLOSED by a set of Planes, apon which our Portals exist.
The SHAPE of a portal is absolutely irrelevant since it can be defined as 'the area of a plane which is NOT obscured by faces in the two connected subspaces".

During collision detection within a given Subspace, I will first try to intersect with the SOLID set of faces.
If that fails, I will try to intersect with the Portal Planes.

If an entity is intersecting with one OR MORE portal planes, then it is protruding into the subspace(s) which the Portal(s) connect to... and so I must then perform collision detection of the Entity versus anything in the connected subspace(s).

So, I am going to press forwards.
I am replacing the mesh representation of the Player Avatar with SkinMesh (animated, of course).
And I am, as you can see, beginning to put serious thought to how Physics fits in with the World representation.
Up until now, my only concern has been to ensure that the physics simulation shares and benefits from the World's space partitioning scheme, a worthy goal, but hardly the end of the story.

Also, I will be fitting the main engine out with switches to implement LOADING and MENU stuff, it will be a refreshing change from the geometry related stuff, which to be honest, is becoming un-fun.

Posted on 2009-08-27 02:26:00 by Homer
I've just finished transcribing the VMR9 header and I've written a MovieMixer object which can blend two movies (avi or mpeg) and render the output to a rectangle of a given window, or to a d3d9 surface.
Its actually possible to blend any number of movies, not that its a good idea.

Anyway as soon as I've had a chance to test these new files, I'll handball them to Biterider for immediate public distribution via the 'Smart Updater' service.

Posted on 2009-08-29 22:14:42 by Homer
I've been working to use animated skinmeshes for the player avatars, instead of the 'static' meshes that I currently support. I always planned to, it was just easier to get the ball rolling using simple meshes.

I decided that it would be nice to implement a manager for skinmesh that implements instances from a library of loaded reference objects, like we did for D3D_Mesh.

And so, I wrote a new object called D3D_SkinMeshManager, and made some important changes to D3D_SkinMesh in order to support externally-provided animation controllers.
Some changes were required by the new Manager class, and others were made to bring SkinMesh/SkinMeshManager into line with the existing Mesh/MeshManager classes.

Since very few people have mentioned that they are using SkinMesh objects in existing projects, or have even worked their way far enough through OA32's object library to reach these 'expert level' objects, I think its fairly safe to make them immediately available on our Smart Updater service, and to update the relevant EXAMPLES/DEMOS within the next few days, then post those on the updater service, say in a week's time or less... just because I'm going camping this weekend, so I won't be here to do it, though really there's not much involved.

Keep your eyes open for updates to these classes, as I expect that they will receive some attention over the coming weeks.

Posted on 2009-09-04 04:37:54 by Homer
Just got back from camping :)

I've already debugged and tested the new MovieMixer object.
It works great, and its very easy to use.
Just a couple of tiny bugs corrected.

Just not sure yet how to detect movie events (end of file, etc) so I'm not quite sure how best to determine when the movie has ended, and I don't have any Get methods to find out how long the playtime for each movie is.
Still, its a very promising and potentially very useful thing.
Posted on 2009-09-05 23:07:50 by Homer
OK, I figured out how to catch movie events, and I've included their definitions and descriptions of them.

Event notifications will be passed to your chosen render window via the custom WM_GRAPHNOTIFY message, which I've declared as being WM_USER+512

When your app gets such a message, you should call IMediaEventEx.GetEvent in a LOOP until it fails (as there may be multiple messages waiting, you only get notified when the queue is no longer Empty, NOT when a message is ready).
You should release resources associated with each event, as many return things like BSTRs which were allocated by the video manager).
When a movie finishes (event=EC_COMPLETE), you need to Stop it yourself, the videomanager wont Stop it until you tell it to, I am guessing that each Mixed movie will generate its own EC_COMPLETE message, even if theres longer movie(s) still playing.

Here is some example code taken directly from GameEngine.

; Method:    GameEngine.OnGraphNotify
; Purpose:   Event procedure for WM_GRAPHNOTIFY message.
; Arguments: Arg1: Nothing
;            Arg2: User-Defined, NULL in my case
; Return:    Nothing
Method GameEngine.OnGraphNotify,uses esi, wParam:dword, lParam:dword
LOCAL evCode, evParam1, evParam2
   SetObject esi

   ; Make sure that we don't access the media event interface  
   ; after it has already been released.  
   .if .cutscene.pME==0
   ; Process all queued events  
       ICall .cutscene.pME::IMediaEventEx.GetEvent,addr evCode,addr evParam1,addr evParam2, 0
       .break .if FAILED(eax)
       ; Free memory associated with callback, since we're not using it  
       ICall .cutscene.pME::IMediaEventEx.FreeEventParams,evCode, evParam1, evParam2
       ; If this is the end of the clip, Stop the mixer 
       .if evCode==EC_COMPLETE
           OCall .cutscene::MovieMixer.stop
           mov   .IsMoviePlaying,FALSE
           DbgDec evCode,,"media event"
   .until 0

Posted on 2009-09-07 04:15:39 by Homer

More information - the DEFAULT behavior is to send one EC_COMPLETE message when ALL videos have stopped playing - we can change the default behavior, and have a message sent for EACH stopped video, if we want to.

I've successfully tested mixing of two Movies (without audio).
I messed with the Alpha of Stream 1 for a while, that was fun.

Posted on 2009-09-07 07:30:34 by Homer
I threw together a short intro movie for OA32 projects.
Here's a screenshot :)

Posted on 2009-09-07 10:05:39 by Homer
I'm firing on all cylinders!

Started putting together a Menu management class (N-Tree based), and also I am adding WEBCAM INPUT support to the MovieMixer class (not sure why, just seemed like a cool idea to be able to blend videos and static images and webcam streams).

Next time I post a beta executable, I won't feel ashamed of its lack of polish... it will at least look the part :)
Posted on 2009-09-09 02:21:40 by Homer

Inheritance path: Primer
Inheritance path: Primer,Streamable
Inheritance path: Primer,Streamable,WinPrimer
Inheritance path: Primer,Stream
Inheritance path: Primer,Stream,DiskStream
Inheritance path: Primer,Streamable,Collection
Inheritance path: Primer,Streamable,Collection,DataCollection
Inheritance path: Primer,Streamable,Collection,DwordCollection
Inheritance path: Primer,Streamable,Collection,SortedCollection
Inheritance path: Primer,Streamable,Collection,SortedCollection,SortedDataCollection
Inheritance path: Primer,Streamable,DataPool
Inheritance path: Primer,Streamable,WinPrimer,Button
Inheritance path: Primer,Streamable,WinPrimer,Button,Hyperlink
Inheritance path: Primer,Streamable,WinPrimer,Dialog
Inheritance path: Primer,Streamable,WinPrimer,Dialog,DialogModal
Inheritance path: Primer,Streamable,WinPrimer,Dialog,DialogModal,DialogAbout
Inheritance path: Primer,MovieMixer
Inheritance path: Primer,Streamable,Direct3D
Inheritance path: Primer,Streamable,Collection,EventManager
Inheritance path: Primer,EventBank
Inheritance path: Primer,Sound
Inheritance path: Primer,Sound,StreamingSound
Inheritance path: Primer,Sound,StreamingSound,StreamingMP3Sound
Inheritance path: Primer,Streamable,Collection,D3D_Audio
Inheritance path: Primer,Streamable,D3D_Camera
Inheritance path: Primer,Streamable,D3D_VertexBuffer
Inheritance path: Primer,Streamable,D3D_IndexBuffer
Inheritance path: Primer,IUnknown
Inheritance path: Primer,IUnknown,IUnknownNoDelegate
Inheritance path: Primer,Component
Inheritance path: Primer,XML3DContentHandler
Inheritance path: Primer,Streamable,WinPrimer,Dialog,DialogModal,DialogDXSetup
Inheritance path: Primer,Streamable,D3D_Font
Inheritance path: Primer,Streamable,Collection,DataCollection,D3D_TextureManager
Inheritance path: Primer,Streamable,WinPrimer,D3D_Window
Inheritance path: Primer,Streamable,WinPrimer,D3D_Window,D3D_Application
Inheritance path: Primer,Streamable,Collection,D3D_Mesh
Inheritance path: Primer,Streamable,D3D_MeshManaged
Inheritance path: Primer,Streamable,Collection,D3D_MeshManager
Inheritance path: Primer,Streamable,Collection,D3D_VectorManager
Inheritance path: Primer,Streamable,Collection,DataCollection,D3D_VectorGroup
Inheritance path: Primer,Streamable,Collection,DataCollection,D3D_SpriteManager
Inheritance path: Primer,Streamable,Collection,SortedCollection,SortedDataCollection,InetAddrCollection
Inheritance path: Primer,Streamable,DataPool,NetComIOJobPool
Inheritance path: Primer,Streamable,DataPool,NetComIOMsgPool
Inheritance path: Primer,NetComConnection
Inheritance path: Primer,Streamable,DataPool,NetComConnectionPool
Inheritance path: Primer,NetComProtocol
Inheritance path: Primer,NetComEngine
Inheritance path: Primer,StopWatch
Inheritance path: Primer,Streamable,Collection,DataCollection,POLYGON
Inheritance path: Primer,Streamable,Collection,Portal
Inheritance path: Primer,Streamable,Collection,DataCollection,Vec4Collection
Inheritance path: Primer,BSPGen
Inheritance path: Primer,Streamable,Collection,SortedCollection,SortedDataCollection,CollisionPairList
Inheritance path: Primer,Streamable,CollisionBody
Inheritance path: Primer,CollisionBodyInstance
Inheritance path: Primer,Streamable,Collection,Simulator
Inheritance path: Primer,ID3DXAllocateHierarchy
Inheritance path: Primer,Streamable,Collection,D3D_SkinMesh
Inheritance path: Primer,D3D_SkinMeshInstance
Inheritance path: Primer,Streamable,Collection,D3D_SkinMeshManager
Inheritance path: Primer,D3D_SkinMeshInstance,Player
"Building as Client"
Inheritance path: Primer,NetComProtocol,NetComCntProtocol
Inheritance path: Primer,Streamable,Collection,DataCollection,D3D_Console
Inheritance path: Primer,Streamable,Collection,GE_MenuItem
Inheritance path: Primer,Streamable,Collection,GE_Menu
Inheritance path: Primer,Streamable,WinPrimer,D3D_Window,D3D_Application,GameEngine

Posted on 2009-09-11 12:03:24 by Homer
Today I tested/debugged the new D3D_SkinMeshManager class, and modified the affected DirectX Demo Projects #11 and #12 (which I promised to do a week ago).
Biterider has been supplied with the relevant files, and I imagine they'll be available via our live updater service within the next few days (possibly already!)

The only thing missing is that the SkinMeshManager does not support Visibility culling like MeshManager does.
I'll add that when I feel so inclined, and probably won't make much noise about it.
Posted on 2009-09-12 07:35:02 by Homer
I'm screwing around in Maya with 3D models of humans.
Really don't have enough time to do it, although I am capable.
Would love to hear from amateur 3D artists !!
Can't pay (yet), but you'll benefit from the exposure, if nothing else :)
Posted on 2009-09-14 22:39:38 by Homer
I will try to spend some time toward advancing the physics integration, based on the BoundingSphere of the BindPose of the Player SkinMesh.
It will be a good step forward, and I don't have to wait for a suitable model to be completed.
Posted on 2009-09-15 00:52:41 by Homer

Anyway as soon as I've had a chance to test these new files, I'll handball them to Biterider for immediate public distribution via the 'Smart Updater' service.

Pardon my ignorance, but what exactly is this project that you and Biterider are working on? I see the term "OA" floating around here and there, and I see you mentioning a 'Smart Updater' service.
So this code that you speak of, where exactly does it go, what is its purpose? Where are the 'headquarters' for this project, etc?
Posted on 2009-09-15 09:28:46 by Scali
Posted on 2009-09-15 09:38:42 by f0dder