RGFW: Single-header C99 window abstraction library
github.com
github.com
(Especially since that'd force the POSIX world to de-fracture itself too.)
A single-header file is not a 'full-sized' library compressed into one file it's codebase is designed to actually be minimalist. Many libraries have single files that are the same size as their alternative single-header.
I don't know if you noticed but no modern languages use Linux packages to provide dependencies, because that obviously sucks balls for many reasons.
Those are a thing? Wasn't aware.
For me it only reveals lack of willingness to learn how to use their tools.
I learned how to use C and C++ build systems at the age of 12 years old, when most of the information was on libraries, or whatever folks down at computer club could explain.
In a computing landscape much more fragmented than it is today?
Do you think combining Windows and UNIX is hard? Try on the glory days of 16 bit home computers.
Here we are in the age of information, and some people couldn't be less bothered.
The closest thing to a C/C++ package manager standard on Windows is probably vcpkg: https://vcpkg.io/en/
But why is being installed by default important?
[1] https://www.petergirnus.com/blog/how-to-use-windows-package-...
If you are convincing people to run commands to install packages:
- they care about trust, they will already have their package manager from the ecosystem they trust (which should be msys+pacman on windows, btw)
- they couldn't care less and will trust your `curl | bash` or `Invoke-RestMethod -Uri http://hacker.com/totallysafe.exe`
on both cases, not having a default package manager shipped caused zero adoption attrition, I mean, besides the attrition of needing a non-standard package to begin with.
Too many possibilities made me choose none.
I'm pretty sure windows uses "long" for 64 bit but linux uses "long long" for 64 bit
You can still typedef those to i32, i64 shortcuts etc, but I would try to avoid this in libraries since it might collide with user typedefs of the same name - or at least try to avoid it in the public API declarations.
Source: https://handmade.network/forums/articles/t/7138-how_to_write...
AFAIK the STB headers are on C89 mainly because nothings likes to use VC6 as C IDE.
E.g. if you depend on other C99 features anyway, including stdint.h is fine, also on MSVC.
PS: FWIW I use stdint.h types in the Sokol headers since around 2017 and never heard complaints from users, with the supported compilers being MSVC, GCC and Clang.
I personally use `_MSC_VER >= 1600`, so it's since Visual Studio 2010 from April 2010. Built-in types like __int32 from before then may be used as well.
Thanks for the advice, I'm a little worried about breaking compatibility with compilers that don't support stdint. But if it's standard for C99 thing then sure.
Windows long is 32bit even on 64bit CPUs.
Linux long is arch dependent and is 64bit on x64, 32bit on x86.
long long is always 64bit on both platforms.
I just roll my own for this because I don't need all the functionality, and generally find such cross-platform libraries to only really test on Linux, and it's too much of a hassle.
other way around
It's low priority though because my main focus is desktop applications.
A quick heads up, the micro UI emscripten example doesn't work on chrome or firefox. The error is: DrawElements doesn't actually prepareClientAttributes properly.
Nuklear (https://github.com/Immediate-Mode-UI/Nuklear) uses separate files with a deploy script that combines them all into a single header; I think that approach is quicker for iterating on the code.
It's also possible to compile it on its own using `gcc -c -x c -D RGFW_IMPLEMENTATION RGFW.h`
Nuklear is not a true single-header style library, it only uses that as a format. The difference is that the design is far less compact and lightweight than a stb-style library.
I'm pretty sure GLFW has some files that are nearly the same size as RGFW, for example.
Nuklear is a full-sized library that can be compiled into and used as one file. However, RGFW and STB are designed to be lightweight and minimalistic. That's the distinctive part of single-header libraries, also known as STB-style libraries.
To be clear, I don't mean this to hate on Nuklear, it's a cool UI library, but its design doesn't match the single-header format.
How is it not designed to be lightweight and minimalistic?
How do you think the design differs from your idea (which is what exactly?) of a "single-header format"?
SQLite is distributed as a single 6 MB .c file and compiles in ... 0.1 seconds.
With -E (only preprocess) we are at around 0.320s for the 260K lines of sqlite3.c. Which makes sense, 1M lines/s for the preprocessor and maybe also the AST should be doable (that may be where you got your 60MB/s number from). But compiling is something else.
MSVC may be faster here or not, I haven't tested it.
A more modern machine (mine is a i5-7600K from 2018) may be 2x or more faster, and running on multiple threads will speed up the build as well.
It's not that. I think I messed up and the 0.1 seconds was tcc and msvc was 1 or 2 seconds. Nothing was 27 seconds. Try tcc, even though you are in a VM it should be very fast as a baseline for what's possible.
The point is that some people talk about single header files being slow are really saying "what if". C is incredibly fast to compile and the slow parts are the overhead from each compilation unit and the optimizers.
287 KB of source code added to a compilation unit is nothing in the modern era. Not only that, but you can just choose to put a lot of them in the same compilation unit and not touch it again.
Every time I've used single file header libraries it makes things simple and fast. I'm not going to change them so dumping them all into a single compilation unit is fine.
$ time gcc -x c -c RGFW.h -D RGFW_IMPLEMENTATION -fPIC -D RGFW_EXPORT
0.42s user 0.03s system 93% cpu 0.485 totalThis makes me think that you're using single-header libraries wrong. These kind of libraries usually require you to do something special prior to including it to get the actual code and you must do it only in ONE file.
For example, you'd #define RGFW_IMPLEMENTATION before #include rgfw.h in exactly ONE .c. If you need the header in other files, you do NOT define RGFW_IMPLEMENTATION and no code will be produced.
In any case, forcing me to figure out the specific XYZ_IMPLEMENTATION for each library is less user friendly that just proving a .c and .h file.
But after being burned a few times by naming or linking conflicts or you cloned your .c and forgot to remove the #define and now you have two implementations or having to debug any BSS/DATA/TEXT issues (because now lib and user code end up in the same .o and the linker can't do its magic for your esoteric architecture), I just took the habit of always manually creating a matching .c that only contains:
#define BLAH_IMPLEMENTATION
#include "blah.h"The single-header format also gives you MORE ways to compile the library and control which features to use or not use.
#include "impl.c"
#define XZUGG_IMPL
#include "impl.h"Where's the bloat? :)
https://github.com/SasLuca/glfw-single-header/blob/master/ex...
Include the header where you want the definitions. Include the header and use the preproccesor definition in the compilation unit you want the functions in. Done.
There is no speed issue here. It would take 100x the C to make a difference and it's actually going to be much faster and simpler to put a lot of single file libraries into one compilation unit. I always wonder if the downsides are theoretical or if people are really doing what I've been doing and still have a problem with it.
You and everyone else, RGFW, you and everyone else.
https://en.m.wikipedia.org/wiki/Direct_Rendering_Infrastruct...
Modern games are expected to work in multi-monitor setups and render in “borderless windowed” mode, so you can alt-tab out to multitask, or have a comms overlay. Single monitor single process gaming still happens, but a good 85% of setups (according to the Steam Hardware Survey) are not that. There are five games I know or that actually handle multimonitor natively of the hundreds I’ve played. So we need some form of cooperative multitasking for graphics with the window manager.
Really bad games with slow multiplayer match making lobby and tiresome repetitive gameplay and bad UX where you need to look most of the actual game information on a fan wiki, or triple A games where you have to login and enter credit card information on a "launcher"... those are the ones you expect to "render in “borderless windowed” mode, so you can alt-tab out to multitask". Good riddance.
(Wayland is broken in very many other ways, though, so you trade one evil for... 5 others).
X11 has a reasonably solid core, though, while Wayland does not.
I think that Wayland actually has some steps in the right direction, but overall I don't think it's actually a very good alternative. It's way more low-level than X11 and a lot of higher level features, like window decorations, are not even officially supported.
Are there any good minimal windowing utilities that support Wayland? SDL does a lot I don't need and I try to maintain minimal dependencies. I suppose I could just use glfw & libsoundio, haven't tried that yet.
The Wayland API itself also really sucks to work with, even more so than Xlib....
But, RGFW's Wayland support will probably be improved in the future. :)
(They may be good alternatives for certain use-cases)
GLFW's codebase is ~10MB while RGFW's is about ~300kb. But RGFW tries to support nearly everything that GLFW supports.
https://gaultier.github.io/blog/wayland_from_scratch.html
I'd also look at the work done on minimal wayland projects like [foot](https://codeberg.org/dnkl/foot), which supports wayland well and seems to be written by hand (see: https://codeberg.org/dnkl/foot/src/branch/master/wayland.c)
..an image decoding library.
..an audio input/output library.
..a multi-channel audio mixer.
..ttf and rtf font rendering.
..networking.
..runtime shader cross-compilation
..its own entire graphics abstraction layer / API.
..its own shader language, shader compiler, and shader bytecode format.
I don't know at which point something becomes 'high level', but SDL is only 'minimal' if you use a subset of its functionality.