"Since I left my job at Amazon I have spent a lot of time reading great source code. Having exhausted the insanely good idSoftware pool, the next thing to read was one of the greatest game of all time: Duke Nukem 3D and the engine powering it named 'Build'. It turned out to be a difficult experience: The engine delivered great value and ranked high in terms of speed, stability and memory consumption but my enthousiasm met a source code controversial in terms of organization, best practices and comments/documentation. This reading session taught me a lot about code legacy and what helps a software live long." Hail to the king, baby.

: If a file/variable name features a number: it is probably not a good name !

Apparently you've never worked with polygons or 3d math -- array indexes are slow so if you have four 2d coordinates representing a square what would make more sense than x1, x2, x3, x4 and y1, y2, y3 and y4 for it's corners... it's not like top/left/right/bottom have any meaning when you're constantly changing the orientation. Particularly true when unrolling for performance since a hardcoded offset from DS:BP is going to be faster than using dynamic indexes on something like an array. (see why pointered lists can often outperform arrays on complex data)

The code section used in the article that the author has some sort of noodle-doodle problem with seems completely normal and rational to me given it's implementing fixed point arithmetic with shifts... Just what in blue blazes would you do instead there? Lemme guess, make it run three times slower by moving the like bits of code into functions?

No offense, but that article to me reeks of someone looking at code they're too stupid to understand.

Of course that there is NO meaningful breakdown of the actual code or anything more than flowchart theory asshattery makes this little more than a fluff piece -- it sure as shine-ola is NOT a "code review"!

-- edit -- my bad, there's more than one page of this -- MEIN GOTT that websites navigation is horrible.