Dithering

[Kzinti]

[Digby]

I did this a while back. It isn't Floyd-Steinberg though. <subjectivism> It's much faster. </subjectivism> (i.e. I never profiled it but in theory it should be faster)

[Kzinti]

Pretty much figured out you used ordered dithering... It seems the only way to get some fps out of the device. Did you go with the simple 2x2 Bayer matrix?

Do you still have the code for this? I'm really curious to see how you did it with only two "and"s and a lookup + clamping.

[Digby]

I used a 4x4 dither matrix. I unable to locate the code right now but I should be able to find it later this week.

Per-pixel, the ordered dither requires two ANDs, one table lookup, 3 adds, and 3 clamps, then a pixel pack.

Have you tried just creating a generic halftone palette and generating a 64K lookup table?

Don't perform the color conversion per-frame. Only do it when the app locks/unlocks a surface.

Personally, unless I had to choose between supporting palettized displays and a having a root canal, I'd do nothing to support these dead devices. They are well over a year old now and there are no future devices being made with 8-bpp displays.

[Kzinti]

[Digby]

[Kzinti]

[Kzinti]

[Digby]

If you are exposing a 16-bpp buffer to an app running on an 8-bpp device, then the look up table is 64K bytes. Each byte in the table contains the 8 bit palette index.

If you're going to dither the entire back buffer then the dithering will help the final image, regardless of what size your sprites are. Or are you talking about dithering the sprites individually before copying to the back buffer?

My comment about doing the color conversion at load time was to think about this problem in the same manner as rotating a bitmap at load time to solve the native landscape oriented displays. If you do the conversion up front, you won't have to do it each frame, which is going to be a big perf win.

[Kzinti]

[Digby]