6 replies to this topic

[the Code Gremlin]

I was wondering how people made a virtual button. by a virtual button i mean a button that is user drawn and controlled. this is my code for dececting a mouse click on the button.

	RECT rcSrc;

	SetRect( gX, gY, gX+2, gY+2 );

	int width = x+w;
	int height = y+h;

	if(x >= rcSrc.left && width <= rcSrc.right )

  	// commented on purpse, just checking x value until i figure it out.

  	//( y > rcSrc.top && y+h < rcSrc.bottom ) )
  	return true;
	else
		return false;

but it won't work right. i just cant seem to figure it out. I'm using direct draw because I'm only doing simple 2d gaming.

Also, is there any input on which is better for mouse and keyboard input (not critical on speed just dependable) win32 or direct input. b/c direct input is a hunk of poo.

[Sage Gerard]

On Win32, you can use GetCursorPos() and ScreenToClient() together to get mouse coordinates relative to the top-left corner of your window's client area. Also, GetAsyncKeyState( VK_LBUTTON ) can tell you if the left mouse button is down. To see if the button was just pressed, check to see if the button is down, and it was not the last time you checked.


Add all of this together, then use a condition like the following:

( x >= rcSrc,left && x <= rcSrc.right && y >= rcSrc.top && y <= rcSrc.bottom && bMouseLeftPressed )

[the Code Gremlin]

I already am tracking the mouse and everything, but here is how i got it to work

	// gX and gY are in WM_MOVE: getting cursor pos



	SetRect( &rcSrc, gX, gY, gX, gY );

	



	int width = y+(w+20); // i don't know why my blitter does that. it is a strech blit which is what ddutil uses?? I have to add 20 to get the correct value b/c i put in exact bitmap values in pixels

	if( rcSrc.left >= y && rcSrc.left <= width )

	  return true;

	else

		return false;

thanks for the help. i hope this can help someone. Still open on the question about Direct Input vs Win32 Input. and any ideas on that extra 20 pixels?

[Krohm]

Also, is there any input on which is better for mouse and keyboard input (not critical on speed just dependable) win32 or direct input. b/c direct input is a hunk of poo.

Yes, it is. Do not used DirectInput (unless you need force feedback).
For character input, WM_CHAR works just fine. It has several advantages compared to DIY-input management such as 1) always correctly adapted to active locale and 2) behavior coherent with user settings (key repetitions per second etc).
For keyboard buttons, most of the time WM_KEYUP and WM_KEYDOWN work just fine... sometimes they get stuck when switching focus and such but I don't think that's a problem in general. I haven't tried WM_INPUT for keyboard management as it looks way more complicated with no sure benefit...
I do mouse input with WM_INPUT and I can say for sure it's incredibly smoother than WM_MOUSEMOVE, especially at low resolutions (and I have a cheap 10 bucks mouse).


An interesting advantage of WM_INPUT is the ability to control keyboard status for different devices (as opposed to WM_KU and _KD). I will play with this in the future I suppose, it might be interesting.

[the Code Gremlin]

Also, is there any input on which is better for mouse and keyboard input (not critical on speed just dependable) win32 or direct input. b/c direct input is a hunk of poo.

Yes, it is. Do not used DirectInput (unless you need force feedback).
For character input, WM_CHAR works just fine. It has several advantages compared to DIY-input management such as 1) always correctly adapted to active locale and 2) behavior coherent with user settings (key repetitions per second etc).
For keyboard buttons, most of the time WM_KEYUP and WM_KEYDOWN work just fine... sometimes they get stuck when switching focus and such but I don't think that's a problem in general. I haven't tried WM_INPUT for keyboard management as it looks way more complicated with no sure benefit...
I do mouse input with WM_INPUT and I can say for sure it's incredibly smoother than WM_MOUSEMOVE, especially at low resolutions (and I have a cheap 10 bucks mouse).


An interesting advantage of WM_INPUT is the ability to control keyboard status for different devices (as opposed to WM_KU and _KD). I will play with this in the future I suppose, it might be interesting.

Thanks for that, what is what i read all over the internet. So you think that WM_INPUT is better than WM_MOUSEMOVE. Ill have to look at tthat. I still can't figure my blitter. The number comes from nowhere here is my blitting code.

	SetRect(&rcRectDest, x,y,x+w,y+h);
	if(x>0)
		gResult = gBuffer->Blt( &rcRectDest, mGraphic, &rcRectSrc, DDBLT_WAIT,0);

kind of hard to mess that up

[Sage Gerard]

I haven't tried WM_INPUT for keyboard management as it looks way more complicated with no sure benefit...
I do mouse input with WM_INPUT and I can say for sure it's incredibly smoother than WM_MOUSEMOVE, especially at low resolutions (and I have a cheap 10 bucks mouse).

He is loosely referring to what the Raw Input API enables. Raw input allows you to communicate with most any human input device attached to the system, and (as implied above) lets you take advantage of things like high resolution mice.

[the Code Gremlin]

thanks for all the help. I think the blitter is messed up by my menu, either that or the coords of my mouse are messed up by it. anyway, thanks again. good day sir.