Creating a GUI in OpenGL, is it possible? [closed]

Question

I'm trying to create a custom GUI in OpenGL from scratch in C++, but I was wondering is possible or not?

I'm getting started on some code right now, but I'm gonna stop until I get an answer.

Answer 1

YES.

If you play a video game, in general, every UIs should be implemented by APIs like OpenGL, DXD, Metal or Vulkan. Since a rendering surface has higher frame rate than OS UI APIs, using them together slows down the game.

Starting with making a view class as a base class, implement actual UI classes like button, table and so on inherited from the base class.

Making UIs using a GFX API is similar to making a game in terms of using same graphics techniques such as Texture Compression, Mipmap, MSAA and some special effects and so on. However, handling a font is a sort of huge part, for this reason, many game developers use a game engine/UI libraries.

Answer 2

https://www.twitch.tv/heroseh

Works on a Pure C + OpenGL User Interface Library daily at about 9AM(EST).

Here is their github repo for the project:

https://github.com/heroseh/vui

I myself am in the middle of stubbing in a half-assed user interface that is just a list of clickable buttons. ( www.twitch.com/kanjicoder )

The basic idea I ran with is that both the GPU and CPU need to know about your data. So I store all the required variables for my UI in a texture and then sync that texture with the GPU every time it changes.

On the CPU side its a uint8 array of bytes. On the GPU side it's unsigned 32 bit texture.

I have getters and setters both on the GPU (GLSL code) and CPU (C99) code that manage the packing and unpacking of variables in and out of the pixels of the texture.

It's a bit crazy. But I wanted the "lowest-common-denominator" method of creating a UI so I can easily port this to any graphics library of my choice in the future. For example... Eventually I might want to switch from OpenGL to Vulkan. So if I keep most of my logic as just manipulations of a big 512x512 array of pixels, I shoudn't have too much refactoring work ahead of me.