6 ms·

I 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 Wind

I 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_keydownwm_char-input-model/ 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 resolution flag. Here's my attempt at making something similar, couple years ago: https://github.com/Const-me/Vrmac https://github.com/Const-me/Vrmac

bob1029 4y ago
> Windows' Sleep() function has default resolution 15.6ms, that's not enough for realtime rendering, and relatively hard to fix Very easy to fix. Call this at the start of your real-time process: https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod https://learn.microsoft.com/en-us/windows/win32/api/timeapi/... Use an argument of 1, and windows will come knocking at ~1Khz. This is extremely effective in my experience. Allows you to do some pretty crazy stuff on 1 thread.
bitwize 4y ago
No direct access to the command buffers of the GPU? No matrix transform routines? No colorspaces besides RGB? Absolute non-starter.
- Const-me 4y ago
  > 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.matrix4x4 https://learn.microsoft.com/en-us/dotnet/api/system.numerics...
  - bitwize 4y ago
    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.
- wokwokwok 4y ago
  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/e71d493fa6d544243dd601425179d6f7c7394b0e/fenster.h#L51 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)
  - stephc_int13 4y ago
    For any graphic intensive application it would be obviously be necessary to use a GPU. But for quick hacking / porting old demos / writing emulators and also text based UI it can be fast enough. With the added benefit of small footprint, high compatibility and fast startup time. The Lite editor https://github.com/rxi/lite https://github.com/rxi/lite is using pure software rendering (on top of SDL) in a rather naïve fashion but it still renders full 32bit colors at full resolution at more than 60FPS on my computer, not the best solution but still surprisingly fast given the simplicity of the renderer. This is typically a case where simple/naïve can beat a juggernaut like Electron.
    - 4y ago
- flohofwoe 4y ago
  > No direct access to the command buffers of the GPU? Lol, show me one library that does this without going through an abstraction layer like Vulkan. Details like this are not even documented by GPU vendors and you'd need to reverse engineer every supported GPU architecture yourself.
  - bitwize 4y ago
    I was being sardonic. Guy writes a library with the design goals of making basic, retro-like graphics functionality easy and fun with a minimum of code, and certain Hackernews dogpile him because it can't be integrated with an AAA pipeline or whatever.
    - flohofwoe 4y ago
      Ah, apologies then :)
flohofwoe 4y ago
> 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/ https://floooh.github.io/sokol-html5/ ...but that can hardly be called 'minimal' anymore.
- krapp 4y ago
  2d graphics are rendered on the GPU nowadays, and rightly so. Even SDL uses the GPU wherever it can, by default.
  - flohofwoe 4y ago
    That's a silly statement. If you want to place single pixels, a GPU won't help in any way. The most efficient way would be to write pixels with the CPU into a mapped GPU texture, and then render this texture as fullscreen quad. That's hardly more efficient than going through the system's windowing system. For applications like emulators, or making vintage games (like Doom) run on modern platforms, that approach makes a lot of sense.
    - krapp 4y ago
      >That's hardly more efficient than going through the system's windowing system. My intuition says otherwise but I admit I don't have math on hand to back it up.
      - flohofwoe 4y ago
        Ok it's most likely slightly slower, but not enough that it matters. Frame latency might actually be lower though if the result doesn't need to go through a swapchain AND the window system composer.
    - zozbot234 4y ago
      Most vintage systems use something way more complex than a pure CPU-controlled framebuffer for graphics. They generally have some sorts of pre-defined "tiles" used to implement a fixed-width character mode, with the addition of a limited number of "sprites" overlaid in hardware. These video modes could be implemented efficiently by modern GPU's.

bob1029 4y ago

> Windows' Sleep() function has default resolution 15.6ms, that's not enough for realtime rendering, and relatively hard to fix Very easy to fix. Call this at the start of your real-time process: https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod https://learn.microsoft.com/en-us/windows/win32/api/timeapi/... Use an argument of 1, and windows will come knocking at ~1Khz. This is extremely effective in my experience. Allows you to do some pretty crazy stuff on 1 thread.

bitwize 4y ago

No direct access to the command buffers of the GPU? No matrix transform routines? No colorspaces besides RGB? Absolute non-starter.

Const-me 4y ago
> 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.matrix4x4 https://learn.microsoft.com/en-us/dotnet/api/system.numerics...
- bitwize 4y ago
  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.
wokwokwok 4y ago
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/e71d493fa6d544243dd601425179d6f7c7394b0e/fenster.h#L51 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)
- stephc_int13 4y ago
  For any graphic intensive application it would be obviously be necessary to use a GPU. But for quick hacking / porting old demos / writing emulators and also text based UI it can be fast enough. With the added benefit of small footprint, high compatibility and fast startup time. The Lite editor https://github.com/rxi/lite https://github.com/rxi/lite is using pure software rendering (on top of SDL) in a rather naïve fashion but it still renders full 32bit colors at full resolution at more than 60FPS on my computer, not the best solution but still surprisingly fast given the simplicity of the renderer. This is typically a case where simple/naïve can beat a juggernaut like Electron.
  - 4y ago
flohofwoe 4y ago
> No direct access to the command buffers of the GPU? Lol, show me one library that does this without going through an abstraction layer like Vulkan. Details like this are not even documented by GPU vendors and you'd need to reverse engineer every supported GPU architecture yourself.
- bitwize 4y ago
  I was being sardonic. Guy writes a library with the design goals of making basic, retro-like graphics functionality easy and fun with a minimum of code, and certain Hackernews dogpile him because it can't be integrated with an AAA pipeline or whatever.
  - flohofwoe 4y ago
    Ah, apologies then :)

flohofwoe 4y ago

> 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/ https://floooh.github.io/sokol-html5/ ...but that can hardly be called 'minimal' anymore.

krapp 4y ago
2d graphics are rendered on the GPU nowadays, and rightly so. Even SDL uses the GPU wherever it can, by default.
- flohofwoe 4y ago
  That's a silly statement. If you want to place single pixels, a GPU won't help in any way. The most efficient way would be to write pixels with the CPU into a mapped GPU texture, and then render this texture as fullscreen quad. That's hardly more efficient than going through the system's windowing system. For applications like emulators, or making vintage games (like Doom) run on modern platforms, that approach makes a lot of sense.
  - krapp 4y ago
    >That's hardly more efficient than going through the system's windowing system. My intuition says otherwise but I admit I don't have math on hand to back it up.
    - flohofwoe 4y ago
      Ok it's most likely slightly slower, but not enough that it matters. Frame latency might actually be lower though if the result doesn't need to go through a swapchain AND the window system composer.
  - zozbot234 4y ago
    Most vintage systems use something way more complex than a pure CPU-controlled framebuffer for graphics. They generally have some sorts of pre-defined "tiles" used to implement a fixed-width character mode, with the addition of a limited number of "sprites" overlaid in hardware. These video modes could be implemented efficiently by modern GPU's.