Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Yes, Openframework is such an usefull toolkit, but it is mostly used by interactive graphic artists and not much in game developement. Maybe it is because there are no build in collision control features and no world editors, like in Unity, etc.
Maybe some developers could use Openframeworks in there next project, and write an article, about the advantages of the library and what features need to be improved.
Again, some self-advertisement:
My GUI library for OpenGL: morda
Github page: https://github.com/igagis/morda
The design of the library is inspired by Android UI framework, so I decided to implement something similar in C++ and fix some nasty problems with Andriod UI fw, like automatic picture dimension derivation from its aspect ratio.
Features:
- C++11
- library with its dependencies is packaged with various packaging systems: Nuget for VisualStudio 2015, deb for Debian and Ubuntu, homebrew for Mac OS X.
- Truetype fonts support
- SVG images support
- Basic controls: Layouts, Labels, Images, Buttons, Combo box, Sliders, Scroll lists, Text input, etc.
- declarative UI description
- styling
- resource manager
- non-intrusive, there is example of using with SDL2.
- Works with at least Open GL 2.0 or Open GL ES 2.0.
- something else I have missed to mention...
Would be nice if someone tries to use it and give feedback, so I can improve it.
Would be nice if someone tries to use it and give feedback, so I can improve it.
Separate the GUI library from the GUI rendering logic, and allow users of the library to replace the rendering logic -- look at other libraries such as Dear imgui, and librocket for examples.
Even if my engine is using OpenGL on a certain platform, I don't necessarily want middleware emitting GL function calls itself -- often you want the middleware to emit abstract commands that your engine can convert to GL calls itself (this can actually be more efficient in some cases!).
Also, GL definitely is not supported on all major gaming platforms.
MacOS supports GL2, but you can't mix GL2 and GL3/GL4 code together -- GL2 works in a legacy support mode. So GL2 middleware in a GL4 game is a bad idea.
Windows supports all GL versions, but there's three different implementations that you need to test against, so the vast majority of games on Windows use D3D as it has a single, stable implementation.
No game console supports GL -- so sticking with "just use GL everywhere" is saying that you don't care about people making console games (which is actually a lot of indies these days).
you can't mix GL2 and GL3/GL4 code together -- GL2 works in a legacy support mode.
Do you mean stuff from GL1 which is present in GL2 does not work in GL3? Like glBegin()/glEnd, glPushMatrix() etc. ? Is it just that or something else?
Actually, I also thought that it would be good to use some kind of multirender library, but could not find elegant one so far, nor could implement one by myslef, mostly because of different shading languages (GLSL vs D3D). So I decided to use just OpenGL as it is present on largest subset of different systems out of all the graphics APIs. I know that consoles are out of support but I concentrate on the rest for now until I find a good solution to this problem...
Having your UI lib issuing GL commands mean the user has to track all the state your library modifies, or needs before rendering. OpenGL is a state machine, which means that your lib not only needs the state it sets, but it also implicitly needs all of the state it doesnt touches in certain ways. Its a pain in the ass to work with and a pain in the ass to debug. Just issue commands and let the game's renderer do its thing. You can see nuklear or libRocket's rendering APIs as an example.
