Game Development Community

Hardware Cursor

by Peter Simard · in Torque Game Engine · 02/22/2007 (4:04 pm) · 10 replies

Anyone have any information regarding hardware cursors. I have read through the DirectInput docs and can't seem to find it. I find one of the biggest signs of an unpolished game is mouse lag. I think enabling a hardware cursor will go a long way to improving Torque.

#1
02/22/2007 (4:27 pm)
I don't think you need to involve DirectInput at all since it deals with input of hardware events, not displaying of the hardware cursor.

Try commenting out the entirety of "GuiCursor::render", and adding a Platform::showCursor(bool) stub that you call in the appropriate places (for your game).

For Windows, that function looks like:

void Platform::showCursor(bool show)
{
   if (show)
      while (ShowCursor(true) < 0) ;
   else
      while (ShowCursor(false) >= 0) ;
}

In addition, you can make fixes to guiCanvas.cc to avoid the math around GL cursor handling in GuiCanvas::renderFrame, although those aren't necessary if you just comment out the GuiCursor::render stub.
#2
02/22/2007 (5:40 pm)
Thanks for the quick response Tim!

I have succesfully got my program to use the hardware cursor. If anyone else needs this, here is what needs to be done:

Comment out all referenced to ShowCursor(false) in winWindow

Add this function to winWindow.cc
void Platform::showCursor(bool show)
{
   if (show)
      while (ShowCursor(true) < 0) ;
   else
      while (ShowCursor(false) >= 0) ;
}

Modify the void GuiCanvas::setCursorON(bool onOff) to:
void GuiCanvas::setCursorON(bool onOff)
{
	Platform::showCursor(onOff);

   cursorON = onOff;
   if(!cursorON)
      mMouseControl = NULL;
}

Now I just need to figure out how to convert the SetCursor method to hardware.
#3
02/22/2007 (6:17 pm)
Brilliant idea!
#4
02/22/2007 (7:24 pm)
Does this break portability?
#5
02/22/2007 (8:40 pm)
I'm sorry I forget to mention commenting out the cursor show/hide functionality in winWindow.cc.

Writing a SetCursor that is cross-platform is easy enough, provided you can live with a specific list of cursors (an enumerated list) and don't need to allow for fully custom cursors.

And, no, it doesn't break portability, if you are able to provide an implementation of Platform::showCursor for your target platforms (and Platform::setCursor, of course, if you need that).

I'm glad I was able to help Peter!
#6
02/22/2007 (9:03 pm)
Well, what I thought was a trivial task has really stumped me. I am unable to set a custom cursor for my application. I added a new cursor to the project resources, but I am unable to access it.

Inside the resource.h file it looks like:
#define IDI_ICON1                       107
#define IDC_CURSOR2                     108

And I am setting the cursor inside InitWindowClass:
wc.hCursor       = LoadCursor (NULL, MAKEINTRESOURCE(IDC_CURSOR2));


Unfortunatly when I do this the cursor becomes a default verticle resize cursor, not the one I set.


Any pointers?
#7
02/23/2007 (10:25 am)
Tim,
Thanks for clarification.
#8
02/23/2007 (1:42 pm)
I actually made:

void Platform::setCursor(void* cursor)
{
   if (cursor)
      SetCursor((HCURSOR)cursor);
}

void* Platform::loadCursor(const char* cursorFile)
{
...
}

bool Platform::unloadCursor(void* cursor)
{
   return DestroyCursor((HCURSOR)cursor);
}

'loadCursor' uses LoadImage to load OS cursors. Haven't looked at the constants in resource.h. We use constants from winuser.h
#9
02/23/2007 (4:09 pm)
Wouldn't it make more sense to create a threaded version of the cursor code? That way you do not throw away functionality, keep cross platform capabilities, and keep the cursor nice and snappy. I guess, if the threading is cross platform too.
#10
04/11/2007 (11:21 am)
Quote:
Wouldn't it make more sense to create a threaded version of the cursor code? That way you do not throw away functionality, keep cross platform capabilities, and keep the cursor nice and snappy. I guess, if the threading is cross platform too.

That doesn't work. The problem isn't threaded'ness, it's that the cursor that Torque uses is the GL one, which is composed onto the frame, and hence, linked to the frame rate that your game is rendering at. The hardware cursor doesn't have this limitation (since, it's, uh... handled in hardware :)

Unless I'm misunderstanding what you mean.