Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Graphics First Person Shooters (Games) Quake Games

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

Posted by EditorDavid from the weaponizing-demons-for-a-brighter-tomorrow dept.
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."
This discussion has been archived. No new comments can be posted.

A Very Detailed Dissection of a Frame From DOOM More

A Very Detailed Dissection of a Frame From DOOM

Comments Filter:

  • And Grand Theft Auto V and Supreme Commander... (Score:5, Informative)

    by Anonymous Coward on Sunday September 11, 2016 @08:57PM (#52868643)
    The same site also posted detailed looks at Grand Theft Auto V, Supreme Commander, and Deux Ex: Human Revolution earlier this year [adriancourreges.com].

  • Wow. (Score:3)

    by basecastula ( 2556196 ) <<moc.liamg> <ta> <mf.esacesab>> on Sunday September 11, 2016 @09:23PM (#52868723)
    Very detailed indeed. Definitely over my head.

    • Re: (Score:1)

      by donaldm ( 919619 )

      Very detailed indeed. Definitely over my head.

      Reading the article for the first time it was definitely over my head but I have played the PS4 Doom demo. Normally I dislike FPS games and especially multiplayer ones, but with Doom I actually found the story mode (What story? Just kill daemons) great fun to play.

      • Re: (Score:1)

        by aliquis ( 678370 )

        Reading the article for the first time it was definitely over my head but I have played the PS4 Doom demo. Normally I dislike FPS games and especially multiplayer ones, but with Doom I actually found the story mode (What story? Just kill daemons) great fun to play.

        Shadow warrior next?

        (Support Rise of the triad too ;D)

  • Not really groundbraking (Score:5, Interesting)

    by gTsiros ( 205624 ) on Sunday September 11, 2016 @10:31PM (#52868859)

    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: (Score:1, Funny)

      by Lunix Nutcase ( 1092239 )

      Cool story, gramps. Need someone to come over and reattach the onions to your belt?

    • Re: (Score:2, Interesting)

      by UnknownSoldier ( 67820 )

      > compiled sprites,

      You used to hang out on rec.games.programmer in the 90's as well ? :-)

      90% of the /. readers probably don't even have a clue what that is. :-/

      Ah, the days of self-modifying code to get high performance ...

      • I couldn't remember my old account so I connected my facebook just to be able to say: YES YES YES omg did the word "compiled sprites" bring me back to newsgroups and dreams directed by Michael Abrash and such :)

    • Re:Not really groundbraking (Score:5, Interesting)

      by UnknownSoldier ( 67820 ) on Monday September 12, 2016 @01:35AM (#52869243)

      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?... [youtube.com]

      • Re: (Score:2)

        by Sowelu ( 713889 )

        That's a huge mindtrip. Why on earth did they store it like that I wonder? I would have assumed that RLE was been more efficient in space and render speed! I could see that being a format that the artists used for work in progress, but why use that in the final version? I'm incredibly curious now.

        • Re: Not really groundbraking (Score:1)

          by Anonymous Coward

          Guess: vectors take up even less space, and can be scaled at no extra cost.

          • Re: (Score:2)

            by Sowelu ( 713889 )

            After looking I was surprised that yes, they are smaller! Fascinating! Even, I presume, if you allow extra "colors" for stippling. But I have to disagree on the scaling thing. All the SCI games I've seen that were upscaled with third party tools look kinda... not good. Mainly when artists scribble with lines that produce good effects in the native resolution, but look like crayons scrawls if you scale them up to be rounded and smooth.

            Oh well. I guess some games probably look better than others (yes Sp

        • > Why on earth did they store it like that I wonder?

          It was optimized for space.

          Remember Sierra started back on the Apple ][ where disk space was limited: 140 KB. When they switched to the IMB PC/jr storing a full 320x200 = 64,000 pixels is a _minimum_ of 8K compared to few hundred bytes to store the same scene.

          > I would have assumed that RLE was been more efficient in space and render speed!

          While RLE is extremely fast to decode it is still bloated compared to a poly-lines and/or polygon fill.

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

        Interesting... I wonder if this means SQ3's graphics are, theoretically at least, resolution-free? They seem to be some kind of vector graphics, after all.

        • > I wonder if this means SQ3's graphics are, theoretically at least, resolution-free?

          Yes, for the most part. It would be trivial to "normalize" the coordinates and then up-sample without general loss of precision.
          As long as the final resolution isn't too large (*) the errors wouldn't be (too) noticeable.

          (*) I'm not sure at what resolution the precision errors would start becoming noticeable. I would surmise that a scale factor of < 200 would be OK.

      • Re: (Score:1)

        by phorm ( 591458 )

        I wonder if that's a deliberate slowdown or just a really old PC. I seem to remember seeing screen paints like that sometimes on really slow hardware (not quite that slow, but you could see the paint-in happen).

    • Re:Not really groundbraking (Score:5, Insightful)

      by blocked_lol ( 4634223 ) on Monday September 12, 2016 @01:36AM (#52869251)

      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 (Score:5, Interesting)

        by Lisandro ( 799651 ) on Monday September 12, 2016 @04:45AM (#52869541)

        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.

      • Doom has pretty high system requirements though, even though it doesn't look like anything special. If we're being honest, Carmack's technowizardry was only really relevant in the early 90s when people wanted to play FPS games on computers bought for DOS spreadsheets. The 3D accelerator made idtech largely obsolete, only remembered by inherited code in the likes of Source and Call of Duty. And they became obsolete as game developers the second Half-Life came out. Romero was right, it was about design not th

    • 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: (Score:3)

      by Nemyst ( 1383049 )
      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

    • Back in the original Doom you would need a 386 with at least 25mhz 4 megs of Ram and a VGA display. It usually took a while to render a full screen display. So there were many tricks with pallet color changing, pattern overlaying, and using a set of pre rendered material.

      Sierra adventure games which were at its heyday during this time. Which offered a lot more detailed graphics, at the expense of waiting for every screen to load. So the excitement was getting to a new screen, each one rendered in high q

  • I'm loving the Vulkan patch (Score:1)

    by Anonymous Coward
    I've been Playing Doom at 1440p with maxed out settings on a three year old graphics card and consistently getting over 100 frames per second. I was lucky to keep it running a solid 60 FPS at those settings before the Vulkan patch. Seems like upgrading to 4K gaming will be happening sooner than I thought it would so long as more studios are able to replicate the success of Doom rendering via Vulkan.

    • I amazed at its 4K performance on a bottom-tier GTX 970. It runs incredibly well.

      No Man's Sky, on the other hand — yikes.

  • Zombies (Score:1)

    by Anonymous Coward

    Moribund artificially sustained tech, big fat evil hardware and software money lusting forces. How long until men recognize the utter superiority of the octree based work of Donald J. Meagher: http://goo.gl/sdjXVG

    Bruce R. Dell's voxel rasterizer is a rediscovery of Meagher's late '70s early '80s discoveries. He had the idea of combining division hungry perspective projection with division free orthographic projection when the difference is negligible enough (e.g., not representable on a certain pixel grid):

  • So dark you can see jack shit. You can even compare it with old 1992 Doom because they included parts of its levels in easter eggs. They're so bright that you can actually see where you're going. And among 1992 games original Doom was pretty dark. If things will keep going like that then soon we'll have to be satisfied with game presenting us a black screen and calling it a day. Rendering black screen can be implemented to be blazing fast too!
  • Edge of technology. Marvelous details. And all in vivid shades of dark brown. Yay!

  • It wouldn't be complete without including the time and resources taken by Denuvo malware.

Slashdot Top Deals

news: gotcha

Close