Immediate Mode GUI

[ACBob]

ImGui's cool, but rather bland and un-customisable.\ Nuklear's cool, but wouldn't fit into the InputManager system very well from a glance.\ (Also something something bloat)

But boy can we copy some concepts.

The game needs an interface. Simple enough to do, just slap some quads together and present to the screen.\ Then there's the case of input, which can be handled with the InputManager, as ALL client-side input should be.\ There's a VERY simple setup here, but it's very simple. It has some buttons, labels, and shitty text input (#16) - but isn't very useable.

API Design

Every element should be a function of the CGui class, and it will present the control to the screen, returning anything if it can.\ I.E For the case of the button, It takes the position & size, and then draws a button, returning if it has been clicked.

bool CGui::Button(CVector vPosition, CVector vSize); // TRUE if clicked

In the case of something like a Text Input, where the state should be preserved through frames, there would be a buffer variable that would take the ID and store it. In the case of a Text Input, there is the m_textBuffers vector which stores the char arrays.

Calling Update at the end should require no arguments, and will actually push the vertex data towards OpenGL, along with updating stuff like the hovered element or the selected element.

Elements

The necessary elements would be as such:

• [ ] Window
  • [ ] Tabs
  • [ ] Dialog Box
• [ ] Generic Menu (Tool-tip?)
• [x] Image
  • [ ] Model renderer?
• [x] Labels
• [x] Buttons
  • [x] Text Button
  • [x] Image Button (Technically done, just weird)
• [x] Check Box/Toggle Box
• [ ] Progress Bar
• [x] #22
• [x] Scrollbar

Other Points

• [ ] Z-Coordinate for depth testing
• [ ] 3D Modes
  • [ ] In-World 3D (i.e applied to a surface)
  • [ ] Cool:tm: perspective "depthed" 3D, where every element is a cube

State Machine

The API and Design are out of the way, but now how do I handle it for the game? A state machine.\ Two, to be exact. One would handle the base game state, Playing, Loading, Menu-ing, etc. But they'd have their own classes to use, like a CGuiMainMenu for example.\ Each of these classes would have their own states, in something akin to CGuiPlaying would have 'playing', 'inventory', 'pause' and 'chatting'. An options menu would have 'overview', 'controls', etc. etc.

[ACBob]

Progress is being made.

However, the actual system should be rewritten entirely - as to work better with magical auto-spacing elements, z-indexing or windows.

Most stuff works and is fine.

[ACBob]

The GUI desperately needs rewritten to use the Z-Coordinate as "depth", to allow putting GUI elements on-top of each other.

The functions should remain similar.

• Button
• LabelButton
• AtlasButton
• LabelAtlasButton
• Image
• ImageAtlas
• Image9Rect
• Slider
• HorzSlider

[ACBob]

has been rewritten, Z is not depth yet, and doesn't need it presently.\ Not an issue for Alpha 1.