🔒 Locked

DXInput and lef mouse click grab screen position?

Started by MARS_999 Aug 15, 2006 at 1:39 AM 8 replies 1.8k views

Original Post

MARS_999

363

MARS_999

Aug 15, 2006 at 1:39 AM

Here is what I have for left click mouse and I would like to grab the screen location but I keep getting zero for x,y return values?


if(directInput.mouseButtonDown(0))
	{
		directInput.getMouseMovement(dx, dy);
		gameCoord.GetScreenCoordinates(double(dx), double(dy));
        gameCoord.CalulateScreenCoordinates();
		gMouseClick_X_First = float(gameCoord.ReturnScreenCoordX());
		gMouseClick_Y_First = float(gameCoord.ReturnScreenCoordY());
		gMouseClick_Z_First = float(gameCoord.ReturnScreenCoordZ());
		fout << dx << " " << dy << endl;
	}

Maybe I am wrong but does this return relative mouse position and not absolute? If not how can I get an absolute position? Because when I was using win32 I used this and it worked fine?


case WM_LBUTTONDOWN:
            gameCoord.GetScreenCoordinates(LOWORD(lparam), HIWORD(lparam));
            gameCoord.CalulateScreenCoordinates();
            gMouseClick_X_First = float(gameCoord.ReturnScreenCoordinates(0));
            gMouseClick_Y_First = float(gameCoord.ReturnScreenCoordinates(1));
            gMouseClick_Z_First = float(gameCoord.ReturnScreenCoordinates(2));
			return 0;
            break;

Thanks

Evil Steve

382

Evil Steve

Aug 15, 2006 at 3:43 AM

That entirely depends on what your getMouseMovement function does. It's been a while since I used DInput, but I seem to recall it gives you relative offsets. And the offsets aren't in pixels, they're in mickeys - so higher DPI mice will move further than lower DPI ones.

This is one of the reasons Microsoft recommends using Win32 for mouse input - Win32 does smoothing and pointer balistics for you, so you don't need to bother with it. If you want to support high DPI devices, WM_INPUT is recommended, since DInput uses WM_INPUT internally in a thread anyway (Which is just slower than doing it yourself).

Impz0r

Aug 15, 2006 at 6:06 AM

Heya,

i've read the other post about DInput, which was very interesting! I didn't know that DInput is just using the WM_INPUT message internally, but i guess i makes sense tho. If WM_INPUT is allready the hardware nearest method to get input, why not just wrap it up.

Which leads me to my question, about the internal thread they using within DInput. Is it just a thread which calls:

void ThreadProc (...) { MSG msg; BOOL foo = GetMessage (&msg, hWnd, WM_INPUT, WM_INPUT); }long SubClassedWinProc (HWND hWnd, MSG msg, ...) { switch (msg) {   case WM_INPUT : {      // do some fancy stuff ...     break;    }  }}

all over again ?

If so, i indeed see no reason at all using DInput anymore, except for using Joysticks as an Input Device.

Any thoughts ?

Impz0r

Evil Steve

382

Evil Steve

Aug 15, 2006 at 6:53 AM

Quote:
Original post by Impz0r
If so, i indeed see no reason at all using DInput anymore, except for using Joysticks as an Input Device.

Pretty much, yes

Impz0r

Aug 15, 2006 at 7:19 AM

Well thats funny, they told you not to use DInput because it's just another unneeded layer. What for was DInput invented anyway Oo

One thing tho, i've read the WinSDK Help and it seems these GetRawInput*() functions are only available on WinXP and greater. What about Win2000 and those other Windows Versions? I wonder how DInput is handle those older Windows Versions. Any ideas ?

Impz0r

Evil Steve

382

Evil Steve

Aug 15, 2006 at 7:31 AM

Quote:
Original post by Impz0r
Well thats funny, they told you not to use DInput because it's just another unneeded layer. What for was DInput invented anyway Oo

One thing tho, i've read the WinSDK Help and it seems these GetRawInput*() functions are only available on WinXP and greater. What about Win2000 and those other Windows Versions? I wonder how DInput is handle those older Windows Versions. Any ideas ?

I suspect that's why DirectInput was created. That, and it's nice to have a single interface to any input device.
Pre-XP I'd guess (And that's all it is) that DInput does something funky to the HID stack to get the data. Or there's maybe some other way of getting high DPI data on pre-XP.

Impz0r

Aug 15, 2006 at 7:53 AM

Yeah makes sense. Thanks Evil Steve!

I've tried to implement it like they do within these MSDN article but there is a problem. My compiler can't find any of these HID_* defines. I've searched the <windows.h> and <winuser.h> and after that the whole visual.net installation. But i wasn't lucky. Any idea how are (or where) they defined ?

Impz0r

Impz0r

Aug 15, 2006 at 8:59 AM

Ok, i didn't found the Defines but the values i need to set.

Thanks anyway!

Impz0r

GaryNas

Aug 15, 2006 at 2:20 PM

Quote:
Original post by Impz0r
What about Win2000 and those other Windows Versions? I wonder how DInput is handle those older Windows Versions. Any ideas ?

DInput is most likely not a wrapper around WM_ messages in older versions of Windows. It only appears to be a special case for Windows XP. Here's my story:

Two years ago we were developing a Windows app that needed to block all user input except for the escape key. Instead of using hooks, I had the great idea to call the Win32 BlockInput() function that will block all WM_ input messages. Then, since DInput accesses the driver directly I would create a DInput keyboard device and only check for the ESC key being pressed.

This worked great on my machine which was Windows 2000 at the time. I then gave the program to one of my co-workers to test on his machine which was WinXP... It didn't work!! :( He entire keyboard was locked out. I tried to figure out what was going on, but couldn't, so I just created an input hook and abandoned the DInput idea. It wasn't until I read a message on the DirectX mailing list saying that DInput was simply a threaded wrapper around WM_ messages that I realized what was going on.

So, in my experience DInput would still appear to be accelerated on older versions of Windows, but not XP.

Impz0r

Aug 15, 2006 at 5:45 PM

I see, i guess it's a good idea to stick to DInput to support those other platforms then WinXP.

Impz0r

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.