here's my fkt file (Caleb's fpu macros)

The changes in here are in regards to name duplication - it's simply a matter of altering Caleb's macro names where applicable, and uncommenting the appropriate protos if necessary...
nonetheless, here it is :)

(I'm of the opinion that macros should use their own naming convention to avoid this kind of contention.. simply a leading underscore or two is highly appropriate imho)
Posted on 2003-11-01 00:27:46 by Homer
Here's the file
I don't make a habit of editing these includes, you should be pretty right now...
Posted on 2003-11-01 00:29:13 by Homer
I'd just like to mention that during parsing of Tiny.x, we ONLY find Frame Matrices of type = "TransformationMatrix", we don't find any translatoin, rotation and scaling matrices, we find already combined matrices.
What I am a bit unsure of is whether they are "true" combined matrices, or are meant to be hierarchically combined and applied.
The cpp source was not exactly clear in regards to this...
Posted on 2003-11-01 02:52:12 by Homer
Hi !EvilHomer2k :)

Very big work which you make!
I am very disappointed not to be able to give concrete expression them I have no version adapted by DirectX. :(
I hope that it will come quickly.

Encouragements to be continued.....:alright:
Posted on 2003-11-01 03:30:49 by Asmgges
Thanks for your support, it's nice to hear words of encouragement.
The project is for DirectX 8.1

This project provides support for animated skinmeshes, the 3d models you see in games like Quake.

It also contains a basic "Direct3D Skeleton" (an example application)
but this is by no means a complete game.
Nonetheless, this source is bigger than many games just by itself !!

The idea is to make this free to asm gamecoders everywhere.

Feel free to use this in your own projects (when it's completed) but please credit any authors who contribute to it. There is no license of any kind on this software, we simply ask that you do this in the spirit of open-source.
Several authors have contributed huge amounts of their valuable time to make this available to you for free, it's the least you can do to repay them.
Posted on 2003-11-01 04:25:16 by Homer
The example xfile we are trying to load (Tiny.x from m$) contains just one "AnimationSet" template.
This animationset contains all the data needed to show the model in a simple "Walk" animation.
What this means is that m$ naming convention for their templates leads to much confusion !! An Animation template does NOT contain all the data needed to produce a "named animation" like "Walk"... that would be an "AnimationSet" !!! Furthermore, in a "real world" xfile, we can expect SEVERAL of these "AnimationSet" templates, and they will contain Names (m$'s example in Tiny.x has no Name for the only AnimationSet).
Should we wish our model to be able to say, scratch his privates, this would be a separate AnimationSet, and the goal of this project is to provide the programmer with the ability to ultimately simply call AnimationSets by name, so youo would have AnimationSets called things like "Jump", "Run", "ScratchPrivates" etc.
Posted on 2003-11-01 06:16:28 by Homer
That last post I made relates directly to at least one of the issues I am experiencing - allow me to elucidate.
When I discover the (in this case, the ONLY) AnimationSet, I create an AnimationNode, attach it to the parent SkinMesh, and then proceed to parse the AnimationSet for its Animation templates. For each Animation discovered, I call AnimationNode_Load, passing it a pointer to the owner SkinMesh.
The AnimationNode_Load procedure does the same thing - it creates an AnimationNode , attaches it to the parent SkinMesh's AnimationNodes list, processes the node, and returns.

Can you see what has happened here?
The root AnimationNode is empty !!

This is not really a mistake as such, since I intend to support MULTIPLE AnimationSets for a SkinMesh.
What I'll do to fix it is replace the SkinMesh's AnimationNodes list with a new container object providing for linked AnimationSets, which will contain a list of AnimationNodes.
I'll let you know when I've implemented these changes, but really, I need a "real" x-file to test the new parsing ideology - one that contains more than one AnimationSet, because Tiny.x does not.

The only reason I've been getting away with it so far is because I have error checking code looking for NULL object pointers and ignoring them.

If any of you want to HELP me with this project, I currently require a REAL XFILE which contains at least one texture, one Material, and MORE THAN ONE AnimationSet - ie, a CharacterSet. I don't care how simple the model is, only that it fits the above requirements.

Thanks again for the moral support, I have no intention of letting this project become one of my many lost causes.
Posted on 2003-11-02 02:18:14 by Homer
Never backwards in moving forwards, here are the revised Structs...

The SkinMesh object acts as a container for Frames and AnimationSets...

LO LinkedObject <>
pFramesRoot DWORD ? ;ptr to Root of entire frame hierarchy of this SkinMesh Model
pAnimationSets DWORD ? ;ptr to Root of all AnimationSets of this SkinMesh Model
SkinMesh ENDS

The FrameNode structure has not been altered...
It acts as a container for the Mesh Node(s) and also contains per-frame Matrix data.
MeshNode Structure has not been altered either, so I won't bother posting them.

The AnimationSet structure is totally new, and simply acts as a container for AnimationNodes as described in the previous post...

MyAnimationSet STRUCT
LO LinkedObject <> ;Support for linking and naming of linkedlist nodes
pAnimationNodes LPANIMATIONNODE ? ;pointer to the AnimationNodes of this AnimationSet
MyAnimationSet ENDS

The AnimationNode structure has not been altered, with the exception of its "hTargetFrame" field renamed to "pTargetFrame" because it's a pointer, not a handle, and was misnamed as a legacy of the previous memory model.
This field indicates which of our FrameNodes is targetted by this AnimationNode, which makes for quite a complex hierarchy of links !! Just as well we're using LinkedLists, isn't it? :)

I'll post the whole lot again in a day or two, when I've had time to mess with the code some more, but it's implemented and compiles.
Posted on 2003-11-02 16:46:06 by Homer
Just for the record, I've just debugged the new code and I'm right back where I was before - with that god-awful and silly-looking vertex stretching thing...

Also, I realized that I'm not setting some of my object rootpointers correctly, which certainly won't help when it comes time to release them. I'm setting them in fields of Owner objects but forgetting to set the appropriate rootpointers in the Data segment which will be used for garbage collection at final cleanup. Still, these are not really relevant to the current issue:
Posted on 2003-11-02 17:17:06 by Homer
Scronty, I could really use a hand with this... please spare me a little of your time, and I'll happily return the favour :)
Posted on 2003-11-04 23:04:53 by Homer
Thanks to the kind support of Ultrano, I now have somewhere to post updates of the project on a day-to-day basis.
For the moment, I've just shoved everything into a single RAR file (about 2 and a half megs worth) which you may find @

well, you'll be able to when he fixes the permissions lol (sorry)

I'll get a frontpage and stuff happening when I get time.
cya :)
Posted on 2003-11-06 22:23:36 by Homer
Changes were made to AnimationNode_Load procedure.
Here's an update of just that file.
(Not that it made any difference to the loading of Tiny.x)

This procedure is capable of loading four different kinds of tranformation data: position, rotation, scale, and transformation, the last one is a precombined matrix of the first three. The changes were in the loaders for the first three, Tiny.x ONLY contains already-combined matrices - the fourth type.
Posted on 2003-11-07 23:40:26 by Homer
Please, nice friendly overseers of, don't spank me for pasting your pseudocode - this translation project is open-sourced !!

Initialize X file API
Register D3DRM templates
Open the X file
For every top level template in the X file
Retrieve the X file data object
Pass the data object to RootFrame.Load
Link the bones to the skin mesh(es)
Link the bones to the animations

Check the type of the data object
If the type is Mesh
Create new CMeshNode object
Attach the new object to the frame
Pass the data object to CMeshNode::Create of the new mesh
Else if type is FrameTransformationMatrix
Load the transformation matrix
Else if type is Frame
Else if type is Animation
Instruct CSkinMesh to load the new animation
Create new CFrameNode object
Attach the new object to this frame
Set the name of the child frame to the name of the template
For every child template of the current
Retrieve the X file data object
Pass it to newframe.Load

Create new CAnimationNode object
Attach the new object to the link list
For every child template
Call CAnimationNode::Load for the new animation object

Check the type of the data object
If the type is a reference
Get the referenced template, which is a frame template
Get the name of it
Store the name
Else if type is data
Check the type of the animation key
Load the key accordingly

The SetTime function is where all the animation functionality is performed. CSkinMesh::SetTime simply calls the SetTime function of all the animation objects.

If a matrix key is available
Get the nearest matrix to the given time
Set it to the target frame
Prepare an identity matrix called TransMat
If a scale key is available
Calculate the accurate scale value
Prepare a scale matrix for this scale value
Append the matrix to TransMat
If a rotation key is available
Calculate the accurate rotation quaternion
Prepare a rotation matrix from this value
Append the matrix to TransMat
If a position key is available
Calculate the accurate position value
Prepare a matrix for it
Append the matrix to TransMat
Set TransMat to the target frame

Posted on 2003-11-08 22:14:00 by Homer
You know, I think the problem is that I am confusing myself a bit with the LinkedLists_AppendSibling function's relatively new modus operandi (method of operation)...

At the moment, it operates in the following way:

Create New Object
If the Object has a Parent,
..If the Parent Has a Child,
Seek the Parents Youngest Child
Add the new Object as a Sibling of the Parent's Youngest Child
..ElseIf the Parent Has No Child,
Add the New Object as the Parent's Child
Leave Object Unlinked

Which means that the first Sibling of a Node is really recorded as Child !!
Later in my parsing functions, I just walk the sibling and child links of nodes, without regarding the hierarchy structure itself, which is fundamentally wrong by all accounts...
I might play with the hierarchy functions again and see if I can make things a bit tidier and less abstracted..
Posted on 2003-11-09 01:17:01 by Homer
Hey Homer

Would it be easier to store the siblings in their own linked list?
I haven't looked at the linked list code so forgive me if this is a stupid suggestion.

linkedListNode struct
parent dd ?
child dd ?
siblings linkedList <>
linkedListNode ends

Have you sorted out whats happening with the streatched polys?
Perhaps it's caused by the problem with the linked list your mention.

Which means that the first Sibling of a Node is really recorded as Child !!

Posted on 2003-11-09 18:12:19 by Maelstrom
Siblings in a linkedlist can be thought of the same as children in a linkedist - any node only knows its next child and/or sibling - but the siblings of a child are grouped to it under my system.

Sorry I've been absent a few days, with the help of Ultrano, I'm altering the source for Object Oriented Programming, with all the code shoved into a handy DLL - and I'm currently at the stage of a basic Render Window so please bear with me - I'll post an update soon which will bring you all up to date :)
Rest Assured, the codebase is being enclosed in a DLL so our launcher exe is tiny - there's a few security issues here being addressed as well...
Posted on 2003-11-11 03:23:44 by Homer
We have created thus far a DLL which contains two relatively complete classes - more classes being added as we speak.
The DLL exports just one function, "main".
We load the DLL from a tiny exe and call "main" from it.
The "main" function creates a single instance of our CApp class (below), and does not return until the application is closed by the user.

The two classes so far are called CApp and CObject.
The CObject class provides support for LinkedLists in much the same way as my LO header object, except this is a full Class and is inheritable. Most of the incomplete classes inherit from it, so it was important to get it happening early, but for now it remains unused.
The constructor method of the CApp class creates a main application window, fires up D3D and associates D3D's renderer with the window.
It then calls the CApp.Run method, which drives the MessagePump, and does not return until a Quit message is noticed in the WM queue.

Basically that's it, I'll post it soon, and also a link to it's new online home, thanks once more to the kind support of Ultrano (author of the Asm Classes support code).

Have a nice day :)
Posted on 2003-11-12 03:12:52 by Homer
Updated regularly - OOPSkinMesh is my first foray into writing object-oriented asm with full inheritable class structures, but it should catch the eye of those OOP and CPP fans out there...

The COMPLETE but still buggy oopskin codebase can be found here
Posted on 2003-11-12 09:32:46 by Homer