Merge different gui elements from Radiance and Birb #56

New issue

Closed

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

kazhnuz commented

2021-01-29 22:24:03 +01:00

Owner

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

HUD elements handled by world objects that draw their variables directly on screen
GUI elements drawn directly by the scene or its managers showing the content of variable and stuff
Some GUI elements handled as object that receive a variable in their draw and draw it
Some GUI elements handled as object that store the variable internally and can change it to draw it
Some GUI elements handled as object that store the variable internally and interpolate it via the timer modules
"Screens" that draw and handle themselves a lot of elements with tweener.
A complete menusystem with internal handling and stuf, that is handled directly by the scene
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)
Some reflexions about game-level gui (like showing a border or something like that) that could even go over transition.
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

kazhnuz commented

2021-01-29 22:44:52 +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.

kazhnuz commented

2022-07-20 15:02:14 +02:00

Author

Owner

Will be part of the "big merge".

kazhnuz referenced this issue

2022-08-03 11:41:20 +02:00

Rebase on Radiance #71

kazhnuz added this to the epervier 0.7.0 milestone

2022-08-08 12:13:40 +02:00

kazhnuz closed this issue

2022-08-12 10:38:22 +02:00