Libretro Cores Quick Look - PrBoom - Fixing Doom's wiggle rendering bugs!
113It's time to start fixing some of Doom's long standing graphics bugs! So let's deal with one of the most severe ones first - wiggle! Update your Prboom Libretro core today through the Online Updater to get access to this new feature!
Doom's software renderer was optimized for early to mid '90s PCs, and as you'd expect, shortcuts were taken to ensure the framerate would at least 'try' to maintain 35 fps most of the time. Doom's rendering is done using fixed point maths, avoiding floats nearly entirely (only 486 CPUs started having a floating point unit coprocessor, and even then, floats were still very expensive). At 320x200/240, these 'clamping' inaccuracies that you can tend to notice in this video tend to be there but they remain almost imperceptible because of how low the resolution already is. When you start increasing the resolution beyond its original DOS limits, though, this display glitch starts becoming far more serious and it's there where the software renderer really starts to fall apart. Hardware accelerated renderers like OpenGL sidestep this entirely, but we feel it's important that the Prboom libretro core has a robust software renderer for maximum portability (and there is a lack of modern GL renderers for Prboom-based ports in general).
Thankfully, smarter minds than us in the Doom community have found ways to combat these visual anomalies! See this thread -
https://www.doomworld.com/forum/topic/70288-dynamic-wiggletall-sector-fix-for-fixed-point-software-renderer/
We have backported this feature to the libretro Prboom port, and the results are impressive. According to the forum posters, there should be little to no real performance loss by doing this. However, it's still possible for the user to turn this on/off through the builtin GUI.
NOTE: The option is disabled by default for those people who think these rendering bugs lend a certain degree of authenticity/charm to the whole experience.