A Very Detailed Dissection of a Frame From DOOM (adriancourreges.com)

DOOM 2016 "cleverly re-uses old data computed in the previous frames...1331 draw calls, 132 textures and 50 render targets," according to a new article which takes a very detailed look at the process of rendering one 16-millisecond frame. An anonymous Slashdot reader writes: The game released earlier this year uses the Vulkan API to push graphics quality and performance at new levels. The article sheds light on rendering techniques, mega-textures, reflection computation... all the aspects of a modern game engine.
Some of the information came from "The Devil is in the Details," a July presentation at the SIGGRAPH 2016 conferences on graphics by Tiago Sousa, id's lead renderer programmer, and senior engine programmer Jean Geffroy. (And there's also more resources at the end of the article, including a July interview with five id programmers by Digital Foundry.) "Historically id Software is known for open-sourcing their engines after a few years, which often leads to nice remakes and breakdowns," the article notes. "Whether this will stand true with id Tech 6 remains to be seen but we don't necessarily need the source code to appreciate the nice graphics techniques implemented in the engine."

Comments

Re: No Carmack?

[Anonymous Coward]

Carmack is at Oculus now...

And Grand Theft Auto V and Supreme Commander...

[Anonymous Coward]

The same site also posted detailed looks at Grand Theft Auto V, Supreme Commander, and Deux Ex: Human Revolution earlier this year.

Wow.

[basecastula]

Very detailed indeed. Definitely over my head.

Re:No Carmack?

[antdude]

Nope. He pursued in other projects. Not everyone does the same thing forever.

Not really groundbraking

[gTsiros]

This kind of tricks were more popular in the older days when you couldn't even wipe a screenful of data in one frame-time, much less render a frame in a straightforward matter

Today most coders rely on hadware speed to get away with things

Go code a realtime 60fps game on a 4 MHz cpu with a 15-cycle byte read from memory, you'll have to figure out the weirdest shit

compiled sprites, software pipelining, incremental rendering...

Re: Not really groundbraking

[gTsiros]

I have a small shell script that does it for me
now get off my subnet
(i'm 36...)
(and i missed an 'e')

Re:Not really groundbraking

[UnknownSoldier]

You'll probably enjoy this ... it shows how SQ3 rendered a frame piece by piece

Space Quest III art timelapse
https://www.youtube.com/watch?...

Re:Not really groundbraking

[blocked_lol]

I can't tell if you're complimenting the Doom 2016 programmers or trying to say this stuff is easy compared to Back In The Day.

I *can* tell you that this stuff is not easy *at all*, and the fact that the game gets such good performance across such a wide range of hardware, while still maintaining a high level of visual fidelity on lower end machines, is impressive in its own right.

That they put in the effort to write a Vulkan renderer is itself proof that they're trying to squeeze as much performance out as possible, and not just lazily relying on the hardware to make up for slow/lazy/incompetent programming.

Re:Not really groundbraking

[Lisandro]

I *can* tell you that this stuff is not easy *at all*, and the fact that the game gets such good performance across such a wide range of hardware, while still maintaining a high level of visual fidelity on lower end machines, is impressive in its own right.

This. The most impressive thing about Doom 2016 its not the way it looks (honestly, there're plenty of AAA games with comparable, if not better, graphics) but that it runs silk smooth on relatively underpowered hardware. You can consistently get 60 fps at 1440p on low-tier GPUs.

Re:Not really groundbraking

[gTsiros]

the mos 6510 in the c64 can do read-modify-write in 6 cycles and it is somewhat pipelined.

the saturn doesn't have such an addressing mode.

you would have to read a byte (15 cycles), load a byte constant in another register (5 cycles) and write the result (14 cycles)

so while the c64 is clocked lower, it can do it in 6 microseconds, the saturn needs 7.25 μs

plus, the MOS 6510 has lots *lots* more addressing modes than the saturn. There is no pre-post increment, no offsets, etc

You don't know what you are talking about. Go away.

Re:Not really groundbraking

[gTsiros]

i even forgot to modify the value, which assuming is an arithmetic ALU op, would take 5 cycles, so the correct total duration is 8.5 μs, not 7.5 μs

Re:Not really groundbraking

[TheRaven64]

ARM's Mali GPU also does a trick in hardware that's similar to one of the things listed here. It stores a hash of every square region in the frame buffer and only writes back the new value to RAM if it's changed. The power cost of communicating with the DRAM is far more than the cost of computing the hash, so if you get a modest hit rate then you end up saving a noticeable amount of power.

Re:Not really groundbraking

[Nemyst]

Eh. Old games had to work around poor performance and lack of hardware acceleration, but their graphical fidelity goal was also laughably low. As long as pixels were on the screen in what roughly looked like something, it was good to go. Today's games could never work without graphics acceleration, but that isn't to say they're easy or simple to do. It's fine if you don't grasp the algorithmic complexity of things such as texture atlasing or tiled rendering, but don't imply that they're easy stuff compared to the old 2D stuff.

Re: I'm loving the Vulkan patch

[Anonymous Coward]

What is bottom-tier about a high-end gtx 970 ?

Re: No Carmack?

[110010001000]

This is true for some software, but not all. Not all types of software are equal. Games take a lot of money and people to produce. It is unlikely that "free" software will succeed in that area. However for IMPORTANT software, the GPL works because there is some funding available. There is one saving grace here: digital computers are not going to improve at the same rate they have in the past. The AAA titles you play now will be very similar to the ones you play 10 years from now, simply because processor speed isn't increasing at a high rate.