July 13th, 2024

Graphical effects in Duke Nukem 1 and 2, part 1

The article explores graphical effects in Duke Nukem 1 and 2, detailing mirror surfaces, underwater, and translucency effects. It compares Assembly and C code optimizations for faster pixel copying and visual effects.

Read original articleLink Icon
Graphical effects in Duke Nukem 1 and 2, part 1

The article discusses the graphical effects in the first two Duke Nukem games, focusing on mirror-surface floors in Duke Nukem 1 and underwater and translucency effects in Duke Nukem 2. In Duke Nukem 1, the mirror surface areas were specified in level files using a dedicated actor number, creating mirror surfaces one tile wide. The mirror effect was achieved by copying pixels from video memory to video memory, compressing the image vertically and applying a shimmering effect. The low-level routine for pixel copying was written in Assembly language, optimized for minimal ISA bus traffic. The article compares a C code version with the Assembly version, highlighting optimizations like register usage and unrolling loops for faster execution. The Assembly version leveraged MOVSB instructions for efficient pixel copying and utilized macros for loop unrolling. Overall, the article delves into the technical details of implementing graphical effects in the Duke Nukem games, showcasing the complexity and optimizations involved in achieving visual effects in early 90s DOS games.

Related

Apple II graphics: More than you wanted to know

Apple II graphics: More than you wanted to know

The article explores Apple II graphics, emphasizing its historical importance and technical features like pixel-addressable graphics and sixteen colors. It contrasts with competitors and delves into synchronization challenges and hardware details.

Total Annihilation Graphics Engine (2012)

Total Annihilation Graphics Engine (2012)

The article details Jon Mavor's work on Total Annihilation's graphics engine, overcoming hardware limitations and implementing optimizations like caching units as sprites and improving image quality. Mavor's dedication and technical insights are well-received.

Weird things I learned while writing an x86 emulator

Weird things I learned while writing an x86 emulator

The article explores writing an x86 and amd64 emulator for Time Travel Debugging, emphasizing x86 encoding, prefixes, flag behaviors, shift instructions, segment overrides, FS and GS segments, TEB structures, CPU configuration, and segment handling nuances in 32-bit and 64-bit modes.

Moiré Error in Doom

Moiré Error in Doom

The Moiré error in Doom versions pre-v1.4 affected tall rooms, causing a flashing screen pattern near walls. Fixed in v1.4 for normal heights, v1.9 still had severe issues in extreme heights. The bug stemmed from numeric overflow in linedefs, leading to infinite tiling of a neighboring sector's flat, resembling a large-scale slime trail.

Non-Euclidean Doom: what happens to a game when pi is not pi (2022) [video]

Non-Euclidean Doom: what happens to a game when pi is not pi (2022) [video]

The YouTube video explores Doom's history, development, open-sourcing, and platform adaptations. It discusses altering pi in the source code, leading to network vulnerabilities, non-euclidean geometry, and gameplay changes. Collision detection in the game remains unchanged.

Link Icon 1 comments
By @nullindividual - 10 months
Related:

Level Editing - Duke Nukem - ADG Mod 12 [0]. It has expanded info about the tile sets, how items in tiles inherit the background from neighboring tiles, mod editor (from the 1990s, still in use today), etc. Interestingly enough, there is no background tile layer!

[0] https://youtu.be/Pd6WoL-G_48