Both so-called "retained" and "immediate" mode graphics libraries continue to exist for most platforms, and you can choose to use whichever one you prefer.
Both so-called "retained" and "immediate" mode graphics libraries continue to exist for most platforms, and you can choose to use whichever one you prefer.
I have looked it up in the past, and I have looked it up now, but I cannot find a reliable documentation that describes it.
For example, do you know what combination of flags listed here https://documentation.help/SDL/sdlsetvideomode.html would do the trick? Or anything that is not listed there would also help.
AFAIK, SDL does not provide both modes. I don't know which mode it is designed around.
SDL retains everything you've drawn to the screen in backing store. You need to do an SDL_Flip (1.2) or SDL_RenderPresent/SDL_UpdateWindowSurface (2.0) to commit what's in the back buffer to the screen.
I mean, you can obviously just draw to your own in-memory framebuffer that you never erase and then copy that to the physical backbuffer every frame. But there's no point in doing it that way when you can easily afford to re-render everything.
Having a limited budget of how much of the screen you can update in 17ms made for fun programming challenges, as did other limitations of the old hardware. Game developers came up with ingenious ways to leverage the hardware and make it seem like it could do more than it actually could.
Scanline-accurate switching of video attributes while wasting no clock cycles doing everything else and without a timer. That kind of stuff.
Programming to artificial self-imposed limits is not the same.