lmemsm | Entries tagged with opengl

I've been using SDL for a long while now. The newest version of SDL 3 will require migrating from SDL 2 versions. Like the switch from 1.2.15 to 2, it will once again break backward compatibility. It will remove support for several older platforms and change the API. The good news is that SDL 3 will have a compatibility layer much sooner than SDL 2 did. I'm still patching some of the SDL 1.2.15 programs I use so that they'll work with either SDL 2 or SDL 1.2.15. In my experiences with it so far, patching seems to work better than using the compatibility layer for SDL 1.2 support. SDL 3 will make more use of the GPU and modern graphics libraries and drivers. From what I've read, it'll introduce a new, portable shader language. So, you may now need more than just a C compiler to write programs. I prefer working with a minimal number of languages and compilers and am not looking forward to some of the new changes SDL 3 may bring. This leaves me wondering if I should seek another graphics/GUI library for more of my development.

I've looked into GUIs, TUIs and graphics libraries in the past and I really wasn't thrilled with most of the options out there. Besides SDL, Raylib seems very promising. It doesn't have the variety of FLOSS applications SDL seems to though. Using OpenGL directly can be just as problematic as SDL because its API keeps changing as well. So, GLFW may not be a great strategy either if the OpenGL compatibility it makes accessible has a changing API. Nano-X seems fairly stable and works on a variety of operating systems. Allegro is often used for applications similar to those created by SDL. However, differences between the versions it supports and what platforms those versions offer is also noticeable. I often use pdcurses with an SDL backend, but pdcursesmod works very well on Windows using Win32 and can also support console mode in Windows and BSD-curses and ncurses offers some benefits over pdcurses on POSIX systems. So, while I've found pdcurses built with SDL highly portable and useful (I even added SDL 2 and SDL2_ttf support), programs that build with pdcurses should port easily to other libraries that don't require SDL.

There are some platforms that only work with SDL 1.2.x and are not supported by later versions of SDL. The same will most likely be true for SDL 2 compared to the latest version of SDL 3. I'm wondering if I should keep using and patching the current SDL 2 and 1.2.15 libraries I've been working with or just make the switch to a new library. I'm also wondering if other developers are in the same situation, trying to determine whether to continue with what they have or port what they can to yet another graphics library or a later version of SDL. If there's interest from other developers in continuing to use older versions of SDL because of platforms they supported or portability issues, it would be nice to collaborate in continuing to maintain these libraries. It's easier to find security issues and bugs when there are a group of users rather than just one programmer using it.

I am currently working on backporting the latest SDL 2 helper libraries so that as many as possible work with SDL 1.2.15. That way SDL 1.2.15 can make use of newer features like loading and rendering SVG images, better utf-8 support, etc. I have a patched version of SDL2_ttf that adds functionality needed for sdl_unifontview to work properly. I've also been adding an alternative build system that doesn't require GNU autotools or cmake. It instead uses CDetect and make.

As one of the earlier contributors to MinGW, I use the original MinGW port to Windows and try to avoid the hostile fork of MinGW whenever possible. Unfortunately, many libraries do not maintain compatibility with the original MinGW compiler. The newer the libraries are, the less compatible they typically are. So, while SDL 1.2.15 is no problem to build with MinGW. SDL 2.26.5 is a nightmare. I'm currently looking into some issues related to building it with the original MinGW now. I maintain my own version of w32api based on the last public domain release and have been trying to add enough functionality to it to compile many of the more modern standard FLOSS libraries. I also built SDL 2 on AIX at one point to experiment with running SDL applications on AIX via X-forwarding. So, I have patches for that as well.

I've started a thread on Mastodon:
https://fosstodon.org/@lmemsm/110413981373101611
Would be very interested to hear how others are dealing with the SDL upgrade path and whether they will be upgrading, staying with what they have or seeking other libraries. If anyone's considering the route of maintaining older libraries, I'd be very interested in sharing resources and patches.

TinyGL is a subset of OpenGL with a zlib license. It uses software rendering. For systems that cannot take full advantage of GPUs or high performance graphics drivers, TinyGL gives decent performance. It's been used on several small handheld devices and on less standard operating systems like Amiga clones and BeOS. It offers much of the functionality of OpenGL 1.1. PicoGL is a fork of TinyGL with several backends including SDL 1.2.x, nano-x, Vesa framebuffer and X11. More can easily be added. I've already added support for SDL 2.x. PicoGL also attempted to add fixed point support for systems that had issues with floating point representation.

I've been patching PicoGL since 2013 and have added several features. It's currently stable enough to use with an OpenGL application such as Emilia Pinball. I've looked at several TinyGL forks with similar licenses and attempted to add the best of these forks into my version of PicoGL. I've updated the math-ssl library to a later version that uses a MIT license instead of the original GPL 2 license.

Other modifications include switching to 32 bit internal representation. I added some missing functions. I coded support for blending textures. I fixed a lighting issue that's visible in the gears demo. The gears are now displaying as red/green/blue as expected instead of white/yellow/cyan. After a lot of research, I found a way to work with power of 2 sized textures that are represented with sizes other than 256 internally.

I still have several modifications I want to make. In order for simple font atlases to work, I needed support for glTexSubImage2D. I recently added that and it appears to be working as long as textures are sized by a power of two. I'm currently working on refactoring the texture related code and cleaning up how to handle conversions between different formats (such as RGB, RGBA, BGRA).

Was surprised that the various forks of TinyGL have not fixed many of the bugs in the code. After I fixed the lighting issue for the gears demo, I ran across a few forks that mentioned the lighting problem. I also found a texture mapping bug. It's very easy to notice when you're using a font atlas. I had a letter next to a box character. When drawing the letter section of the texture, it went over by one pixel in the x direction. The first pixel of the box was displaying along with the letter. None of the forks I've looked at have made mention of the issue. The bug is in the s and t transforms in the gl_transform_to_viewport code. Assuming the texture has a width of 8, then the code should transform the x texture coordinates ranging from 0 to 1 to the texture bitmap coordinates 0 to width - 1 which in the example is 7. The PicoGL code is attempting to convert from one coordinate system to the other and then shift left by 14. However, the formula is combining the coordinate transformation with the shifting into one formula. It takes the highest shifted coordinate as ZB_POINT_S_MAX and the lowest shifted coordinate as ZB_POINT_S_MIN. The TinyGL code looks like s * (ZB_POINT_S_MAX - ZB_POINT_S_MIN) + ZB_POINT_S_MIN. In the texture routine, the bits of the s coordinate are ANDed with a mask to remove fractions and then shifted back to get the transformed coordinate. The problem appears to be in how the transform and shift were combined in the formula. I believe the transform should be using 0 as the minimum and then doing the shift. The formula for the example texture should be (s-0/(1-0))*(width-1 - 0)+0 and then the shift is applied. That means the added minimum value should be 0 and even after it's shifted should still be 0. The maximum (width - 1) can be shifted once before it's multiplied with v to save time calculating (which is similar to what the original formula does). Thus, the formula should look more like s * (width - 1 << 14). Actually, the formula in the program is a little more complicated. It does the equivalent of adding in .5 to the maximum texture coordinate (width - 1) during the multiplication process for better rounding and then lops off the fractions from the result using a mask (in this case, width - 1 << 14) during the texture rendering phase before shifting the results to the right. However, I try to go through the formula or calculate this, adding in ZB_POINT_S_MIN in the original formula moves everything off by one pixel. The coordinate system should be 0 to width - 1 not .5 to width - 1. Fixing the coordinate system, fixes the bug. With a coordinate change in place, I no longer see an extra line of pixels when I use texture mapping to display parts of a font atlas to the screen.

It's difficult to find good documentation on how to create a rendering engine similar to the one used by PicoGL to render triangles and perspective correct textures. There really aren't any useful details on how the rendering works in documentation within TinyGL. That can make it difficult to figure out what the intention of the programmer was and whether there are any issues with the implementation (such as the texture mapping being off by a pixel) or whether they are 'intended features'. Best information I could find on how texture rendering engines work is in the Perspective Texture Mapping articles at http://chrishecker.com/Miscellaneous_Technical_Articles
There is also a discussion of some techniques here:
http://www.phatcode.net/~fb/forum/viewtopic.php?t=24889 If anyone runs across other good documentation on the subject, please let me know.

If there are any other projects, groups or developers using or investigating using TinyGL, PicoGL or a similar fork, I would love to share development ideas and code and/or discuss design issues. Have you worked with or done something interesting with PicoGL or TinyGL? Please let me know. I'm also in search of useful, portable applications that will work with a TinyGL or PicoGL backend. Have any favorites? Please share some details about them. Feel free to contact me: http://www.distasis.com/connect.htm

Along the lines of investigating portable C GUI libraries, I started looking at cross-platform library options for font rendering in C. This area is particularly useful if you're investigating creating your own GUI library or game library. I was most interested in the TrueType font rendering libraries and techniques. It was rather surprising to read just how difficult it is to get simple internationalized text to the screen especially using graphics libraries like OpenGL.

Here's what I've located. If you have other recommendations for C font rendering libraries, please let me know.

GUI library options like nuklear and nanovg use stb_truetype.h:
https://github.com/nothings/stb
They also use some kind of font stash, such as this one used with nanovg:
https://github.com/memononen/fontstash

Other GUI libraries use FreeType2.
https://www.freetype.org/

For instance, SDL2_ttf uses FreeType2.
https://www.libsdl.org/projects/SDL_ttf/

Allegro also has font libraries available that are based on FreeType2.
http://opensnc.sourceforge.net/alfont/mirror/

Here's one that works with Allegro or SDL:
http://kirill-kryukov.com/glyph-keeper/files.shtml

There are several font libraries for OpenGL, but there aren't many options written in C. Some are for older versions of OpenGL and some only work with later versions. Here's what I found so far:

https://github.com/rougier/freetype-gl
https://github.com/jtsiomb/libdrawtext
http://quesoglc.sourceforge.net/

Here's another C option that works with FreeType2 and embeds fonts in C programs:
https://github.com/chrisy/fontem

The most recommended technique used by OpenGL developers seems to be texture mapping. A texture can be used like a hash table to store various characters and other pixmaps that need to be rendered. An OpenGL function can draw a piece of the texture or update/change parts of it in memory without affecting performance too much. While software renderers have no real trouble copying or blending a bitmap graphic or pixmap, the newer OpenGL versions send the textures to the GPU for rendering. So utilizing a texture instead of bitmaps/pixmaps and minimizing the number of textures one is working with can improve performance.

I personally find it easier to render text with SDL. It handles copying and blending bitmaps (as an SDL_Surface) and offers a useful library (SDL_ttf) to do most of the work. SDL 2.x does use OpenGL underneath on some platforms, so some of the texture concepts used by OpenGL programmers might improve font rendering performance on some versions of SDL as well.

Freetype seems to be the library for working with TrueType fonts. SDL_ttf uses freetype to interpret the Truetype font format and create bitmaps/pixmaps to represent characters (converting them from vector format to bitmap/pixmap format). I found working with SDL_ttf a lot more user-friendly than trying to use Freetype directly.

Another viable option is stb_truetype.h. The license for this software is definitely an advantage. However, from what I've read the rendering still isn't quite as good as Freetype. I look forward to testing this out on my own at some point.

At this point, I'm still investigating SDL_ttf, stb_truetype.h and OpenGL texture mapping. A combination of these might be just what's needed in a font rendering design for a cross-platform GUI library.

Know of some other font rendering options that work well for Truetype fonts or have a better way to get fonts to the screen, I'd love to hear about it?

Some of the C graphics libraries are great, but I've yet to find a simple GUI that makes it easy to port some older BASIC programs that I want to be able to keep working with. I've created several iterations of my own GUI library, but have never been satisfied with the results. That's the main reason I keep investigating cross-platform GUIs, to see if someone's found a better way to do it. Of the various designs, the ideas behind the immediate mode GUIs seem the most useful for the type of programs I'm targeting. However, I can't seem to find one GUI library that provides a simple way to do what I want. So, I've decided to revisit my old GUI library designs but eliminate some of the framework constraints and some of the object oriented elements. Instead, I'm looking at a more procedural approach that uses concepts from immediate mode GUIs.

Even though I'm avoiding popular C/C++ GUI libraries, I'm not starting completely from scratch and writing everything myself. There are plenty of good graphics libraries that are very portable and make a great basic starting point for a GUI. One of the libraries I've been very impressed with is SDL. It makes a great base for porting software. I've also done a lot of work with PicoGL (a TinyGL fork). It's a convenient way to make OpenGL more portable and avoid some of the version issues. It works on low resource platforms such as handheld devices that don't have high performance video driver support. I've often found OpenGL and Mesa slow on older computers and low resource systems. PicoGL provides very good performance on these types of systems. While using Win32 is not as portable as I would like, it's not that hard to get an OpenGL window up and running on Win32. That easily allows switching between Win32/OpenGL and SDL (1.2.15 or SDL 2.x)/PicoGL. SDL can work on a variety of platforms and PicoGL can work with SDL or with other options such as nano-x, X11 or vesa framebuffer. It shouldn't be too hard to take the output from PicoGL to use with the Android bitmap API either. Another possible option for a backend is Allegro. Like SDL, it works on a variety of platforms. It would be nice to switch between SDL and Allegro as backends depending on which works best for a particular platform without needing to redesign an entire application.

The PDCurses/ncurses API provides a standard way to create console based programs that work well on a variety of platforms from DOS to Windows to FreeBSD to Linux. However, it provides only text support and no real graphics support. While it's great for porting programs written to work with it, I don't think it's the best option to use as a GUI backend. I recently came across TinyCurses which provides a subset of the API and uses SDL as a backend. PDCurses also offers SDL as a backend option. I couldn't help thinking, once a decent GUI design was finalized, it wouldn't be too hard to provide a subset of functionality similar to PDCurses/ncurses. That would allow for easy porting of some PDCurses/ncurses based applications to any platform the GUI library works on.

So, why not just use OpenGL as the backend to design a GUI library? After considering the pros and cons, I decided I don't want to be tied specifically to OpenGL as an API for 2D graphics. While it's very popular and available on several platforms, the changes from a fixed function pipeline to a programmable pipeline with its own shading language make it hard to port programs from one version to another. PicoGL makes use of old fixed function pipeline concepts. Windows OpenGL also uses the older design. Mobile devices and WebGL make use of the newer concepts and the ability to harness the GPU to do more processing. Many developers seem to be abandoning the older concepts and embracing the new programmable pipeline design. However, that leaves some nice older applications that were designed for earlier versions of OpenGL that won't port easily to the newer versions. They might require a complete redesign and rewrite. Using PicoGL is one way to make it easier to port such applications. It can do software rendering to a bitmap which can then use more modern methods (including later versions of OpenGL or SDL 2.x) to transfer the bitmap to the screen. While the idea of using OpenGL as the portable backend for a GUI library sounds good, dealing with version differences and what versions may be available on which platforms does not make it the best option for a complete cross-platform portable solution. Instead, I prefer the concept of being able to switch out backends to use what works well on a particular platform. The GUI library should encapsulate the rendering as much as possible to avoid needing to rewrite applications in order to switch to another backend.

On the other hand, many GUI libraries and some other rendering libraries (such as SDL) offer ways to interoperate with a graphics library like OpenGL. While I want my GUI library code to be cross-platform, I don't want to limit a developer to using just that API. If a programmer wants to use OpenGL or SDL2_gfx or some other library to handle 2D/3D graphics, I'd like the GUI to be able to interoperate with that choice. It would mean that the resulting application would be less portable. However, if an application is already designed to utilize SDL2_gfx, OpenGL or some other library that could work compatibly with the GUI library, it could make adding some GUI functionality to an existing application much easier.

I definitely know what I'm looking for in a cross-platform GUI. I want a simple, portable way to get text, menus, forms, file/directory picker dialog functionality to the screen. I'd like to make use of Freetype fonts. I want an internationalized way to display text and for users to input text. The text strings will probably involve a library such as gettext. I want the options to use keyboard input for those of us who prefer keyboard commands to get their work done and mouse/touchscreen input for devices such as mobile phones where a real keyboard may not be available. I need to be able to access graphics and audio information from a file system or from a zipped file (such as .apk file on Android). I don't care if the look and feel matches what's in style for a particular device or operating system. I just want it to be user-friendly and ergonomically designed.

If you're interested in GUI design or working on a GUI or gaming library of your own, I'd love to compare notes on the subject. Have an idea for what C library might make a good backend for a portable, cross-platform C based GUI? Let me know. Feel free to discuss design issues or other C/C++ topics on the CppDesign mailing list or contact me to compare design notes and share ideas ( http://www.distasis.com/connect.htm ).

I'm always on the look-out for a simple to use, lightweight, portable GUI library. I've put together several lists of available C/C++ GUI libraries. (For instance: http://www.distasis.com/cpp/scrlib.htm ) I've also tried out and experimented with several GUI and text user interface libraries. It's difficult to find one that will let you get a new application up and running or an old one ported to C/C++ quickly. Most GUIs seem to get in the way of development or complicate it.

I still keep debating whether to create my own GUI library in projects or use what's currently available. There's no point in creating your own if there's something better out there. That's the main reason I continue to look for interesting GUI libraries. However, I've yet to find that "something better" that I really enjoy working with.

With that in mind, here's another list of GUI libraries. This time I've limited the field to C only libraries that are highly portable. Since many lighter GUIs use various graphics libraries and other frameworks as backends, I'm including information on graphics libraries that can be used for GUI development as well.

Graphics libraries often used with GUIs:

Some lightweight GUI libraries use graphics libraries as backends to improve portability and decrease library code size. Popular graphics backends written in C include SDL (Simple DirectMedia Layer) and Allegro.

SDL

https://www.libsdl.org/
SDL2_ttf provides TrueType text support for SDL.
https://www.libsdl.org/projects/SDL_ttf/
SDL2_ttf provides internationalization support using a UCS-2 character set. I have patches to support the UTF-32 character set.
http://www.distasis.com/cpp/lmports.htm

Allegro

https://www.allegro.cc/about

AGG

Anti-Grain Geometry library is also used as a graphics backend. Some projects stick with the older version of AGG 2.4 which has a BSD license.
https://en.wikipedia.org/wiki/Anti-Grain_Geometry

Nano-X/Microwindows

Nano-X is highly portable and can work on a wide variety of platforms including DOS and embedded systems. It makes it easier to port X11 and Win32 applications by providing a subset of those APIs (with nano-x/NX11 or microwindows).
https://github.com/ghaerr/microwindows
https://github.com/georgp24/microwindows-android-bin
https://github.com/ghaerr/nxlib

OpenGL

I've seen several lightweight GUI and screen libraries designed for OpenGL. However there are issues with portability to different versions of OpenGL or OpenGLES. Projects like freeglut and GLFW try to make OpenGL easier to use for cross-platform development. There are also several libraries that work with the freetype library and add TrueType font support including ftgl, ftgles, GLTT, freetype-gl, OGFLT
http://freeglut.sourceforge.net/
https://www.glfw.org/

PicoGL

I like PicoGL (a fork of tinyGL) for OpenGL development. It's a subset of OpenGL. It supports several backends including SDL, nano-x, X11 and vesa framebuffer. Since it's software based, it ports well to hand-held devices and other systems that may not have rich hardware support for graphics.
http://people.openmoko.org/jserv/graphics/

I've made several updates and additions to PicoGL including adding some missing OpenGL functionality, SDL 2.x support, bug fixes including a fix for lighting bug in the gears demo. It includes enough OpenGL support to port Emilia pinball. I haven't uploaded my changes to the Internet yet, but if anyone's interested, feel free to contact me about it.

GUI and text user interface options:

PDCurses with SDL backend

This is an option I really like. I've been experimenting with using this for development. I have BSD libmenu and libform working with it too. PDCurses can be used to create a text user interface and SDL can add graphics capabilities.
https://github.com/wmcbrine/PDCurses

TinyWidgets

Lightweight GUI with graphical screen designer. Uses nano-x as a backend. While the original project is dated, there's been some recent development by some of the nano-x developers.
http://tinywidgets.sourceforge.net/
https://github.com/ghaerr/microwindows/tree/master/src/contrib/TinyWidgets

nuklear

This looks promising. Has several backends including GLFW, SDL, Win32, X11, SFML, allegro, nanovg.
https://github.com/Immediate-Mode-UI/Nuklear
https://github.com/vurtun/nuklear
https://github.com/vurtun/nuklear/issues/202
There are also projects that combines nuklear and raylib:
https://github.com/RobLoach/raylib-nuklear
https://github.com/tcfunk/raylib-nuklear

raygui

Another promising cross-platform option. It has support tools to help create layouts. It works on a variety of systems including mobile devices. There's also raylib (a graphics/video game library used by raygui) and raudio (for audio support). The raylib library uses OpenGL/GLFW for graphics support.
https://github.com/raysan5/raygui

c_ugui

Immediate mode GUI using Raylib.
https://github.com/Aurumaker72/c_ugui

nanovg

nanovg is a 2D vector drawing library by the developer of nanosvg (popular svg parsing library). The examples show GUI elements. Other GUI libraries (including nuklear and oui-blendish) also use this as a backend option.
https://github.com/memononen/nanovg
https://bitbucket.org/duangle/oui-blendish/src

GTK+

GTK+ is one of the more popular GUI libraries. However, while each new major version came with added features, it also came with a lot of added complexity. Some distributions use older versions of GTK+ (no longer in development) in order to cut down on complexity. While there were several applications written with this library, it's hard to find up-to-date, supported applications that still use an older version of GTK+.

Amigo Linux is still using GTK 1.2 and has patched some applications to keep them working.
ftp://distro.ibiblio.org/amigolinux/misc/Amigo%20Linux%20Project.html

I've also seen some patches to GTK 1.2 to keep it more up-to-date.
https://github.com/dimkr/gtk
https://github.com/tindzk/GTK

Another interesting GTK+ based option, there were some ports of GTK+ that use the ncurses backend.
https://atrey.karlin.mff.cuni.cz/~pavel/cursed/cursed.html
https://sourceforge.net/projects/zemljanka/files/

If you're interested in more up-to-date GTK+ versions that try to avoid some of the bloat and unneeded dependencies, check out these forks for GTK 2 and a minimal ATK to use with GTK 3:
https://github.com/stefan11111/gtk2
https://github.com/stefan11111/atk

XForms Toolkit

http://xforms-toolkit.org/

LessTif

https://sourceforge.net/projects/lesstif/

Kiss_sdl

GUI toolkit for SDL.
https://github.com/actsl/kiss_sdl

kiss-nanovg-sdl

Based on kiss-sdl but modified to support svg using nanovg.
https://gitlab.com/Mis012/kiss-nanovg-sdl

KiWi

GUI toolkit for SDL.
https://github.com/mobius3/KiWi

RetroGui

Minimalistic GUI library based on SDL.
https://gitlab.com/Pix3l/RetroGui

rouziclib

Works with SDL and other libraries.
https://github.com/Photosounder/rouziclib

Green-GUI

GUI for SDL 1.2 written in C99.
https://github.com/Laurefinwe/Green-GUI

swk

Minimalist widget kit for SDL.
https://oldgit.suckless.org/swk/files.html

WidgetSDL2

C99/SDL2 Cross-platform GUI using include headers.
https://github.com/nuchida7727/WidgetSDL2

uGI

Micro Graphical User interface. Needs SDL2.
https://github.com/wernsey/uGI

SDL GUI

Simple SDL GUI libraries, mainly targeted toward Windows.
https://github.com/David-H-Bolton/sdlgui

CGUI

GUI toolkit using allegro.
http://cgui.sourceforge.net/index.html

Win32

I've seen several C applications written with the Win32 API. That might not sound very portable for platforms other than Windows. However, keep in mind that X11 users have access to winelib and Microwindows offers some Win32 API compatibility. I have been able to get some programs written using a Win32 backend to port and run fine on Microwindows/nano-x.

Otk (Open Tool Kit)

C and OpenGL GUI.
https://sourceforge.net/projects/otk/

IUP

https://sourceforge.net/projects/iup/

LCUI

https://github.com/lc-soft/LCUI

sgui

https://github.com/AgentD/sgui

libui

https://github.com/andlabs/libui

libui-ng
https://github.com/libui-ng/libui-ng

GraphApp

http://enchantia.com/software/graphapp/

Microraptor GUI

https://github.com/hodefoting/mrg

Micro-GUI (ugui)

https://github.com/ryankurte/micro-gui

microui

https://github.com/rxi/microui

FTK

https://github.com/xianjimli/ftk

EasyGui for embedded systems

https://github.com/MaJerle/EasyGUI

m2klib

https://github.com/olikraus/m2tklib

Milkymist Gui Toolkit

https://github.com/m-labs/mtk

mGui

http://web.tiscali.it/morello/MGui/index.html

RGFW

https://github.com/ColleagueRiley/RGFW

RSGL

https://github.com/ColleagueRiley/RSGL

Yzone

http://lifesoft.chat.ru/yzone/

GUISlice

https://github.com/ImpulseAdventure/GUIslice

newt

https://pagure.io/newt

notcurses

https://github.com/dankamongmen/notcurses

vtk

https://github.com/vktec/vtk

Agar

GUI toolkit using SDL. I've read several posts about it being buggy and not well supported. I've personally had no luck porting it to certain platforms.

STFL

Use with PDCurses, ncurses or similar libraries to provide common controls and widgets.
http://www.clifford.at/stfl/

CDK

Curses Development Kit.
https://invisible-island.net/cdk/cdk.html

Widget Curses ToolKit

Ncurses TUI widget toolkit library.
https://github.com/stfsux/libwctk

This list is in no way comprehensive. If you know of other highly portable, strictly C GUI or text user interface libraries, please mention them. If you're working on your own GUI library, would like to discuss C/C++ GUI libraries and development or other C/C++ related topics, feel free to continue the conversation on the CppDesign mailing list.