Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[pjcast]

I've already mentioned elsewhere, but I have begun a big refactoring of the next version's API in order to handle externally created Devices (i.e. WiiMote, et al).

Anyway, I have pretty much reduced the number of virtual functions in InputManager, and now it does a lot more of the work itself. Anyway, what does this mean?

* InputManager will now cleanup all created devices that you may have forgotten to when it is destroyed
* InputManager now handles creation and destruction of devices, and uses the FactoryCreator classes to do the work of enumerating and createing/destroying the actual devices
* Derived InputManager classes must create a FactoryCreator class of some sort (can be itself) to create objects
* A FactoryCreator instance can create different Types (i.e. OISJoyStick, OISKeyboard, OISUnknown...)

One thing I havn't quite worked out yet, is how buffered events/state polling will happen with devices other than the basic types (OISUnknown).

[pjcast]

Ok, Linux side is cleaned up. I will attempt to clean up the OSX side too, but no garentees there until I get a OSX guy to build and test it

[pjcast]

Oyy, more refactoring

I made the base Object class now need a speacialized constructor, to at least ensure derived classes are filling in needed information. Now, the base classes Keyboard/JoyStick/Mouse all fill in the OIS::Type automatically (only need to know information for device writers).

Anyway, i think the API is very clean now. 1.1 (cvs head) should be stable enough for brave users now (under Win32 and Linux). Even brave Wii users can try to enable Wiimote under Win32 (OISConfig, uncomment the Wii mote support line and rebuild all). You don't get any information from it, yet, all it does is update the WiiMote, and print a debugging dump. I do not have any Wiimotes currently, so I cannot go any further. To build the Wiimote code, you will need to get the lfollowing ib's and headers from here:

*  HID.LIB
* HIDPI.H
* HIDSDI.H
* HIDUSAGE.H
* SetupAPI.H
* SetupAPI.LIB

I would include them, but they were part of the Windows' DDK. And, I'm not sure of the legality of doing such. Perhaps, I will include them in CVS though. Just place them in the ois/src/win32/extras/Wiimote/ folder and build all :-)

[pjcast]

I just (hopefully) fixed up the Mac files. I cannot say for sure, as I cannot test here. I did not mess with the project files, as they are beyond my ability here. However, looking at some of the source files (namely the MacMouse.cpp), I don't really see how mouse works under OSX.. as there are several stub functions.  :?

[pjcast]

Ok, besides LIRC & WiiMote changes. I added another method to InputManager that allows you to set (at runtime) what optional components are activated. You can activate them one by one, or all at once. You cannot deactivate them, just destroy and restart OIS for that. If the coponent support was not compiled in, the call has no effect.

Why? Because, the component such as LIRC has a network connection test when activated, which if no LIRC sever found takes about a second or so to return (if LIRC server is found, it is much quicker). Not too long, but quite annoying to someone using OIS if they do not plan on supporting those things. However, this leaves the lib builder to still compile support in, and allow the user to decide if they want to enable support.

Basically, it boils down to more flexibility, which is what 1.1 is all about.

[Steven 'lazalong' Gay]

What is the status of 1.1 ?

Any change log, roadmap, planned features, api breaks doc?

Also there are some bugs, patches and features requests on SF that are open.
Any reason?
http://sourceforge.net/tracker/?group_id=149835

Perhaps a "1.1 Status" sticky post

[pjcast]

What is the status of 1.1 ?

Any change log, roadmap, planned features, api breaks doc?

Also there are some bugs, patches and features requests on SF that are open.
Any reason?
http://sourceforge.net/tracker/?group_id=149835

Perhaps a "1.1 Status" sticky post

Status of 1.1 is that Windows and Linux version appears pretty stable. The OSX version is unclear at the moment... However, since I now have access to a MacBook, I can test and compile the latest version... once I have some time that is. There is no more roadmap than what you see on the forum. Mainly, what would be nice for a next release is to get XInput/360 controller support in. No time for this yet though. No plans on breaking interface anymore, it has been stable for the last 9 months.

Reason why I haven't taken the time to clear/approve/fix bugs yet has been the time factor. Feel free to test any of the patches on the tracker and let me know if they fix any issues you face. however, for the most part, OIS is fairly stable and does what is needed to do, the only areas for improvement right now are OSX support for joysticks, and supporting more devices.

[OvermindDL1]

I still have no clue why XInput broke the standard DI interface, yes DI was ugly, but it worked, and I see no real offering that XInput has over DI...

[pjcast]

The only benefit it has really, is that it supports MS new standard controller API - which I bet, just because they are MS, will be used more and more. It does offer a simple interface over DI, but of course is not very compatible... if it worked for (*cough*) legacy controllers, it would not be so bad.. but anyway, would be good to support it here.

[OvermindDL1]

It is a better designed API no doubt, but it still has nothing new over the old, nor (as you stated) is it backwards compatable, which of course just makes no sense at all...

[pjcast]

Just wanted to post a little update. I've started looking at & working with the OSX HID manager, and currently am able to enumerate devices and open a handle to them. Hopefully, I will soon have a great little system in place for Joysticks on OSX!!!

Just for reference, my current joystick for mac testing is my trusty old USB modified XBox (Original) controller :-). Works pretty good after I grabbed some drivers. I hope to have something to show in a week or so.

[pjcast]

Update -

I committed the enumeration stuff and made an OSX Hid factory creator class which currently enumerates gamepads / joys, and shows them as available. However, creation is not implemented and if tried will raise an exception.

Also, I found a bug/issue with OIS::Exception where on OSX platform it is impossible to catch an OIS Exception, seems the symbol somehow was hidden ?? I took the time to enforce symbol visibility under OSX compilation properly, and _OISExport will unhide symbols. However, this didn't affect the problem at all. Seemed the only way to solve it was to add OISException.cpp and a class member within the file. So, i took the liberty to inherit  OIS::Exception from std::exception and the what() function simply returns the text of the exception. Anyway, this solved the issue, so I can now move on to device creation, and then device polling.

Also, I've noticed some issues with Mac Mouse, in that absolute values and in fact mouse hiding is/was not working properly. Seems that when you lock the mouse, you get relative value increase, but absolute position never changes from the real OSX mouse. And, hiding also is not working properly... If you click on the window, the mouse gets hidden. However, if you click on the icon in the dock of the application window, the mouse does not hide, though it gets locked. This has the interesting side effect of mouse clicks start clicking on the app icon over and over

No idea best way to solve this yet, but if anyone has a suggestion, feel free to post. My only current thoughts are to do something like what is done on x11, which invovles manually warping the mouse around inside the window to keep it within bounds.

[pjcast]

Ok, I think I have a solution for the Mac OIS mouse movement.

When OSX Mouse is set to invisible:
First - get the center of the window and warp the mouse there. This prevents the OS cursor being visible on the system dock.
Second - hide the OS mouse
Third - lock the mouse position. Now, this means relative motion will work, but real OS absolute position will not work. So, OIS absolute position will simply add up the relative motion events (and of course capping the results).

This will allow both relative and absolute mouse positioning information to be correct.

Now, if the user elects to show OS cursor, then we will not warp, lock, or hide the mouse. So... I just need to figure out how to get the window's location and warping the mouse is easy.

[pjcast]

Hmm, I've also noticed that the Mac Input Manager required that the user code 'push' events. This sort of went out of OIS standards, whereas callbacks were happening outside the capture method. So, I modified the keyboard class to raise its own events when capture is called. It filters only the keyboard messages and ignores the rest. The same was done for mouse event handling.

Not sure why it was the way previously, but not so important at the moment. Hopefully this doesn't break something I am not aware of.

[pjcast]

Finally, made some progress getting the Mouse cursor on the OSX console demo version to behave. Still have to fix absolute motion values, but at least the mouse cursor can now safely leave the window by pression Apple key + tab, and you can click on the window's dock icon to bring the window back in focus... However, like the x11 platform, the mouse does not get captured again (on purpose) until the user clicks on the window itself. This gives the user a chance to move the window and/or resize it before the mouse is grabbed again.

For absolute values, I simply need to add the relative motion (only when not using OS cursor) and that should be that. Anyway, now I can start looking more seriously at the HID stuff some more - which is also, a pita.