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?

  • \$\begingroup\$ check out IMGui \$\endgroup\$ Feb 27, 2017 at 12:07
  • \$\begingroup\$ See also Good GUI for OpenGL? \$\endgroup\$
    – Theraot
    Feb 27, 2017 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, 2017 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, 2017 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, 2017 at 13:06

1 Answer 1


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 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


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:


It is better to understand with this diagram from Wikipedia:


But using MVC isn't enough...


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...

  • \$\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\$ Feb 27, 2017 at 13:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .