The Problem With 'Almost Right'
A developer documenting their PyGame lighting engine build has produced a useful case study in why visual correctness isn't the same as mathematical correctness - a distinction that matters in any real-time rendering system.
The project started simple: black-and-white silhouettes, single light source, pure geometry. No textures or visual noise to hide problems. When switched to real image silhouettes, the system "almost looked correct." Tiny gaps and jagged edges proved otherwise.
Where the Math Broke
The core failures came down to floating-point precision. Casting rays directly at segment endpoints wasn't sufficient - the developer added ±0.00001 epsilon offsets to prevent rays from "slipping between edges." Small change, visible impact.
Parallel line detection broke under precision limits:
if abs(cross) < 1e-8:
return None
Almost-parallel rays vanished entirely, creating shadow gaps that took time to diagnose.
Division by very small r_dx values caused numerical explosions: "What looked like minor instability ended up becoming very obvious lighting glitches."
The Missing Boundary
Early versions had no screen borders defined as geometry. Rays that missed objects continued infinitely, producing edge artifacts. The fix was architectural - treating the screen itself as geometry so every ray intersected something.
Context That Matters
PyGame remains active for prototyping and education, not production. Libraries like pygame-light2d (requiring ModernGL 5.8.2+) use shader acceleration for performance. The community continues sharing implementations via Discord and GitHub, though no significant updates emerged in recent months.
The techniques here - ray casting, polygon projections, BLEND_RGB_ADD for additive lighting - apply beyond PyGame. But the precision lessons are universal: in graphics programming, "looks acceptable" often means "mathematically wrong underneath." Those issues surface when systems scale.
Worth noting: This is hobbyist tooling solving hobbyist problems. The real lesson is about precision discipline, not PyGame's viability for serious work.