[qsera]

One thing that was nice about the graphics programming those days was that when you drew something on the screen, it remained there until your program erased it.

This means that you could create cool looking graphics easily. For example, you can just compute the points of a circle and draw the points one by one, and in the screen it will show a full circle being drawn.

"Modern" graphics libs (even SDL I think), made this impossible by having redraw the whole screen every frame so that now my program has to remember all the points there the program drew before to get the same effect.

The former workflow made graphics programming so much fun for me and I find the modern "fast rendering pipeline" boring and not a lot of fun.

Things like that, one by one, have sucked the whole fun out of computing.

[PaulDavisThe1st]

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.

[qsera]

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.

[bitwize]

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.

[PaulDavisThe1st]

AFAIK, SDL does not provide both modes. I don't know which mode it is designed around.

[mike_hock]

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.

[rhyperior]

Your post just clicked something from of a deep memory into place.

In the early 80s when the IBM PC hit the scene, Hercules had a graphics card that was amazing and offered better than CGA graphics. I was plinking on it at my dad’s friend’s house, drawing circles and stuff, and on HIS computer the graphics were retained. I had to figure out how to clear the screen, whereas on mine, not having the Hercules card, it wasn’t retained. Never understood what was happening until now.

[Jtsummers]

It's been a while (over a decade now), but I think SDL allows you to leave the contents on the screen if you don't call the clear function before you render new content. I don't know how well that'd work with resizing a window though.

[qsera]

I think it works like that if acceleration is no enabled. But even then I think it does not work reliably..I might be missing something though.

[PhilipRoman]

SDL is a relatively high level API and framebuffer style graphics work fine on it. I think there are some edge cases for X11 with non-compositing window manager where you will get interesting glitches if the window moves.

[bitwize]

Historically these weren't "edge cases"; all windowed environments sent a "redraw yourself" event to a window when it needed to be shown after having been covered up, that was handled specially by the application. In X11 this was an Expose event, in Windows this was called WM_PAINT. If you had a fancy X server back in the day, you could enable backing store; this kept a framebuffer of the window contents in memory even if the window itself was covered up that could be quickly restored upon exposure. This was incredibly useful and made redraws fast and glitch-free, but back in the days when RAM was expensive (you know, unlike today...) it could not be relied on in all X implementations. Compositing WMs have the equivalent of backing store for all windows, all the time.