Framebuffer management on modern software rendered source ports

Hello everybody,

I'm going to ask a, maybe, trivial question, but I would like to have a bird's view before looking into it.

I am a little familiar with some parts of the Doom source code, but the last time I studied it heavily was when DOSDoom still ruled (go figure!).

I wonder how exactly Chocolate Doom and other current ports (such as Eternity) do their framebuffer thins. I assume all of the more modern, non 3D accelerated ports are based on SDL, so I wonder how they model their framebuffer, how this FB is converted to an SDL surface, and at which point, and also if there are some caveats to have into account.

Simply pointing me to the correct set of files in the sources (no matter in which modern port) would suffice, since I'm right now far from home and I plan on doing it when I get back, I hope some of you can point me in the right direction.

Thanks.

In Eternity the buffers the game draws into directly are generally separate from whatever low-level device exists, in order to allow for full abstraction of the "blit" process.

High level video is initialized here:
https://github.com/team-eternity/eternity/blob/master/source/v_misc.cpp

The raw screens[0] array is also wrapped with a VBuffer object, which is implmented here:
https://github.com/team-eternity/eternity/blob/master/source/v_buffer.cpp

Low-level video on the other hand is implemented with classes that derive from the generic HALVideoDriver interface, which is implemented here:
https://github.com/team-eternity/eternity/blob/master/source/hal/i_video.cpp

There are currently two child classes of this interface, the "SDL" software renderer, and the "SDL GL2D" hardware renderer:

• https://github.com/team-eternity/eternity/blob/master/source/sdl/i_sdlvideo.cpp
  
• https://github.com/team-eternity/eternity/blob/master/source/sdl/i_sdlgl2d.cpp
  

In both of these drivers, the high-level screens[0] pointer points to the contents of an 8-bit paletted SDL software surface that is allocated by SetPrimaryBuffer. In the software backend, regardless of the actual screen format, the blit from this surface to the display in the low-level code is accomplished using SDL_BlitSurface.

In the GL backend, screens[0] is, depending on whether or not the ARB PBO extension is available and enabled, converted into a 32-bit ARGB texture and uploaded to the video card in one of two manners (glTexSubImage2D if no PBO in use, or glMapBufferARB with a direct blit into video memory).

Thank you for the detailed explanation, Quasar. This will definitely answer many of my questions.

Unrelated to this, I'm going to abuse your kindness a little more... since you know everything about Eternity (quite logical... ;)), where can I start to dig in order to see the Cardboard renderer? I'm interested in the interface between the old code and the new renderer.

I assume Cardboard is a software-only renderer?

I have derailed my own post...

LordMeow said:

Thank you for the detailed explanation, Quasar. This will definitely answer many of my questions.

Unrelated to this, I'm going to abuse your kindness a little more... since you know everything about Eternity (quite logical... ;)), where can I start to dig in order to see the Cardboard renderer? I'm interested in the interface between the old code and the new renderer.

I assume Cardboard is a software-only renderer?

I have derailed my own post...

Most of the Cardboard related changes are in r_segs.cpp, where the projection of linedefs is accomplished through a proper 3D projection op rather than the angular mess that the vanilla renderer used. There were also changes, some unrelated to the core of Cardboard itself, in r_bsp, r_sprites, and r_plane. The more stable flat rendering is thanks to changes in r_span, but again that's technically separate from the core of what SoM called "Cardboard".

You may find the changes underwhelming; not everything the stand-alone Cardboard renderer was capable of has yet made it into EE thanks to how difficult supporting 32-bit color is (I have some designs on it that have not yet come into fruition).

Do you mean that Cardboard existed as a separate renderer independent of Eternity?. I had no idea about that, is there any full implementation? Or at least just the renderer?

Al ways thought that Cardboard was started and then merged into Eternity as its renderer.

Anybody knows if there is a standalone implementation of the Cardboard renderer?

As far as I know Cardboard was developed within the context of Eternity and I don't believe it existed as a standalone renderer (what would it render other than a id Tech 1 format map?).

DaniJ said:

As far as I know Cardboard was developed within the context of Eternity and I don't believe it existed as a standalone renderer (what would it render other than a id Tech 1 format map?).

This gave me a clue:

Quasar said:

You may find the changes underwhelming; not everything the stand-alone Cardboard renderer was capable of has yet made it into EE thanks to how difficult supporting 32-bit color is (I have some designs on it that have not yet come into fruition).

And that's why I am asking. But I'm afraid only Quasar can give us the answer on this one.

Besides, there is no problem in programming a standalone renderer for a given map format. I have done that myself with Quake maps, just for fun, and I am sure that I have not done the same renderer as John Carmack did (because I have also studied it and because I went straight to Direct3D, to learn DirectX 9).