70 lines
4.1 KiB
Plaintext
70 lines
4.1 KiB
Plaintext
GUI
|
|
----------------
|
|
As a first principle, the GUI shall accept and process coordinate inputs as floats normalized between 0 and 1. Coordinates may also be provided as integers, whereupon they shall be normalized by v_width and v_height as defined in Core.
|
|
|
|
GUI Elements shall be scaled and position based upon the same normalized coordinate inputs.
|
|
|
|
These normalized values are tied strictly to the size of the screen as returned by v_width and v_height as defined in Core.
|
|
|
|
Furthermore, the special GUI element position flag indicates the point of origin. These points are:
|
|
* LEFT, indicating x origin being at 0.0 of the screen and moving positively
|
|
* RIGHT, indicating x origin starting at 1.0 of the screen and moving negatively from there
|
|
* TOP, indicating y origin starting at 0.0 and moving positively from there
|
|
* BOTTOM, indicating y origin starting at 1.0 and moving negatively from there
|
|
* HCENTER, indicating an x origin of 0.5 and moving either negatively or positively
|
|
* VCENTER, indicating a y origin of 0.5 and moving either negatively or positively
|
|
|
|
Creation
|
|
--------
|
|
Each GUI element shall be created via the GUI, which then in turn creates a new RenderObject() for the UI RenderScene as defined in Core.
|
|
|
|
Each GUI element shall rely on a generated texture that should contain visuals to indicate the function of the element.
|
|
|
|
Modification
|
|
--------
|
|
GUI elements may have their sizes, positions, and textures modified. Texture modifications, which stem from changes in element content, cause the RenderObject's referenced texture to be updated with the new texture source.
|
|
|
|
Destruction
|
|
--------
|
|
GUI elements should be requested to be destroyed by the original context that requested their creation.
|
|
|
|
On GUI service destruction, as would be triggered by the closing of the program, all GUI elements and their corresponding RenderObjects will be destroyed.
|
|
|
|
Live Game/Editor Design
|
|
--------
|
|
As the campaign master, at the top of the screen(top-right?) you can press on map editor controls to bring up the editing toolbar. This toolbar has:
|
|
* Toggle terrain modifier (mountain icon)
|
|
* Switch between map layers
|
|
* Create map token (icon of a tree with a star?)
|
|
* maybe "add token to <layer>"
|
|
* Create new token (icon of token with a star or something on the top-right)
|
|
* Delete select(ed) tokens (icon if token with an X across it)
|
|
|
|
End-User interface bar:
|
|
* Open Menu (home icon)
|
|
* Open/Close Chat (speech icon)
|
|
* Open Camera controls (camera icon)
|
|
* Rotate screen (two semi-circle arrows following a circular path)
|
|
* Pitch screen (arrow pointing down at an angle)
|
|
* Change render mode (isometric camera and perspective camera icons)
|
|
* Activate Stereoscopic mode? (left and right cameras pointing towards center icon)
|
|
|
|
Default mode is "play" mode, which allows for:
|
|
* Token selection (arrow/pointer finger)
|
|
* Token movement (standard selection/double anchor icon)
|
|
* Token rotation (rotation icon around a token?)
|
|
* Token properties (icon list, like a text file (think tiny char sheet))
|
|
* at top of screen, top-bottom, maybe right-click/double-tap?
|
|
|
|
--------------------------------
|
|
2015-03-08 - 17:20:45
|
|
|
|
With complex GUI elements, such as a Text button, the following method seems reasonable:
|
|
* Complex GUI Elements are made up of other GUI Elements. For example, a Text button would be: GuiButton->GuiText, wherein the parent GuiButton specifies the dimensions and positioning of the element and GuiText specifies the text content, generally centered within the button.
|
|
|
|
This may impose a degree of inefficiency during rendering, at least with the current model. It would be faster to have the top-most parent element contain a fully rendered version of the entire bounding box (FBO/Texture) and the children elements render to and update specific portions of that framebuffer.
|
|
|
|
In this way, there would only ever be one set of vertices and one texture sent to OpenGL, rather than a set and texture for each element.
|
|
|
|
The issue with this approach, however, is that we use a RenderScene with an orthographic camera contained within the Gui class. Each child would have to refer to these objects to ensure their rendering is appropriate.
|