Modernizing the Wolfenstein 3D Fizzlefade Algorithm (2017) | Hacker News Reader

Modernizing the Wolfenstein 3D Fizzlefade Algorithm (2017)

jacopretorius.net

18 pointstodsacerdoti12 comments

Tiny correction: it's 320x240 also called mode X [0], an undocumented VGA graphical mode discovered by Michael Abrash which made him famous at the time. One of the big advantage of the mode X is that the pixels are square, unlike mode 13h (320x200).

It was previously used in the commander keen series and was in great part to credit to their success because for the first time on PC a game was matching console graphical quality. It has square pixels. IIRC Carmack improved on the mode X and him and Michael started a correspondance.

Who knew such a great story was behind such a tiny mistake: nothing less than the advent of games on PC.

[0] http://archive.gamedev.net/archive/reference/articles/articl...

> One of the big advantage of the mode X is that the pixels are square

On the then-ubiquitous 4:3 resolution monitors.

(Made this addition because on first reading, I wondered why square pixels would occur on anything but 320x320 resolution)

1 Abrash wasnt the first person to discover modeX.

2 All Commander Keen game were EGA, with some having additional CGA mode.

3 Carmack didnt improve modeX, he hired Abrash to help with optimizing Doom. As a result Doom ended up with the stupid modeY (variation of modeX) which was a wash performance wise on slow 486, while tanking performance on faster processors. https://github.com/viti95/FastDoom switching original Doom sourcecode back to mode 13h (or even better VESA 320x200) results in substantial to huge performance improvements.

Can you explain point 3 a bit more? Specifically where the performance impact came from:

A) Mode 13h has not enough ram to have 2 pages, so either you get screen flicker as you see Doom draw, or you loose 64k ram for an offscreen buffer, and the extra data transfer also takes time.

B) The core of ModeX/ModeY is disabling the chain4 mechanism and manually dispatching bytes to the 4 planes. The cost of this is some 'out' instructions, I assume 1 group per vertical slice. I don't know how doom did floors here, maybe draw them 4 times?. Even so, the cost seems not that expensive.

Doom, like Wof3d, renders screen in 1pixel wide columns.

https://www.youtube.com/watch?v=ujXrQVyl610

8-bit accesses only, this alone tanks performance for faster VGA cards. The second problem is slow plane switching in some implementations, especially later cards didnt bother optimizing this.

When you write to VGA (ISA in general) CPU is paused for the duration of the transfer. Switching back to 13h and rendering to RAM buffer benefits from motherboard cache and lets you actually use whole bandwidth when copying to the card (rep movsd). Typical 8-Bit VGA write bw is between 700KB/s for very bad Trident up to almost 2000KB/s for ET4000. At the same time fast 386 will do >20MB/s cache writes and extremely fast VGA on overclocked ISA bus can do 7MB/s. Heretic performance is higher compared to Doom because Raven dropped modeY.

Fastdoom:

Cyrix MediaGX https://www.youtube.com/watch?v=3PAfvDsmzVY 24 vs 64 fps

and extreme case of very bad modeY handling by Rendition Verite https://www.youtube.com/watch?v=6unNuPympE4 modeY 14, 13h 60, VBE2 300 fps

I forgot one more thing: reading! Doom reads back VGA memory when painting invisible sprites (Spectres, player sprite with partial invisibility blur sphere), this is extremely slow because absolutely nobody optimized VGA cards for reading. Ram buffer removes this disadvantage.

I think we played on different machines. You talk about high end VGA and cache. But most 386's had no cache, mine surely hadn't. My VGA was slow enough not to care about transferring 16 bits instead of 8, it just got half as fast or worse. OTOH, the low res mode, 160x200, was created by enabling 2 of the planes, and made a big difference. And 64K on a 4MB meant less of hard disk activity, which was my main bottleneck.

The semi translucent spectres causing VGA reads were very bad on that machine, causing <5FPS if there were multiple on screen. I learned to shoot them on sight and from a distance.

Fastdoom on 386DX40 is as fast at full resolution as regular Doom in low detail modeY.

Why are variables in C named so obscurely? Why rndval instead of random_value, for example?

Autocomplete barely existed back then, and was something performed by purpose-built TSRs that maintained their own text expansion dictionaries, rather than a thing your text editor automatically did by scanning the current file for things you might be trying to type. "r a n d o m shift - v a l u e" is a lot more to type by hand than "r n d v a l".

And even if you did have that you'd still have to deal with coding on a textmode screen that was probably 80x50 characters. Maybe 132x60 if you had a really top-of-the-line video card. Not much room for those long variable names.

(Admittedly the C code under discussion was written long after the original assembly routine was written, but by someone who'd spent a lot of time with his head in the source of these games, absorbing the idioms of early-nineties programming.)

Additionally, in the before-times, in the long-long-ago, some C compilers had really absurdly short identifier limits. Like, 8 characters short. They'd usually let you use more than 8 characters, they'd just ignore the extras. Fun times.

flashbacks to the wonderful 8-bit BASICs that only cared about the first two characters of a variable name

    #define FIRST_BIT        (uint32_t)(0x00001)
    least_significant_bit = random_value & FIRST_BIT;
    if (least_significant_bit) {

how is that more readable?

Reply on news.ycombinator.com