   life without DirectInput
  So I picked up an old game project I had started a long time ago but never finished and started fixing it up. It's 2D written to DirectX 8. It's a mouse based game and I had been using DirectInput.Anyway, I tracked down one of those bugs that only happen in a release build in which the app was immediately crashing. It turned out the bug had something to do with DirectInput, some kind of race condition when attempting to read the mouse state the first time. So I thought, I know I'll just remove this application's dependence on DirectInput because it's deprecated anyway. So I did that and rewrote my mouse state reading function to use GetAsyncKeyState and GetCursorPosition and just hid the cursor at start up with ShowCursor(0). This all works fine in windowed mode but in fullscreen everything is completely screwed up. ShowCursor(0) is not hiding the cursor no matter where I put it in the code. Handling WM_SETCURSOR with SetCursor(NULL) does nothing. Windows is still like moving the cursor around underneath my application so other windows are getting painted on top of my fullscreen app and so forth. Calling SetCapture(my_apps_window) doesn't help. It's very bad. I think it's all because I'm no longer acquiring the mouse in exclusive mode but I still don't understand why hiding the cursor doesn't work after you change the screen mode. Has anyone seen this? I'm really starting to think that I'm going to have to put DirectInput back in.[Edited by - jwezorek on May 9, 2010 4:20:14 AM]
  Are you using the Win32 API's ShowCursor or the IDirect3DDevice one?You might want to check the Remarks section under whichever of the following applies: DX8 or DX9.   ;  Win32's   ;  Thanks a lot. g_pd3dDevice->ShowCursor(FALSE) fixes the problem. EDIT: spoke too soon -- it's still happening in the release build.   ;  Odd.  Perhaps you should set hCursor to NULL when registering your window class?  Another possible solution.  Awkward though, as it'd involve having to create (and possibly track and release?) a transparent 32x32 surface, and I'm not sure it'd actually fix your problem.  Something else to try anyway.   ;  It's very strange. I just logged a message from my WM_SETCURSOR handler. In the debug build it WM_SETCURSOR is getting posted, in the release build it isn't. Wtf? Today has been a long day...[Edited by - jwezorek on May 9, 2010 2:25:28 AM];  I figured it out, or at least it's working now. I had to set WS_EX_TOPMOST when calling CreateWindowEx. I think what was happening is that for some reason the release build was creating the window under the other processes' windows and the debug build was creating it over the other windows, so the release build wasn't seeing WM_SETCURSOR messages because the cursor wasn't over my window. Very strange.   ;Quote:Original post by jwezorekThis all works fine in windowed mode but in fullscreen everything is completely screwed up. ShowCursor(0) is not hiding the cursor no matter where I put it in the code.From the remarks section of ShowCursor: (link)Quote:This function sets an internal display counter that determines whether the cursor should be displayed. The cursor is displayed only if the display count is greater than or equal to 0. If a mouse is installed, the initial display count is 0. If no mouse is installed, the display count is –1.=> You have to use something like:[source language="c++"]do {} while(ShowCursor(0));Quote:Handling WM_SETCURSOR with SetCursor(NULL) does nothing.From the remarks section of SetCursor: (link)Quote:If your application must set the cursor while it is in a window, make sure the class cursor for the specified window's class is set to NULL. If the class cursor is not NULL, the system restores the class cursor each time the mouse is moved.=> You have to set the class cursor (in WNDCLASS(EX)) to NULL. Then, however, you are also responsible for setting the cursor when the mouse enters the window, and you want the cursor to be visible. You can do this in WM_MOUSEMOVE. This approach works fine for me (in windowed and in fullscreen mode).I don't know why you get different behavior in windowed and fullscreen mode. However, carefully reading the MSDN documentation has helped me fix all mouse cursor issues in my Win32 apps without using DirectInput and without using ShowCursor.   ;  majickthise, yeah, I know I was doing all of that, but like I said it's all working now. An important thing to understand that I don't quite understand is that once I set fullscreen mode, I wasn't dealing with the regular windows cursor; i was dealing with the d3d cursor -- Evil Steve talks about it in this old thread...Anyway, now my problem is dealing with the mouse clamping to the edge of the screen. (I want relative mouse events and using am GetCursorPos to generate them). I see people talking about doing this in three different ways:(1) Use GetCursorPos() or WM_MOUSEMOVE messages but position the cursor to the center of the screen at the start of each frame.(2) Use GetCursorPos() or WM_MOUSEMOVE messages along with caching the last cursor pos but write my own code to make the cursor wrap toroidally around the edges of the screen i.e. if it goes off the left side it comes back on right side.(3) Use WM_INPUT messages but write code implementing cursor ballistics myself.Personally I lean towards (3) because it seems the cleanest, but I'd like to look at some cursor ballistics sample code. Can someone help me out on that? Also is WM_INPUT supported on Windows XP? -- because I definitely want this game to run on XP. I don't know I'm probably just going to do (1) for now because it's the easiest to implement.   