4 ms·

What realmode in DOS offered was a boon for beginner programmers, i wonder has anyone done something similar in linux framebuffer without using X server. Perha

What realmode in DOS offered was a boon for beginner programmers, i wonder has anyone done something similar in linux framebuffer without using X server. Perhaps a game in /dev/fb0 ?

endgame 2y ago
I think the search term you want is "svgalib" - https://en.wikipedia.org/wiki/SVGALib https://en.wikipedia.org/wiki/SVGALib It looks like at least some versions of Allegro and SDL supported it as a backend.
- matttproud 2y ago
  One of the original Quake I implementations — as in authored by Carmack and Taylor themselves — used SVGAlib as a backend. I remember this because of having to configure my mouse to co-exist with GPM in some file in /etc for svgalib. Nice breadcrumb: https://web.archive.org/web/19991008210746/http://webpages.mr.net/bobz/howto/Quake-HOWTO-2.html#ss2.6 https://web.archive.org/web/19991008210746/http://webpages.m...
- pankajdoharey 2y ago
  Allegro thats a name i have not heard since 2002 i think. Kids these days would know SDL, DirectX , LOVR or Raylib.
pajko 2y ago
https://en.wikipedia.org/wiki/DirectFB https://en.wikipedia.org/wiki/DirectFB
- pankajdoharey 2y ago
  How do these Nintendo handhelds work? i thought they use some kind of framebuffer for such great performance for the substandard quality hardware they use. Every generation of Nintendo chip is way behind Apple and Android systems yet they achieve remarkable performance.
  - pjmlp 2y ago
    Yes they use some kind of framebuffer, just like 8 and 16 bit home consoles. They also used plenty of Assembly programmer and special graphics units, the console percursors of GPUs. However since the N64 that they use graphics APIs like everyone else, GBI, GX, GX2 and nowadays NVN. For porting purposes, the Switch also supports GL 4.6 and Vulkan. Other than that, there is also a performance culture, and not using generic game engines.
    - wk_end 2y ago
      The 8 and 16 bit home consoles did not use a frame buffer. The NES had 2KB of VRAM and an output resolution of 256x240 - even if you only had 1bpp it wouldn’t fit. These consoles - along with everything handheld up until the 3DS - create images out of scrolling layers of background tiles and freely positionable sprites. You don’t have any kind of per pixel access, although you can manipulate the state of the hardware as the screen is being drawn to get unorthodox effects.
      - pezezin 2y ago
        The GBA had 6 videos modes: 4 of them were tile based, and the other 3 were framebuffer based. That's how games like Doom could run on the GBA.
jchw 2y ago
Others have pointed out DirectFB and SVGALib. Both very interesting. SVGALib was supported by a lot of commercial Linux game ports in the earlier days, whereas DirectFB was possibly one of the most serious alternatives to X11, although I think like most such projects it mainly found use in embedded devices (Coincidentally, Wayland seems to have finally unified some of the "embedded" and desktop use cases.) These days SVGALib doesn't work and fbdev is deprecated. However, the "next-generation" Linux graphics stack can achieve a fairly similar goal using the DRM/KMS APIs, albeit it's definitely a lot more work if you just want a framebuffer. On the other hand, though, it's relatively straight-forward to get an EGL context and start doing hardware accelerated things. Maybe that takes some of the fun out of it, but I think it's pretty cool.
pjmlp 2y ago
Yes, in the early days, as many others have replied. What most have missed is that those libraries usually required root access, or setuid, unless you want to go clever with group permissions, which no one did.
2mlWQbCK 2y ago
Currently reading The BLUE Book About GW-BASIC and QuickBasic (Thomas C. McIntire, 1991, https://github.com/robhagemans/hoard-of-gwbasic https://github.com/robhagemans/hoard-of-gwbasic). It is full of fascinating and somewhat horrible advice. For rendering text-mode user interfaces the author recommends having a ~4000 bytes binary file saved that is just BLOADed straight from disk into graphics RAM (in text-mode that sets all the text and attributes/colors for the screen). Tricks like that would probably never cross my mind, being used to having to load some library to draw anything to a screen. I discovered just some day ago pc-basic is a really impressive project. pip install pcbasic gives you a portable python-implementation of essentially GW-BASIC, running in a terminal or graphics window. But you can of course also grab the MIT-licensed GW-BASIC 1.0 that Microsoft released a few years ago (and that TK Chia modified to make it possible to build) and run that in DOSBox. I am having a lot of fun with both of those. https://github.com/robhagemans/pcbasic https://github.com/robhagemans/pcbasic https://gitlab.com/tkchia/GW-BASIC https://gitlab.com/tkchia/GW-BASIC
zozbot234 2y ago
Doing graphics via the framebuffer is really slow on modern hardware. Even if you want true pixel-perfect graphics (something that modern 3D-rendering API's aren't easy to use for, hence where simply relying on the framebuffer is the most obvious approach) it's just far better to use GPU compute. Actually even simple GPU compositing (which can be feasibly made pixel-perfect, as shown by its routine use w/ modern desktop environments) gives you an unlimited amount of arbitrarily-large "sprites" - way better than what you get with pure CPU rendering on a framebuffer, and something which can be quite useful in a real program.
- kbolino 2y ago
  Yeah, I think it should be emphasized that the framebuffer (in this sense) is actually an outdated abstraction and not the "low-level" or "raw" access to the hardware that one might naively expect it to be.
dale_glass 2y ago
The X server is mostly irrelevant, these days you'd use something like SDL for a simple 2D game, which abstracts it away entirely and works just the same on the framebuffer and under X. So no reason not to use X/Wayland since it's just more comfortable to develop for.

What realmode in DOS offered was a boon for beginner programmers, i wonder has anyone done something similar in linux framebuffer without using X server. Perhaps a game in /dev/fb0 ?

endgame 2y ago

I think the search term you want is "svgalib" - https://en.wikipedia.org/wiki/SVGALib https://en.wikipedia.org/wiki/SVGALib It looks like at least some versions of Allegro and SDL supported it as a backend.

matttproud 2y ago
One of the original Quake I implementations — as in authored by Carmack and Taylor themselves — used SVGAlib as a backend. I remember this because of having to configure my mouse to co-exist with GPM in some file in /etc for svgalib. Nice breadcrumb: https://web.archive.org/web/19991008210746/http://webpages.mr.net/bobz/howto/Quake-HOWTO-2.html#ss2.6 https://web.archive.org/web/19991008210746/http://webpages.m...
pankajdoharey 2y ago
Allegro thats a name i have not heard since 2002 i think. Kids these days would know SDL, DirectX , LOVR or Raylib.

pajko 2y ago

https://en.wikipedia.org/wiki/DirectFB https://en.wikipedia.org/wiki/DirectFB

pankajdoharey 2y ago
How do these Nintendo handhelds work? i thought they use some kind of framebuffer for such great performance for the substandard quality hardware they use. Every generation of Nintendo chip is way behind Apple and Android systems yet they achieve remarkable performance.
- pjmlp 2y ago
  Yes they use some kind of framebuffer, just like 8 and 16 bit home consoles. They also used plenty of Assembly programmer and special graphics units, the console percursors of GPUs. However since the N64 that they use graphics APIs like everyone else, GBI, GX, GX2 and nowadays NVN. For porting purposes, the Switch also supports GL 4.6 and Vulkan. Other than that, there is also a performance culture, and not using generic game engines.
  - wk_end 2y ago
    The 8 and 16 bit home consoles did not use a frame buffer. The NES had 2KB of VRAM and an output resolution of 256x240 - even if you only had 1bpp it wouldn’t fit. These consoles - along with everything handheld up until the 3DS - create images out of scrolling layers of background tiles and freely positionable sprites. You don’t have any kind of per pixel access, although you can manipulate the state of the hardware as the screen is being drawn to get unorthodox effects.
    - pezezin 2y ago
      The GBA had 6 videos modes: 4 of them were tile based, and the other 3 were framebuffer based. That's how games like Doom could run on the GBA.

jchw 2y ago

Others have pointed out DirectFB and SVGALib. Both very interesting. SVGALib was supported by a lot of commercial Linux game ports in the earlier days, whereas DirectFB was possibly one of the most serious alternatives to X11, although I think like most such projects it mainly found use in embedded devices (Coincidentally, Wayland seems to have finally unified some of the "embedded" and desktop use cases.) These days SVGALib doesn't work and fbdev is deprecated. However, the "next-generation" Linux graphics stack can achieve a fairly similar goal using the DRM/KMS APIs, albeit it's definitely a lot more work if you just want a framebuffer. On the other hand, though, it's relatively straight-forward to get an EGL context and start doing hardware accelerated things. Maybe that takes some of the fun out of it, but I think it's pretty cool.

pjmlp 2y ago

Yes, in the early days, as many others have replied. What most have missed is that those libraries usually required root access, or setuid, unless you want to go clever with group permissions, which no one did.

2mlWQbCK 2y ago

Currently reading The BLUE Book About GW-BASIC and QuickBasic (Thomas C. McIntire, 1991, https://github.com/robhagemans/hoard-of-gwbasic https://github.com/robhagemans/hoard-of-gwbasic). It is full of fascinating and somewhat horrible advice. For rendering text-mode user interfaces the author recommends having a ~4000 bytes binary file saved that is just BLOADed straight from disk into graphics RAM (in text-mode that sets all the text and attributes/colors for the screen). Tricks like that would probably never cross my mind, being used to having to load some library to draw anything to a screen. I discovered just some day ago pc-basic is a really impressive project. pip install pcbasic gives you a portable python-implementation of essentially GW-BASIC, running in a terminal or graphics window. But you can of course also grab the MIT-licensed GW-BASIC 1.0 that Microsoft released a few years ago (and that TK Chia modified to make it possible to build) and run that in DOSBox. I am having a lot of fun with both of those. https://github.com/robhagemans/pcbasic https://github.com/robhagemans/pcbasic https://gitlab.com/tkchia/GW-BASIC https://gitlab.com/tkchia/GW-BASIC

zozbot234 2y ago

Doing graphics via the framebuffer is really slow on modern hardware. Even if you want true pixel-perfect graphics (something that modern 3D-rendering API's aren't easy to use for, hence where simply relying on the framebuffer is the most obvious approach) it's just far better to use GPU compute. Actually even simple GPU compositing (which can be feasibly made pixel-perfect, as shown by its routine use w/ modern desktop environments) gives you an unlimited amount of arbitrarily-large "sprites" - way better than what you get with pure CPU rendering on a framebuffer, and something which can be quite useful in a real program.

kbolino 2y ago
Yeah, I think it should be emphasized that the framebuffer (in this sense) is actually an outdated abstraction and not the "low-level" or "raw" access to the hardware that one might naively expect it to be.

dale_glass 2y ago

The X server is mostly irrelevant, these days you'd use something like SDL for a simple 2D game, which abstracts it away entirely and works just the same on the framebuffer and under X. So no reason not to use X/Wayland since it's just more comfortable to develop for.