CreateDevice error on other comps
Author
I'm attempting to run a demo that I've written on other computers, but it doesn't seem to want to run.
Apparently, CreateDevice returns "Invalid Call" (using DXGetErrorDescription), but the same executable works fine on the comp I developed it with. So it seems that one of the parameters was invalid for the particular computer. I am creating the device to use the primary display adapter (D3DADAPTER_DEFAULT), with hardware rasterization (D3DDEVTYPE_HAL) and with hardware vertex processing.
I've tried it on two computers, a laptop (winXP, I think) and a desktop (win2000), and they both come up with the same error. I tried creating the device with software vertex processing on the laptop (not the desktop), and it returned that it was unavailable.
The app was compiled with the October 2006 version of the SDK, and I also ran the re-distributable packages for both DX (Feb 2007) and VC++ 8 on the machines, and it doesn't come up with any errors of libraries not loaded, so it doesn't appear to be a dependency problem.
Link to a zipped version of the app (compiled in release build).
Could someone help me understand what is happening? More importantly, could you tell me if it actually runs?
P.S. If the game does run, turn the volume down before playing (no sound in the menu, but check option menu for volume control). The sound effects can be very loud at 100% volume. Keys are arrows and space for shoot.
Can we see the code where you set up your present parameters? Are you calling the various validation functions like IDirect3D9::CheckDeviceFormat and IDirect3D9::CheckDepthStencilMatch? If not, you need to in order to find out if the formats you want to use can actually be used on the target hardware.
What graphics card and OS are you running, and what card and OS are on the machines you've tested? Would it be possible to install the SDK and debug rumtimes on one of the target machines to capture the debug output? That'll get D3D to tell you why the call is failing (Although using the validation functions will tell you that anyway).
What graphics card and OS are you running, and what card and OS are on the machines you've tested? Would it be possible to install the SDK and debug rumtimes on one of the target machines to capture the debug output? That'll get D3D to tell you why the call is failing (Although using the validation functions will tell you that anyway).
It ran on my machine, but I have the Directx SDK. It will be hard for anybody to help you without seeing any code, but here are my guesses anyway. The machines you're testing the demo on use 24-bit color depth for display, and don't support 32-bits... I've seen a lot of those. Direct3D, afaik, doesn't support 24-bpp display modes, so you will have to use 16bpp for your backbuffer format and also switch to fullscreen. OR: you're using a depth/stencil format which is not available.
At any rate, check this out:
http://www.geocities.com/adelamro2004/files/D3DSettings.zip
This is a program which displays a settings dialog before it initializes the device, and it takes into account the capabilities of the underlying hardware (source included). I wrote it for an article that never saw the sunlight. I hope this helps.
-Love & Peace!
At any rate, check this out:
http://www.geocities.com/adelamro2004/files/D3DSettings.zip
This is a program which displays a settings dialog before it initializes the device, and it takes into account the capabilities of the underlying hardware (source included). I wrote it for an article that never saw the sunlight. I hope this helps.
-Love & Peace!
Author
At the moment, it doesn't need to be elegant, it just needs to work on most computers.
This is what I've got so far:
How do I specify a 16bpp back buffer? Am I doing it right, because when I attempt to run in fullscreen, my app crashes and has a cry because the back buffer format is wrong. I can run it in X8R8G8B8 without a problem. Well, without a problem with the app running.
I quite intelligently decided, when I was writing it, to run my app windowed, at 800x800, and from what you guys have told me, that's not always going to be possible. If I run it fullscreen, it's going to need to be one of the native resolutions, right? Which would be 800x600. Because this was only a demo, I have specified the size and position of everything in screen coordinates. So, if I have to run in 800x600, everything messes up and I get to spend hours changing it all.
Fun, fun.
Edit:: Okay, I'm now using D3DFMT_R5G6B5 for a 16bpp back buffer format, and at least on my comp (the dev comp) it seems to be working. My problem at the moment is that with the most recent build, the device format check seems to be failing, and I'm not sure why.
I also just changed the two D3DFMT_X8R8G8B8 into D3DFMT_R5G6B5, but it didn't do anything helpful. It still works on the dev comp, but not on the laptop.
[Edited by - Endar on March 19, 2007 7:03:25 PM]
This is what I've got so far:
// get a pointer to something (don't know what), that we can use to create the d3d9 device IDirect3D9* temp = Direct3DCreate9( D3D_SDK_VERSION ); if( !temp ){ util::LogManager::log( boost::format("%1%: Call to 'Direct3DCreate9' failed.") % __FUNCTION__, util::MSGTYPE_ERROR); return false; } D3DPRESENT_PARAMETERS d3dpp; // set the parameters for the D3D9 device ZeroMemory(&d3dpp, sizeof(D3DPRESENT_PARAMETERS) ); d3dpp.Windowed = !settings.fullscreen; // set if the d3d instance is windowed or fullscreen d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD; // if we're running DX fullscreen if( settings.fullscreen ){ // we're trying to run in fullscreen, so we have to set the proper resolution d3dpp.BackBufferHeight = (unsigned int) settings.screen_size.height; d3dpp.BackBufferWidth = (unsigned int) settings.screen_size.width; // set the back buffer format //d3dpp.BackBufferFormat = D3DFMT_X8R8G8B8; d3dpp.BackBufferFormat = D3DFMT_X1R5G5B5; } // else if we're running windowed else{ // if we set either (or both) to 0, DX will use the size of the window d3dpp.BackBufferHeight = 0; d3dpp.BackBufferWidth = 0; // set the format of the back buffer to unknown because in windowed mode, it doesn't matter d3dpp.BackBufferFormat = D3DFMT_UNKNOWN; } // check that the device format is valid for the machine HRESULT result; IDirect3DDevice9* d3d9_device = NULL; if( FAILED(result=temp->CheckDeviceFormat( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, D3DFMT_X8R8G8B8, 0, D3DRTYPE_SURFACE, D3DFMT_X8R8G8B8 ) ) ) { // get a string describing the error that occured std::string str_result = getDirect3DError(result); util::LogManager::log( boost::format("%1%: D3D9 Device Format Check failed for reason: \"%2%\"") % __FUNCTION__ % str_result, util::MSGTYPE_ERROR ); return false; } // create the device else if( FAILED( result=temp->CreateDevice( D3DADAPTER_DEFAULT, // use the primary display adapter (primary monitor) D3DDEVTYPE_HAL, // hardware rasteriztion window_handle, // the window handle // set hardware or software vertex processing settings.hardware_vertex_processing ? D3DCREATE_HARDWARE_VERTEXPROCESSING : D3DCREATE_SOFTWARE_VERTEXPROCESSING, &d3dpp, // the settings for d3d9 &d3d9_device ) ) ) { // get a string describing the error that occured std::string str_result = getDirect3DError(result); util::LogManager::log( boost::format("%1%: D3D9 Device creation failed for reason: \"%2%\"") % __FUNCTION__ % str_result, util::MSGTYPE_ERROR ); return false; }// if FAILED( temp->CreateDevice(......) )How do I specify a 16bpp back buffer? Am I doing it right, because when I attempt to run in fullscreen, my app crashes and has a cry because the back buffer format is wrong. I can run it in X8R8G8B8 without a problem. Well, without a problem with the app running.
I quite intelligently decided, when I was writing it, to run my app windowed, at 800x800, and from what you guys have told me, that's not always going to be possible. If I run it fullscreen, it's going to need to be one of the native resolutions, right? Which would be 800x600. Because this was only a demo, I have specified the size and position of everything in screen coordinates. So, if I have to run in 800x600, everything messes up and I get to spend hours changing it all.
Fun, fun.
Edit:: Okay, I'm now using D3DFMT_R5G6B5 for a 16bpp back buffer format, and at least on my comp (the dev comp) it seems to be working. My problem at the moment is that with the most recent build, the device format check seems to be failing, and I'm not sure why.
I also just changed the two D3DFMT_X8R8G8B8 into D3DFMT_R5G6B5, but it didn't do anything helpful. It still works on the dev comp, but not on the laptop.
[Edited by - Endar on March 19, 2007 7:03:25 PM]
I don't understand, you're saying you can run it without a problem with X8R8G8B8? If so, where is the problem then? Anyway, I'd pick up one of the "Direct3D initialization" samples (which are plenty on the net) and continuously tweak and test until I find what's causing the problem. But here are more guesses :)
1. You're possibly not adjusting the window size such that 800x800 is the size of the client rectangle, not the entire window (tip: check the platform SDK function AdjustWindowRect()). If you create the window to be 800x800, the client rect (and thus the back buffer) will possibly have a non-power of two width or height, which is typically not supported.
2. To test using 16bpp for the back buffer, use D3DFMT_R5G6B5, not D3DFMT_X1R5G5B5 (which I suspect is never supported for use with the back buffer).
3. A comment in your code says:
// set the format of the back buffer to unknown because in windowed mode, it doesn't matter
Well it does matter. Like I said, 24bpp formats (which are possibly being used for the desktop display... this is quite common in laptops) are not supported for use with the back buffer.
4. This is wild, but who knows... Try setting the presentation interval member of the presentation parameters structure to D3DPRESENT_INTERVAL_ONE - it's guaranteed to be supported on all cards, but D3DPRESENT_INTERVAL_IMMEDIATE (which is maybe what D3D uses if you set it to 0) is not.
-Love & Peace!
1. You're possibly not adjusting the window size such that 800x800 is the size of the client rectangle, not the entire window (tip: check the platform SDK function AdjustWindowRect()). If you create the window to be 800x800, the client rect (and thus the back buffer) will possibly have a non-power of two width or height, which is typically not supported.
2. To test using 16bpp for the back buffer, use D3DFMT_R5G6B5, not D3DFMT_X1R5G5B5 (which I suspect is never supported for use with the back buffer).
3. A comment in your code says:
// set the format of the back buffer to unknown because in windowed mode, it doesn't matter
Well it does matter. Like I said, 24bpp formats (which are possibly being used for the desktop display... this is quite common in laptops) are not supported for use with the back buffer.
4. This is wild, but who knows... Try setting the presentation interval member of the presentation parameters structure to D3DPRESENT_INTERVAL_ONE - it's guaranteed to be supported on all cards, but D3DPRESENT_INTERVAL_IMMEDIATE (which is maybe what D3D uses if you set it to 0) is not.
-Love & Peace!
Author
Quote:Original post by hikikomori-san
I don't understand, you're saying you can run it without a problem with X8R8G8B8? If so, where is the problem then? Anyway, I'd pick up one of the "Direct3D initialization" samples (which are plenty on the net) and continuously tweak and test until I find what's causing the problem. But here are more guesses :)
1. You're possibly not adjusting the window size such that 800x800 is the size of the client rectangle, not the entire window (tip: check the platform SDK function AdjustWindowRect()). If you create the window to be 800x800, the client rect (and thus the back buffer) will possibly have a non-power of two width or height, which is typically not supported.
2. To test using 16bpp for the back buffer, use D3DFMT_R5G6B5, not D3DFMT_X1R5G5B5 (which I suspect is never supported for use with the back buffer).
3. A comment in your code says:
// set the format of the back buffer to unknown because in windowed mode, it doesn't matter
Well it does matter. Like I said, 24bpp formats (which are possibly being used for the desktop display... this is quite common in laptops) are not supported for use with the back buffer.
4. This is wild, but who knows... Try setting the presentation interval member of the presentation parameters structure to D3DPRESENT_INTERVAL_ONE - it's guaranteed to be supported on all cards, but D3DPRESENT_INTERVAL_IMMEDIATE (which is maybe what D3D uses if you set it to 0) is not.
-Love & Peace!
I can run it without problem in X8R8G8B8 on the dev computer, not the one I'm using for testing.
1. I've said "stuff it" for 800x800 for the moment, and I'm attempting to create the window at 800x600, which again, is working on the dev comp, but not the laptop.
3.
Quote:BackBufferWidth, BackBufferHeight
Width and height of the new swap chain's back buffers, in pixels. If Windowed is FALSE (the presentation is full-screen), these values must equal the width and height of one of the enumerated display modes found through IDirect3D9::EnumAdapterModes. If Windowed is TRUE and either of these values is zero, the corresponding dimension of the client area of the hDeviceWindow (or the focus window, if hDeviceWindow is NULL) is taken.
This is what I meant by "doesn't matter". It says that if it is windowed and I set the width and height to 0, then it uses the whole window.
Author
Okay, the laptop keeps saying that the Format check failed.
Okay, I changed from the HAL to the REF device, which apparently is not suitable for any kind of retail application, but it has gotten the laptop past it's issue with the device format.
if( FAILED(result=temp->CheckDeviceFormat( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, D3DFMT_R5G6B5, 0, D3DRTYPE_SURFACE, D3DFMT_R5G6B5 ) ) )Okay, I changed from the HAL to the REF device, which apparently is not suitable for any kind of retail application, but it has gotten the laptop past it's issue with the device format.
My bad, the back buffer width and height shouldn't be a problem in windowed mode. However, your comment was about the back buffer FORMAT, which DOES matter. Anyway, don't use CheckDeviceFormat, use CheckDeviceType. Also, I'm curious as to whether the "demo" I posted a link to above works well on your laptop. (By mistake, I included unnecessary files with it, but the project file ignores those). Hope this helps.
-Love & Peace!
-Love & Peace!
Author
Quote:Original post by hikikomori-san
My bad, the back buffer width and height shouldn't be a problem in windowed mode. However, your comment was about the back buffer FORMAT, which DOES matter. Anyway, don't use CheckDeviceFormat, use CheckDeviceType. Also, I'm curious as to whether the "demo" I posted a link to above works well on your laptop. (By mistake, I included unnecessary files with it, but the project file ignores those). Hope this helps.
-Love & Peace!
Well, the demo brings up the window and shows me all the details, but even with just the initial settings it brings up, I always get the error "Failed to create the Direct3D rendering device!"
Anyway, I just realised that even though I was checking if the REF device was valid, I was still attempting to create a HAL device. I just changed it on my dev computer, and it is so stupidly slow. It runs at like 0.5 fps. So, if it runs that slow on my dev comp, I'm not bothering trying REF on the laptop.
Also, I installed the DX SDK on the laptop, but I don't know how to get debug information from the DX libraries without running the app in debug mode in the IDE. Is there any other way to get the DX library output?
Edit:: Okay, still nothing. I've changed the call to CheckDeviceType, and now the laptop fails on that, in both fullscreen and windowed.
I'm attempting to call the function with using the primary display adapter (D3DADAPTER_DEFAULT), using the HAL instead of REF, with both the display and back buffer as 16bpp (D3DFMT_R5G6B5), and windowed or not, as appropriate.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
