I was ecstatic late last night when I finished polishing the final set of features on my list for engine proof-- then I copied my release-mode build (I didn't forget the map, image, models, or any other special directories) to another machine I have that doesn't have the DX9 SDK installed. At first I got the infamous "cannot find D3DX9_25.dll" file issue... so then I copied over the April DX9 Redistributable and installed that. After rebooting, I tried running the game again. This time the game ran fine, but it aborted somewhere in the initialization/loading phase. This is where I load the map into memory, load all my sprites for the UI, and prep a few other classes. Instead of completing this process, it eventually gets a "false" returned from one of the init functions, which then causes the program to simply to close normally. I know I need to add some error messages for such cases (which I plan to do today!)... but what would cause this problem? Both machines have almost identical specs... both are running modern processors (one Intel, one AMD), both have DX9 video cards (nVidia GeForce FX 5900 Ultra and ATi 9800 128MB) with sufficient RAM. Both also have DX9.0c installed. But when I run my release build (outside of my IDE) on my development machine, everything runs perfectly. On the other, non-SDK installed machine, I lose it somewhere during init. The only thing I can think of is how I am compiling... I have the DX9 Debug SDK installed-- not the runtime. Could that be the issue? If it is, how do I go about switching it to the runtime build? Thanks, -dbh

It could very well be a bug in your own application, caused by false assumptions about target hardware capabilities and/or behaviour. I recommend logging all error messages and including the error locations in the log, to determine the exact reasons for the program's failure.

You should use the "release" build profile when building the distribution version of your application. In addition, check that the debug DX libraries are not referenced in the release configuration - this causes the app not to work in machines without the SDK installed.

Niko,

I'm in the process of spitting any abnormalities to a log right now... I was already error-checking every initialization process I perform, I just wasn't doing anything other than returning falsely and cleaning up should something go wrong. I should have a better idea of exactly what is causing the hang-up over my lunch break.

I'm a little confused on the release configuration you are mentioning... I assume you mean in my IDE (I'm using .net 2k3), I should configure my release and debug builds to have seperate settings. I believe at the moment they are using the same settings-- they are just linking with the d3d9.lib and a few other necessary files (dinput, etc. etc.). I can look for sure when I get back for lunch...

What should my debug and release configs look like, exactly? Should they each be linking with seperate files? Is there somewhere I can go for a tutorial for the latest DX9 + IDE setup?

Thanks again,
-dbh

Quote:Original post by dbh

What should my debug and release configs look like, exactly? Should they each be linking with seperate files? Is there somewhere I can go for a tutorial for the latest DX9 + IDE setup?

It is generally good practice to use the debug DirectX libraries (for example, d3d9d.lib over d3d9.lib) with the "Debug" configuration. However, the linker doesn't require this, and it is the programmer's responsibility to link with the appropriate libraries for each situation. Other than this, standard distinction between debug and release configurations should be applied depending on your judgement of how much debug info you want.

For release configuration, it is pretty much required that you use the libraries designed for release use - otherwise, the program won't work on machines without the SDK.

To test if your program can run on the release dll's only without having to jump it to another machine you can open the DirectX settings in the Control Panel. On the top right on every DX subsystem tab (D3D, DInput, etc.) is a radio button that indicates either Debug or Retail versions of the runtime. Switch the ones you use to Retail before you run your program and it should behave the same was as on a computer without the SDK installed.

You can also check the DxDiag tool (also available from DirectX on the Control Panel). On the 'DirectX files' tab you see all the installed runtime files for DX and in the third column it says whether a certain file is Final, Debug or Retail. If you use a dependancy viewer program (I use ShowDep) you can see if your program uses any of those files and how it changes when you switch between Debug and Retail runtime mode.

Hope this helps some at least... [smile]

Regards.

Actually Steaf, that's very helpful. I was looking for a dep viewer like that... thanks for the tip!

I found out where and why it was aborting during init, as well. As it turns out, all of the models I exported with Quest .X exporter from 3DSMax were given ABSOLUTE PATHS for their textures.

So... when my game loads a .x model, it goes to look for my texture based on a "C:\somedir\somedir\img\texture.tga" lookup, instead of looking in its own directory for the texture!

I tried manually editing the .x and removing the path, so it's just "texture.tga" - but it still crashes (now on both machines).

Totally unrelated to my original question, but does anyone have any idea how to use relative pathing with 3dsmax generated models for textures? :)

-dbh

Quote:Original post by dbh

Totally unrelated to my original question, but does anyone have any idea how to use relative pathing with 3dsmax generated models for textures? :)

You could extract the filename from the full path (the part of the string after the last backslash), and append it to the path where your all runtime resources reside. This way, you don't have to care about the paths that MAX gives to the textures.

Or, you could modify the exporter to treat the texture file paths as relative instead of absolute.

Quote:Original post by dbh
Both machines have almost identical specs... both have DX9 video cards (nVidia GeForce FX 5900 Ultra and ATi 9800 128MB)

Some of the most aggravating, pull-your-hair-out, commit suicide bugs are just because of differences in graphics hardware. Every once in a while, IHV's will handle stuff differently in the driver, which can lead to totally unexpected results. Sometimes, the graphics card even deadlocks (if you're unlucky [wink]).

It only gets harder, because your test machines generally don't have debugging stuff installed. And if it's a driver issue, you usually have to contact the IHV and go from there.

Thanks again Niko, you're suggestion is exactly what I ended up implementing ;)

Of course, I didn't realize it until after I switched to a different .x exporter (Panda instead of Q3D). If only I had checked the forums again before spending my entire lunch break playing with it :| On the bright side, I did learn something!

Anyway, thanks again.

circlesoft: the more I get into testing, the more I'm fearing what you speak of! You're right, it is a real pain to have a bug that seems machine dependent (as it only breaks on machine x), and yet you have no real way of stepping through the code :) Gotta love it...

-dbh