Is there anyone working on "Controller" implementations for other platforms, i.e. Linux?
On another note, has anyone considered extending the LWJGL controller support to allow multiple controllers on one machine?
Kev
Not that I know of. I (the linux maintainer) don't even have a gamepad or joystick of any sort. Multiple controllers would be nice though, it's probably a pretty common setup (esp. if you're a wannabe console maker, right? ;-) )
- elias
Quote from: "elias"Not that I know of. I (the linux maintainer) don't even have a gamepad or joystick of any sort. Multiple controllers would be nice though, it's probably a pretty common setup (esp. if you're a wannabe console maker, right? ;-) )
- elias
Are there harsh penalties (duties and what not) for importing USB gamepads to Denmark and what not? If not, I might be willing to ship you a couple Gravis pads (if I can locate some) for the Linux/OS X cause, if you're interested.
EDIT: actually, It'd probably be better to ship a couple Playstation2->USB converters. I like the PS2 controllers over anything I've messed with on the PC front...
I think that elias won't have time for doing controllers for linux / mac before the actual mac port is done (ogl/oal first). And when that time arrives, hopefully somone else has done it ;) - and if not, I could probably just drive over to elias and let him borrow my controller (we live ~ <10 km from each other)
I wouldn't mind taking a look, I'll probably want it soon anyway. But I'd like to do the multiple controllers bit at the same time (since if anything I reakon thats more important).
Essentially, since JInput already does linux alright and SDL exists it should make it pretty easy. Not to mention Endolf being a mate of mine :)
Kev
well, I am all for doing multiple controllers, but it needs to be in a very simple api - jinput is too... fiddly for my liking.
isn't linux controllers possible without sdl? I would hate that dependency...
I know that at least recent kernels (>=2.4) supports HID like the Mac OS X. That would be a good standard to expose, avoiding SDL.
- elias
Ah, I didn't mean USE SDL, I meant read their code, work out how they did it and rewrite. SDL is LGPL anyway, too scary to get dependant on.
API:
Controllers static, getControllerCount() and getController() returning an interface that looks just like the Controller now?
Kev
either that, or public static array of controllers?
Controller.controllers[1].getX();
or set active controller before using methods
Controller.setActiveController(index) (or Controller.use(index))
we could also pass the controller index to a method?
Controller.getX(0);
lots of ways... - though somewhat untraditional, I kinda like the last way... opinions?
Definitely the Kevglass way. We certainly don't want to pass an index around to all methods.
- elias
I agree. No point in passing around indices when you can just hold onto an Object.
Looking at the C for the controllers stuff it'd need heavy work to support multiple controllers (WIN32). Does this need doing?
Kev
While we're at it, Controller seems slightly limited. Isn't a controller merely a collection of axes (digital or analog), buttons and whatnot? Or does every controller fit the POV, Rot axis and axis and buttons view?
- elias
Careful, you'll turn it into JInput complexity... shouldn't the API be as game oriented as possible, the functionality it currently exposes should cover every game type in existence (and does so in a simple manner)
Kev
Maybe so, but I'm still worried. What is done if the controller in question has more than one of the same type of axis for example? Will we choose one? Make them all act the same?
- elias
QuoteDefinitely the Kevglass way. We certainly don't want to pass an index around to all methods.
Aye, but now you're passing a Controller around. Threre is also option 3, setting the active controller before playing with it - kinda like pbuffers. Then we wouldn't have to pass anything around...
As for controllers being able to handle all cases, we have a slight problem. There are literrally thousands of different devices out there. And I think we should just make our api support common controllers (whatever that may be) and not go the axis route. The JInput way of doing things, is really messy. Flexible, but messy. And the end result is that you have a developer that doesn't even know how to use the controller api!
What we have right now might not support *all* devices equally well - but it sure as hell is simple to use.
That said, the current controller api hasn't gotten the testing it deserves, so there might still be issues in it wrt. axis/pov/rot
Fair point, so you reakon it should be done something like:
class Controllers {
static int getControllerCount();
static Controller getController(int i);
}
class Controller {
int getButtonCount();
boolean getButtonState(int i);
int getAxisCount();
double getAxisState(int i);
}
I'd be worried about not identifiing Axis specifically. While most of the time the game needs to get the user to configure their controls (i.e. move the stick in the direction you want the banking of the plane to be) assuming that devices are consistant on reporting their axis it would be possible to do some auto configuration.
Probably the answer is if the device reports the same axis twice then its a "Just pick one". However, this would be pretty odd behavior from any controller.
I still think passing a Controller is preferable, you hold the reference to the controller your using and call methods on that. If you have an int you have to pass it in to every call. Setting the active controller might be cool, but if you're supporting multiple controllers this could get irritating switching all the time (thread safety, complexity of the underlying code).
I'm still of the opinion that the currently Controller interface is fine, it just needs to be non-static and have a manager type class that dolls out Controllers on an indexed basis.
Kev
I'm thinking something along the lines of a simple Controller with the ability to explore all it's axes, buttons and whatever. Kind of like extensions to the Core GL (which by your argument should be removed - you don't need anything else than GL11 to make a game)
- elias
While I see your point I think theres a considerable difference between missing extensions and missing repeated axis. However, how about a combined interface then...
Controller as it is now, i.e. with getPov() and getRx() with the addition of:
int getAxisCount();
int getAxisState(int i);
String/int? getAxisName/Type(int i);
This way for general purpose its really easy and for any extended controls the functionality is still there.
Kev
Well, for the axis state I like floats better (range 0..1?). And we need some kind of event queue functionality like the mouse and keyboard.
- elias
I don't think there's a way around an Axis object with type, state and queue.
- elias
Axis object internally for sure, its whether they get exposed to the outside world or not? Does an axis without a controller really make sense?
Float range might be better -1 .. 1 since axis normally centre on 0.
Kev
Axis instances are only visible as an interface returned from Controller.getAxes().
- elias
Regardless of the public LWJGL API, wouldn't it be a good idea to develop a common HID interface to all platforms to use as basis? HID is supported on win32, linux and mac and using the same underlying terminologi and interface would simplify the development a lot.
- elias
Would that fix the DirectX NT issues as well?
Reading about a bit, it seems like HID is the right way to go. Although there arn't many examples of using it on Windows. I suspect it'd take a bit of playing around with..
I'll go and have a play...
Kev
Great. It could actually be a separate "jHID" implementation that LWJGL Controller then builds upon.
- elias
Just been looking at jUSB and libhid. Neither seem to be properly complete or available :(
Kev
libhid is absolutely naffed. libusb is available (ish) but isn't really complete.
jusb is available for both windows and linux (although limited) but requires you to come along with a new device driver which doesn't seem all that great to me.
So the options appear to be:
a) Write a wrapper for the different HID functionality on each platform (even tho its not exposed fully on windows).
b) Write a wrapper around the exposed input APIs on each platform, basically whats been done already but more.
c) Use the JInput plugins but get rid of that infernal plugin system and wrap the API is something thats easier to use.
Any others...?
Kev
a) or c) is the way to go I think. I wouldn't worry about windows lacking some HID functionality because DirectInput itself uses HID for HID enabled devices.
- elias
I quite like c) because it means any development is shared (i.e. macos!) Unfortunately it might require some changes in the JInput world becuase I know they had to work round not being able to get access to the AWT window (sic!).
However, I suspect some sort of "Context" object could be used in JInput to allow it to work with any window provider...
Kev
I don't like c) because of the hidden window and all that crap. HID is simple and "crossplatform". In fact, I already have a mac os x (hid.c in native/macosx) implementation of HID for mouse and keyboard from the time I experimented with input.
- elias
Having done a bit more research:
1) HID is just a hardware standard? There's no common software API? (Maybe everyone else knew this, but it was news to me :))
2) The linux JInput plugin requires no window at all, so lwjgl could pick that up with no penalty
Kev
Hi
I can confirm, that the linux plugin requires no window at all. infact, one of the ways I tested it was to ssh into my dev box and fiddle with the gamepad (the joys of wireless gamepads). It's all console compatable :)
Endolf
P.S. After a longish discussion with KevGlass a solution to the plugin usability option has emerged, I'm putting it to the JInput list now to see how they take it. It means that each platform will have 1 jar and 1 native lib, rather than 3 jars, a native lib, and a system property or stange dir structure.
Sounds good, but doesn't the win32 version use a hidden window? I've also heard about problems regarding JInput<->LWJGL input interactions. I think it was rgrzywinski.
- elias
And if we are to use JInput for LWJGL Controller support, it would almost certainly be required that the native library can be merged into the lwjgl library at compile time (same goes for the jar, but that's a lesser problem I guess). Is that possible?
- elias
The windows version currently uses a hidden window. However, the trade might be that someone implements a windows plugin for JInput that doesn't use a window (like the current LWJGL impl).
Since the JInput license is BSD I don't see any reason why the LWJGL build can't drag any source it requires into the build ;)
Kev
Quote from: "elias"Sounds good, but doesn't the win32 version use a hidden window?
Yup, but looking at it, I'm not sure it needs to any more, tested ok without one for just a mouse and a keyboard, but no access to a joystick right now. Anyone willing/wanting to test let me know :)
QuoteI've also heard about problems regarding JInput<->LWJGL input interactions. I think it was rgrzywinski.
I've not heard of this at all though.
Endolf
Quote from: "elias"And if we are to use JInput for LWJGL Controller support, it would almost certainly be required that the native library can be merged into the lwjgl library at compile time (same goes for the jar, but that's a lesser problem I guess). Is that possible?
I see no reason why not. The source is BSD, mingw and directx8+ is the only windows compile time requirements.
Endolf
Here's what I use. (http://puppygames.net/forums/viewtopic.php?t=422&highlight=)
Is there any reason why directx 8 is required (along with the window)? Couldn't JInput on win32 be implemented in win32 with the HID interface?
- elias
Because it's not just HID devices that are supported, game port joysticks, non usb keyboards and mice etc. Same goes for linux.
Endolf
Nothing to stop the implementation of a JInput plugin for windows that just used DirectInput (i.e. Not 8) ?
Kev
Maybe it should read 'DirectInput from directx8+ required', the rest of directx is unimportant, but we use some features that were not present before directx 8. Seeing as LWJGL is a gaming lib, and most gaming machines can cope with dx8 (and will almost certainly have it installed, most are on 9 by now I imagine) that dependency shouldn't be an issue. Unless i'm missing something here?. The window seems to have been needed in the past, but I've done a quick test and don't seem to need it, I posted a message somewhere I think saying that i think it's no longer needed, but need to do some more testing.
Endolf
Ah ha, even better! So, if LWJGL were to use JInput plugins wrapped up in some nice easy shell there could be support for multiple controllers on Windows, Linux and at least a start on the MacOS one?
And as and when someone with access to a Mac gets the chance to sort out input there JInput would benefit from a complete Mac Plugin?
Kev
That just about sums it up, yup :)
Everyones a winner :)
(Including me as it means jME gets joystick support on things other than winblows :))
Ooer, could JInput be build into static libs aswell as dynamic? I presume thats not to difficult? Then instead of building all the code in LWJGL could simply build against the libs?
Kev
No idea on mac, but certainly on linux and win32 it's just changing the args to g++. I'd add another ant target, that non of the scripts call, but could be called to create them, that way they arn't done for jinput noobs, but your average dev could work out how to build them.
Endolf
This is very interesting. One thing left though - does the mingw requirement also comes with a requirement of a mingw runtime library at the user? And if yes, how large is that?
- elias
Don't think so, at least I didn't ship it with Martian Madness and that seemed to work happily :)
Kev
I'm wondering whether we really want to create a LWJGL wrapper. Is JInput really so complex that we can't just ship it "embedded" in the LWJGL native library and jar?
- elias
From talking to Endolf today I get the feeling its come on a bit since I last tried. Although I still think some utility functions could be provided (like being able to detect the next input recieved for control configuration). However, I suspect these could do with being added to JInput generally.
EDIT: Also at the moment JInput is dependant of the plugin mechanism (i.e. you specify with plugin is going to be used by dropping it in a particular location in the file system). I don't really think this fits LWJGL. In addition, for gamepad support, which I'm assuming is all thats wanted here, there would be no need for this plugin nature. On windows you'd want one plugin, on Linux another and MacOS another. No need for multiple plugins on multiple environments. This could all be preconfigured in LWJGL preventing the developer having to worry about it.
Kev
But apart from the configuration of plugins (which could probably be defaulted in the LWJGL package distribution), how complex is the actual JInput API? Too complex for LWJGL? and if no, what can be simplified such that most controllers are still fully supported (PS2 controllers, Joysticks, Wheels and whatnot).
- elias
Its not really that complicated, but its easy for me to say that, I've used it before. Theres a slight difference in that buttons are treated as Axis (which I think might confuse a few people) and that there are method named relating to particular Axis. You say getAxis(int AxisType) not getRX(). Neither of these things are particularly hard to understand but both are slightly less as intuitive as LWJGL's current Controller.
Kev
Quote from: "elias"This is very interesting. One thing left though - does the mingw requirement also comes with a requirement of a mingw runtime library at the user? And if yes, how large is that?
MingW compiles against the MSVCRT, so nothing beyond that is needed.
Quote from: "elias"does the mingw requirement also comes with a requirement of a mingw runtime library at the user?
No, it's just the build environent, ming includes g++ on a win32 platform, and has the libs required to build directx stuff with g++, after that, you only need the binary it creates and the directx runtimes (the standard ones that everyone already has).
Endolf
Quote from: "kevglass"Its not really that complicated, but its easy for me to say that, I've used it before. Theres a slight difference in that buttons are treated as Axis (which I think might confuse a few people) and that there are method named relating to particular Axis. You say getAxis(int AxisType) not getRX(). Neither of these things are particularly hard to understand but both are slightly less as intuitive as LWJGL's current Controller.
The Axis object has been renamed, controllers are made up of components, a component is a key (for keyboards), a button (gamepads, joysticks) or an axis, as in throttle/POV hat etc. To get the list of controllers you call DefaultEnvironment.getControllers() (or something like that) and it returns a Controller[] you then can call getType() on those and it will return Controller.GAMEPAD or Controller.MOUSE etc, you can then do a getComponent(Component.Identifier) which are a bunch of static defined id's, like Component.Identifier.Button.START or Component.Identifier.Axis.THROTTLE and it will return one if it has it, or, you can call getComponents() and it will return them all, and you can then query them.
The plugin system is the biggest downfall in terms of usability (I think), but I have a solution that allows it to still be used, but also to be defaulted if wanted (like in LWJGL).
Endolf
What happens if I disconnect a joystick? Is the application notified?
- elias
There is a system in there to allow for that yes. Currently, when you call poll on the device, it will return non zero indicating an error, but there is a listener interface that is unimplemented so far that is designed for exactly this purpose.
Endolf
Theres a slight problem with the Button.START type thing. One of my joypads for instance doesn't identify its buttons in any other way than "BUTTON15" and "BUTTON1". Is there anyway that JInput (or anything else) could tell that its a start button?
If not then I'd have to basically rule out ever using the identifiers since they couldn't be consistantly assumed... hmmm maybe as defaults or something?
EDIT: Also interestingly, I tried the JInput webstart demo with my PS1 controller and although it detects the named buttons (BUTTON1 etc..) it doesn't actually detect them being used.
Kev
It's down to the driver what it defines, assumptions could be made, but thats a baaaaaad thing to do.
The webstart demo is about 12 months old or something silly, ignore it, it's not up to date :)
The way I'd seen them being used is like you say, just defaults, then once the config screen is run, you get the id's from the component selected, and store that, then next startup, you can just try and get that component from the id.
If that makes sence
Endolf