Afternoon, All.

The attached example is a translation of Jim Adams' Frame hierarchy sample. (see Here ).

It's based upon the "Parsing an X File" example, with the addition of code to build the frame hierarchy.

Let me know if you have any problems getting it to work (post in this thread).

Cheers,
Scronty
Posted on 2002-08-13 08:40:02 by Scronty
Nice work - I'll be needing skinned animated meshes shortly ;)
I'd like to do a public demo in this forum as a learning tool and to get things shaking around here.
Posted on 2002-08-16 10:34:48 by Homer
Afternoon, EvilHomer2k.

I fully agree. That's one of the reasons I have for mucking about with the Linked-List in the other thread.

The Skinned-Mesh sample of Microsofts is fine as a basic example, however it's quite awkward to modify the code for a game. Far better to start with the game hierarchy, and implement what's neccessary as we go along.

I imagine that any mesh/material/texture/etc inside a linkedlist for the object, would also require a "reference count" for it.
i.e. for a weapon mesh, it'd make sense to load the weapon in once, and have any other character use a pointer to the original weapon. The first time the weapons' mesh is loaded, it's given to its Parent, and its "reference count" is set to '1' to indicate that there's one "parent" who owns this type of weapon. Any other characters who also want to use this weapon, have a pointer to the one already in memory, and have the original weapons' "reference count" incremented. Obviously, I'm only talking about the general Mesh/Frame/Animation data for the Weapon. Anything else for the weapon (rounds left/ distance travelled/ coords/ direction/ acceleration/ etc) would still be inside the "Weapon" sublist.
The "reference count" is needed so that, when a "Weapon" (or machine/ character/ etc) is destroyed, then the textures/ materials/ mesh/ etc aren't deleted if they're still in use by someone else.

I don't like the idea of having the implement many separate lists for each part of a game (a bullet list, a character list, etc). Far better to have the one list if possible, and have everything neccessary inside the hierachy (any sound FX also).

Cheers,
Scronty
Posted on 2002-08-17 09:02:17 by Scronty
I fully agree, almost...
I'd prefer to see the List implemented with a single Root, but with some Objects having sublists that they "Own", implementating a hierarchy within the List itself... I was thinking that a Player would Own a Weapon, and that Weapon would Own the projectiles it fired.
Thinking in terms of hierarchy, this is more efficient than a single long list, allows faster sorts should sorts be required, and reduces some of the non-linearity in the access-times of data stored in such a database, as compared to storing it in what amounts to a sequentially-accessed single.
What I'm really describing is still a lot like what you have in mind.
We still keep just one single Handle to the entire database.
We just have a bit more structure to the order in which game objects are stored in the list. This is easier than it sounds - check out the sockets code using 2DLL I just posted in Networking..
I like the idea of using Instancing.. in my own code I've used two lists, one is a master-list of loaded objects , textures and sounds, the other is a list of "instance" objects in play in the game... instance objects are virtual objects that refer to real ones for their crucial data, but store unique data themselves.
This allowed me to easily create new Instances of anything I had loaded, and to load everything just once.

So how were you thinking of arranging the game data?
How do you intend to store the data for Loaded Objects as opposed to Instanced ones?
Would you tag each object so it knew what kind of object it was?
(actually not a bad idea)
Will the World be loaded from a Mesh object?

Questions Questions :tongue:
Posted on 2002-08-21 12:40:53 by Homer
Afternoon, All.

Attached is the same hierarchy loading example, however now it's using the linkedlist being developed in another thread.

It seems to be working most of the time. It still has a few problem with the tiny.x file though :/.

Cheers,
Scronty
Posted on 2002-09-02 22:00:03 by Scronty
Takes a squiz..

I've begun the arduous task of translating the m$ animated meshes example, beginning with a quick rip of the files mframe.h and mframe.cpp. They describe the SFrame structure (animated mesh frame container) along with some constructor and destructor methods. They haven't been modified to use the LinkedList procs yet, I'll do a half-hearted rip of the whole lot, and then we can decide better what we wish to implement from this shemozzle.
Am I wasting my time, since this stuff is heavily copyrighted?
That's my motivation for not performing a literal translation :tongue:
Are you already doing this or have different ideas?
Their implementation is a nice example to build our own on ;)
Posted on 2002-09-03 01:35:36 by Homer
Here's a teaser - one of the procs from mload.cpp

LoadAnimationSet PROC pxofobjCur:ptr LPDIRECTXFILEDATA, pde:ptr SDrawElement,options:DWORD,fvf:DWORD, pD3DDevice:LPDIRECT3DDEVICE8,pframeParent:ptr SFrame

LOCAL pframeCur:ptr SFrame
LOCAL type:ptr GUID
LOCAL pxofobjChild:LPDIRECTXFILEDATA
LOCAL pxofChild:LPDIRECTXFILEOBJECT
LOCAL cchName:DWORD
LOCAL hr:DWORD

mov pxofobjChild,NULL ;Initialize
mov pxofChild,NULL

; pframeCur = new SFrame();
invoke NewChildEntry,NULL,sizeof SFrame ;just using this to allocate memory - heh
mov pframeCur,eax
mov esi,eax
.if pframeCur == NULL
mov hr , E_OUTOFMEMORY
jmp e_Exit
.endif
mov .SFrame.bAnimationFrame , TRUE

invoke AddFrame,pframeParent,pframeCur
invoke GetName,pxofobjCur,NULL, addr cchName
.if eax==FAILED
jmp e_Exit;
.endif
.if cchName > 0
; pframeCur->szName = new char ; fix this
; invoke NewName,
.if .SFrame.szName == NULL
mov hr,E_OUTOFMEMORY
jmp e_Exit
.endif

invoke GetName,pxofobjCur,.SFrame.szName, addr cchName
mov hr,eax
.if eax==FAILED
jmp e_Exit
.endif
.endif


; // Enumerate child objects.
; // Child object can be data, data reference or binary.
; // Use QueryInterface() to find what type of object a child is.

invoke GetNextObject,pxofobjCur,addr pxofChild
.while eax==SUCCEEDED
; // Query the child for it's FileData
mcall ,QueryInterface,IID_IDirectXFileData,addr pxofobjChild
mov hr,eax

.if eax==SUCCEEDED
invoke GetType, pxofobjChild.addr type
mov hr,eax
.if eax==FAILED
jmp e_Exit
.endif

lea eax,type
.if eax == TID_D3DRMAnimation
invoke LoadAnimation,pxofobjChild, pde, options, fvf, pD3DDevice, pframeCur
mov hr,eax
.if eax==FAILED
jmp e_Exit
.endif
.endif
invoke GXRELEASE,pxofobjChild
.endif
invoke GXRELEASE,pxofChild
invoke GetNextObject,pxofobjCur,addr pxofChild
.endw

e_Exit:
invoke GXRELEASE,pxofobjChild
invoke GXRELEASE,pxofChild
return hr

LoadAnimationSet ENDP
Posted on 2002-09-03 02:21:37 by Homer
Your FramesHierarchyLL loader seems to be working reasonably well :alright:
Now I suggest we construct a Frame object like m$'s SFrame.
Check the thread I posted for the proposed variant using LL.
I didn't at all base it on m$'s highly-copyrighted SFrame object ok? ;)
Posted on 2002-09-03 03:16:34 by Homer