Heya.. I'm having a problem and looking for an answer.
Let's suppose I want to load a mesh, then store it in a "container" object
which is just a struct and a chunk of dynamically allocated memory...
I have found that I cannot access anything directly stored this way when calling any of the directx interface methods (at least using mcall).
I can use the application data segment, or I can use locals (application stack),
but I cannot use memory I allocated myself.
I'm allocating memory with GlobalAlloc.
Would using HeapAlloc fix my problem? The Win32 api helpfile says that GlobalAlloc allocates "heap" memory !!?!
If the application has access to the memory it allocates (which it does), and if the application launched directx (d3d in my case), then why would directx not have direct access to the allocated memory? How could I solve this?
Does using a growable heap mean the app's stackspace is elastic?
Posted on 2003-02-17 04:59:35 by Homer
Afternoon, EvilHomer2k.

Show some code please? ;)

I'm guessing that the problem is with the first param passed in mcall. Have you tried putting the pointer into eax/edx/esi/edi/whatever first and using that?

Posted on 2003-02-17 05:29:57 by Scronty
ok basically what I have is a proc which is kinda like a frames loader:
I create a container object for a mesh, then I call a proc to load a mesh into the container object ... I successfully load a mesh...
I do all the usual stuff: allocate some memory for materials and textures,
then I shove pointers to those, plus the mesh interface pointer (pMesh), number of materials and anything else relevant into fields of my container object, and return from that proc, happy that I've loaded the mesh correctly.
In my Render function, I loop through the material and texture arrays together, setting the material and texture for each subset of the mesh. Then when I try drawing the incremental subset (using my stashed pMesh) I get a nasty crash...
It's crashing exactly on that call, after successfully setting material / texture.

Does that tell you anything? If not I'll post the code - I am going to anyway, it's an attempt at a functional win32 dx8 game skeleton, based on Donuts3D. It contains the beginnings of physics and has directmusic and other stuff implemented.
I have a mountain of code to add to it (particle engine, animated meshes etc) but I just can't seem to get a grip on this issue.
Oh - and yes, I tried using a register indirection and a local redirection.
Weird how sometimes one of those will work where the other fails too.
Posted on 2003-02-17 06:05:27 by Homer
Afternoon, EvilHomer2k.

k. Next thing I'd like to know is whether you're creating/loading/whatever the mesh/texture/whatever using local variables? If so, then remember that the local stuff is on the stack and is destroyed when the proc returns. This means that the pointers you've just loaded into the container object are pointing to somewhere on the stack which has an invalid value.

Posted on 2003-02-17 06:37:09 by Scronty
Well, that's a good question.
I was forced to use locals as an intermediate to my object.
That is, I'd load the mesh using locals, and store all the good stuff in the container object before leaving that proc, so yes, It's not that obvious, though I agree, it's usually something obvious :)
I have created and used meshes before, but I've always kept their vitals in the data segment, or in dynamically allocated memory whose pointer is stored in the data segment, like you do in your examples.
It's only when I try using container objects in dynamic memory that I have an issue.
I'll prepare the code, though you can look straight to StaticObject_Create if you wish... it's the entrypoint to the problem code.
Anyhow I'll post that in a moment.
Posted on 2003-02-17 06:50:03 by Homer
Here's the code...
unfortunately I had to strip out some media - just an xfile and a bmp used in the splashscreen
Posted on 2003-02-17 07:03:04 by Homer
awwwww cmon - it's not THAT scary is it?
Posted on 2003-02-20 21:44:26 by Homer
Afternoon, EvilHomer2k.

Just having a few problems getting it to reassemble so that I can check the error.

Just looking over that proc you mentioned:
I see that you use the SADD macro for the MessageBox calls. I've found in the past that the usage of these macros (SADD/CTEXT/etc) sometimes cause proggys to crash for some unknown reason. Try taking them out or replacing the SADD parts with strings already declared within .DATA and see if it works. This may be a bug with Masm rather than your code.

Posted on 2003-02-21 05:23:13 by Scronty
ok maybe a better idea...

I'm going to mess around with your "meshes" example, and try to encapsulate the loading of the mesh into a container structure.
In fact, I've already had one unsuccessful attempt at it.
Would you prefer to write an example showing this, say for your site?

Oh ps - I had to modify the DirectMusic include headers just a tad to stop them from reloading certain already loaded includes.
You could just disable all references to music if that's the compile problem.
Posted on 2003-02-21 23:05:06 by Homer
Here is a mostly complete and very working encapsulated mesh example.
I brutally ripped your example code, just to get the idea working.
I'll now backwash this code with my existing code to complete the encapsulation of the loading process and creation of instances of the reference object, and importantly, the encapsulation of the the creation of the the container object.
I am posting the code so you can see clearly what I am doing. I claim no rights to the code I am about to post - Scronty, this is just an elaboration on one of your examples, and as such should prove worthy example source.
Posted on 2003-02-22 00:20:44 by Homer
I have now backwashed that working code into my project code.
I have disabled positive messageboxes.
I have disabled most everything irrelevant to the current issue.
This code compiles nicely.
I am forcing the app to draw a mesh object from a fixed viewpoint as per my encapsulation expansion to your "meshes" example source.
What happened to my textures? The mesh is all white !!?!
Can you see what I'm doing wrong here?

(as usual - some media and all runtimes not included due to size restriction)
Posted on 2003-02-23 00:05:13 by Homer
Afternoon, EvilHomer2k.

The texture name given to D3DXCreateTextureFromFile inside LoadStaticObjectFromXFile.inc would probably not have any pathname for it. This means that any texture would have to be within the main working directory. Since the texture isn't found, that texture is made NULL which allows the setting of a texture to work correctly.

Posted on 2003-02-23 06:25:13 by Scronty
LoadStaticObjectFromXFile is called by StaticObject_Create, which first calls FindMediaFile to search for the filename and replace it in future calls with the fully qualified path. It finds the the texture, and I'm sure the texture is being loaded.
It's something more basic methinks, possibly in the Render state?
I just transplanted working code from one app to another.
Does my D3D initialisation look ok to you? (CreateDisplayObjects)
What's happening when i load your little spaceship, its drawing only one surface, and drawing it in white.
What irks me is that I just got this code working in the JustTesting example.
When I try to run it from my application shell it fails...wtf?
The application shell doesn't differ greatly from say one of yours, and is in fact a fairly straightforward translation of an m$ example.
Maybe I'll have another beer after all.
Posted on 2003-02-23 09:54:08 by Homer
Afternoon, EvilHomer2k.

LoadStaticObjectFromXFile is called by StaticObject_Create, which first calls FindMediaFile to search for the filename and replace it in future calls with the fully qualified path. It finds the the texture, and I'm sure the texture is being loaded.

The path you supply is for finding the X file itself. Is the texture for the mesh within the same folder as the X file?

Posted on 2003-02-23 16:51:14 by Scronty
ah.. yes it is... and I see what you mean about the texture filename.
Modified LoadStaticObjectFromXFile to call FindMediaFile for each texturefile.
Made stuff all difference, because the texture is in the project root folder.
Regardless, the texture IS being loaded... I'm using your version of SetupMatrices... I'm still getting the feeling that I'm setting a bad render state someplace before I start rending...
How does my d3d initialising look ??
Could it be an incompatible pixel format or backbuffer format?
(btw - thanks for putting up with me - obviously I'm not a timewaster :))
Posted on 2003-02-23 23:11:25 by Homer