5 ms·
Doom engine code review
- light3 16y agoLink to nice doom port at bottom: http://www.chocolate-doom.org/wiki/index.php/Chocolate_Doom http://www.chocolate-doom.org/wiki/index.php/Chocolate_Doom
- thibaut_barrere 16y agoThe first (and only one, currently) comment brought me back years ago! A major performance trick back then was to ensure the code and data would remain into the (very small) cache, as well as preferring structures that would be read in order. ==================== "Because walls were rendered as columns, wall textures were stored in memory rotated 90 degrees to the left. This was done to reduce the amount of computation required for texture coordinates" The real reason is faster memory acces when reading linearly on old machine, less cpu cache clear. It's an old trick used on smooth rotozoomer effect in demo scene year ago.
- thedjinn 16y agoActually, rotating a texture 90 degrees in memory when making a rotozoomer still results in large amounts of cache misses depending on the current rotation angle. In order to get a smooth rotozoomer effect you have to use a technique called block rendering. This means you divide the image in square cells and render these one by one. Because the pixels in the cell are always near eachother you can reduce cache misses. There is an old snippet from Niklas Beisert floating around the web that explains exactly how this works.
- thibaut_barrere 16y agoYup :) Here's the code if someone is interested: ftp://latvia.tucows.com/pub/mirror/x2ftp/msdos/programming/demosrc/pasroto.zip (I managed to find it back thanks to hornet.org) Edit: you can also check out the list at ftp://latvia.tucows.com/pub/mirror/x2ftp/msdos/programming/demosrc/00index.txt
- dman 16y agoThanks for digging this up. Much appreciated.
- CamperBob 16y agoActually, the real reason was that Doom ran in "Mode X", where it was actually faster to rasterize vertical strips rather than horizontal ones. This worked out especially well in Wolf3D and Doom, since perspective correction in the vertical direction was never needed.
- simcop2387 16y agoActually it didn't it ran in the bog standard 320x200 256 color mode. mostly because using "mode x" back then wasn't as widely supported on lots of low end machines. mov ax, 13h int 10h ah those were the days.
- CamperBob 16y agoAfraid not. (http://www.idsoftware.com/wolfenstein3dclassic/wolfdevelopment.htm http://www.idsoftware.com/wolfenstein3dclassic/wolfdevelopme..., "Programming notes")
- andrewf 16y agoLooking at the Doom source, it seems that the actual 3D game view was rendered into a linear buffer, and subsequently blitted onto the mode X surface. Some UI elements went straight to the screen. (The DOS Doom source was never publicly released, just the Linux port, but there are remnants of some DOS code in the archive. I'm specifically looking at R_DrawSpan in README.asm and V_DrawPatchDirect in v_video.c)
- simcop2387 16y agoThat may be where my misunderstanding came from then, didn't realize the original dos version wasn't what was released.
- hapless 16y agoIt's amazing that this would run halfway well on a 33 MHz 486. Doom had a 35 fps cap, and ran at 320x240 (square pixels): 2.7 million pixels per second at 35 fps (the cap). 1.4 million pixels per second at 18 fps (~50% of cap). At the more realistic target of 18 fps, you have 24 clock cycles per pixel. A 486 averaged about 0.8 instructions per clock, so you're looking at 19 instructions per pixel. With a 33 MHz memory bus and the DRAM of the day, you're looking at about 5 clocks for memory latency. That looks like an upper bound of no more than 4 memory operations per pixel. A convincing 3d renderer averaging 19 instructions and 4 memory operations per pixel. And we're not even counting blit/video delays here. Good lord is that savage optimization work. Carmack is famous for a reason. P.S. The really scary thought is that Doom would hypothetically run on any 386 machine -- can you imagine painting e.g. 160x120 on a cacheless 20 MHz 386 laptop?
- grimlck 16y agoDoom actually ran at 320x200 Good points regardless though.
- hunterjrj 16y agoIf I recall correctly, you had to shrink the view port on lower-end 486s for playable framerates. Also, the status bar shrank the area to be rendered to some extent. Your point still stands, just pointing out that the target area for rendering was often smaller than 320x240.
- rograndom 16y agoI remember it was very playable on the 33mhz, 8mb 486DX machines I had at my high school. A friend had a 50mhz 12mb 486SX-2 which was wonderful for Doom. I sadly only had a 16mhz 386sx with 2mb of RAM. I amazingly did get Doom to "run" on this machine through some virtual memory program for Win 3.1. I had to shrink the screen size down to the smallest size for it to run at about 1fps. I also remember a couple of other people that had "486" upgrades for their 386 based systems and Doom was perfectly playable on those systems as well. RAM was the big limiting factor that I remember.
- Luc 16y agoMichael Abrash' "Zen of Graphics Programming" has a good overview of many of the tricks used during that era: http://www.amazon.com/Zen-Graphics-Programming-Ultimate-Writing/dp/188357708X http://www.amazon.com/Zen-Graphics-Programming-Ultimate-Writ... (now, of course, mainly to be read for nostalgic reasons).
- kabdib 16y ago... and, to avoid similar architectural mistakes in the future. History is useful. We're not at the point where we want CS students to memorize what happened at the Battle of Algol in 1968, but it's darned close.
- Tyrant505 16y agoAny qed users? I liked it for map editing most.