Hi. I am sort of rebuilding in a new Visual C++ project an older one
that I began after learning how DirectX, specifically Direct3D retained mode, displays 3D objects. The first project was an attemp to go beyond simple viewing and make a 3D modeling program, but it was kind of a haphazardly organized thing with only an object hierarchy architecture thought out. I determined to redo as though from scratch all the functionality I did have only this one would be completely modular and object oriented. Using the old project, which works correctly, I have been reached the point where the Viewports can display what's in a frame hierarchy.

The problem is that the test object that is supposed to have a texture
that a load texture callback function loads when the MeshBuilder2's load function is called gets displayed without the texture. I encountered that problem inside the project folder of the old editor earlier on. After a diagnosis attempt to enumerate the colors on my
old computer and the new one that I am now running both projects on, I found the answer to be a lot simpler. I had to copy all relevant files onto a flash drive and use that to put them on my new computer and though I had copied the X file into old editor's folder, I had failed to copy a tex1.ppm file that's name was in the X file. Putting that file in there as well fixed it. Naturally, I though the same thing must be the problem with the new one when I first tested it and it didn't display the texture. I was wrong.

The ppm file and that X file are both in the new editor's folder. I compiled versions that had a SetCurrentDirectory call to where it was and ones with that line commented out, but no good. I even changed the source code of the old editor where it set its directory to point
into the new editor's folder instead and it displays the object right. I ran a test with the same code pasted into both programs to GetImage from the texture (which by the way claims to have loaded just fine-D3DRM_OK) and then write all the bytes of the pallete it indicates it uses and the actual image buffer itself to a file. I then compared them with a routine, byte for byte, and both the file the old editor which does still display right and the new one which does not are identical.

Clearly, I am missing something. It cannot be a difference in my old computer and my new one that causes this because both the running copy of my old editor and the new one are doing different things on the same machine. It can't be the fact that my old computer ran Windows 98 and the new one is Windows XP, nor the old one's DirectX version 5.0 only versus the new computer's DirectX 9.0 for the same reason. Both programs use only the calls, and the same ones, that work in one but not the other project. Besides, though I would like to explore what new wonders seem to be available in the new version, my copy of Visual C++ is the Standard 6.0 version which had only header files for up to DirectX 5.0. I know the answer is therefore locked in the code, but everything I can think of has failed to resolve it. I even tried reordering the D3DRM objects' creation and setup calls so that just as in the old one, the MeshBuilder load call happens after the retained mode device is created (though admittedly, the viewports get created before the object too, which is unlike the old version).

I don't know if its order of events, but any help on understanding exactly what DirectX does to load an object from an X file with a file named texture reference would probably help shed light on it. I can't really proceed if I have a problem I don't understand with something as crucial to a 3D modeling program as textures. Thank you for any help. Sorry about the long post.

I wound up having to take all the relevant objects of my new version and bring them into a copy

of the old version to hunt down where the difference was. At first, I just adjusted non-existant

references and other things that would prevent this hybrid version from compiling at all. This

created a version of the old that had but did not use any of the new one's functionality. Then,

one small step at a time, I placed the lifetime of DirectX objects and API objects under control

of the new version Application object and its initialize member. The last version that worked

before behaving strangely was when I replaced the subroutine that makes the first scene.

Then I recreated the original viewer sample code project I had studied to learn the use of

Retained Mode. This always worked on my old computer, but it had its own perplexing behaviour I

never witnessed before. One of its menu options allows for change from an RGB color model to a

mono color model. In the DirectX sections of the MSDN library disk, it specifically mentions

that it is not possible to change the color model of a device. It is necessary to enumerate the

devices available on your system or use FindDevice like the viewer program and both my editors do

for a device that has capabilities you want. And the original viewer code responds to that menu

command by rebuilding the device and searching for a GUID of one that supposedly uses that color

model. This is what's new: when that menu item is used to change to RGB model, the ship loses

its texture. But only if any other meshbuilder does not have any part of it visible in the

viewport. It remains "skinless" through all manner of manipulations and through window resizings

until or unless you happen to move or load another visible object into view. At that point, it

immediately gets its texture back as if by magic. Switch back to what the menu says is mono, and

even if alone in the viewport, resizings do NOT lose the texture.

I speak of whether it is actually in mono or RGB doubtfully because I put test code in to call

GetColorModel method of the DirectX device object, but in both states, it returns 1, which is the

indicator of mono. So I have the actual made device object telling me its color model is mono

when I perform the menu command to change models, but a visible difference on screen.

I have a NVIDIA Vanta/Vanta LT card according to dxdiag tool, and remember seeing topics about

problems in DirectX with those cards. I hope somebody may have encountered similar issues or

have some thoughts. I'm going to copy both versions of my editor so far and the original viewer

back to my old computer and see if the weirdness vanishes, but I am still in the dark.