Yeah well, its kinda weird - what happens is that it renders the dude onscreen, but each terminal vertex is stretched to the LOWER LEFT corner of the screen !!?!

When I post it you'll see what I mean, even every strand of his HAIR , the last vertex is shifted to the LOWER LEFT of screen - bizarre - BUT - I need to repair the AnimationNode_SetTime function which probably has EVERYTHING to do with it - still, I would have expected stuff to rip to the TOP LEFT corner of the screen, not the BOTTOM LEFT !! Nevermind, I'll fix it :)

Nonetheless, thanks for the vote of support !! It's been maybe 4 months now and FINALLY I can see SOMETHING on my screen !! It feels better than good - in fact, I feel better than James Brown !! I actually danced a jig when I got it to render something, and have worn a big wide grin ever since seeing as I am probably the only dude in the world who currently has working masm source for SkinMesh :)
Posted on 2003-10-30 08:24:19 by Homer
Well, after adding some call-once debug code to AnimationNode_SetTime, I discovered that the Time associated with the "Last Key" was ZERO !!?!
So I thought - ok, that's not right... I better look again at my AnimationNode Loader and see what's going on !!
Added some debug code to AnimationNode_Load, discovered that "pmatrixkey" was being incorrectly calculated, fixed it, now I am getting all "MatrixKeys" loading correctly (i think).
For Tiny.x I am getting 62 MatrixKeys per AnimationNode, whose Time values range from zero to 4880 (I have to assume this is milliseconds).

Here is a little bit of the (currently 91 kb) debug logfile..

A TopLevel Object has been discovered, and it's an AnimationSet...
Discovered AnimationKey
====================================================
Discovered MATRIX KEY
Allocated buffer space for 62 MatrixKeys
pmatrixkey=0x1F60830
Key #0 - dwTime=0
Key #1 - dwTime=80
Key #2 - dwTime=160
Key #3 - dwTime=240
Key #4 - dwTime=320
Key #5 - dwTime=400
Key #6 - dwTime=480
Key #7 - dwTime=560
Key #8 - dwTime=640
Key #9 - dwTime=720
Key #10 - dwTime=800
Key #11 - dwTime=880
Key #12 - dwTime=960
Key #13 - dwTime=1040
Key #14 - dwTime=1120
Key #15 - dwTime=1200
Key #16 - dwTime=1280
Key #17 - dwTime=1360
Key #18 - dwTime=1440
Key #19 - dwTime=1520
Key #20 - dwTime=1600
Key #21 - dwTime=1680
Key #22 - dwTime=1760
Key #23 - dwTime=1840
Key #24 - dwTime=1920
Key #25 - dwTime=2000
Key #26 - dwTime=2080
Key #27 - dwTime=2160
Key #28 - dwTime=2240
Key #29 - dwTime=2320
Key #30 - dwTime=2400
Key #31 - dwTime=2480
Key #32 - dwTime=2560
Key #33 - dwTime=2640
Key #34 - dwTime=2720
Key #35 - dwTime=2800
Key #36 - dwTime=2880
Key #37 - dwTime=2960
Key #38 - dwTime=3040
Key #39 - dwTime=3120
Key #40 - dwTime=3200
Key #41 - dwTime=3280
Key #42 - dwTime=3360
Key #43 - dwTime=3440
Key #44 - dwTime=3520
Key #45 - dwTime=3600
Key #46 - dwTime=3680
Key #47 - dwTime=3760
Key #48 - dwTime=3840
Key #49 - dwTime=3920
Key #50 - dwTime=4000
Key #51 - dwTime=4080
Key #52 - dwTime=4160
Key #53 - dwTime=4240
Key #54 - dwTime=4320
Key #55 - dwTime=4400
Key #56 - dwTime=4480
Key #57 - dwTime=4560
Key #58 - dwTime=4640
Key #59 - dwTime=4720
Key #60 - dwTime=4800
Key #61 - dwTime=4880
====================================================

:)
I have not yet completed debugging, but I'm finding a few silly things, like the last line of code in AnimationNode_Load was a call to GlobalUnlock,pNode which I removed since we no longer lock and unlock our dynamic object nodes (we are using Heap-based mem now, remember?)

There's more than one answer to these questions, pointing me in a crooked line..
but the less I search for something more definitive, the closer I am to finding it !!
Posted on 2003-10-31 00:28:08 by Homer
Afternoon, EvilHomer2k.

Great to see you've managed to get something rendering:alright: .

Have you managed to fix the problem with the last vertex stretched to the corner of the screen?
If not, it *could* be that you're telling the rendering routine to render one-too-many vertices or triangles *but* still allocating one-too-many vertices (and hence, there's no crash, but there's no data filled for that last vertice).

Cheers,
Scronty
Posted on 2003-10-31 06:03:28 by Scronty
That sounds logical, except that I don't specify the #vertices to Render, because I am using a SubSet rendering method ... There's been no changes to MeshNode_Render, so the previously posted code ofr that function is still current.

Without discussing the finer points of vertex blending, I am using non-indexed blending and eventually I call ..
mcall .pD3DXBlendedMesh,ID3DXBaseMesh_DrawSubset ,ipattr
..in order to Rend a particular SubSet.

I'll keep bashing this source around until I get some satisfaction :)
At least my attitude towards this project has improved, and that has everything to do with the Debug macros I've implemented (which will be stripped later).

Thanks, and nice to see you back in here.
Posted on 2003-10-31 06:15:21 by Homer
Afternoon, EvilHomer2k.

When you find the time, repost the zipped current updated project files again, including a description of your directory structure for the project (or... where to place the files/folders) and where you place the tiny.x and its texture.

As you've actually got something rendering, work should go a lot faster now.

Cheers,
Scronty
Posted on 2003-10-31 07:03:16 by Scronty
Not a problem, I'll repost when my son gets off my boxen - I'm currently working on a terminal on my LAN, but QED doesn't understand network paths, and I don't plan on installing MASM on this almost full 4 gig hdd, now I've made some changes and I can't recompile from here, so as soon as I have done so I will repost the entire project as it stands.
The changes I made are minor and involve the way I go about creating HeapObjects (like the Root FrameNode of a SkinMesh).
Also I've implemented two more Debug helpers, which are called DebugValue and DebugFloat, more for source clarity than any other reason.
Should have it posted before midnight, he's playing Wolfenstein, it's Friday, and I let him play as much as he likes on Fridays, but he's only 11 and I think even on a Friday that midnight is a reasonable bedtime for an 11 year old...
Posted on 2003-10-31 07:24:59 by Homer
Well, it's Halloween, and my son just turned into a pumpkin :tongue:

Here's the first zip, which contains the project ASM file. If you've been following my Naming convention, you'll notice that I don't use the .asm extension for any files except the main one, basically everything else is a .inc file...

I expect that the zips will contain full paths for easy extraction, but I'll describe the project folder hierarchy anyhoo..

The project folder, called "directxex", lives in the MASM folder, as usual.
Inside here we find all the files included in the attached zip, as well as the usual late-bound dx libs like uuid etc (I know you are familiar with these..)
The project folder contains just two subfolders, called Include and XFILE.
Obviously, XFILE contains our xfiles (just Tiny.x and Fighter.x for now).
Less obviously, any bitmaps used as textures do NOT live in there, they live in the Project folder as well (Fighter.bmp and Tiny_Skin.bmp etc).

Rather than get ahead of myself, here is the first zip as described:
Posted on 2003-10-31 08:45:21 by Homer
Now I'll describe the content of the c:\masm32\directxex\Include folder.
There's a bunch of files and folders in here.
The folders are:
AudioEngine
Camera
Debug
Macros
ObjectManagement
SkinMesh
Terrain

Note that not all code modules are currently implemented...
The files which also dwell in this Include folder are in the attached zip:
Posted on 2003-10-31 08:54:53 by Homer
I'm going to post everything, even unimplemented code, in the spirit of wholeness and completion of the project source.
With that in mind, here's the contents of the AudioEngine folder:
Posted on 2003-10-31 08:56:51 by Homer
...and here is the content of the Camera folder, which describes not only the Camera object but also the Player object which uses one internally..
Posted on 2003-10-31 08:58:26 by Homer
Sticking with alphabetical order, the next folder is the Debug module:
Posted on 2003-10-31 08:59:24 by Homer
and following that would be the Macros folder..
Posted on 2003-10-31 09:00:16 by Homer
The core of the project is the memory manager, aka the ObjectManagement folder..
Posted on 2003-10-31 09:01:15 by Homer
The SkinMesh folder contains several files and some subfolders.
The folders are:
AnimationNode
FrameNode
MeshNode

..and the files in the SKinMesh folder are in the attached zip..
Posted on 2003-10-31 09:03:15 by Homer
The SkinMesh\AnimationNode folder contains the following files..
Posted on 2003-10-31 09:04:04 by Homer
The SkinMesh\FrameNode folder contains the following files..
Posted on 2003-10-31 09:04:53 by Homer
The SkinMesh\MeshNode folder contains the following files..
Posted on 2003-10-31 09:05:22 by Homer
Finally, the Terrain folder (one of the ones in the Include folder), contains the following files:
Posted on 2003-10-31 09:06:35 by Homer
If I missed anything, please let me know.
Also - I wish you guys used RAR !!
At least I could make split archives, the filesize limit on this board is quite debilitating and it's rather painful for me to build all these zips !!
(see the doctored makeit.bat I included in the first zip !!)

There's a little more content I have not included because it is not even CLOSE to being implemented, such as SkinMesh-based vegetation with basic hierarchical animations calculated on the fly (plants that grow with some randomness and can sway in the breeze etc)..
Posted on 2003-10-31 09:08:30 by Homer
Afternoon, EvilHomer2k.

Only a few other items to include:

Your versions of d3dx8math.inc, d3dx8math_fkt.def, and any other main dx file you've modified/created/etc.

Cheers,
Scronty
Posted on 2003-10-31 18:58:14 by Scronty