Slashdot Mirror
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."
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."
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...
Looking for people to chat about multicopters, coding, music. skype: gtsiros