The other AppState thread was getting a little long, so I thought it might be time for a new topic 
I've got the core of the input system pretty much worked out and am concentrating on elements for each type of input. I did have a thought though. The one thing I am not seeing is an input mapping system that would allow the player to configure their mouse/kb/stick inputs to their personal preferences.
Most mapping systems I have seen in commercial games allow setting 2 sources for a given "command" (a command being a button event or an axis event). An alternative would be to have 3 sources, one for mouse, one for kb, one for stick. In either case if only one source is specified, then the other source(s) would be stored in the map as a null. It should also be reasonably simple to serialize the map so it can be saved and reloaded by the game.
Elements wanting to handle a given command would ask the Mapper to create an InputGroup for the command configured to call the correct methods in the Element using Delegates. The mapping system would keep track of all the input groups it had created (since each is custom to the Element that requested it), and when a change to the mapping is made, would update the InputGroups to match the new mapping.
Right now the Input system has custom router elements for mouse(button,move,wheel), kb(button), and stick(button,axis). I think it would be helpful if there were a generalization that boils all those event types down to being either Button or Axis events, but that would require something to convert a key pair into an axis, and a scale/accumulate system that could take mouse, keyboard, or stick input and produce a consistent axis output.
Has anyone put any thought into something similar ??
oO It would really be more helpful if you tried to go along whats there instead of proposing system changes all the time. The inputsystem just has been overhauled and will surely not be changed that quickly.
How about you pick one of the topics that are of more interest to jme3 users than your idea of an inputsystem, theres still lots to do like water, networking, camera controllers etc. I suggest getting more familiar with jme3 and what the community expects from it and going on from there 
Cheers,
Normen
You asked for the AppState system that evolved with our discussions into what I'm calling the Element system. The input system is just a logical extension of that concept, one that is necessary if the input system is going to participate in the threading system you asked for. The input mapping system I just described is a layer that could be grafted on to the input system fairly easily to make game development easier.
In any case, this is all being created as a layer on top of the current system… nothing in the current core need be replaced. Current apps in development can continue as they are. I'm not attempting to force anyone to use the Element system. I'm asking for input as to what might be useful features that do not exist in the current core.
I'm about 20 classes into this setup and making some good progress, and you want me to stop and work on something else ?? Are you afraid you have unleashed a monster <Evil Grin> in the middle of the jME code ?? I've got a little bit to go on the input system and I have to create the video system, then I'll have everything I need to punch out a demo app so everyone that is interested can see how it all fits together. THEN we might have something to talk about as to whether or not we continue on this track.
Ohh… on other notes… I thought you represented the community when you asked for the AppState code, and then proposed extensions that evolved into the Element system. Also, I'm a member of the community and what the element system represents fits in very nicely with what I would like to see out of jME I don't need all the things I'm creating here for my current app, so from one point of view doing this for you is a waste of my time, but I will need them for apps I would like to create in the future. I can always stop talking about it if you want, and just keep it for my own apps.
Right now the Input system has custom router elements for mouse(button,move,wheel), kb(button), and stick(button,axis). I think it would be helpful if there were a generalization that boils all those event types down to being either Button or Axis events, but that would require something to convert a key pair into an axis, and a scale/accumulate system that could take mouse, keyboard, or stick input and produce a consistent axis output.
It's already there, look at the InputManager class. Ignore the methods that are deprecated.
We won't implement delegates in jME3 because people who use our engine are used to the Java way of doing things and thats using listeners.
Delegates are possible to implement in scripting languages running in the JVM, for example in Scala.
I'm about 20 classes into this setup and making some good progress, and you want me to stop and work on something else ?? Are you afraid you have unleashed a monster <Evil Grin> in the middle of the jME code ?? I've got a little bit to go on the input system and I have to create the video system, then I'll have everything I need to punch out a demo app so everyone that is interested can see how it all fits together. THEN we might have something to talk about as to whether or not we continue on this track.
Me and normen were talking about your ideas and we given them consideration. We might not agree with what you say, but we do think about your proposals and how they could help make jME better.
I hope you wouldn't feel bad if this doesn't go into core, we are trying to keep jME3 simple and easy to use for the most part, so we stray from anything that might complicate things too much.
You could always post this system as an external library that works with jME.
Ascendion said:Don't think your work and enthusiasm isn't appreciated; it's not often we've seen a newcomer put in a monumental effort such as this right off the bat. I think the point is, with regards to the very recent overhaul of the input system, all this add-on work just comes a bit sudden. We don't have a great many use case examples yet, which means it hasn't had the time to 'organically' evolve much. Your additions could very well shed more light on the subject, but it could also complicate things prematurely.
I'm about 20 classes into this setup and making some good progress, and you want me to stop and work on something else ?? Are you afraid you have unleashed a monster <Evil Grin> in the middle of the jME code ??
In any case, this is all being created as a layer on top of the current system.. nothing in the current core need be replaced. Current apps in development can continue as they are.So long as the Element system is developed as an extension to jME and not necessarily an addition to the core, and so long as it doesn't convolute the simpler concepts of AppState, I say go for it. Like Momoko_Fan said (as I was writing this reply), we stray away from over-complicating core aspects of jME3, but there's nothing in the way of this being an external library we can gladly point to.
I've got a little bit to go on the input system and I have to create the video system, then I'll have everything I need to punch out a demo app so everyone that is interested can see how it all fits together. THEN we might have something to talk about as to whether or not we continue on this track.A demo application would be great.
I'm doing my best to keep it as an extension – the Input element wraps the existing InputManager and exposes a getter for it so current style input code can be used. What I'm doing is just a thin layer on top of that.
I just couldn't see how to do other things, like the input mapping system, without some way to group event routers and without delegates that I could move around from one event router instance to another when the mapping changes. (blame my c# background)
I hope the demo app will demonstrate simplicity when I get this all sorted out.
Speaking of simplicity… since the Element System is prerequisite based, I don't really have a way to make viewport rendering participate in the threading system because a viewport doesn't know what Elements need to process before the render (at least it wont unless I create Node and GeometryElements). I pretty much have to wait all elements to process before I can kick off any render, though once I start kicking off renders, I can do multiple viewports if rendering is thread safe.
Save me a little time digging into the rendering system ?? Is rendering thread safe and do we want a wrapper around nodes and or geometry to enable full threading ??