Ember UI Discussion

From WorldForgeWiki
Jump to: navigation, search

Ember User Interface Discussion

This page is intended to be a place where ideas for the user interface for ember are thrashed out. Each point is written as someone's opinion on how an aspect of the user interface should be. Clearly written follow ups should be added as paragraphs to the end. Do not post random chat - use irc or the discussion for this page for that. Eventually the information here can be condensed down into a more formal specification for implementation.

Points

Mouse look feel

Currently the mouse look feels very juddery, which is quite distracting and unpleasant when using the client. It does not feel as though this is because of low frame rate, though it might be. If this is an issue with the resolution of mouse movements, it will probably be necessary to slightly decouple the camera from the mouse, so that it moves more slowly. I do not think however that the coupling should be too loose. Having almost direct control of the camera with the mouse, without noticeable lag is key to being in full control, and being able to respond quickly. --Alriddoch 15:54, 17 October 2007 (CEST)


On Windows I've sometimes experienced that when you press and hold a button the input parsing stops, which makes the client non-responsive. The solution is to sleep a little each frame so that the OS gets time to do its stuff. The relevant code can be found at src/components/ogre/input/Input.cpp:317. Perhaps this is needed on *NIX platforms too? Other than that it's also possible to change the camera speed by editing ember.config at

[input]
#how many degrees per second the camera should pitch and yaw
cameradegreespersecond = 180

Though from your description it sound more like it's a problem with the rendering lagging behind the input from the mouse.--Erik 00:09, 19 October 2007 (CEST)

Chat dialogue focus

Currently the right button is used to switch out of the mode where WASD are used to control movement into a mode where they can be used for chat, but it does not automatically focus the chat dialogue. When the keyboard is in text mode rather than movement mode, the chat dialogue should get focus by default. It would probably also be a good idea to allow switching to this mode by pressing either the return or / key, as many games allow this. It makes it possible to switch very fast to chat while moving around in an intense game play scenario. Pressing return while in the chat dialog when no text has been entered should probably cause it to loose focus, and return the keyboard to movement mode. This means a player who is controlling their character on the keyboard only can very quickly switch to chat, say something, then switch back. Whenever the keyboard is in movement mode, the chat dialog should visibly loose focus and return it it's semi-transparent state. --Alriddoch 15:55, 17 October 2007 (CEST)

  • There's already support for this, to some extent. If you press "tab" when in movement mode it will switch to gui mode. Pressing tab again will focus on the console. This is all configurable in ember.conf. I say "to some extent" because this is how it worked until ten minutes ago. I've now checked in code that make it work just as you describe: issuing the command /console_focus (which is bound to tab, but can be bound to enter or / through changing ember.conf) will both switch to input mode and focus on the console. Pressing enter in the console without having something entered will switch to movement mode and deactive the console (making it semi-transparent) :) I wonder about making it so that the chat window always gets the focus even when the user switches to input mode by pressing right mouse button though... --Erik 22:59, 16 October 2007 (CEST)

Hardware cursor

Since the cursor is rendered by CEGUI I've disabled the hardware cursor. This has the advantage that we have much more control of the cursor (it's just a texture like any other) but the disadvantage is that when the frame rate drops the mouse feels sluggish. If the hardware cursor was used instead this wouldn't be too much a problem, but I haven't really looked into how hard or easy it would be to alter the cursor in good way. There might also be other issues that needs examination.--Erik 23:09, 16 October 2007 (CEST)