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

[BielBdeLuna]

[BielBdeLuna]

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]

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 < ***@***.***> 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 <#146 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA19OrnCvlLRfrMhWTIsndrfGB5mV1ltks5so6TqgaJpZM4Pr98A> .

[BielBdeLuna]

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]

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]

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]

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