Merge different gui elements from Radiance and Birb #56

Closed
opened 2021-01-29 22:24:03 +01:00 by kazhnuz · 2 comments
Owner

For the moment, the whole GUI story on Birb is all over the place. Basically, we have :

  1. HUD elements handled by world objects that draw their variables directly on screen
  2. GUI elements drawn directly by the scene or its managers showing the content of variable and stuff
  3. Some GUI elements handled as object that receive a variable in their draw and draw it
  4. Some GUI elements handled as object that store the variable internally and can change it to draw it
  5. Some GUI elements handled as object that store the variable internally and interpolate it via the timer modules
  6. "Screens" that draw and handle themselves a lot of elements with tweener.
  7. A complete menusystem with internal handling and stuf, that is handled directly by the scene
  8. Reusable menus that would serve as some kind of interactive screen (like a game over screen that go over the gameplay, or a pause menu)
  9. Some reflexions about game-level gui (like showing a border or something like that) that could even go over transition.
  10. The transition system could be seen as part of the GUI ?

All that could be simplified a lot with a global GUI system that would handle all these case, using a generic "gui object" that would be derivated into menus and stuff.

For the moment, the whole GUI story on Birb is all over the place. Basically, we have : 1. HUD elements handled by world objects that draw their variables directly on screen 2. GUI elements drawn directly by the scene or its managers showing the content of variable and stuff 3. Some GUI elements handled as object that receive a variable in their draw and draw it 4. Some GUI elements handled as object that store the variable internally and can change it to draw it 5. Some GUI elements handled as object that store the variable internally and interpolate it via the timer modules 6. "Screens" that draw and handle themselves a lot of elements with tweener. 7. A complete menusystem with internal handling and stuf, that is handled directly by the scene 8. Reusable menus that would serve as some kind of interactive screen (like a game over screen that go over the gameplay, or a pause menu) 9. Some reflexions about game-level gui (like showing a border or something like that) that could even go over transition. 10. The transition system could be seen as part of the GUI ? All that could be simplified *a lot* with a global GUI system that would handle all these case, using a generic "gui object" that would be derivated into menus and stuff.
kazhnuz added the
1. Feature
label 2021-01-29 22:24:27 +01:00
Author
Owner

The idea would be to create a gui system inspired a bit by the current menu system, that would be extended to have layer support. At the top level, the core.gui object would be a set of layers.

Each layer would have a unique name, would be global or local (meaning "be destroyed when the scene change", handling 9.) would have a depth variable and a visible boolean. The depth could be relative to the transition, with 0 being just under the transition (it would be the default value, handling 10.), and lower (bigger depth) layer would be covered by the higher.

In layers would be a list of guiElements. This list would be ordered by creationId, but would use global naming (in order to ensure compability with current gui system). These elements would be drawn.

The cases 1. and 2. would NOT be handled, HUD support in world object would be dropped, replaced by guiElements that are linked to a variable of an objects (which could either directly change the shown variable on change, or would interpolate the change according to some criteria).

Menus would be guiElements, and the current menumanager would add them to the gui. This would handle everything but the "screen" system concept.

The idea would be to create a gui system inspired a bit by the current menu system, that would be extended to have layer support. At the top level, the core.gui object would be a set of layers. Each layer would have a unique name, would be global or local (meaning "be destroyed when the scene change", handling 9.) would have a depth variable and a visible boolean. The depth could be relative to the transition, with 0 being just under the transition (it would be the default value, handling 10.), and lower (bigger depth) layer would be covered by the higher. In layers would be a list of guiElements. This list would be ordered by creationId, but would use global naming (in order to ensure compability with current gui system). These elements would be drawn. The cases 1. and 2. would NOT be handled, HUD support in world object would be dropped, replaced by guiElements that are linked to a variable of an objects (which could either directly change the shown variable on change, or would interpolate the change according to some criteria). Menus would be guiElements, and the current menumanager would add them to the gui. This would handle everything but the "screen" system concept.
Author
Owner

Will be part of the "big merge".

Will be part of the "big merge".
kazhnuz added this to the epervier 0.7.0 milestone 2022-08-08 12:13:40 +02:00
Sign in to join this conversation.
No description provided.