Very nice! I like that it's a single header. I wrote something similar although it's not single header, doesn't do audio, and no X11 backend https://github.com/samizzo/pixie. I use mine as a backend for Windows ports of MS-DOS demos that I make.
Minimal Cross-Platform Graphics
11–20 of 67 posts
Re: Minimal Cross-Platform Graphics
#12I used to use a timer to limit the frame rate to 60 Hz too. But on Windows, I found that DwmFlush() seems to act like WaitVSync(), so I've been using that in preference for years now. I think this is undocumented behaviour. I guess what it actually does is wait until the compositor is ready for another frame. To be able to call that function, I LoadLibrary("dwmapi.dll"), and then GetProcAddress(dwm, "DwmFlush").
Why not just use VSync?
Re: Minimal Cross-Platform Graphics
#13I think this needs much more complexity to be useful. For the rendering, ideally it needs GPU support. Input needs much more work, here's an overview for Windows: http://blog.ngedit.com/2005/06/13/whats-broken-in-the-wm_key... Windows' Sleep() function has default resolution 15.6ms, that's not enough for realtime rendering, and relatively hard to fix, ideally need a modern OS and a waitable timer created with high re…
No direct access to the command buffers of the GPU? No matrix transform routines? No colorspaces besides RGB? Absolute non-starter.
> direct access to the command buffers of the GPU
Impossible given the platform limitations at that time, on Linux that code works on top of GLES 3.1. I didn't want too many Windows-only features there.
> No matrix transform routines?
There's no need for that. That library is for C#, which includes these routines in the standard library of the language for many years now, since .NET core 1.0: https://learn.microsoft.com/en-us/dotnet/api/system.numerics...
Re: Minimal Cross-Platform Graphics
#14Earlier quoted context omitted.
No direct access to the command buffers of the GPU? No matrix transform routines? No colorspaces besides RGB? Absolute non-starter.
> direct access to the command buffers of the GPU Impossible given the platform limitations at that time, on Linux that code works on top of GLES 3.1. I didn't want too many Windows-only features there. > No matrix transform routines? There's no need for that. That library is for C#, which includes these routines in the standard library of the language for many years now, since .NET core 1.0: https://learn.microsoft.…
My remark was about Fenster, and a critique of your comment that it somehow isn't good enough because it lacks GPU acceleration and that sort of thing. The point of Fenster is to be minimal and simple yet still allow programmers to get stuff on the screen in a way that's easy and fun. It performs superbly at the role it was conceived for. We can list features we want/think are table stakes for a modern graphics pipeline or whatever, and there are plenty of libraries that are up to those tasks. This one is doing something different.
Re: Minimal Cross-Platform Graphics
#15I used to use a timer to limit the frame rate to 60 Hz too. But on Windows, I found that DwmFlush() seems to act like WaitVSync(), so I've been using that in preference for years now. I think this is undocumented behaviour. I guess what it actually does is wait until the compositor is ready for another frame. To be able to call that function, I LoadLibrary("dwmapi.dll"), and then GetProcAddress(dwm, "DwmFlush").
Why not just use VSync?
If I am not too much mistaken, because on some hardware (mobile), there is no vsync feedback.
vsync feedback support has to be queried (look at vulkan API/wayland API). Usually it is called "presentation" something.
Re: Minimal Cross-Platform Graphics
#16I think this needs much more complexity to be useful. For the rendering, ideally it needs GPU support. Input needs much more work, here's an overview for Windows: http://blog.ngedit.com/2005/06/13/whats-broken-in-the-wm_key... Windows' Sleep() function has default resolution 15.6ms, that's not enough for realtime rendering, and relatively hard to fix, ideally need a modern OS and a waitable timer created with high re…
No direct access to the command buffers of the GPU? No matrix transform routines? No colorspaces besides RGB? Absolute non-starter.
There’s simple and there’s naive.
SDL already walked this path. So did pygame.
It turns out without shaders, and all their complexity, you basically can’t do anything useful at high resolutions.
/shrug
It’s too slow; compositing, transformations, all the things people want to do are very much harder to implement in software on top of a naive graphics stack.
Simple doesn’t mean naive; you can have a simple api that is excellent.
…but this is a naïve implementation, and it won’t work in any useful way at scale.
People complain about ballooning complexity, but they often forget that stuff (eg. specialised graphics hardware) wasnt invented by a bunch of idiots.
It was invented because the naive approach, that they used before was found to be in practice fundamentally limiting, inferior and failed to meet people’s expectations.
Of course, if you vastly lower your expectations, and target say, 320x240 at 8bit colour, you can happily have a naïve implementation that works just fine
(Don't believe me? Quote:
> Having this we can now draw complex polygons and would probably need a “flood fill” algorithm. Typically it is implemented using a queue of pixels to check and paint, but we can use recursion, as long as the filled area remains small enough to not overflow the stack
^ This is the very definition of a naive implementation, and https://github.com/zserge/fenster/blob/e71d493fa6d544243dd60... settings one pixel at a time, is too. Delightfully charming as it might be to write your own functions that set one pixel at a time, it's a joke, really, if you expect to do anything serious)
Re: Minimal Cross-Platform Graphics
#17Very cool! This example I think needs editing: memset(f->buf, rgb, f->width*f->height*sizeoof(uint32_t)); it's described as a way to "fill the complete framebuffer with a solid colour", but 'rgb' is shown in the previous snipped to be 'uint32_t'. That is not how 'memset()' [1] works, it will only use the least significant 8 bits of the 'int'-typed value argument. So it would use whatever blue bits where in 'rgb', onl…
Fine, but at least fix this bug:
.. (sizeof *f->buf) ..
Re: Minimal Cross-Platform Graphics
#18Re: Minimal Cross-Platform Graphics
#19I think this needs much more complexity to be useful. For the rendering, ideally it needs GPU support. Input needs much more work, here's an overview for Windows: http://blog.ngedit.com/2005/06/13/whats-broken-in-the-wm_key... Windows' Sleep() function has default resolution 15.6ms, that's not enough for realtime rendering, and relatively hard to fix, ideally need a modern OS and a waitable timer created with high re…
> For the rendering, ideally it needs GPU support.
It's a 2D framebuffer library for placing single pixels like in mode 13 *eyerolling* (GPUs are hardly useful for this type of stuff).
If you want something more complete, check out the sokol headers (shameless plug): https://floooh.github.io/sokol-html5/
...but that can hardly be called 'minimal' anymore.
Re: Minimal Cross-Platform Graphics
#20I think this needs much more complexity to be useful. For the rendering, ideally it needs GPU support. Input needs much more work, here's an overview for Windows: http://blog.ngedit.com/2005/06/13/whats-broken-in-the-wm_key... Windows' Sleep() function has default resolution 15.6ms, that's not enough for realtime rendering, and relatively hard to fix, ideally need a modern OS and a waitable timer created with high re…
> For the rendering, ideally it needs GPU support. It's a 2D framebuffer library for placing single pixels like in mode 13 *eyerolling* (GPUs are hardly useful for this type of stuff). If you want something more complete, check out the sokol headers (shameless plug): https://floooh.github.io/sokol-html5/ ...but that can hardly be called 'minimal' anymore.
2d graphics are rendered on the GPU nowadays, and rightly so. Even SDL uses the GPU wherever it can, by default.