Just a quick question regarding object behaviour under D3D8.
When I load a Mesh that contains multiple Materials and Textures, when I load the Texture for a Material (in a loop), should I be concerned about a single Texture being loaded multiple times? What I mean is - will I get returned a pointer to a loaded Texture if I try to load the same Texture twice (which is the standard COM behaviour) or will it return a different pointer, having successfully Loaded the Texture more than once?

IE Should I be keeping an array of "loaded texture filenames" with associated Pointers to the loaded Textures, and then checking the entire array everytime I go to load a Texture - or will D3D do this for me thanks to COM?
Posted on 2002-05-26 02:58:18 by Homer
Afternoon, EvilHomer2k.

You'll have to keep your own record of what textures have been loaded.

The X fileformat is open, so that it leaves it up to the programmer to decide on what is actually loaded.

Whether or not it's a good idea *not* to allow duplicated textures to be loaded would depend on what effects you're going to allow i.e. *with* duplicates, chip-marks from bullets could be drawn directly onto a particular walls' texture.

Cheers,
Scronty
Posted on 2002-05-26 03:56:31 by Scronty
Thanks for the quick reply.
I planned for this YAY :D

I keep an array of MyTextureStructure structs as follows:

MyTextureStruct STRUCT
lpFilename LPSTR <> ;Pointer to a loaded Texture Filename
g_pMeshTexture dd ? ;Pointer to a loaded Texture
Redundant dd ? ;Flag for destruction
MyTextureStruct ENDS

MyTextureArray MyTextureStruct MAXIMUM_TEXTURES dup (<>)

When I load an Object, I store its Textures as an array of indices into this MyTextureArray array,
and in my Object structure I keep a pointer to that array.
This way, if I have 500 references to a single TextureFile in the Materials List of a single Object Mesh, it would only ever be loaded ONCE.
I use a similar strategy in order to implement a map of Instances of a Loaded 3D MeshObject within a Sector of my portal-based engine, again, allowing iteration without overhead.
Note the use of a Redundancy flag in the textures array, it also appears in my loaded objects array (not the instances map)
and I use it to save reloading common objects (and textures) when a new level is loaded !!! :)
I do appreciate your remark concerning local surface blemishes (as I call them), they can't be encoded into a regular x-file hierarchy unless you have separate material and texture for every surface, thats too much overhead, so what I do is simply keep an array of flags the same length as the number of surfaces, and the value of the flag identifies the blemish (it's actually a texture index, too), which is blended at stage 1, thus a soft limit of one blemish per surface.
You may care to note that my surface blemishes are permanent, ie don't have a TTL.
It's been a few weeks now and I still haven't even tried to compile my source, it's a pretty big project and I wanted to get it right the first time, think it through.
I very much appreciate this forum, and thanks, for what it's worth.

For anyone who's been curious about my recent postings,
here is most of the RunTime data structures I use for my Hybrid Engine, with a fair bit of commenting.

;=====================================================================
; The following structures are used to define the format we use
; to store information for all the sectors in the 3d world
; once they've been loaded by the Loader.
; Each Sector has its own InstanceMap which is a map
; of Instances of loaded objects relative to the sector they live in.
; The actual objects themselves are kept in a similar yet separate array.
; The reason is that objects which are Instanced more than once
; (and especially where we have Instances of the same object in
; more than one Sector) are only loaded ONCE in the main Object Array.
; A Sector's ObjectInstanceMap merely identifies an Instanced object
; by its Index in the array of loaded Objects, and also contains
; a set of transformation matrices for positioning, rotating and scaling
; of the Instanced object relative to the origin of its Parent.
; Thus a loaded Object can appear in different sectors, in different
; positions in those sectors, in different orientations and at different
; scales with complete independence, and MAY BE MANIPULATED EASILY.
; For example, we may pick up a hammer in one sector, carry it through
; a Portal into the next Sector, and then drop it in there.
; The game will REMEMBER EXACTLY the new position and orientation of the
; object instance, and other players will see those changes too.
; It is up to the Loader to determine whether Instanced things like
; Sector Objects have been already Loaded or not.
; That goes for Textures too.

;--------------------------------------------------------------------------------------------
;The D3DVERTEX Structure defines our custom Flexible Vertex Format (FVF)
;It contains 3D position coordinates for a single vertex,
;the 3D Normal Vector of the Vertex,
;as well as the 2D Texture Coordinates of the Vertex.

D3DVERTEX struct DWORD ; Lets's define a D3DVERTEX structure
position D3DXVECTOR3 <> ; The position of the vertex in 3D
normal D3DXVECTOR3 <> ; The normal vector (also 3D)
tu FLOAT 0.0f ; The texture coordinate in X, and
tv FLOAT 0.0f ; The texture coordinate in Y.
D3DVERTEX ENDS ; And that, my friends, is a D3DVERTEX.

sizeofD3DVERTEX EQU (sizeof D3DVERTEX) ; Well that's nice dear.
D3DFVF_VERTEX EQU (D3DFVF_XYZ OR D3DFVF_NORMAL OR D3DFVF_TEX1) ;What we're using

;---------------------------------------------------------------------------------------------
;The My3DRotation Structure houses three floating-point values.
;They define rotation around x,y and z axes.

My3DRotation STRUCT
fYaw FLOAT ? ;Yaw is @X rotation, ie it's YZ (nod your head positively)
fPitch FLOAT ? ;Pitch is @Y rotation, ie it's XZ (shake your head negatively)
fRoll FLOAT ? ;Roll is @Z rotation, ie it's XY (tilt your head questioningly)
My3DRotation ENDS

LightInstance STRUCT ;This defines an single Fixed Light within a Sector.
Position D3DVECTOR <> ;3D Position of the Light in the Sector.
Diffuse D3DCOLOR <> ;RGB Color of the Light
Intensity
;---------------------------------------------------------------------------------------------
;The ObjectInstance Structure holds all the data for a single Instance of a loaded Object
;within a Sector. It contains an ObjectID (which is simply the Index of the Object within
;a global array of Pointers to loaded Objects), some structures defining the object's
;orientation and position, the object's 3d trajectory if it is under "rigid motion",
;and the object's rotational change if the object is under "rigid rotation".

ObjectInstance STRUCT ;This defines an Instance of an Object within a Sector.
ObjectID DWORD ? ;Index of a loaded 3D Object within our array (what am I?)
ObjectOrientation My3DRotation <> ;3D Rotation of the Object Instance (which way am I facing?)
ObjectPosition D3DVECTOR <> ;3D Position of the Object Instance (where am I?)
ObjectRotation My3DRotation <> ;3D Change to Orientation
ObjectTrajectory D3VECTOR <> ;3D Change to Position (Velocity and Direction)
ObjectLocalMatrix D3DMATRIX <> ;Local Matrix is used to hold concatenated object matrix
ObjectInstance ENDS

;----------------------------------------------------------------------------------------------
;The SectorLightsMap Structure defines a map of Instances of Fixed Lights in a Sector.
;Firstly, it has a Counter for how many Fixed Lights are in this Sector, and then it has
;an array of D3DLIGHT Structures (defined elsewhere).

MySectorLightsMap STRUCT ;This structure defines a map of local lights in a Sector.
NumLights DWORD ? ;How many Fixed Lights there are in this Sector.
LightsMap D3DLIGHT8 MAX_FIXEDLIGHTS_PER_SECTOR dup (<>) ;Array of Lights
MySectorLightsMap ENDS

;----------------------------------------------------------------------------------------------
;The SectorObjectMap Structure defines a map of Instances of a loaded Object within a Sector.
;Firstly it has a Counter for how many objects are in this Sector, and then it has
;an array of ObjectInstance structures (defined above).

MySectorObjectMap STRUCT ;This structure defines how we keep Instances of a loaded Object
NumObjects DWORD ? ;How many objects are there in this Sector
InstanceMap ObjectInstance MAX_OBJECTS_PER_SECTOR dup (<>) ;Array of Object Instances
MySectorObjectMap ENDS

;---------------------------------------------------------------------------------
;The Sector Structure holds all the data for a single loaded Sector.
;It contains a handy pointer to the Object Mesh for this Sector,
;a handy pointer to the MeshMaterials array for that Sector,
;a handy pointer to the MeshTexturePointers array for that Sector,
;a map of Instanced Objects which appear in that Sector (described above), and
;a map of Local Lights which appear in that Sector (also described above).

MySectorStructure STRUCT ;This structure holds sector-unique data
lpSectorFileName LPSTR <> ;FileName of this Sector.
g_pMesh LPD3DXMESH <> ;Pointer to sector Mesh Interface
g_pMeshMaterials dd ? ;Pointer to sector MeshMaterials Array
g_pMeshTextures dd ? ;Pointer to sector TextureIndex Array
g_dwNumMaterials dd ? ;Number of Materials in this Mesh
SectorObjectMap MySectorObjectMap <> ;Map of local objects in Sector (see above)
SectorLightsMap MySectorLightsMap <> ;Map of local lights in Sector (see above)
Redundant dd ? ;Flag for destruction
MySectorStructure ENDS

;---------------------------------------------------------------------------------
;The World Array is basically the whole world.
;It is an array of MySectorStructure(s) which you will find defined above.

World MySectorStructure MAXIMUM_SECTORS dup (<>)

;----------------------------------------------------------------------------------
;The Texture Array is used to store an array of pointers to texture filenames.
;Each time a texture is loaded, we store a pointer to its filename,
;and a pointer to the loaded texture. This may be unnecessary but I wanted to avoid
;textures being loaded multiple times, so this serves as an indexed array,
;thus as we load new textures, we can check if they are loaded, and if so,
;we can use the existing texture pointer.

MyTextureStruct STRUCT
lpFilename LPSTR <> ;Pointer to a loaded Texture Filename
g_pMeshTexture dd ? ;Pointer to a loaded Texture
Redundant dd ? ;Flag for destruction
MyTextureStruct ENDS

MyTextureArray MyTextureStruct MAXIMUM_TEXTURES dup (<>)

;-----------------------------------------------------------------------------------


I'm still open to suggestion and abuse, so any feedback positive or negative from anyone remotely interested in 3D would be greatly appreciated. Thanks in advance.
Posted on 2002-05-26 14:36:08 by Homer
Afternoon, EvilHomer2k.

Good start:alright: .

... now on with the abuse :grin: ...

My3DRotation STRUCT 

fYaw FLOAT ? [COLOR=red];Yaw is @X rotation, ie it's YZ (nod your head positively) [/COLOR]
fPitch FLOAT ?[COLOR=blue] ;Pitch is @Y rotation, ie it's XZ (shake your head negatively) [/COLOR]
fRoll FLOAT ? ;Roll is @Z rotation, ie it's XY (tilt your head questioningly)
My3DRotation ENDS

... should be ...
My3DRotation STRUCT 

fYaw FLOAT ? [COLOR=blue];Yaw is @Y rotation, ie it's XZ (shake your head negatively) [/COLOR]
fPitch FLOAT ?[COLOR=red] ;Pitch is @X rotation, ie it's YZ (nod your head positively) [/COLOR]
fRoll FLOAT ? ;Roll is @Z rotation, ie it's XY (tilt your head questioningly)
My3DRotation ENDS


A few other items to remember...

The maximum number of lights, if you're using hardware acceleration, is usually 8. However, the proggy really should check the vidcard statistics to find out what is available.

Your idea of reusing the mesh objects, and just have separate rotation/orientation structures is a good one.
The next step is to have the LOD of each mesh object inside the objects' X file. That'd make it easier for your proggy to select which mesh-detail to use.

Cheers,
Scronty
Posted on 2002-05-26 18:05:38 by Scronty
Thanks for the feedback, and yep ur right silly me:tongue:
I'll take on board your suggestion of using Level Of Detail data within the X-file...well I was going to keep just one high-polygon copy of each mesh, load it fully for use in cut-scenes, clone it and simplify it for in-game use, but I like your suggestion better.

Can you tell me what happened to RetainedMode?
I've been using your includes for dx8 and dx8.1
In particular the IDirect3DRMFrame interface seems not to be at all referenced... or are those includes meant to cover IM only?
Posted on 2002-05-29 00:18:04 by Homer
Afternoon, EvilHomer2k.

No more "Retained Mode" junk. It's all combined. Most of the fancy stuff is in the D3DX calls.

Cheers,
Scronty
Posted on 2002-05-29 00:54:22 by Scronty
I assume then that D3DX api covers Frame-specific functions as well then.. I'll take a look again at D3DX though I don't recall seeing any references to framebased functionality, from memory it was about skinning models and using indexed matrix arrays etc... and I just took a look in my 8.1 sdk at the H file for d3drm and then took a look at your include.. oh dear.. seems you don't have it. Neither does Caleb. But the SDK does. And so I have begun the task of converting the H file by hand, using your includes compared to their originals as a guide.
Is the reason that RM headers have not been converted due to the use of L2INC ? OR am I totally misguided in assuming that because it made it into the sdk that it is part of the sdk?
We were told in the dx7 sdk to expect a new interface in 8.
I'm feeling stupid here. help!
Posted on 2002-05-29 03:01:16 by Homer
I've just re-examined the d3dx reference at MSDN.
Guess what.
D3DX is a two-part API.
The first section has a variety of matrix math functions.
The second has a number of texturing functions.

This appears to be aimed at Immediate Mode programmers who are too lazy to code their own matrix math.
I want to be a lazier Retained Mode user for a very good reason - only the RM api offers us a ready-made hierarchical frame manipulation and rendering library.
I have been creating my own hierarchical structure as you saw earlier, but only through sheer lack of information.
The entire Retained Mode Reference at MSDN is a mess of broken pages, although picking through articles I have found enough working links to good information to identify the header files have been updated in dx8 and 8.1
If I am wasting my time converting these headers to masm format then let me know please!
Otherwise, if as I suspect they have never been converted to MASM format since dx6, then they probably should be.
I realize that I could use those functions to perform most of the tasks I require, but why the hell should I if an api exists already, I could better spend my time on the perfect vertex shader than wasting time constructing limp hierarchies !!
Down with the system !!!
Posted on 2002-05-29 03:13:38 by Homer
Afternoon, EvilHomer2k.

DX8/8.1 doesn't use RM. Those files are for DX6 & 7.
If you're planning on coding in DX8/8.1, then don't use that file.

Cheers,
Scronty
Posted on 2002-05-29 03:28:11 by Scronty
That is a terrible shame !!
Sure we can code functionally with D3DX - so we are supposed to invent our own frame format/object hierarchy structure, similar to what I proposed? We're meant to code a rending function which walks our structure? This is not going to encourage beginners!
I thought the CONCEPT of frames-of-reference was a sound one... I can't understand why m$ have dropped it... figured if anything that they would have EXTENDED it's functionality!
I won't go ahead and convert the headers, obviously the GUID is the same as the old one.
I will have to forge ahead with my own structures. Yay!!
That's what I love about programming, even when you lose, you win :)
Thanks again for your prompt replies, I'm gonna go bury my head in a bottle of scotch and then get funky on the keyboard:tongue:
Posted on 2002-05-29 03:38:35 by Homer
Afternoon, EvilHomer2k.

I think what you're talking about is what M$ is now calling "common DirectX code" which is in their (SDK root)\Samples\Multimedia\Common directory.

I started translating some of that stuff for the DolphinVS example, however I've only done a few basic procs for it.

Cheers,
Scronty
Posted on 2002-05-29 03:44:20 by Scronty
Ok I took a look at the common code,
it doesnt cover what I wanted, nevermind.
I wanted to make it easy to attach the END of a chain of objects to some remote vertex, and force the orientation of the nodes.
For example, attach a character's hand to an apple in a tree, and then morph between the original arm matrices and the new arm matrices during animation.

Anyway, I did look at your Dolphins sample and I noted that you made no use of Bones. Interesting , vertex tweening using vertex blender. Nice !!

The application I have in mind must be able to assemble animated models from a library of generic bodyparts, so although not immediately suitable, it did lead me down new paths.

While working on the concept of mounting a Camera within
the Head of each character, something occured to me in terms of first-person view which is worth noting and I ask your opinion.

The Camera needs a Position vector, and a Direction vector,
and an "UP" vector normal to one another.
The values need to be transformed in realtime, but due to floatingpoint rounding error, we need to keep a copy of the original values to avoid spatial distortion.

I was thinking about the way dx stores bone models, (in the past I have used a system based on mobs using sprites with attachment points) and I thought, well, bones are just extra vertices in the mesh, right? And they are just remembered using the Index of the vertex, right?
Well what if we represent the Camera by just adding two extra vertices to the Head? The third of course is its Origin.
Then, when I build my animated character, I can calculate the rays in realtime for Direction and Up using those vertices, and Postition is Origin of the Head!!

I don't wanna waffle on, I think I covered the idea.
What do you think?
Posted on 2002-05-30 03:35:53 by Homer
Afternoon, EvilHomer2k.

k. That'd work, depending on exactly what you wish to happen.

For instance....

Are you wishing to have moveable eyes as the camera? or would the camera be the direction the face is pointing in? The usual way is to have the camera pointing in the direction of the face, therefore you can get away by just using the face(head) position and direction, and just offset the coordinates by where the eyes are in relation to the head.

As for how to transform the camera into world space, I made the "Fly" example especially for the purpose of figuring this out. It "gimbal locks" the camera to get rid of those floating point errors.
I haven't got around to uploading the source for the example, however it's quite simple once you've seen the code to do it. Let me know if you wish to see the code for the camera.

I was up to the stage of looking into boning and skinning when I got a little sidetracked ;p .

The support for animation is strongly lacking in DX8/8.1 . You've got to create the procs for the animation yourself.

Cheers,
Scronty
Posted on 2002-05-30 06:30:02 by Scronty
This is the system I propose:
The Camera Origin == The Head Origin, and backface culling is ON.

Therefore, we are looking in the direction of the face.
No, I didn't plan on moving the eyes :tongue:

What I plan to do is firstly to load a number of bodyparts into a custom array. The bodyparts are skinned dx meshes, and are animated individually. Models are built by my application on-the-fly, allowing for building of models from arbitrary parts, and allowing the model to be blown to bits more easily, and more importantly in my case, to function with bits missing.

During normal runtime, the model is kept as a single skinned mesh, and I intend to code a vertex-shader and perform either a morphed or interpolated tween between the last and current animation matrix.

The premise of all of this was to have two sets of animation matrices for the player-model...
The first is based on the orientation of the Head (ie the Camera) as follows: Orientation of the Head creates a rotation matrix which is applied back down the torso-chain in a degrading linear fashion, ie, the matrix values are rationalized ("ratio") for all the bodyparts in the chain, so that the pelvis (root) is unaffected.
Thus the upper-half of the model will twist and bend to suit the view, and will translate the camera accurately as it does so.
When I wasn't bending the model, I would use that to preset the build-time orientation of those bodyparts.
To achieve to bend-displaces-camera affect, I think I still need them,if I want to do it right, because...
The second set of animation matrices are used for animating the overall stance of the model depending on the player's action.
That covers running, jumping, crouching, aimed tracking, scratching of private parts, or whatever else we'd have the model doing.

What I have done is create several base structures which define an animated model. For example, there is a structure that covers humanoids, one for arachnids, one for four-wheeled vehicles, and an open one which could be used to make an 18-wheeled truck that has tentacles coming out of the cab.
It works using a 3D implementation of my oldschool 2d attachment-vertex method, which is just a hierarchical object structure that keeps an extra vertex for each attached child.
It's power lays in its linked-list implementation, allowing for each node to know its parents identity matrix, have its own identity matrix, and have N child nodes. This makes for complex beasties.
Of course, it's a little generic, thus the specialized structs for common animated objects.

Remembering that I am coding a Game Engine here, I am trying to allow the game designers as much freedom as possible while squeezing all I can from the common tools out there.

Ok question for today I guess would be this :
Assuming I had built my model in BIND pose from a number of smaller (!skinned and animated!) objects, how would I go about blending all those objects into a single skinned and animated object for final animation under the control of the vertex-shader?

You did it using Vertex-Streaming, in your Dolphins example.
Think I could do both transformations in a single pass by applying both the matrix-sets in the vertex-blending pass?

I don't have experience with vertex-shaders, though I hear it's simple enough if ur into opcodes, so I am just trying to decide the best time to apply these transformations.

It's good to see that the thread is generating some interest.
As usual, all feedback is welcome.
Posted on 2002-05-30 07:22:57 by Homer
Afternoon, EvilHomer2k.

Ummmm...dunno if vertex blending is what you're wanting though (that's what the DolphinVS example uses).

It takes three meshes of a dolphin (head up tail up| head horizontal tail horizontal|head down, tail down) and it uses vertex "weights" to blend between them. As the weights are changed, so the rendered object looks closer to one mesh than the other.

This doesn't use your idea of separate sections of body parts.

You'd still need to iterate through each of your body parts. I started doing something similar to this with the "Tentacle" example. It uses three meshes (two simple cylinders for the "arm" and a modified cylinder for the "tip"). It uses two matrices to transform the meshes (blends between two world matrices).
i.e.


mcall [pd3dDevice],IDirect3DDevice8_SetTransform, 256, ADDR matWorld3
mcall [pd3dDevice],IDirect3DDevice8_SetTransform, 257, ADDR matTentacle3
mcall [tentacle2Mesh01_pSysMemMesh], ID3DXMesh_DrawSubset, 0


By using two matrices for each mesh (body part) you can have them bend/blend however you wish (within reason). The code I've made is pretty messy (a lot of copy/paste - not using structures like you are).
I think that method may be the one you're after. It means that "elbows" and "knees" (or whatever an arachnid has) are merged seamlessly, plus it allows the use of only one mesh per body part (not three as for the dolphin example).


Cheers,
Scronty
Posted on 2002-05-30 18:17:10 by Scronty
I am thinking about creating the model in three phases -
phase one is where a base model is built from smaller objects, such as your tentacle example, where we also take the opportunity to bend the model following the Head orientation matrix as I described,
phase two is a secondary deformation which is applied to the individual parts (the "action" animation),
and phase three (here is where I'd consider using a vertex blender) is a tertiary deformation to tween the model between one animation frame and the next animation frame based on Time. This is similar to what you do in the Dolphins example, where you are using Trig to calculate nice smooth sinusoidal movement based on Time, and it's a lot like a Motion-Blur effect except that we are interested in a particular position for our model which is somewhere between the two fixed frame positions based on the real Time.
Thus it is Non-Linear KeyFraming, where each keyed frame is associated with an exact Time displacement, and the actual frames rendered are tweened between them.
This means we can store less data for model animation and still achieve synchronous and fluid animation overall.

We can create Goal-Oriented animations on the fly with real ease using this system. For example, if the player wanted to pick the apple from the tree, we only need our current frame,a frame for the hand ON the apple, and a Time displacement for each Frame (start time and end time in this case), then we simply tween between these frames based on Time.

What I wanted to achieve with the multiple objects was to create a single mesh before any manipulations take place, to avoid having obvious joins in the rended model.
This means removal of shared vertices, and I need to ensure during design time that some exist and they have exactly the same values so we can identify them. Then we create a single array of vertices, with each bodypart having its own array of indices into them.
This way when we manipulate the vertices of one bodypart, the shared vertices of the complete mesh are manpulated to the same degree.

Can I keep the parts separate and yet treat them as components of a shared vertex array for manipulation and rending?
Can I Stream from multiple buffers? Shouldn't be a problem, right?

You can't blame me for wanting the best of both worlds, after all, I chose MASM fot that very reason - I like to ride the fence (the neighbour has a gorgeous teenage exchange student... :tongue:)
Posted on 2002-05-30 23:54:01 by Homer
I have problems accessing texture filename strings...
I am trying to keep an array of filenames of textures I've already loaded, here's a scrap showing what I'm doing..

mov esi, .D3DXMATERIAL.pTextureFilename
push edi
lea edi,FileName
.while byte ptr!=0
mov al, byte ptr
mov byte ptr , al
inc edi
inc esi
.endw
mov byte ptr,0
pop edi

This causes an access violation every time.
I loaded the xfile using the helper api,
does that mean I don't have read access?
How can I snarf the Material's TextureFileName string
so I can check if I have instanced the texture already?
(lstrcpy also caused a violation)
Posted on 2002-07-15 09:57:16 by Homer
Afternoon, EvilHomer2k.

What's the code around this 'while-loop' doing?

I've just tried this:
...

push esi
mov esi, [edi].D3DXMATERIAL.pTextureFilename
push edi
lea edi,FileName
.while byte ptr[esi]!=0
mov al, byte ptr [esi]
mov byte ptr [edi], al
inc edi
inc esi
.endw
mov byte ptr[edi],0
pop edi
pop esi

; Create the texture
invoke D3DXCreateTextureFromFile, g_pd3dDevice, ADDR FileName, esi
...

... and it works fine.

Is the 'FileName' buffer large enough to contain the textures' string?

Cheers,
Scronty
Posted on 2002-07-15 19:14:01 by Scronty
There's three while loops in my code.
The outer loop checks the xfile filename against
an array of filenames of alreday loaded xfiles.
If the xfile is found to be loaded, I return early with the index
of the filename.
If not, I load it, then I enter the Materials processing loop.
Inside this loop I attempt to check the filename of the Material's texture against another array which contains filenames of loaded Textures...
I have defined my own Material struct which is just like D3DXMATERIAL except the filename string is replaced with a dword. This dword is merely the Index of an already loaded Texture.

MyMaterial STRUCT
Material D3DMATERIAL8 <> ;Material data
TextureIndex dd ? ;Index of a loaded texture in my array
MyMaterial ENDS

Like you, I allocate an array for my Materials and copy the Materials into it, but I keep the Index of the Texture.

If a Texture filename is found not to be already loaded,
I simply create a new entry in my Textures array...
for clarity, here's my Texture struct which makes up that array:

MyTexture STRUCT
szTexture db 128 dup(?) ;Filename of a Texture
lpTexture dd ? ;Pointer to loaded TextureObject
MyTexture ENDS

I'm not terribly good at explaining myself, but I think you can see what I'm doing here.
I wish to load multiple small xfiles at once, and I wish to prevent duplication of textures or meshes in memory.
What I have done is code a generic LoadXFile proc which manages its own arrays, a "smart" loader.
You say that didn't cause an access violation, interesting...
I'm going to pore over this piddly piece of code for the third night running, and if there's some silly error I will find it, but just for curiosity's sake, what are your system specs?
I am coding on an old amd333 with an ati rage2, under xp and masm7, and your dx includes.
Thanks for the fast reply, as always :alright:
Posted on 2002-07-16 00:40:10 by Homer
Afternoon, EvilHomer2k.

I'm using a Celery700 with an SiS630 chip on the motherboard under WinME. Masm6 with a few additions to the windows.inc file (>ver 4 equates/etc)

Interesting stuff you're doing:alright:.

What are you using esi]/b] for *before* this algo? The only difference I made, was to push/pop esi around that algo.

Cheers,
Scronty
Posted on 2002-07-18 10:31:49 by Scronty