ZDoom rendering piece-by-piece

[edward850]

You've probably seen how Doom renders a scene. But what about ZDoom, and its vastly more complex maps? Watch and learn how the software renderer constructs everything piece by piece.

(This isn't quite pixel by pixel, because if it was we'd be here forever watching it generate a 1920x1080 scene, with overdraw. That's not fun.)

Maps in order of appearance:
CyberCrime3 - Map04
Abandonedrig (CutmanMike)
KDIZD - Z1M8
Back to Saturn X E1 - Map01
Frozen Time - Map01
DWFORUMS3
KDIZD - Z1M5
ZArena - Map01
ZDoom Community Map Project 2
Crusharghs ( http://crantime.org/wads.html )
KDIZD - Z1M10
Vela Pax - Map05

[Sgt. Shivers]

Neat stuff!

[Xeotroid]

This is amazing. How does Doom decide which walls / floors to draw first? It seems to be somewhat random, even though the original Doom draws walls closest to player first (according to Doom wiki).

[Blzut3]

It appears random since sorting only needs to be done for segments that touch the same column of pixels (which sets up the clipping region for when the farther segment is drawn).

[Zanieon]

Very impressive, this reminds me of the VFX Breakdowns that Industrial Light & Magic likes do on their Youtube channel.

[Siberian Tiger]

Very interesting, thanks for sharing this!

[Kappes Buur]

ZDoom rendering piece-by-piece

What wizardry did you use to accomplish this?

[edward850]

Very careful rendering page flips around select rendering calls. Each time rows or columns drew (usually after batch calls to improve time), it would then flip to DirectX, finish the frame, reset, sleep (1-10ms), then relock and continue the scene. Very quick and dirty. That's also why you see the HUD display instantly, as that's all done on the hardware layer.

I could have done it pixel by pixel using the C renderer, but that would be a minimum of 2073600 draw calls. The overdraw (Frozen Time, 9 minutes in, for example) would have made that much worse. So I just did everything a couple of levels beforehand.

[GooberMan]

I did something quite similar with Chocolate Doom's renderer, except since it renders to a buffer in main memory I just dumped it to a PNG after each draw call.

The first instance of someone doing such a thing happened in 2011.

[ibm5155]

Neat stuff, I Always liked to see how the engine Works "by the looks". Could the sme thing be done in gzdoom?

[edward850]

It's just polygons assigned by a BSP. Not exactly something we haven't seen before.

[ibm5155]

Hmmm, but the frame redone all the time like in zdoom or all the geometry created is saved on gpu memory to save some performance?
I'm still curious about the difference btw vavoom and gzdoom, at the end, they do the same thing right? (polygon meshes)

[edward850]

Hmmm, but the frame redone all the time like in zdoom or all the geometry created is saved on gpu memory to save some performance?

Well I don't see how you would think static meshes would work in a world that can be updated anywhere at any time. VBOs are used to optimize the CPU->GPU transfer time, however.

[enderkevin13]

That was hot.
10/10 would bang again. -Everyone

[Hindsight2020]

Thanks for sharing this edward850.

This an insane amount of work... and if I understand it correctly, it goes through this every time a frame is drawn? So like 30+ times a second?