Using TGUI class as base graphical class

Started by Garwin, 30 April 2022, 20:37:53

Garwin

I am in the middle of the first simple game and start thinking about something more complex.

I am still thinking about how to merge TGUI which I would like to use for GUI and game graphics itself. I have some ideas however I do not know if there are good ones so some feedback is welcome.

1. Use TGUI as the base graphical engine and use canvas for drawing the game itself
I can see some advantages and disadvantages:
advantages:
- as the canvas is defined, everything inside can be drawn there and can have a separate handling
disadvantages:
- having canvas as fullscreen and GUI as widget over it seems more difficult, bat probably achievable?

2. Game graphic integrate with TGUI as widgets
advantages:
- can use features of TGUI having same theme (eg. tooltips, rightclick menu etc.)
disadvantages:
- quite complex to make widget for graphic entities and unknown if this is possible and reasonable

texus

#1
I've never created anything complex with my own gui, so I can't give much advice. I would go for whichever method is easiest to implement, which I imagine is probably to render the game and gui separately and determine which of the two has to handle the events you receive.

The gui.handleEvent function returns a boolean whether TGUI handled the event. While there might be complications in more complex cases, it might be a good starting point to try passing the event to TGUI and handle it in your own game when TGUI discards the event.

Quote1. Use TGUI as the base graphical engine and use canvas for drawing the game itself
I wouldn't draw anything to a canvas unless needed, and instead render directly to the window.
TGUI renders all widgets at once, but you can draw whatever you want before or after it. A CanvasSFML class exists to render your content to the canvas and then let TGUI draw the canvas together with the widgets, but it's only use case is to allow custom rendering inbetween widgets (e.g. draw inside a child window). As long as your content is below or above TGUI, there is little reason to use the canvas.
Rendering either your own stuff to a TGUI Canvas, or rendering TGUI to your own kind of canvas will both work to have the game and UI drawn separately in fullscreen, but they only add unnecessary draw instructions when you can draw both directly to the window.

Quote2. Game graphic integrate with TGUI as widgets
There might be a few cases where this might be helpful (e.g. use Picture widget instead of drawing your own sprite so that you can use the onClick callback instead of writing your own code to check if the sprite was clicked), but in many more complex cases I think this will complicate things. If an object is not a UI widget (or clearly acts like one) then it probably should be handled in your own code where you have full control over it. Trying to turn everything into a widget will add boilerplate code and might make it more difficult to handle all events.

Of course it all heavily depends on the type of game. If it almost exclusively relies on mouse events then you might be more easily wrap graphic objects as widgets, but if you need to handle keyboard events then you might be much better off implementing things in your own code.

Garwin

Thanks for the reply and ideas. I will think about it as, there are really several options.