Wrecked Games

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're just that awesome.

Author Topic: capture()  (Read 1158 times)

cdsnyder

  • Regular
  • *
  • Karma: +0/-0
  • Posts: 26
    • View Profile
capture()
« on: February 15, 2006, 08:21:52 PM »

Ok, just making sure I understand this correctly.  In the case of buffered input, does the user-provided callback get initiated only when capture() is called?  I was reading through the implementation in linux, but I'm not well versed in X and don't quite get the whole keyboard grabbing thing.

Chris
Logged

Rackle

  • Regular
  • *
  • Karma: +0/-0
  • Posts: 26
    • View Profile
capture()
« Reply #1 on: February 15, 2006, 09:20:58 PM »

The short answer is: yes.

I'm using buffered input under Windows.  Here's a tiny bit of code:

   bool frameStarted(const FrameEvent& evt)
   {
      if( mWindow->isClosed() )
         return false;

      if( mWindow->isActive() )
      {
         mKeyboard->capture();
         mMouse->capture();
         if (processUnbufferedKeyInput(evt) == false)
            return false;
      }
      return true;
   }

I'm calling capture() every frame.  If you look through the code you should see (under Windows at least) that capture() calls _readBuffered() which in terms calls your implementation of keyPressed() and keyReleased().  In addition OIS maintains an internal buffer of keystates, which you can access via isKeyDown() both within the buffered function callbacks (keyPressed and keyReleased) as well as whenever you wish; I've adopted Pjcast's processUnbufferedKeyInput as my function to check for user input, such as monitoring the arrow keys for character movement and pageUp + pageDown for camera movement.

Hope this helps.
Logged

pjcast

  • Administrator
  • Veteran
  • *****
  • Karma: +1/-0
  • Posts: 2661
    • View Profile
    • http://www.wreckedgames.com
capture()
« Reply #2 on: February 15, 2006, 09:44:19 PM »

Capture is called for both unbuffered and buffered input. On Win32 DirectInput has anotion of buffered and unbuffered devices. The Win32 Mouse however, is created only in buffered mose internally, but is updated to the outside as buffered or unbuffered. The keyboard is created in either unbuffered or buffered (_read is unbuffered  and _readBufferer IIRC is buffered)

Under Linux, X has no sense of either buffered or unbuffered. It is more like buffered (like the Win32 Winproc) and OIS internally keeps track of state changes for unbuffered input. The same is true for Joystick under Linux.
Logged

cdsnyder

  • Regular
  • *
  • Karma: +0/-0
  • Posts: 26
    • View Profile
capture()
« Reply #3 on: February 15, 2006, 11:15:20 PM »

Ah, ok. I understand. In order to keep the interface uniform, I've made my own internal fifo event stack.  The trick is that I'm registering listeners for raw keyboard events with OSX, and I can't tell OSX to queue them until I want them. It calls my callback immediately when the event occurs, so I'm just going to keep a stack of events and then send them off upon capture(). A bit redundant but it gets the job done ;)
Logged

pjcast

  • Administrator
  • Veteran
  • *****
  • Karma: +1/-0
  • Posts: 2661
    • View Profile
    • http://www.wreckedgames.com
capture()
« Reply #4 on: February 15, 2006, 11:28:21 PM »

Sounds good. Just remember, for mouse axis movement, you can just total up all the X & Y movements per frame and just call the mouseMoved once. Though, I would seperate out the Z motion from the mouse XY axes as it is usually used differently then the Mouse X/Y.
Logged