OpenTechEngine / OpenTechBFG

Engine based on (RB) Doom 3 BFG aiming to allow the creation of standalone games
Other
84 stars 11 forks source link

the UI still relies on ceGUI or SWF, we could have a fallback using the internal GUI #146

Open BielBdeLuna opened 6 years ago

BielBdeLuna commented 6 years ago

revising it I see there is a menu handler, and then the actual menu screen, and the menu widget, and a menu shell.

one way to approach this could be to start from the simplest menu and try to recreate what happens with SWF files but with GUI files, i think the best bet would be the "lading map" screen, that's the first effort I'll concentrate myself to.

kortemik commented 6 years ago

I can guide you around with cegui if you like as I created the abstraction layer for different menu systems.

It should be quite easy to use any opengl system for the menus though.

https://github.com/OpenTechEngine/OpenTechBFG/tree/master/neo/d3xp/menus

Here the files https://github.com/OpenTechEngine/OpenTechBFG/blob/master/neo/d3xp/menus/MenuHandler.h and https://github.com/OpenTechEngine/OpenTechBFG/blob/master/neo/d3xp/menus/MenuScreen.h select that if shipped swf-implementation is used OR if the abstraction classes are included.

The _CEGUI in the .h files is bit misleading as the headers actually declare the virtual classes that are to be implemented by the actual menu system, which can be cegui or something else: https://github.com/OpenTechEngine/OpenTechBFG/blob/master/neo/cegui/MenuHandler_CEGUI.h https://github.com/OpenTechEngine/OpenTechBFG/blob/master/neo/cegui/MenuScreen_CEGUI.h

Implement those in cegui or in something else and you should have a working menu system

-Mikko

On Wed, Oct 4, 2017 at 6:31 PM, Biel Bestué de Luna < notifications@github.com> wrote:

revising it I see there is a menu handler, and then the actual menu screen, and the menu widget, and a menu shell.

one way to approach this could be to start from the simplest menu and try to recreate what happens with SWF files but with GUI files, i think the best bet would be the "lading map" screen, that's the first effort I'll concentrate myself to.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenTechEngine/OpenTechBFG/issues/146#issuecomment-334195285, or mute the thread https://github.com/notifications/unsubscribe-auth/AA19OrnCvlLRfrMhWTIsndrfGB5mV1ltks5so6TqgaJpZM4Pr98A .

BielBdeLuna commented 6 years ago

yeah, I know that, for what I see I need t create a Menu handler for the GUI, i guess the shell should stay the same, because I see it's just the environment in which the menus work.

the menu widgets shouldn't be the first priority, I first want to have something in screen, and then start with the widgets.

and the screen? I don't know what those do

BielBdeLuna commented 6 years ago

now I understand the inner workings of this system somewhat better, shells: are the different fullscreen ui possible in the game. screens: are the different screens a shell can have, the main menu shell has different screens handlers: handle the interaction between shells, and the transitions amongs screens and among shells widgets: all the different generalized interactions that populate the screens

BielBdeLuna commented 6 years ago

wouldn't it be far easier to start again from the menu folder In Robert's repo? and reintegrate it all with GUI and ceGUI?

BielBdeLuna commented 6 years ago

nope, none of the approaches I've taken have shown an easy path, right now the best bet I've come up with is to recreate whatever is asked the SWF to do with the GUI user interface, but this probably will make require extensive changes to the GUI system too