Hi all you lovers of Homer's splendid work on the OOPSkinMesh project ,

Maybe for you it is a long time ago that you got interested in Homers work on animated skinmeshes.
And maybe you are already focusing on something else. But for me this is a start.
Maybe you could help me.

I am using DirectX 8.1b on a Windows98 system.
When I tried to assemble and link the OOPSkinMesh project, it wouldn't build at first.
According to some comments in the Win32AsmCommunity board, I had to correct some
minor things in Scronty's includes, and in Calebs d3dx8math_fkt.def.
For example: I had to add 2 parameters to the ConvertToBlendedMesh proto in Scronty's d3dx8mesh.inc,
because in DirectX8.0 the function had 6 parameters, and in DirectX 8.1 it had 8 parameters.
In Homers OOPSkinMesh example there were 8 parameters already.

After making these changes, I was able to assemble and link the project, but the application crashed.
It crashed on the ConvertToBlendedMesh line in the GenerateMesh function of the CMeshNode object.


       
mov ecx,me
        mcall .CMeshNode.pD3DXSkinMesh,ID3DXSkinMesh_ConvertToBlendedMesh, D3DXMESH_WRITEONLY, \
padjacencyin, .CMeshNode.rgiAdjacency, addr .CMeshNode.dwAttrCount, \
addr .CMeshNode.pBoneCombinationBuf, 0,0, addr .CMeshNode.pD3DXBlendedMesh


The last information in the DEBUG_LOGFILE.TXT file before the crash was:

*** CMESHNODE_CREATE (RE)_ENTERED WITH THESE PARAMS ***
THIS = 0x1A61F4C
pxofobj = 0x15110E8
pd3ddevice = 0x5D5680
D3DXLoadSkinMeshFromXof returned success = 0xB32340
4427 Faces, 5642362 Materials.
Here we go...
AdjacencyIn    = 0x1A61FAC
AdjacencyOut  = 0x623210
AttributeCount  = 0x0
pBoneCombinationBuf = 0x0
pD3DXSkinMesh= 0xB32340


Can anyone of you, maybe Homer or someone else who is interested in this matter, tell me what could be
the problem?

Friendly regards,
mdevries.
Posted on 2005-09-27 14:05:29 by mdevries
A bit more info on the exception could help - register values and code around the crashpoint
Posted on 2005-09-27 15:37:42 by Ultrano
Homer is rather busy I guess. I would direct him to this thread.
Posted on 2005-09-27 22:49:36 by roticv
Hi Ultrano and roticv,

Thanks for your replies.

Ultrano,
Do you mean the registers before the call, or the registers at the moment of the exception?

Friendly regards,
mdevries
Posted on 2005-09-28 01:09:22 by mdevries
I need to see the code that the macro generated. While I don't know much about D3D, I could help with macros.
Also, I need the values of EIP, EAX and ECX - to see if the crash is really caused by the macro.
Btw, I checked the DX8.1 reference, there the 6th and 7th parameter weren't marked as optional (having value of 0).
Posted on 2005-09-28 06:10:54 by Ultrano
Hi Ultrano,

I don't think the macro is wrong, because it was right for Homer, so it should be right for me too, isn't it. But maybe I am mistaken.
Couldn't it be a hardware problem? I tested it on the before mentioned Win98 system, on a pentium II, without a 3D card, but also on WinXP system, having a 3D card.

Friendly regards,
mdevries.
Posted on 2005-09-28 16:30:11 by mdevries
Hi Ultrano,

Homer uses your ATC to do his OOP-stuff. And when I read his comments on ATC, he is rather lyric about it.
So I downloaded his tutorial on it, and also the 10 tutorials you wrote on it. I became rather enthousiastic about it. So I was wondering: Have you written any more tutorials, because the version of ATC has fairly increased in the meantime. I want to know it's new features. But I couldn't find them. However in one of the threads on this board you wrote:

A brief tute to the newest features in ATC can be found here:
http://www.asmcommunity.net/board/index.php?topic=17987.0


This link isn't working. Can you direct me to it?
Or do you have any more tutorials ready?

I am also curious: What does ATC mean? Does it have something to do with Air Traffic Control? Or am I totally wrong?

Friendly regards,
mdevries.
Posted on 2005-09-29 17:51:52 by mdevries
I had described the new features of ATC in topics here. But later I deleted them while being upset that ATC's users count became 0 ^^".
ATC stands for "A touch of class", like the once-famous music band (kind of a tribute :) ).

What's new in the last, final and rewritten version:
- removed "hardcode" listing, to improve compilation speed
- classes can be 4 types: normal, C++ compatible, COM compatible and non-virtual (without destructor). Their usage is absolutely identical
- set/pcall macro <- important improvement
- some unimportant tools for COM host development

Below's maybe a complete tute on the newest features in ATC. The new features are easy to use, and backwards-compatible.

To define a COM compatible class:

class ClassName,,COM compatible

or

class ClassName,ParentClass,COM compatible


to use set/pcall macros:
Let's assume we're making a DirectSound app:

.data?
DSOUND dd ?
Primary  dd ?
Secondary dd ?
.code

set DSOUND as IDirectSound ; does not generate any code or data.
set Primary,Secondary as IDirectSoundBuffer
...
pcall DSOUND.CreateSoundBuffer,addr RenderedDesc,addr Secondary,0
...
pcall Primary.Play,0,0,1
pcall Secondary.Play,0,0,1
...
pcall DSOUND.Release



That's all :)


iirc, the "foreach" macro was present in some older versions of ATC. But I moved it to a more apropriate file. This macro's usage is like:

foreach vectorAllWindows,invoke CloseWindow,edx

It's tightly connected with some separately defined classes ObjVector,VarVector and HookVector.
Attachments:
Posted on 2005-09-29 20:24:11 by Ultrano
Hi Ultrano,

Thanks for your explanation. When I see your macros: They look nice to me.
Don't be disappointed because it seems people don't use your product.
Maybe more people do, than you think. So, keep up your chin.
And as you can see: It's not only me who downloaded your ATC.INC file!!
Atleast I will definitely use it, because it looks like a good product to me.

Friendly regards,
mdevries
Posted on 2005-09-30 12:36:28 by mdevries

Victor got in touch with me, et voila - here I am :)

I've sent you a PM via this board regarding your queries.
I will help in any way I can.
I've been coding under the OA32 model for some time now.
It's got a lot of user-friendly features, and a fair bit of useless overhead too.
I was not aware that Ultrano was going public with the rebirthed ATC..
Yes I was always happy with ATC even though it was difficult at first for me to understand well.
It was never meant to be used as a teething ring, and I owe Ultrano a lot for throwing me in at the deep end, so to speak. Had I begun with OA32, I am not sure I would have had the same feelings toward oopasm as I do today.. I am not implying that OA32 is inferior, I believe that both models are complementary - ATC has a lighter framework with less overhead and faster execution/smaller size as a result, whereas OA32 has taught me to better understand the tricks and traps, the potential and the limitations of the macro language that is hidden within masm.
I say hidden because an absolute minority of programmers appreciate it, fewer see its true potential, and fewer still understand it well enough to take advantage of it.
Ultrano has a nasty habit of writing uncommented and obfuscated macros which nonetheless are elegant in their simplicity... Biterider's macros are often far easier to read due to his taking the longer approach to certain situations with little obvious benefit at the binary level.
I'm never bloody satisfied, am I? :P

In any event, I found I never used most of the classes which Biterider put so much work into.. I tended to treat OA32 as ATC on rollerskates, writing my own classes while observing the minimum requirements under that model, and taking full advantage of his generous macro set (in particular the debug support has been invaluable).

Biterider and Ultrano, you have done all of us a service, by making it clearer than ever before that the old arguments against asmcoding just don't stack up - whether you realize it or not, the two of you have breathed new life into a dying art, and for that I thank you.
I know that neither of you invented anything here, and we all stand on the shoulders of giants and stuff, but I mean it guys, well done.

I'm willing to rework SkinMesh related code from the ground up, under whichever model you prefer. For me it'll be I think the fourth time around the park in regards to SkinMesh.
A lot of stuff has changed since I wrote that, with new graphic cards on the market and new vendor extensions in the drivers. A lot of water under my bridge too, as I've totally done the OpenGL thing ever since I quit messing with DX stuff..

Hope you all enjoyed my rant lol, have a nice day :)

Posted on 2005-10-02 07:43:04 by Homer
Hi Homer,

I appreciate your offer of rewriting the SkinMesh code from the ground up. Last time you did it using ATC. I guess, it had a good reason that you changed to OA32. Can you share your reasons with us on the board? If you prefer it over ATC, I would suggest you do it using OA32.
Personally I have begun to like ATC. It looks fast to me.

I am very interested in your work, and can't wait to see the first results of your fourth try!!

Friendly regards,
mdevries.
Posted on 2005-10-13 14:33:24 by mdevries
The reason I suggest writing it under OA32 is mostly for the debug support.
ATC basically contains zero debugging support. Unless you like spending lots of time in a debugger/disassembler, you really want to build using OA32.
Once we have the thing working and stable, its a trivial job to switch it back to ATC which will make it smaller and faster.
My debug support for ATC consisted (as you saw) of some wrappers to write junk strings to a textfile. This is fine until you consider the following:
1) theres only one stream of debug output, and no synchronising of multithreaded debug output
2) we can't view the debug stream efficiently during runtime
OA32's debug support consists of a bunch of macros for sending strings to a debug window, which happens to be MDI, so has N child windows = N debug streams, visible during runtime.
You'll need the "DebugCenter" package from Biterider.
Just place the exe someplace permanent and run it once to register its filepath, then you can see the debug output of any application which uses this debugging method.
Posted on 2005-10-17 23:27:30 by Homer
Hi Homer,

It's a great idea, using OA32 to get the product running, and after that translating it using ATC. In this way we can benefit from the best of both models.

I think Utrano will we glad to be hearing that his product isn't dead. In fact, it will outrun OA32 when it comes to size and speed. In what way can we honor him more than by using his model, and by sharing our experiences with it on this board.

Please Homer, when you have something to say, share it with us on this board, because maybe there are only a few people who listen, but in the future many more can benefit from it. At least, if you hadn't published your masm OOPSkinMesh example, I wouldn't be here talking to you, because I wouldn't have known that someone did this excellent job.

As I said earlier, I can't wait to see the first results of your efforts.

Friendly regards,
mdevries.
Posted on 2005-10-18 12:05:15 by mdevries
We have a fair bit of work to do, but most of it is relatively painless.
Our first mission is to build a DX9/OA32 Skeleton application.
That's not such a big task, except that we're going to have to write OA32 classes for D3D9.
We can either take my existing classes for ATC or obtain the DX ones, and convert them to OA32 format.
But before even that, let's decide on an existing demo to translate for our Skeleton.
I suggest we base our skeleton on http://www.riaz.de/download/d3d02.zip
If there's another demo you feel more comfortable about using as the base for this project, let me know.

I'm suggesting this because if we use OA32's fledgling 3D engine we'll probably lock ourselves into staying with OA32, and the whole point of the exercise is to move this back to ATC as soon as its stable, purely for speed and size.
That being said, we should attempt to optimize any support code (such as math functions) as much as we can along the way.

I'm not going to take this project and run with it, I want you to carry some of the load too. If we build this from the ground up and comment the progress in this thread, others can benefit from it as well.
Posted on 2005-10-20 05:55:28 by Homer
Hi Homer,

You are so much more experienced than me.
But ofcourse I will try to carry some of the workload to.

We could use the skeleton in your previous post.
However the skeleton is using D3D9 and I want to use DirectX 8.1,
but if that were the biggest problem to solve, we had only small problems.
In reality our challenges are a lot bigger.

We surely want to be able to switch back from OA32 to ATC without difficulties,
so let's translate the classes you already have. Not only because we can switch
back to ATC, but also because we needn't reinvent the wheel where not necessary.

It always helps to have an example that has been proven to be working.
As I can see your classes are based on Sarmad Kh Abdullah's SkinMesh example,
which he described in the document "Implementing Skin Meshes with DirectX 8".
We could keep doing that. Isn't it?

Friendly regards,
mdevries.
Posted on 2005-10-21 17:07:26 by mdevries
I know I've been conspicuously absent recently.
Time has not been on my side.
Rest assured, I'm working on this project.
I will have something for you shortly.
Posted on 2005-11-07 17:18:48 by Homer
Hi Homer,

Isn't time something we would all like to have more than we really do?
But don't worry. I'm patient.

In the meantime I tried to use OA32 on my Pentium II notebook (Win98). But it doesn't work. It crashes on using DebugCenter.
When I try it on my Pentium IV (WinXP), it doesn't crash. So, isn't DebugCenter meant for a Pentium II?
I hope it is something else. Is this a known problem that can be fixed?

Friendly regards,
mdevries.
Posted on 2005-11-07 17:37:44 by mdevries
Hi
DebugCenter is compiled by default for an Intel Pentium III or above. If you want to use an older processor, compile the ObjMem32 library for 386 and the objects in the objects folder. Finally rebuild the DebugCenter.exe

Regards
Posted on 2005-11-08 01:15:06 by Biterider
Hi
I certainly found a bug in one of the string handling routines for the 386 target.
I also added the DebugCenter.exe compiled for 386.

Regards

Biterider
Attachments:
Posted on 2005-11-08 04:07:27 by Biterider
Hi Biterider,

Thanks for your response.
I'll try it.

Friendly regards,
mdevries.
Posted on 2005-11-08 15:18:14 by mdevries