There seems to be very little happening here.
Has everyone moved to Hutch's new board already?

I'm looking for a little assistance in debugging the SkinMesh support code (see zipfile) which I'm more than happy to place in the public domain (considering that it's based on the example at GameDev and so isn't mine to begin with).

The code provides for loading, rending and manipulating animated skinned mesh objects like player models and is built around XFILE format.
I can also provide the application shell in which I have been attempting to implement the loader - it already contains loads of stuff like support for mouse-based camera rotation ("ArcBall").

Please help me to give something back to the ASM gamecoding community.
Posted on 2003-09-19 15:55:21 by Homer
Well, a week later and less than two dozen of you are even interested enough to take a look - that is both depressing and telling.
I've debugged the Frames Loader and the SkinMesh Loader and helper for converting it into a Blended mesh - I am now debugging the Animation support code and if anyone actually gives a crap they can ask for it.
I still require assistance debugging this code module and I will keep my word concerning posting the finished product.
The term "community" implies social interaction - why does this board make me feel so lonely?
Posted on 2003-09-23 01:17:10 by Homer
Don't despair EvilHomer2k I still loves ya :grin:

I'd like to help but I'm currently waiting for my new computer to arrive and the wait is driving me nuts :tongue:
I'll take a look at your code but I suppect your waaaaay ahead of me but I'll see what I can do.

I must admit that I'm also surprised by the lack of interest :confused:

Maelstrom
Posted on 2003-09-23 03:41:15 by Maelstrom
I can partially understand the lack of interest if placed in the context of dx9 once more containing Frames support, however the dx9 includes I have seen for masm are far from complete, and the majority of the goodies in dx9 are not within reach of the average graphic card...

HOWEVER

The whole point of coding in asm (for me) is the speed and size benefits achieved in comparison to something more loathsome.
Maybe I am going to sound a little jaded (and even just plain old) by stating the obvious, that almost all commercial games were once hand-optimized for speed.
Even the average village idiot would agree that by optimizing the most-often called code we get to shave enough cpu cycles to put into other things like special effects.

I have stated in the past that I am willing to go it alone if I am forced to, because all the best game houses were formed by talented amateurs like myself, but I am just a little ismuth in the middle of an ocean of high level coders who can implement standard code in a fraction of the time that I can in asm.
I would sorely like to take them to task, and have spent some time developing a set of helper api and macros to this end, based on the examples set forth by some of our regs on this board, including Caleb and Scronty.

What's the problem? Do we need a "Thomas" around here to write tutorials aimed squarely at asmcoders?
The gear I base my work on is all cpp sourcecode.
I simply translate it directly and then look for optimisations.
That's one step up from one Scronty does (he has simply translated existing examples directly, without any further effort).
I don't expect to be congratulated for my work, but I kind of expected some show of interest in my optimisations because I know damn well that a lot of cpp coders waltz through here looking for a handout - and that's exactly what I have offered.
Furthermore, I don't like the masm object support code I have seen because it appears not to support dynamic arrays etc. So I coded an entire library of linked list support code because I wanted it and it wasn't available.
If you want something done (right or wrong, just at all), you have to do it yourself. I truly expected this thread to generate more interest in this forum, and I'm rather disappointed to see that most of us are still thinking in 2D terms ...
Posted on 2003-09-24 03:00:43 by Homer
Don't give up EvilHomer2k

I'm very interested in your work as it's something I want to get into myself, but I'm struggling to play catchup at the moment.

I agree with your reasons for using ASM, I'm personally sick of bloatware that eats up my disk space and runs slower than a cow with no legs.
Speed and size have been sacrificed for producivity, but why can't we have our cake AND eat it?

Maelstrom
Posted on 2003-09-24 18:36:56 by Maelstrom
You're a pioneer EvilHomer2k.

Unfortunatly that means it might take some time for the value of what you are doing to be realized by others.



I tried doing some DX9 stuff, but to many problems trying to link with the C++ only lib d3d9h.lib(??).

DX is complicated stuff. I'd guess alot of this board is not ready to get into that yet.
Posted on 2003-09-24 21:13:34 by ThoughtCriminal
I'm personally sick of bloatware that eats up my disk space and runs slower than a cow with no legs.
Speed and size have been sacrificed for producivity, but why can't we have our cake AND eat it?


I think we can :)

My programming philosophy is the same as my style of programming, which might be described as "sitting on the fence" - I like to benefit from the "best of both worlds", and see no reason to reinvent the wheel, while simultaneously being conscious of the calculation bottlenecks in such code as m$'s DirectX Math helpers. I have read articles which describe m$'s DX api as being pretty much already optimized, and also that HAL layer is smart enough to detect hardware and use casecode based on the capabilities of the platform.
This is just a blatant lie.
I have already benchmarked the parts of the dx api which I felt were slow, and even compared to Caleb's naiive fpu helper macros, they are plain slow.
Therefore my philosophy leads me to utilize those parts of dx which are acceptable in their existing form, and simply to replace other parts with hand crafted and cpu optimized case code (especially for things like matrix manipulations and other stuff that can benefit from cpu cache).
My goal is NOT to code a better DX - I am a realist. I shall state my goal as creating a useful and FAST set of helper code for ASM GAMECODERS who wish to take advantage of the existing technology without making the traditional sacrifices associated with the tradeoff between low and high level languages.
(I hear that if you run out of lambs you can use two pidgeons instead).
Posted on 2003-09-25 04:29:41 by Homer
I've spent a little time considering the layout I was using for building the frame hierarchy. After some time I decided to rework it in a way which was both simpler to understand and suited the particular job better.
Here's a silly picture with three diagrams, let's call them A, B and C.
A and B are images of a simple hierarchy which you might find in any tutorial on the subject. Diagram C describes the same hierarchy again, and shows my implementation of tree hierarchies under a 2D linkedlist without the need for any one node to keep more than two links in each direction. It describes the way I will be using the links in my object header fields. I've recoded it already and it seems fine. I'm revising the dependant code to this system and will post the results, but it compiles, and the loader returns without a hitch, and the app doesn't crash, so I might even be bold enough to turn on the Render code shortly :)

Some important things to note about this system:
#1- A Parent may have multiple Children, but only knows the First Child.
It is then assumed that Child will remember the next Sibling, and so on.

#2- All objects know their Parent, this is true even for younger Siblings.
Posted on 2003-09-29 07:41:03 by Homer
EvilHomer2K,

Like you, I would think there would be loads of interest in the work you are doing. Probably like me though, they have limited time and have just not seen it yet.

quoting you:
I can partially understand the lack of interest if placed in the context of dx9 once more containing Frames support, however the dx9 includes I have seen for masm are far from complete, and the majority of the goodies in dx9 are not within reach of the average graphic card...
end quote:

I downloaded the dx9 SDK only to find that everything ran in rasterizer (turtle) mode. On investigation I found that your card has to support dx8 or better. Luckily ATI had a driver update for my older Rage Fury card and now can run HAL. So, while I can't use most of the new goodies, many of the examples that come with the SDK will at least run software mode.

Like you, I think the Frames support would be great and was sorry to see them discontinued in dx7. Thankfully, they continue to support xfiles and I believe this would certainly be an area where someone could make an excellent contribution, along with optimizing everything else. :alright:

I no doubt have the same dx9 includes you speak of and they are quite incomplete. I did play around some with the example he included with them, and managed to do some cool things.

The lack of dynamic arrays is an issue and I would like to see your implementation. I don't think they would be particularly hard to code, but hey, why reinvent a good wheel. I think they would be especially useful in an editing app.

Well, this is getting long winded, and I probably jumping around crazily, so will close with this:

Nice to see the interest in this area, and will stay tuned.
Posted on 2003-09-29 11:18:14 by djinn

I've spent a little time considering the layout I was using for building the frame hierarchy. After some time I decided to rework it in a way which was both simpler to understand and suited the particular job better.
Here's a silly picture with three diagrams, let's call them A, B and C.
A and B are images of a simple hierarchy which you might find in any tutorial on the subject. Diagram C describes the same hierarchy again, and shows my implementation of tree hierarchies under a 2D linkedlist without the need for any one node to keep more than two links in each direction. It describes the way I will be using the links in my object header fields. I've recoded it already and it seems fine. I'm revising the dependant code to this system and will post the results, but it compiles, and the loader returns without a hitch, and the app doesn't crash, so I might even be bold enough to turn on the Render code shortly :)

Some important things to note about this system:
#1- A Parent may have multiple Children, but only knows the First Child.
It is then assumed that Child will remember the next Sibling, and so on.

#2- All objects know their Parent, this is true even for younger Siblings.


Wanted to PS your work. Looks good and is consistent with the .x file format. It will be interesting to see how you continue.
Posted on 2003-09-29 11:21:43 by djinn
Today I found one of those nasty intermittent bugs - you know them, you love to hate them.
The Materials Parser section of the SkinMesh Loader contained a call to RtlMoveMemory which was trashing the esi register (which I use as an object pointer, so is critical to my code).
Maybe a Micro$oft employee can tell me why RtlMoveMemory trashes registers sometimes and not others :)
Posted on 2003-09-30 12:43:37 by Homer
I'm almost happy with the majority of the code in the hierarchical parser.
I have it building a complete frame hierarchy, converting the skinmesh into a blended mesh, and am currently debugging the code which is meant to link bone data to frames of the same name. Seems to be another case of a trashed register, am looking into it.

Isn't it nice when things just work the first time?
Posted on 2003-10-01 10:29:54 by Homer
Ironed out a few wrinkles in the Animation Loader.
Here's an update of the complete module.
Posted on 2003-10-03 02:51:10 by Homer
I might have uncovered the source of my intermittent stack issues ...

My LinkedObject support code basically allocated memory for new objects (and locked it) until the object was destroyed (where it was unlocked first).

This is a bad thing.

I've reworked the codebase so that objects are not locked at creation, but are locked and unlocked whenever we need to access their contents.

Can anyone tell me - is this only necessary for WRITES?
Posted on 2003-10-04 23:45:43 by Homer
It's a bigger issue than I thought.

I'm reworking the ENTIRE codebase to work with Handles to Objects instead of using Pointers to objects.

All functions will now take handles rather than pointers in their parameters.

All functions will assume THIS object to be UNLOCKED ON ENTRY.
This requirement means that sometimes we'll need to UNLOCK the current object before passing its handle to one of our functions, and then RELOCKING IT for the duration of that procedure.

You can possibly imagine how much hair I have lost. Doh! :(
Posted on 2003-10-06 04:15:28 by Homer
Entire codebase reworked in a single day (well, with loads of stuff disabled, it compiles and runs once more...)

Since the changes were made so quickly, chances are that I will encounter bugs in the changes as I re-enable further code sections, but I'd have to say that the changes are being implemented quite quickly indeed considering how long it's taken to put the codebase together :)
Posted on 2003-10-06 10:08:34 by Homer
All the codebase up to but not including SkinMesh has been patched and enabled.
At the moment, the app is rock solid. Yay !!
Now I'm bound to stuff it up :)

Patching and debugging of the SkinMesh code module was resumed.
Sigh.
Posted on 2003-10-07 09:34:16 by Homer
Hey EvilHomer2k

Why do you need to lock and unlock your memory?
What app do you use to create your models?

Anyway, sounds like your slowly winning the battle so what do you have planned for this code?


tell me why RtlMoveMemory trashes registers sometimes and not others


You know the MS slogan 'That's not a bug, it's a feature!' :grin:

Maelstrom
Posted on 2003-10-08 20:37:57 by Maelstrom
Why do you need to lock and unlock your memory?


My application is object-oriented, and the objects are stored in dynamic arrays rather than being hardcoded as global data. I dynamically allocate memory for each and every object I use, which returns me a handle to that object.
I then store that handle for later reference, and quite often that handle is being stored as a field of some OTHER object. In order to store something inside one of my objects, I need to access the object. Calling GlobalLock on a handle returns a pointer to the object memory that I believe CHANGES depending on the context of the caller. Regardless, its good practice to lock memory before you access it, and to unlock it when you are done with it.

In my old version of LinkedObjects support, I used to lock objects as soon as I created them, and store not the Handle to the object, but the Pointer to its memory. As I allude to above, this Pointer can become invalid for some calling contexts even though its valid when its created.
I'd only Unlock the object when I destroyed it, and inside all my code I'd pass "Object Pointers" whereas now I pass "Object Handles" which makes not a HECK of a lot of difference to my code, just a few Lock and Unlocks here and there.

What app do you use to create your models?


I use Maya 4.0 and I use m$'s xfile exporter plugin.
I keep my models in Maya format (MA or MB) because its actually more powerful than XFile alone, and because I go through HELL to import an xfile back into Maya (I have to convert it to several intermediate formats first).

Anyway, sounds like your slowly winning the battle so what do you have planned for this code?


I'm planning on creating an open-sourced gamecoding support library for asm coders as well as high level script kiddies and anyone else who likes fast software.
The project is educational and non commercial, and you can do with it whatever you like, provided you credit the contributing authors.
Posted on 2003-10-10 01:38:31 by Homer
After much hair-tearing, I went back to the cpp source apon which I am modelling the SkinMesh Loader.
On closer examination of its Frames Parser, it appears that it simply IGNORES REFERENCE AND BINARY OBJECTS and ONLY processes DATA OBJECTS.
This is contrary to the algorithm provided by the author !!

I'll try handling only DATA Objects which are Frames, and ignore ALL else, and see what happens to my poor old much-maligned Frames Parser.
Sigh.

Some days you just seem to revolve in ever-diminishing circles until you disappear up your own fundamental orifice :(
Posted on 2003-10-10 04:15:13 by Homer