Manually set mouse position?

83 views
Skip to first unread message

Niklas Rosenqvist

unread,
Nov 18, 2013, 9:39:01 AM11/18/13
to urh...@googlegroups.com
I have an ingame pause menu which I open with ESC. When I use the mouse to press the "continue" button the camera rotates slightly upwards since the continue button is above the center of the window and when the game resumes the engine interprets it is as a movement with the mouse forward. Is there any way to tell the engine that it should "move the input" to the center so that there is no visible camera rotation after I've returned to the game? From the looks of the scripting API pages it seems that all related input properties are readonly.

Lasse Öörni

unread,
Nov 18, 2013, 10:11:28 AM11/18/13
to urh...@googlegroups.com
Is the operating system mouse cursor visible or hidden (input.mouseVisible)? Or are you toggling this property on/off when opening/closing the pause menu?

There is no API to set the physical operating system mouse cursor position. When input.mouseVisible is false, the physical mouse cursor is constantly being recentered in the window center anyway to allow endless relative movement.

One way is to disregard mouse move input for one frame when closing the menu. If you're currently toggling input.mouseVisible I would recommend to not do that, rather let the OS cursor stay hidden the whole time and define a cursor UI element in the UI subsystem. That you *can* reposition freely.

You can also take a look at how some examples like 17_SceneReplication combine camera movement and UI interaction. In that one, the right mousebutton hides the cursor and enables camera movement. The bottom line is, the engine just gives you mouse movement for each frame and it's up to you to interpret it as camera movement, or choose to disregard it.

Niklas Rosenqvist

unread,
Nov 19, 2013, 4:57:31 AM11/19/13
to urh...@googlegroups.com
Alright thanks, I was using the operating mouse cursor. I'll see what I can do instead. Just a quick question regarding the UI components. Is there anyway of specifying relative movement and selection as one would when navigating the menu with a gamepad. I noticed in one of the samples an attribute called "index" on the element in the UI/*.xml file, is that how it's controlled?

Lasse Öörni

unread,
Nov 19, 2013, 5:37:17 AM11/19/13
to urh...@googlegroups.com
How you'd do joystick/gamepad control would be UI-element specific, there is no unified API for that. For example for a ListView you could change the selected item index with the "selection" property.

Niklas Rosenqvist

unread,
Nov 19, 2013, 6:01:08 AM11/19/13
to urh...@googlegroups.com
ok, I guess I'll have to do some experimenting with that. Thanks!

Chris Friesen

unread,
Nov 19, 2013, 11:32:22 AM11/19/13
to urh...@googlegroups.com
I have been thinking about relative ui movement.  unfortunately i am so stinkin slow.  here is a gist from rygorous https://gist.github.com/rygorous/6981057 which aims to do exactly that.  it would definitely be a nice touch.

Niklas Rosenqvist

unread,
Nov 20, 2013, 6:08:51 AM11/20/13
to urh...@googlegroups.com
It would be really nice to have something like that :)

Lasse Öörni

unread,
Nov 20, 2013, 6:18:55 AM11/20/13
to urh...@googlegroups.com
Now that I think of it, for the kind of menus you often see in games, like the graphics & controls settings, the existing high-level UI elements (Menu, ListView etc.) really aren't a good match.

I'd probably just compose them of the lower-level elements like buttons, sliders and texts.

That would also mean making up the control scheme completely with own, manual code.

I would agree though that it would be nice to have navigability of the inbuilt menus with arrowkeys or joystick controls.

Chris Friesen

unread,
Nov 20, 2013, 5:49:02 PM11/20/13
to urh...@googlegroups.com
i agree that there are really 2 different types of uis.

if we could get a global rule for navigation set we could probably axe a ton of code :D  seeing how hard it would be to make list views work for complex list items, or worse more hacked custom interfaces (imagine nesting horizontal/vertical layouts to simulate grids and such) relative navigation may be the only sensible solution.  starting with focusable items as a subset of recieved controls.  the currently focused ui control could stop the event from propagating to the next in line.  so the logic being that each control has responsibility for holding its focus.  that way text inputs can stop left and right when they are in the bounds of a word but can go up and down whenever.

being said i appreciate the that has been done already and am thankful.  there is quite a bit of ux features in there.  
Reply all
Reply to author
Forward
0 new messages