Ok, guys, now’s your chance.
I just finished the keyboard input. Now I am working on the mouse input. (For the new jME stuff). I’ll be hitting controllers after that.
Flood me with requests/suggestions/etc.
So far, my requirements are: Relative mouse movements handled, Absolute mouse movements handled. Easy to “switch” controllers on the fly.
Now, let me have it, what would you like to see?
Nice to have a zoom at some point - but not sure it belongs here, or is much of a priority in the short/medium term. Would this go with picking? So you picked a point & then zoomed?
Just a thought.
Zoom is a posibility, which I think will be contained within the Camera object itself rather than a pure controller. I have zoom working on a couple tests, so I can go ahead and implement it.
Just a few things:
-
Being able to load various icons for the mouse pointer would be good.
Be able to speed up moving around the terrain say by pressing a key while keeping mouse down etc.
Selecting objects by clicking on them (picking)
[/list:u]
And if you still have time
-
Rubberband boxes, i.e. select an area of the terrain using rubberband and then when we let the mouse go the area occupys the main window and in the focus.
[/list:u]
tomcat
;)
Being able to load various icons for the mouse pointer would be good.
Good idea. Will put this in the controller that shows an arrow (whatever that will be called).
Be able to speed up moving around the terrain say by pressing a key while keeping mouse down etc.
Ok, easier to set speeds. Probably in basie fps controller. (Or is this more a physics thing?)
Selecting objects by clicking on them (picking)
On my list, right before collision detection. (It's nothing more than a simple line/sphere collision test).
Rubberband boxes, i.e. select an area of the terrain using rubberband and then when we let the mouse go the area occupys the main window and in the focus.
Interesting, I'll have to think about that one.
Be able to speed up moving around the terrain say by pressing a key while keeping mouse down etc.
Ok, easier to set speeds. Probably in basie fps controller. (Or is this more a physics thing?)
I did not think about the physics, but come to think of it might be very useful.
I guess if I know how to do it with the basic fps, I would be happy with that. I like to be able to turn the speed on and off when I like to.
tomcat
I’ll just make sure that I make the controller values very easy to modify so that you can easily do such things.
Being able to load various icons for the mouse pointer would be good.
This should be fairly easy for the Spag GUI & also the ability to switch mouse icons on the fly should lead easily on from this.
Ok, now that the basic controllers (mouse and keyboard) are done, I was thinking how to handle high level controllers, tracking, fps, etc. Here’s an idea. There is a base class InputController. It simply maintains a hashtable of InputActions whose keys are commands. For example, I might create a ForwardAction and tie the “forward” key to it. Then whenever the KeybindingManager detected “forward” that ForwardAction would be fired. I would create plenty of generic actions to work off of, forward, backward, jump, etc. But it would be easy to create your own. Also I would create a few basic InputActions that tied all the basic Actions together.
This might make it as easy as saying:
MyInputAction input = new MyInputAction();
input.addAction("shoot", MyShootAction());
input.addAction("nuke", MyNukeAction());
Actions would be a basic interface that has a fire method. So to make your MyShootAction:
public class MyShootAction implements InputAction {
public void fire(InputActionEvent evt) {
//perform some action here.
}
}
The InputActionEvent class would have to contain relevent information to perform the action (not sure what that is yet).
Anyways, that's the basic idea. Just wanted to bounce it off you guys. Pros, cons?[/code]
Ok, I think I understand it. Basically this lets us to create our own actions say jumping up, throwing something, shooting etc and allows that to be bounded to a key say spacebar etc. So whenever I press this key I get this action.
OK, If this is right, then this is cool and very useful. It would also be good to add or remove actions from any key for example in one scene I use the key to jump, in another scene I change it to smoething else like crawling on the ground.
tomcat.
Yes, basically you create an action, you give it a key value, this key value matches a key value from the keybinding manager. The action is performed. Add all these actions together and you have a full controller. That handles key presses…
Mouse is a little different, you’ll add MouseActions to the InputController. These actions do not wait to be called from a keypress, they are called each update cycle and check the mouse values.
Ok, the initial check-in of the Input System is in CVS. Pretty massive check-in and I have yet to comment it. I’d recommend taking a look at the TestKeyActions test to get an idea of how you would go about making your own controller. Not to worry though, I’ll be adding some typical controllers that will build some of these for you.
Only issue I’m running into is:
Look up, down, left and right allow rolling. That is, if you look up, look right, and look down at your original point, you will have rotated. I need to fix this.
Some actions are frame rate dependant which isn’t good.
I’ll fix those ASAP. Add a couple controllers, document and call it done for now.
Then get back to the graphics stuff.
Look up, down, left and right allow rolling. That is, if you look up, look right, and look down at your original point, you will have rotated. I need to fix this.
This is now handled. You can set a lock axis, this will keep the camera from rolling, if you do not set this, the camera is allowed to roll.
Now, just handle framerate independance and documentation...
ok, all the actions are framerate independant there is a FirstPersonController class that will work as a FPS game controller or similar.
If you guys have a chance, check out the input package and the tests, let me know if anything is wrong.