Sign in to follow this  

Problem with window immediately closing after execution

This topic is 3477 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm relatively new to DirectX programming and I've recently run into a very strange problem with a program. The issue I'm having is that when I compile the program, I don't get any errors, but then when I attempt to run the .exe file (from a Debug compile), the window opens and then immediately exits. I don't get any sort of errors, no "unhandled exception" messages, just nothing. However if I run the program through debug, the window opens and the program works exactly as it should. Has anyone else encountered such weirdness? How can I fix this? As a side note and to offer a bit more context, I've found that I frequently have to change the vertex processing to software instead of hardware because my laptop (Dell Inspiron 6000) has a video chipset that does not support hardware acceleration. Could this be a cause? I've uploaded my VS2005 project to the below URL if anyone could be so kind as to take a look and offer some insight: http://www.webetry.com/SG220/Stranded2005.zip

Share this post


Link to post
Share on other sites
I haven't tried your code, but it sounds like some load function is failing because the working directory is different. If you load anything like textures or meshes, are you exiting the program if the application fails?

And are you using the Debug Runtimes? Even if you're running the app from explorer, you can use something like DebugView to view the debug output.

Share this post


Link to post
Share on other sites
do you have an update loop in your game? sounds like it might be doing exactly what it's supposed to do. unless you keep the computer busy, your program will terminate.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
I haven't tried your code, but it sounds like some load function is failing because the working directory is different. If you load anything like textures or meshes, are you exiting the program if the application fails?

And are you using the Debug Runtimes? Even if you're running the app from explorer, you can use something like DebugView to view the debug output.


Thanks for the response, Steve. I do have my DX SDK running in debug mode. That was something I toggled way back on the recommendation/advice of a friend who is also taking the same class I am.

I have encountered pathing issues with other projects from the textbook we're using, so I decided to investigate that route. It turns out that if I move the .exe generated by a compile into the base folder of the project, it loads and now it works exactly as expected. Of course I can see the instructor marking off points if I tell him he has to do that for it to work; our project involves modifying the program a couple ways from a predefined list of acceptable modifications.

This might be a dumb question, but could I simply edit the .x model files to correct the pathing of the textures/models? Is there any sort of environment variable I could use which says the files are in the base folder of the VS2005 project?

Share this post


Link to post
Share on other sites
If like you say the program runs from straight .exe without VS debugging when you put it in the project's directory, then provided that you haven't hard-coded the .x file locations into the program itself you should be able to simply copy all the .x files into a directory with the .exe and give that to your teacher. I'm not sure if there is a design restriction for the assignment however, (I don't see why this wouldn't be acceptable) but that's my 2 cents.

Edit: And yes, as far as I know (haven't worked much with .x files or DirectX for that matter) as long as you preserve the directory structure between the .x files and their textures as they appear in the project's folder, you should be able to copy those as well and have it work A-OK.

Share this post


Link to post
Share on other sites
When you run your app from within Visual Studio, it sets the working directory to the same directory as the solution (or project, I can't remember - I always have the project and solution in the same directory), even though the EXE is spat out into the Debug or Release folder.

it's perfectly fine to have the game fail to start if it can't find the required resources - although I'd make sure you display an error with MessageBox(). If your instructor tries to run the EXE from the Debug or Release folder and it fails to start, then that's his own problem really :P

There might be a way to override the output file project setting via a #pragma directive in Visual Studio - anyone know?

Share this post


Link to post
Share on other sites
A universal solution to finding resources is to maintain a folder-to-folder relationship between the project folder and the resources.

For instance, I commonly have a "resources" directory as a sub-directory in the project folder.

When my app starts, I use getcwd to get the path to the folder where the app was launched. I then search that path for the name of the project, truncate the string and strcat "\\resources\\" to it. I now have a path to the resources folder. If I don't find the name of the project, I emit an error message ("Resource directory not found in current directory path" or similar).

I specify textures in the x-file by filename only (not full path). To get the path to the texture, append the filename to a copy of the resource directory path.

That's not foolproof as it's possible for the user to execute the app with a different working directory but that's what the error message is about.

Using something like this method allows the user to move the project folder to whereever is desired, even another drive, which is a "friendly" thing to do.

E.g.:
1. getcwd returns "f:\\projects\\xmodel2\\release"
2. truncate the string to "f:\\projects\\xmodel2"
3. append the name of the resource directory (or whereever resources are stored), resulting in "f:\\projects\\xmodel2\\resources\\"
4. generate a path to texture file "tex1.png" by appending the name to the resource directory, resulting in "f:\\projects\\xmodel2\\resources\\tex1.png"

Share this post


Link to post
Share on other sites
Quote:
Original post by Buckeye
A universal solution to finding resources is to maintain a folder-to-folder relationship between the project folder and the resources.

For instance, I commonly have a "resources" directory as a sub-directory in the project folder.

When my app starts, I use getcwd to get the path to the folder where the app was launched. I then search that path for the name of the project, truncate the string and strcat "\\resources\\" to it. I now have a path to the resources folder. If I don't find the name of the project, I emit an error message ("Resource directory not found in current directory path" or similar).

I specify textures in the x-file by filename only (not full path). To get the path to the texture, append the filename to a copy of the resource directory path.

That's not foolproof as it's possible for the user to execute the app with a different working directory but that's what the error message is about.

Using something like this method allows the user to move the project folder to whereever is desired, even another drive, which is a "friendly" thing to do.

E.g.:
1. getcwd returns "f:\\projects\\xmodel2\\release"
2. truncate the string to "f:\\projects\\xmodel2"
3. append the name of the resource directory (or whereever resources are stored), resulting in "f:\\projects\\xmodel2\\resources\\"
4. generate a path to texture file "tex1.png" by appending the name to the resource directory, resulting in "f:\\projects\\xmodel2\\resources\\tex1.png"
I'd suggest making it more robust by going back along the directory structure, and searching for the "resources" directory in each directory. It's also not foolproof, but it's slightly more stable. For example:
1. getcwd returns "c:/documents and settings/administrator/desktop/stuff/app/release"
2. See if "c:/documents and settings/administrator/desktop/stuff/app/release/resources" exists. It doesn't.
3. See if "c:/documents and settings/administrator/desktop/stuff/app/resources" exists. It does, bail out using this as the resource directory.

Although, as I said in my last post - generally the debug and release directories are only used if you're building the app, and if you're building it, it's assumed you know where the exe will end up. I usually set my project settings to spit my exe out in a different directory (A projectname/bin directory), which has my resources in it.

Share this post


Link to post
Share on other sites
Sign in to follow this