Youtube Channel "Decino" is nothing but deep dives into Doom's Logic and it's amazing (2024)

This is one of the best channels on Youtube, they make multiple videos breaking down all the algorithmic logic that dictates Doom's behavior:

Great examples:

How Enemy AI and pathfinding works:

How Revenants decide which missile to fire:

How Doom's RNG works

Bonus: Quake II's particle engine

I can't recommend this channel enough.

Metalmucil said:

I love his vids. Beast of a player.

Click to expand...

Click to shrink...

Similarly awesome series, that is solely focused on the 3DO doom engine, is here:

Also, it'd be irresponsible to not recommend THE DOOM ENGINE BLACK BOOK: https://fabiensanglard.net/gebbdoom/

That and no death runs of highly difficult levels of classic FPS.

My only issue with him is when he, during a live stream, knowingly and enthusiastically accepted a donation from Markus Persson.

Krejlooc said:

Similarly awesome series, that is solely focused on the 3DO doom engine, is here:

Also, it'd be irresponsible to not recommend THE DOOM ENGINE BLACK BOOK: https://fabiensanglard.net/gebbdoom/

Click to expand...

Click to shrink...

Was Doom ever fixed on the 3do? I think I heard that a woman had to port the game to the system with very limited time and that it was a bad port so I wondered if someone fixed it by using the 3do properly.

signal said:

Is doom objective c? I'm no programmer but the code for checking an odd number ( if (gametic & 3) ) looks weird. Someone explain pls.

Click to expand...

Click to shrink...

Doom is C. that is a bitwise AND operation, it's less cycles than modulus division:

It performs a bitwise AND operation on every bit of the bitstring "Gametick," an unsigned 32-bit integer. You only need to examine the lower 2 bits of a bit string (xxxx-xx00, xxxx-xx01, xxxx-xx10, xxxx-xx11) for this purpose. an AND expression equates to 1 if both bits being compared are 1. In this case, the expression only evaluates to true if the lower 2 bits are 0x11 (binary 3), which is the same as doing x%4 only faster. 1 is the same as true. It's not checking to see if it's an odd number, it's a gate that only opens every 4 game ticks. This is because the lower 2 bits of any binary value will loop every 4 iterations:

0 = 0x0000
1 = 0x0001
2 = 0x0010
3 = 0x0011 (= &3 = %4 = true)
4 = 0x0100
5 = 0x0101
6 = 0x0110
7 = 0x0111 (=&3 = %4 = true)
8 = 0x1000
9 = 0x1001
10 = 0x1010
11 = 0x1011 ( = &3 = %4 = true)
etc

"3" as a 32-bit number is actually 0000-0000 0000-0000 0000-0000 0000-0011 so the upper 30 bits are always 0. 0 AND 0 is 0, 0 AND 1 is 0, 1 AND 1 is 1. By using bitwise and operations, you reduce the complexity of the check.

Krejlooc said:

In this case, the expression only evaluates to true if the lower 2 bits are 0x11 (binary 3), which is the same as doing x%4 only faster. 1 is the same as true. It's not checking to see if it's an odd number, it's a gate that only opens every 4 game ticks.

Click to expand...

Click to shrink...

Oh ok that's what I was looking for. My head hurts but thanks!

Krejlooc said:

How Enemy AI and pathfinding works:

Click to expand...

Click to shrink...

The cacodemon at 9:50 is the most adorable thing.

Krejlooc said:

In this case, the expression only evaluates to true if the lower 2 bits are 0x11 (binary 3)

Click to expand...

Click to shrink...

Careful with your prefixes. 0x11 is decimal 17, not 3.

c evaluates anything nonzero as true, so the statement evaluates to true not only if the lower bits are binary 11, but also if they're binary 01 or binary 10.
I think you're mistakenly visualizing the code as if((gametic & 3) == 3).

HTupolev said:

Careful with your prefixes. 0x11 is decimal 17, not 3.

c evaluates anything nonzero as true, so the statement evaluates to true not only if the lower bits are binary 11, but also if they're binary 01 or binary 10.
I think you're mistakenly visualizing the code as if((gametic & 3) == 3).

Click to expand...

Click to shrink...

lol both of those points are completely correct, should have been b0000, b0001, etc. I rarely have to work in raw binary strings, I'm used to hex notation every time I'm not dealing with decimal, my bad

functionally, it's sorta the same result (once aberration per every 4 ticks), I just got the swing of the gate incorrect. It'd be false every 4 ticks, not true every 4 ticks (and the aberration would be off by one in my example). Thanks for the help on the explanation.

I'm a simple man.

I see Krejlooc recommending me to subscribe to something and I do so.