I'm not exactly sure why, but when I set my Build Target to 'Release' DirectInput just doesn't work. Under debug, it works wonderfully. I'm just stumped to say the least. I receive no error messages, no linker errors (obviously), and my application compile perfectly; 0 errors and 0 warnings. Am I missing something? Maybe something obvious? :P Thanks for any help! EDIT: I forgot to mention: I'm using VS 2005 Express.

Define "doesn't work". Do DirectInput functions say there's no data? Can you not create devices? Are you enumerating devices and none are showing up? Are you checking the return value from all your DInput calls to make sure they're not failing?

Hey Oyerth,

Well, it seems difficult to help you with so few information. Are you sure that the DirectInput code is executed in Release mode ? You cannot debug the Release program, but you can still put some code that will either popup a dialog box (::MessageBox), or a beep message (::MessageBeep) or also write into a log file --which is always a good reflex whatever your application ;)

Could you give more detail about your project, and how you link to the DirectX libraries ?
Cheers
StratBoy61

When I said "no error messages" I ment that I check all DirectInput instructions for errors (a la the 'FAILED' macro and a messagebox) and it never seems to 'fail.'
I have my project setup for buffered input; it works in my Debug build but not in my Release build (when I hit a key or a mouse button a MessageBox usually pops up telling me I've done so. It doesn't, however, for my Release build).
I link the libraries via the project properties; both Build Targets have the correct libraries linked (or the compiler would spit linker errors in which I have already stated that I received none).

I once had a similar problem : I was using a #ifdef _DEBUG where my main window creation would differ. Because of this, it appeared that my DirectInput initialization would fail --the device would never be created.
However, my code would just return, errorless, in that particular case, and the input would not work.
Have you double-checked that your code does show an error if the DirectInput device is not properly created ?
Oh, and I meant, "do you link statically or dynamically ?"
Cheers
StratBoy61

I did use "#ifdef _DEBUG" to shield ugly MessageBoxed errors in my Release build but I removed them and tested before making this topic. To make sure I removed all them though, I did a quick 'Find in Files' search and it came up empty.
This is what I have for creating the DI object:

// --// Create DirectInput object.// --if (FAILED(DirectInput8Create(hInstance, DIRECTINPUT_VERSION, IID_IDirectInput8, 	reinterpret_cast <void **> (&m_dIn), NULL))){	ERRORBOX("Could not create DirectInput object!");	return false;}

'ERRORBOX' is a macro that is defined as:

#define ERRORBOX(x) MessageBox(NULL, __t(x), __t("Error!"), MB_ICONERROR | MB_OK)

I am dynamically linking.

[Edited by - Oyerth on March 20, 2007 4:40:04 PM]

Okay, I am not very familiar with the DirectX libraries used with dynamic linking, but here is the idea : If we rule out a problem in your code, we want to check what is wrong at the level of the DirectInput library.
You can first use dependency walker to make sure that both versions of your exe (release and debug) link to the same modules. There might be discrepancies, as the debug versions of the libs can be suffixed "_d", but the overall should be the same. Then, you might want to run a tool like Process Explorer and double-check that your release exe loads the correct dlls, and that nothing is missing.
Then, if everything is okay, you might want to dynamic link your release exe to the debug version of the DirectInput library. You might also want to compile in release mode, add the "generate debug info", remove optimizations and start debugging your exe at the level of the DirectInput initialization (but that would mean an error in your code).
Good luck !
StratBoy61

I've fixed it. I was handling buffered input incorrectly; it's strange how it worked in debug mode, though.

Thanks for your replies, though. :)