I’ve taken a quick glance at the console dithering code again, and re-enabled some lines of code that makes it extra smooth. Seriously, it can be hard to distinguish between that dithering and hardware interpolation. The thing looks so beautiful it makes me want to implement and enable it by default. There are a couple problems though.
First, complexity. This extra dithering looks crap in resolutions lower than double of the dimensions of the source image. In cases like that, the previous dithering algorithm looks better. This would imply in the code having at least three different scaling algorithms (non-dithered, dithered, and extra-dithered), and it just feels like the kind of thing that would make the code needlessly more complex and therefore harder to maintain.
Also, if all of those methods gets implemented, it would be best to make them independent for each axis - which means that stretching a 320x200 image to 360x400 would be done using regular dithering on the Y axis, and extra dithering on the X axis. Note that dithering (at least in my implementation) is done perpendicularly to the stretching, so the dithering for the horizontal stretching is done vertically, and dithering for the vertical stretching is done horizontally. Allowing the user to disable dithering completely should also be possible.
Second, speed. The current code is too slow to be actually useful, and I’ve got to find ways to optimize it for speed. I love how PrBoom does this kind of ordered dithering insanely fast, but after trying to figure out this functionality in its source code for a while, I figured out that trying to devise my own optimizations may eventually consume less time.
All of this is too much work for a non-essential feature, but now that I’ve gone halfway through implementing it, it would feel like a waste to just throw it away.
