05:16 pm - And on a different note...
...work progresses unravelling the 'HQ' image-enhancement effect back to equation-level, and then re-working it properly. I have about half the equation-components graphed out for 4x mode, will be progressing to 3x mode when that's done.
When I'm done it will use a dynamically-generated array of multipliers, allowing for arbitrary scaling in either direction using the re-rasterization effects.
The code itself is going to be optimized for MMX usage only, also creating support for 64-bit framebuffers (AKA the 16:16:16:16 RGBA textures used on the newer DX9-capable video cards from ATI and nVidia) as a handy side-effect.
Current approach is a three-pass system using a temporary buffer. First pass is upconverting from 8bpp, 15bpp, 16bpp, or 32bpp to 64bpp, then calculating the 'difference' bits and storing them ahead of time, so I only need to load a 16-bit value to know what equation to execute for each pixel. Specifically, since I have a 16-bit 'free' channel, I can store the entire 'difference equation' currently there, and simply calculate that channel with a single pass over the upconverted buffer.
Initialization will calculate the custom-sized equation table, as this will share the load between the code and data cache, as well as reducing the overall size since the data will be under 2k*X*Y, where X and Y are the upscaling factors for the horizontal and vertical components. 2x2 would be a roughly 8k table, 3x3 18k, 4x4 32k, etc.
The equations are showing an interesting symetry though, and if I can exploit that I can reduce the table size to roughly 25% of it's original size, odd-sized-scalings excluded from the math as they retain the 'center' column for any given scaling, so don't "compress" quite as noticably. This would reduce the 2x2 table to 2k, the 3x3 table to 8k, and the 4x4 table to 8k as well, for example.0 comments