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 ?
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.
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://gitlab.com/tkchia/GW-BASIC
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.
So no reason not to use X/Wayland since it's just more comfortable to develop for.
It looks like at least some versions of Allegro and SDL supported it as a backend.
Nice breadcrumb: https://web.archive.org/web/19991008210746/http://webpages.m...
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.
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.
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.