Input System

[1337]

I just cannot believe what I've just seen. To restore compliance with OIS 1.0RC1, I downloaded and tested it --> doesn't compile.

The reason is quite simple. v1.0 has a method called numKeyboards(), v1.0RC1 has one called numKeyBoards(). The same goes for numJoySticks() resp. numJoysticks().

Unfortunately both versions are versioned 1.0.0, codename "nitro". I'm not sure whether I can resolve this.

EDIT: That's really going to be tricky. The only way to make it portable automatically is with CMake. But that's not very easy since I would have to read the appropriate header file (one of 7 that are different; diffed them all...) and compare the string lengths.

EDIT2: fabian suggested to simply build ois with orxonox. That makes things a lot easier for me: The version is always 1.2 and I can update whenever a new version releases without having to bother about compatibility. OIS by the way is only 270KB heavy, just if you're wondering.
Anyway, OIS compiles right now, but I couldn't test it on linux yet.

[beni]

Well, that's the shit about those RCs in the repositories. It's the same with Firefox 3 Beta 5 in Ubuntu. RCs mustn't survive somewhere in a package, because they are NOT supported at all. Even if older versions are supported an RC is left out, because a newer version replaces its functionality completely. This is a big issue, with which developers have to deal with.

The solution is okay, but I don't like it that much. There is nothing better we could do, unfortunately.

[1337]

A little status update on my work:

The InputManager class is now complete for the moment. As far as I can right now, There's nothing to add. What it does:

• Initialises and destroys the OIS devices
  
  Captures and redistributes input events. I have added the button/key Held event and a mouseScrolled event (OIS puts this under mouseMoved and uses the Z-axis which I didn't change) to make things easier
  
  Manages different input handlers like a keybinder, 'gui input feeder', text input buffer, or whatever we need. You can add any handler any time later since they're simply stored in a map.
  
  Input mode IS_CUSTOM enables to configure (enable/disable) the input handlers customary.

The KeyBinder class is not that complete actually. There are two major issues to deal with:
- Analog input (will make a comment on this below)
- OnPress, OnRelease and OnHold are three different bindings right now. That's overkill in the keybindings.ini file. But we've got ideas to solve that one.

The InputBuffer on the other side is in good shape. Fabian has done most of the work already. I only adjusted it to be an InputHandler and I have added automatic key repetition that can be configured in orxonox.ini

@Felix, I think you might be interested in this:
There are two ways you can capture mouse movements.
One is absolute coordinates. That's exactly like your usual mouse pointer. (0|0) is the upper left corner and (ResolutionX|ResolutionY) is the lower right corner. In order for this to work, you need to set the mouse clipping size when the window size changes. Felix has already done that in GraphicsEngine, thanks
The other possibility is 'relative': In every tick() you simply get the relative mouse movement from OIS since the last tick(). But what happens when we go past (0|0) for instance? Doesn't matter, relative movement is independent on that.
Now, the SpaceShip does a mix: It uses the relative coordinate to calculate absolute values. That's why things don't always work the way they should. But the issue is going to fade anyway soon when analog input works fine.

So much about the input system for now.