2
\$\begingroup\$

I'm not sure whether this place is the correct for asking this. If it's the wrong place I'm sorry, please tell me if so!

I'm making a small game for fun which would uses an own engine with OpenGL and Vulkan as underlying renderer implementation. The engine itself is targeted for Mono/.Net.

Currently I'm not yet there but I'll come to the point where I'm pushed to implement some kind of GUI (I'm thinking ahead because of good design). I already searched the Internet for render independent GUI systems but I wasn't lucky yet. As result I thought about how I could implement the GUI on my own and came to the conclusion:

  • a independent implementation is needed which takes care only for layout, positioning of GUI objects with responding to inputs.

  • another implementation is needed which only takes the results of calculations for rendering (the renderer)

Before I start inventing the whole wheel new I simply want to know:

Is it a correct approach to doing it this way? Is there a different common approach doing what I described?

\$\endgroup\$
  • \$\begingroup\$ check out IMGui \$\endgroup\$ – ratchet freak Feb 27 '17 at 12:07
  • \$\begingroup\$ See also Good GUI for OpenGL? \$\endgroup\$ – Theraot Feb 27 '17 at 12:28
  • 1
    \$\begingroup\$ Welcome to GDSE! Unfortunately, you can't ask for technology recommendations here, this includes asking if there is a library that exists for X or Y. You might want to rephrase the question to ask for a global approach, though. \$\endgroup\$ – Vaillancourt Feb 27 '17 at 12:36
  • 1
    \$\begingroup\$ @Theraot Sure! As long as we remind the user to read their help pages before posting, just to make sure their question fits well over there :) They have rules, just like we do! \$\endgroup\$ – Vaillancourt Feb 27 '17 at 12:59
  • 1
    \$\begingroup\$ @ArthurP.R. I don't think this question formulated as it is now could be moved verbatim to Software Recommendations, but I think you could post a new over there using their expected format, which seems to be quite formal. I suggest you peek into their top rated questions to see how they ask :) \$\endgroup\$ – Vaillancourt Feb 27 '17 at 13:06
1
\$\begingroup\$

For a video game, consider your... ern... non-widget-GUI. If you use your game window to handle rendering and to handle widgets, you are mixing concerns. Therefore, either you make the widgets a subsystem (which probably means you have to roll your own), or you render your game inside of a widget.

OpenTK.GLControl

OpenTK.GLControl is a WinForms control that allows you to render using OpenGL (via OpenTK). Since it is a WinForms control, it is a widget you can add to a regular WinForms form and use it to render.

That will allow you to add other regular WinForm controls (such as button, text boxes, etc...) ontop of it.

I have been able to get the verion 1.1.1589.5942 to work on WinForms. To have it work properly, you need to:

  1. Use Application.Idle to place your render codde.
  2. Make sure you call control.Context.SwapBuffers();
  3. If you want to have multiple GLControl, you will have to call MakeCurrent. Your GL calls only apply to the current control.

Futhermore, Mono supports WinForm on Linux and other platforms. In theory this can work without additional changes to the code.

Tested no Windows on .NET 4.6, working correctly. Not tested on Linux.

Roll your own

MVC

Do you remember SmallTalk? Yeah, me neither. But I'm aware the MVC was introduced in SmallTalk by Trygve Reenskaug.

The real MVC, not that thing the PHP frameworks claim to be.

It is a simple idea... You have an object-oriented model of reality, and to access it you create a tool that presents a view and handles the interaction with the user:

Model-View-Controller

It is better to understand with this diagram from Wikipedia:

Model-View-Controller

But using MVC isn't enough...


Widgets

Plot twist! MVC is dead. well, sort of.

MVC was dethroned by the concept of GUI components (A.K.A Controls, A.K.A Widgets) a long time ago.

Using widgets it is common to implement a "fat"※ view class, because it does not have to deal with the actual display instead its concern is to handle the widgets (which will worry about rendering the interface).

※: I say "fat" because it has the controller logic. It no longer has to worry about rendering, so this is not really mixing concerns.


To implement GUI widgets you need a hierarchical structure that as the window as root and contains the different GUI widgets.

Each widget is a class, it has an internal view model (state) and behavior, and it is responsible of rendering its appearance. Therefore, the widget class is an encapsulation of fragments of view, controller and view model. It should be noted that the view model in the widget is a surrogate for a fragment of the actual model of the application... if you do not want your "fat" view to handle synchronizing the model (reading and writing attributes to the widget), you would have to implement some kind of binding. And then you have MVVC.

The object in charge of that hierarchy is the "composer", it should compartmentalize the window to give each widget the space where it will render. It should take care of Z order, it could handle widget sizes and preferably it should abstract the coordinates in such way that the widget code does not need to worry about its own position on the parent widget when rendering.

Speaking of handling the coordinates, one of the important features of the GUI widget system is scrolling. The composer should allow you to scroll all the contents of the window by some offset, and the widgets should not have to have special code to handle that. You should also think about positioning and resizing. For instance, Layouts are a useful model, also Dock and Anchors. And you may also want to borrow the ideas of fixed, relative and absolute position from HTML + CSS.

Finally, for a modern widget system, you also need to implement an "event dispatcher", capable of bubbling events.


While the above is enough to make a good GUI widget system, I want to note that some modern systems has opted to support CSS (or a subset of it) to manage the attributes of the widgets. So, if you want to create a general solution, consider to support selectors, to facilitate the creation of tools that apply CSS (or similar) to the system.


Of course, you still would need to implement buttons, sliders, input boxes, etc...

\$\endgroup\$
  • \$\begingroup\$ Using existing stuff would really be the easiest for me and also goes conform with my needs of using which already exists. I'll be on the main chat room of GameDev ;) Many thanks @Theraot ! \$\endgroup\$ – Arthur P. R. Feb 27 '17 at 13:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.