Thank you very much. And you also put in the “trigger” line. =D
@revv said: Thank you very much. And you also put in the "trigger" line. =D
Yep… seemed to do no real harm and it prevents the triggers from being confused as another axis.
@pspeed said: I bought these just for testing a variety of gamepads... so I went cheap. Nothing more than $20 and most less than $15.
I’ve just bought a collection of gamepads and joysticks too.
I mixed some PlayStation-style devices and some XBox-style devices (different layout).
I now have 5 Joysticks and 10 Gamepads. Mostly to test them with jME during development.
I only find Windows drivers, and these must be installed for some features (like force feedback / rumble).
I’ve found one particular device (a PS3-style gamepad) that doesn’t have Z-axis / Z-rotation, but the right stick is “slider”+“inverted Z-axis”. The gamepad was made by Thrustmaster - the leading joystick manifacturer, and their engineers kind of must have mixed things up. This gamepad can serve as a joystick replacement, but not as a gamepad. Usually it’s the other way round and gamepads are supposed to be joystick-replacements. 
However, with a proper remapping function, one might map:
new z-axis = slider
z-rotation = old z-axis
Also I finally got rumble to work, but there are some quirks and I don’t like the jME rumble interface. See this post:
http://hub.jmonkeyengine.org/forum/topic/joystick-implementation/
@Ogli said: I've found one particular device (a PS3-style gamepad) that doesn't have Z-axis / Z-rotation, but the right stick is "slider"+"inverted Z-axis". The gamepad was made by Thrustmaster - the leading joystick manifacturer, and their engineers kind of must have mixed things up. This gamepad can serve as a joystick replacement, but not as a gamepad. Usually it's the other way round and gamepads are supposed to be joystick-replacements. :-) However, with a proper remapping function, one might map: new z-axis = slider z-rotation = old z-axis
So does this joystick properly name itself something that easily distinguishes it from other sticks? Were you able to configure a remapping that works?
If so then we can include it in the default remappings.
Where is your famous remapping file again? I have so many locations I work on in my filesystem.
I’ve found many more of these ‘odd specialties’, here some examples:
- zRotation and zAxis are switched under Xbox versus PS3 style controllers
- some devices constantly send axis values, while others remain ‘silent’ until a stick is moved
- one device had two zAxis, but one of these couldn’t even be found on the gamepad itself (I looked everywhere)
- similar, one of the joysticks should have 12 buttons, but I could only find 8.
- the aforementioned gamepad that comes from Thrustmaster, with its strange zAxis, zRotation setup
To solve all this mess:
I would like to go even a step further and want to make a jME AppState that will let the user visually configure their input device.
To accomplish that, I will have to inspect the current input system of jME, which is quite hard to read for some reasons.
But… I could need your help for one particular part:
Where does this nice interactive image of the Playstation-controller originate from? Could you make two more? I need a Xbox-controller and a Joystick with thrust slider and some buttons on it. These three images would cover a lot of gaming devices. The only things that won’t be recognized are things like steering wheels, gas pedals, drawing tablets, and so on.
What do I have in mind with this?
Every time an unknown device has been detected, the AppState will start a graphics interface where the user has to press all buttons for each highlighted button in the shown image - one after the other. Also the user must move all sticks, sliders, analog triggers when requested to.
The result would be three standard gaming device classes:
StandardJoystick, StandardXbox360Controller, StandardPlayStation3Controller
The second step is of course the persistence/serialization of this configuration to a file that could be shared among all games on the same machine. You could easily copy-paste it if you want to play under a different machine with your favorite settings. Therefore the best storage location would be the home directory of the user.
The result would now be a .xml file in the user dir that looks similar to this:
[java]
<StandardDevices>
<StandardDevicePlayStationController>
<StandardPlayStationSupporter name=“Thrustmaster T-Mini Wireless 3-in-1” type=“Joystick”>
<StandardPlayStationKey name=“Square” supported=“true” mappedto=“button” id=“3” name=“Button 3”/>
<StandardPlayStationKey name=“Cross” supported=“true” mappedto=“button” id=“2” name=“Button 2”/>
<StandardPlayStationKey name=“Triangle” supported=“true” mappedto=“button” id=“1” name=“Button 1”/>
<StandardPlayStationKey name=“Circle” supported=“true” mappedto=“button” id=“4” name=“Button 4”/>
… (x N)
<StandardPlayStationSupporter>
… (x N)
</StandardDevicePlayStationController>
<StandardDeviceXboxController>
…
(similar to PS controller)
…
</StandardDeviceXboxController>
<StandardDeviceFlightStick>
…
(similar to PS controller)
…
</StandardDeviceFlightStick>
<StandardDevices>
[/java]
The third step is a jME AppState that lets the user visually configure the mappings of buttons to several game action - either directly or with things like “those two buttons together” or “double click on fire button”. Also for some game actions it would be good if they would accept both analog thresholds and key up / down events (for instance the analog trigger on the xbox controller for gas of a racing car could be used with a simple key from a playstation gamepad).
The result would now be a mapping of this kind:
[java]
<GameActionMapping game=“Big Trouble in Little Minecraft”>
<GameState state=“WalkingKickboxer”>
<StandardDevicePlaystationController status=“fully supported”>
<GameAction action=“UpperCut”>
<StandardPlayStationControllerKeyDown what=“id”/>
<StandardPlayStationControllerAxisUp what=“id”/>
</GameAction>
… (x N)
<StandardDeviceFlightStick status=“not yet configured”>
… (empty)
</StandardDeviceFlightStick>
<StandardDeviceXboxController status=“not yet configured”>
… (empty)
<StandardDeviceXboxController>
</GameState>
<GameState state=“DrivingAround”>
<GameAction action=“Accelerate”>
… (similar)
</GameAction>
… (x N)
</GameState>
…
</GameActionMapping>
[/java]
I know exactly what I want and I will get it. Overall this isn’t so hard to achieve and I will implement it, so that jME is a valid gaming platform for desktop games. I just hope that there will be at least basic support under Linux, Mac and so on. I don’t know how fit these platforms are compared to Windows.
For the most part this is really just annoying dull duty work for me. And I would like to make this all open source, together with my console system that is almost finished now.
A good programmable console and a superb input mapping for gamepads should be part of every game engine. (Not ment as an offense, because I know how much time and effort went into this project already by many people)
By the way, here is an overview of my gaming device collection:
http://www.lostplanets.de/files/Joysticks-and-Gamepads.pdf
@Ogli said: Where is your famous remapping file again? I have so many locations I work on in my filesystem.
The one distributed in JME is here:
http://code.google.com/p/jmonkeyengine/source/browse/trunk/engine/src/core-data/joystick-mapping.properties
You can put one anywhere on your classpath to have a local version also. JME loads all of them that it finds… so if you stick it in your assets directory or in your src directory or whatever, it should get built into a jar and available. This is the easiest way to test new mappings.
@Ogli said:I've found many more of these 'odd specialties', here some examples: - zRotation and zAxis are switched under Xbox versus PS3 style controllers
Is this not already covered in the latest default XBox mappings above? Or is it something different?
@Ogli said:I've found many - some devices constantly send axis values, while others remain 'silent' until a stick is moved
The second being the normal expected behavior, yes? I saw this from some joystick controllers also.
@Ogli said:I've found many - one device had two zAxis, but one of these couldn't even be found on the gamepad itself (I looked everywhere)
This happens also in some cheap joysticks I have. In those it seemed like the first ones were always the right ones or something.
@Ogli said:I've found many - similar, one of the joysticks should have 12 buttons, but I could only find 8.
Neat.
@Ogli said:I've found many - the aforementioned gamepad that comes from Thrustmaster, with its strange zAxis, zRotation setup
This should already be supported as a remapping (see above).
@Ogli said:I've found many To solve all this mess: I would like to go even a step further and want to make a jME AppState that will let the user visually configure their input device. To accomplish that, I will have to inspect the current input system of jME, which is quite hard to read for some reasons.
In general, InputManager wanted to be remappable like this but it would be so painful that I’m not sure it’s worth trying to fix at this point. There are quite a few things that make it hard. I ended up making an InputMapper wrapper for my games and then ultimately made that a part of Lemur. It adds a more distinct abstraction layer, better remappability, and the ability to more easily define multiple input triggers to actual ‘actions’. Furthermore, it allows ananlog and button-style listeners to be tied to either type of input. (For example, my game sees no difference between WASD and a pair of joystick axes.)
@Ogli said:I've found many But.. I could need your help for one particular part: Where does this nice interactive image of the Playstation-controller originate from? Could you make two more? I
I sort of hand drew it just for that app.
@Ogli said:I've found many need a Xbox-controller and a Joystick with thrust slider and some buttons on it. These three images would cover a lot of gaming devices. The only things that won't be recognized are things like steering wheels, gas pedals, drawing tablets, and so on. What do I have in mind with this? Every time an unknown device has been detected, the AppState will start a graphics interface where the user has to press all buttons for each highlighted button in the shown image - one after the other. Also the user must move all sticks, sliders, analog triggers when requested to. The result would be three standard gaming device classes: StandardJoystick, StandardXbox360Controller, StandardPlayStation3ControllerThe second step is of course the persistence/serialization of this configuration to a file that could be shared among all games on the same machine. You could easily copy-paste it if you want to play under a different machine with your favorite settings. Therefore the best storage location would be the home directory of the user.
The result would now be a .xml file in the user dir that looks similar to this:
[java]
<StandardDevices>
<StandardDevicePlayStationController>
<StandardPlayStationSupporter name=“Thrustmaster T-Mini Wireless 3-in-1” type=“Joystick”>
<StandardPlayStationKey name=“Square” supported=“true” mappedto=“button” id=“3” name=“Button 3”/>
<StandardPlayStationKey name=“Cross” supported=“true” mappedto=“button” id=“2” name=“Button 2”/>
<StandardPlayStationKey name=“Triangle” supported=“true” mappedto=“button” id=“1” name=“Button 1”/>
<StandardPlayStationKey name=“Circle” supported=“true” mappedto=“button” id=“4” name=“Button 4”/>
… (x N)
<StandardPlayStationSupporter>
… (x N)
</StandardDevicePlayStationController>
<StandardDeviceXboxController>
…
(similar to PS controller)
…
</StandardDeviceXboxController>
<StandardDeviceFlightStick>
…
(similar to PS controller)
…
</StandardDeviceFlightStick>
<StandardDevices>
[/java]The third step is a jME AppState that lets the user visually configure the mappings of buttons to several game action - either directly or with things like “those two buttons together” or “double click on fire button”. Also for some game actions it would be good if they would accept both analog thresholds and key up / down events (for instance the analog trigger on the xbox controller for gas of a racing car could be used with a simple key from a playstation gamepad).
But isn’t this really the only thing that’s needed? I’m not sure I understand why the user would remap their joystick if they are then just going to map inputs to game functions. Just show them the game functions and let them click on it and then wiggle an input to make the association. Then you never have to worry about getting the mappings wrong.
Even the default remapping support provided was just to make most joysticks work most of the time. Ultimately, most games will need some kind of “game function - input” mapping screen.
@Ogli said:I've found many The result would now be a mapping of this kind: [java] <GameActionMapping game="Big Trouble in Little Minecraft"> <GameState state="WalkingKickboxer"> <StandardDevicePlaystationController status="fully supported"> <GameAction action="UpperCut"> <StandardPlayStationControllerKeyDown what="id"/> <StandardPlayStationControllerAxisUp what="id"/> </GameAction> ... (x N) <StandardDeviceFlightStick status="not yet configured"> ... (empty) </StandardDeviceFlightStick> <StandardDeviceXboxController status="not yet configured"> ... (empty) <StandardDeviceXboxController> </GameState> <GameState state="DrivingAround"> <GameAction action="Accelerate"> ... (similar) </GameAction> ... (x N) </GameState> ... </GameActionMapping> [/java]I know exactly what I want and I will get it. Overall this isn’t so hard to achieve and I will implement it, so that jME is a valid gaming platform for desktop games. I just hope that there will be at least basic support under Linux, Mac and so on. I don’t know how fit these platforms are compared to Windows.
For the most part this is really just annoying dull duty work for me. And I would like to make this all open source, together with my console system that is almost finished now.
A good programmable console and a superb input mapping for gamepads should be part of every game engine. (Not ment as an offense, because I know how much time and effort went into this project already by many people)
Anything like this would have to be a plugin, I think. The UI would be heavily game specific and there will be games that never want it and stuff. Also, the game function remapping itself is entirely in how the listeners are registered which either requires game involvement or would require something more amenable to remapping than InputManager is.
Actually, I would love a GUI piece like this in Lemur and it would already support reskinning, would already have access to the more advanced remapping capabilities of InputMapper, etc… And you’d already have GUI controls that are just scene graph elements. But I’m biased.
@pspeed said: The one distributed in JME is here: http://code.google.com/p/jmonkeyengine/source/browse/trunk/engine/src/core-data/joystick-mapping.propertiesOkay, this is a nice feature. Is this because it is a .properties file? I mean, the build script recognizes this by its file extension?You can put one anywhere on your classpath to have a local version also. JME loads all of them that it finds… so if you stick it in your assets directory or in your src directory or whatever, it should get built into a jar and available. This is the easiest way to test new mappings.
The problem is populating such a file. You always need some expert who then configures an ever growing text file by hand. The devices have so many different names - under Windows they even have a different name before or after the correct driver has been installed, sometimes without the driver two devices have the same name but different buttons. I consider this solution as being a workaround.
@pspeed said: Is this not already covered in the latest default XBox mappings above? Or is it something different?I mean there are many different Xbox-style controllers. It's about the layout of the two sticks. Most of them aren't from Microsoft and many have different features (see my list of gaming devices for example).
@pspeed said: The second being the normal expected behavior, yes? I saw this from some joystick controllers also.I don't yet know what is normal for gaming devices. The devices I have might have errors in them. Or it is all about this mysterious "dead zone" - a certain area of values where one would ignore the input received by the game engine. It might need calibration. I would need to investigate this in much more detail.
@pspeed said: Neat.Here is another one: - gamepad from Microsoft has 'circular area for x-axis, y-axis values' (diagonal.x=0.7, diagonal.y = 0.7) - gamepad from all others have 'square area for x-axis, y-axis values' (diagonal.x = 1.0, diagonal.y = 1.0)
Other things include stuff like “very imprecise in the middle” or “jitters like hell, because of cheap pots”.
@pspeed said: This should already be supported as a remapping (see above).Okay, I will give it a try and post the complete remapping for this particular device soon. As I already mentioned, I don't see the remapping file as the ultimate solution and will only do it for one or two particular devices.
@pspeed said: In general, InputManager wanted to be remappable like this but it would be so painful that I'm not sure it's worth trying to fix at this point. There are quite a few things that make it hard. I ended up making an InputMapper wrapper for my games and then ultimately made that a part of Lemur. It adds a more distinct abstraction layer, better remappability, and the ability to more easily define multiple input triggers to actual 'actions'. Furthermore, it allows ananlog and button-style listeners to be tied to either type of input. (For example, my game sees no difference between WASD and a pair of joystick axes.)Yeah, I will sure have to do something like this too. I started a thing like that some years ago, but never had the time to finish it. When I'm finished with learning Nifty, I shall have a look at tonegod ui and your lemur. Is this code for Lemur from January 2013 still the latest code? Or is there an updated version today? http://code.google.com/p/jmonkeyplatform-contributions/source/browse/trunk/Lemur/src/com/simsilica/lemur/?r=756 Okay, and after having looked around I now know that you are the person behind Mythruna.
@pspeed said: I sort of hand drew it just for that app.I saw in the lemur files above that there was a .psd file. Do you make these images with Photoshop? Could you make these other two devices in the same fashion? I could send you a sketch for this.
I sometimes use a very old version of a commercial image editor, but I tend to try it with GIMP+Inkscape now, to be consistent. Sadly, these two programs are quite bad and lack both features and performance.
@pspeed said: But isn't this really the only thing that's needed? I'm not sure I understand why the user would remap their joystick if they are then just going to map inputs to game functions. Just show them the game functions and let them click on it and then wiggle an input to make the association. Then you never have to worry about getting the mappings wrong.There are advantages by the way that I imagine. It is a kind of remapping like your .properties file. And obviously such thing is good, because every game that uses the remapping can automatically recognize the gaming device and provide default input mappings at first start of the game.Even the default remapping support provided was just to make most joysticks work most of the time. Ultimately, most games will need some kind of “game function - input” mapping screen.
So for N games you only have to undergo the remapping once - or even better: have a database on the internet (similar to the CDDB for audio CDs).
Another advantage is, that the player can remap how they like. I for example like the lowest of the four buttons on my gamepad to be the primary fire button. Other players might like the left button instead. And now: Whenever I start a new game (which might be 10 simple party games in a day), the game already has my switched buttons and I can use the default game-to-device mapping and start playing without even seeing such a mapping screen.
This place is where your .properties map comes in handy:
A local remapping of a global remapping - small changes that only this particular user needs, compared to the CDDB-users worldwide that only need the standard mapping for device named “Thrustmaster 3000 Super Joystick”.
Ultimately, you’re right, most games would have a screen where the user can change the default input-settings. It would map “game actions” from “logical game states” to “combinations of input channels” or “alternative combinations of input channels” - this part two can become a plugin.
Only the first part with the three standard joysticks would need to be a standard engine component for the jME SDK.
What if the player has two or more gamepads and sometimes unplugs one to free up USB ports or after the gaming computer has been moved to a different location. All mappings to game actions would be lost after having disconnected the joystick and having connected a different one.
@pspeed said: Anything like this would have to be a plugin, I think. The UI would be heavily game specific and there will be games that never want it and stuff. Also, the game function remapping itself is entirely in how the listeners are registered which either requires game involvement or would require something more amenable to remapping than InputManager is.Two things on that:
One could always argue what kind of functionality is really needed and which part is optional.
If you are right, and it does become a plugin - then this means that the picture I have about “many games supporting my three standard joysticks” is dead, because there will be no games other then my own that would support this basic feature.
Better would be that this becomes a standard part and some day we will have this CDDB-like database and lots of nice jME games using this mechanism.
The other thing is: I did never really write “plugins”, so the concept is new to me. I guess it’s programming against a Service Provider Interface and writing own libraries (.jars). I did not see how modular jME3 is (how “pluggable” so that I can replace important subsystems).
Can you point me to a simple example of how to make a plugin for jME? I would like to see how it is integrated and what kind of pluggable subsystem it replaces.
@pspeed said: Actually, I would love a GUI piece like this in Lemur and it would already support reskinning, would already have access to the more advanced remapping capabilities of InputMapper, etc.. And you'd already have GUI controls that are just scene graph elements. But I'm biased. :)- What's "reskinning"? - Overall this sounds interesting, maybe we could use the adapter pattern to let Lemur use it too - For the UI I will use the standard Nifty GUI, because it has all that I need and is a standard part of the jME bundle - Most problematic will be to work with the jME input management code, but maybe I can study your Lemur and even use this part of your code, so that all your input-related advantages can become available
Monkeeey!
Going to split this up because inline comments is starting to kill me…
@Ogli said: Okay, this is a nice feature. Is this because it is a .properties file? I mean, the build script recognizes this by its file extension?The problem is populating such a file. You always need some expert who then configures an ever growing text file by hand. The devices have so many different names - under Windows they even have a different name before or after the correct driver has been installed, sometimes without the driver two devices have the same name but different buttons. I consider this solution as being a workaround.
I added support for this file to the joystick stuff when I redid some of it recently. It’s not the end-all but a nice stop gap to better cover joysticks that do properly identify themselves and may be more common, yet still require remapping.
For more advanced remapping, it’s really better to use one of the 400 windows tools to do this, I guess. They have much better access to the hardware than we get through JInput. For example, MS’s built in joystick calibrator/tester thing can already make better sense of the inputs than we can from JME.
The problems with including such a screen/utility in JME directly are many:
- nifty is part of the bundle but it’s not part of the core engine… so already it gets relegated to a separate module at best, or part of nifty at worst.
- making it configurable enough to not look out of place in a game is tricky. I know nifty supports styles but it always seemed tricky and 80% of the games tend to just use the default.
- if you use nifty then you force nifty on the games which to me is completely unacceptable. I do not want to use nifty in my games at all but even worse, nifty is a singleton and so now you will be competing even with games that are trying to setup nifty for their own purposes.
Getting this right will be extremely problematic.
- compared to the amount of work and pain required, it’s of relatively little benefit. Especially when there are already tools that can do this at the OS level for exactly the reasons that most joysticks are mapping mavericks. And especially in light of the fact that many games would want a separate function-to-input mapping screen anyway which is more logical to the game.
You are, of course, welcome to implement this for your games. I’m just not sure how it could ever be adapted into the core bundle. Note: I believe every remapping that is available to the .properties files is also available through the API. 99.9% sure that the properties file support is just using that API after all.
So if your game wants to use InputManager and already setup 3 completely separate movement schemes (keyboard, mouse, joystick all require separate listeners, basically) then you can still external to that remap the joystick buttons and stuff.
@Ogli said: Yeah, I will sure have to do something like this too. I started a thing like that some years ago, but never had the time to finish it. When I'm finished with learning Nifty, I shall have a look at tonegod ui and your lemur. Is this code for Lemur from January 2013 still the latest code? Or is there an updated version today? http://code.google.com/p/jmonkeyplatform-contributions/source/browse/trunk/Lemur/src/com/simsilica/lemur/?r=756 Okay, and after having looked around I now know that you are the person behind Mythruna.
Is that good or bad? 
There is newer Lemur code in SVN… I think you need to remove the r=756 from the end. There are even more recent releases than that.
http://jmonkeyplatform-contributions.googlecode.com/svn/trunk/Lemur/release/
Various links are here:
http://hub.jmonkeyengine.org/forum/topic/lemur-repo-link/
Both of the Zay-ES examples use Lemur, also.
@Ogli said: I saw in the lemur files above that there was a .psd file. Do you make these images with Photoshop? Could you make these other two devices in the same fashion? I could send you a sketch for this.
I don’t really have time right now. I didn’t really have time then, either which is why it’s so plain looking.
@Ogli said: The other thing is: I did never really write "plugins", so the concept is new to me. I guess it's programming against a Service Provider Interface and writing own libraries (.jars). I did not see how modular jME3 is (how "pluggable" so that I can replace important subsystems). Can you point me to a simple example of how to make a plugin for jME? I would like to see how it is integrated and what kind of pluggable subsystem it replaces.
There is extensive documentation. I’ve never personally made a proper plugin because the documentation was so extensive that it scared me off.
I don’t have the link handy but could probably find it if forced. I think it’s linked from the main documentation page, though.
@Ogli said: - What's "reskinning"?
Styles, basically. Probably similar to what nifty is doing… definitely similar to what CSS does (since that’s were I took most of my inspiration).
@Ogli said: - Overall this sounds interesting, maybe we could use the adapter pattern to let Lemur use it too
Maybe, though you are talking about something that is primarily UI in the first place… and lemur is somewhat less monolithic since it tries to just be regular JME Nodes.
@Ogli said: - For the UI I will use the standard Nifty GUI, because it has all that I need and is a standard part of the jME bundle
Yeah, but you will somehow then need to directly expose this to the game since you can only have one nifty instance and they may be creating their own. I’ll reiterate that this is tricky to integrate since it would almost certainly have to be a completely separate package. (I can’t see putting it right in the JME nifty package though that’s the only other alternative.)
@Ogli said: - Most problematic will be to work with the jME input management code, but maybe I can study your Lemur and even use this part of your code, so that all your input-related advantages can become available
Yeah. Lemur’s InputMapper first existing as its own project in my personal stash and then I just plopped it wholesale into Lemur. It’s probably not perfect but it’s many steps in the right direction (in my opinion) and is already headed the right way. And being outside of the core engine has a little more latitude in the direction it takes.
I really want to make an InputMapper UI part of the standard Lemur bundle. As part of a GUI, GUI things are not hard to put together. It’s only separately that they become a pain.
@pspeed said: I don't really have time right now. I didn't really have time then, either which is why it's so plain looking. :)
Sometimes a stylized thing can be recognized better for most situations. I like the gradients and the bevels. Makes me wish to learn Photoshop. My old tool offers similar effects with an extremely simple interface, but is not that good.
@pspeed said:Yeah, but you will somehow then need to directly expose this to the game since you can only have one nifty instance and they may be creating their own. I’ll reiterate that this is tricky to integrate since it would almost certainly have to be a completely separate package. (I can’t see putting it right in the JME nifty package though that’s the only other alternative.)
I don’t think that this is a problem - one can simply ask for the Nifty instance at creation time of the JoystickConfigureAppState that I imagine. This AppState would then append a nifty screen to the given Nifty instance (either directly or via “addFromXml” method). So if you don’t want such a configuration tool, you wouldn’t even create the AppState in your application. Okay, just a first idea on this, but it should be possible.
The graphics could also come from standard jME features - you wouldn’t even need Nifty, but BitmapText, custom Shapes and maybe the cool image showing a gamepad that you have drawn. So you could achieve all this with the ugliest GUI in the world, provided you have a MVC-like concept.
What you said about styles and that not fitting to other applications - well, I guess that’s not such a problem. If you create your own style anyways, then you could just apply this to the joystick mapping tool yourself. Those who start create their own styles should have gathered enough knowledge to know how to do this.
And then there are these two possibilities: to provide a more versatile interface OR to give this tool as a second separate application to the user. It’s not that complicated if solved right. Core, Plugin, Library, separate Tool, I will get it done, even though I’m not a programmer, more a game designer, artist, computer scientist. I hate this tedious dull work and would like to protect other people from this annoying step in their game creation, people who are like me and follow a similar philosophy - I think there are many like me out there (most of them will decide to use Unity3D).
But the subliminal topic in this talk has now become a different one. I guess this is a typical open source scene discussion, it’s just about philosophies of work and project management in its core.
My philosophy is simple:
- take the most advanced and most popular, synergy and user base is important
- it should be for free, because everyone should be allowed to make games
- do not reinvent the wheel, even if you think that your wheel will look nicer
- help support those projects that are most advanced and most popular
- always the most mature language and IDE to speed things up
->
That’s why I chose jME & jME SDK and Nifty GUI and thus OpenGL and Java.
Yes, they need some more work, but hey, it’s all open source and complies to my philosophy.
Another good thing about Nifty is the larger audience because it supports many different Java UI systems (or in fact they support Nifty). You might have noticed, that this kind of thinking complies well to my philosophy of maximum synergy and user base.
One thing that you mentioned was the Singleton of niftygui - yes, this also is a problem for one of my ideas (to have multiple devices in 3D and each showing one nifty screen - you know “in-game fake ads” and “computer terminals”), but this is also possible with Nifty as it is now - I just need to be very creative.
Better would be many Nifty instances that are sharing a common resource loader. You’re right, I too see this as a design flaw at the moment, which can be solved later. But hey, if you want that fixed, talk to void (the Nifty maker) and help him with his code and system design.
I think, it is always better when people help push other projects, because:
Better one Nifty with 90% completeness than ten UI systems with 50% completeness each.
Better write the input-to-command-stuff which is now in Lemur as a separate module.
Use and improve the Nifty GUI to get it faster to full productivity.
@pspeed said:Yeah. Lemur’s InputMapper first existing as its own project in my personal stash and then I just plopped it wholesale into Lemur. It’s probably not perfect but it’s many steps in the right direction (in my opinion) and is already headed the right way. And being outside of the core engine has a little more latitude in the direction it takes.
Okay, I understand, you really like your library. I will have a look at it when I’m done with Nifty and want to solve this ugly input-to-action-mapping mess that is still unsolved in standard jME.
@pspeed said:I really want to make an InputMapper UI part of the standard Lemur bundle. As part of a GUI, GUI things are not hard to put together. It’s only separately that they become a pain.
If you strictly follow a MVC pattern, this should not be too hard.
If you follow a MVP pattern, you would use fake input event injection. I assume that you could do all you want with input injection into niftygui or custom controllers for nifty.
I don’t know at the moment, what the exact problem is here. I’ve been coding GUIs under C# and C++ and Java and it was not such a big topic.
Btw, did you know that once jME (version 2) could render Swing GUIs in 3D? This was sooo f***ing awesome! You only see things like these in C++ fps shooters typically, but jME2 had it too.
I plan to make something like this somewhere in the near future, because awesomeness can help push engines - people see this stuff and think ‘how cool is this? I would like to make a game that has such a feature’.
@Ogli said: I don't think that this is a problem - one can simply ask for the Nifty instance at creation time of the The graphics could also come from standard jME features - you wouldn't even need Nifty, but BitmapText, custom Shapes and maybe the cool image showing a gamepad that you have drawn. So you _could_ achieve all this with the ugliest GUI in the world, provided you have a MVC-like concept.
Actually, this is not a bad idea… but when you work out the UI model, mouse events, clicking, etc. all managing some standard JME Spatials then that’s essentially what Lemur core is. It was precisely created to be a GUI built with existing JME stuff. This is why you can attach mouse listener capability right to any existing spatial with one line of code.
I don’t mean to harp on it too much but your scenario is exactly why I created it. “I want to use BitmapText and custom shapes in a GUI using regular JME Nodes and Spatials.”
@Ogli said: What you said about styles and that not fitting to other applications - well, I guess that's not such a problem. If you create your own style anyways, then you could just apply this to the joystick mapping tool yourself. Those who start create their own styles should have gathered enough knowledge to know how to do this.
To me, this entire app state is mostly GUI. Images with stuff to click that either let the user select from a drop down or wiggle the joystick. At it’s simplest, it’s some kind of mapped image(s) with a raw input listener that gets enabled upon click. If you use JME’s Saveable stuff then you don’t even have to write a persistence piece. So then a “reskinning” or “restyling” without inbuilt support for such is just reimplementing most of the feature.
It’s not a replacement for full nifty. It’s trying to occupy a sweet spot for people who’d rather have a GUI directly integrated with the scene graph… and I think so far it is the only GUI library that can easily augment an existing 3D scene (or do 3D GUIs at all, really).
@Ogli said: And then there are these two possibilities: to provide a more versatile interface OR to give this tool as a second separate application to the user. It's not that complicated if solved right. Core, Plugin, Library, separate Tool, I will get it done, even though I'm not a programmer, more a game designer, artist, computer scientist. I hate this tedious dull work and would like to protect other people from this annoying step in their game creation, people who are like me and follow a similar philosophy - I think there are many like me out there (most of them will decide to use Unity3D).
You were against doing this as a plugin before. I think it would be a great plugin. Users who want it can browse the plugins list, tick a box, and now have that available to their applications. They even get automatic updates that can happen more often than the SDK is released.
I think half of the stuff delivered in JME now probably could have or should have been a plugin… terrain, networking (which I rewrote from the ground up, by the way, and still I don’t think it should be included by default)… all could be better served with an independent release cycle. But I understand the alternative thinking and I’m in the minority among the core devs on this topic.
It’s not about creating second class citizens. It’s about fostering a vibrant plugin community where users can automatically think to go to get anything the core engine might not provide “out of the box”.
1 Like
Okay, I think I do better understand now.
To be honest, the serialization in Nifty is quite complex compared to the Saveable mechanism.
What I’m missing with Saveable is a default callback after the scene has been loaded.
This ‘OnDeserializedAll’ is nice when you have references to fix after a scene has been loaded completely.
Maybe I’m just blind to see that there is already such a mechanism for this.
I think it’s all said now. Such a visual mapping screen will be one of my goals (TodoList++).
For now I will use your remapping .properties file during development, maybe for the first test events too.
I have my own ideas for input-to-action mappings too, but I will sure have a look on Lemur / ZayEs.
There is also a problem with different gamepad worlds that I did not mention before.
It might be that the remapping tool currently cannot solve this, I don’t know. So…
Many Xbox gamepads have “analog triggers” - instead the 4 buttons on the lower front, they have 2 buttons and 2 “triggers” (LT and RT):
These two “triggers” together are in fact one “analog axis”: The left trigger gives values [0…1], the right trigger gives values [0…-1].
The two input values get mixed internally - so if left trigger is at +0.5 and right trigger is at -0.3, you get 0.2 from the joystick interface, as intended by design.
These triggers are very popular in racing games, because the left one is for acceleration of the car and the right one is for the brakes.
It is similar to the slider that can be found on any modern flight stick joystick.
I believe a previous poster has already mapped these triggers to a separate axis since they tend to conflict with an existing one.
…but this further illustrates the fact that you will never come up with images and a picture-based mapping screen for every joystick layout. Ultimately (and anyway) you will require some kind of game function to input mapping. In that respect you could support flight sticks, pedals, wheels, stick + pedal combos with a joystick on the side and the mouse between your legs, or whatever.
The idea is to “out of the box” at least provide the most common setups automatically mapped and make it easy to reconfigure.
The approach of having a PS3 layout, xbox layout, wii-mote layout, PS4 layout, thrustmaster layout, xbox-one layout, wii-u layout, etc… is a lot of work for less benefit. You are of course willing to tackle this sisyphean task if you like. 
Yes, I understood what you meant earlier.
I adapted your suggestion and will now be using this approach:
1st step - Aim to build an input-to-action-mapping screen first (enough problems like recognizing which input has changed significantly during interaction with the user)
2nd step - Create a separate tool for people that want a visual editor for the .properties file (my original idea that I’ve now dropped in favor of step 1 first).
3rd step - Define the defaults for the well-known standard controllers: Keyboard / Keyboard+Mouse / PS3-Gamepad / Xbox-Gamepad / Joystick / Wheel / Touchpad
4th step - Somewhere in the future create a kind of administrated CDDB that does exactly this: provide a slightly enhanced .properties file for all my players worldwide
All these steps are not rated topmost priority, but I will keep that in mind when designing my software architecture, so that there will not be too much trouble later on.
Thanks for having me led back to a more time budget friendly and more universal approach of doing things.
This “mouse between your legs” is somewhat scary to read. But I will accept this as a joke.
You forgot to mention the PC-version of kinect (or xtion), voice recognition, head tracker (e.g. Rift) and BCI (EEG like devices).
No, these will definitely not be support by version 1 of my software suite.