PocketMatrix

PocketFrog is an easy to use API to write games for pocket PCs.

PocketFrog v0.4.5 has been released on
http://frog.flipcode.com.

New features include dithering for palletized devices such as the Jornada 525 and various fixes.

Congrats on your release! (you didn't forget to mention pocketmatrix in your release notes, right???)

I'm curious, where did the name "PocketFrog" come from?

Hey.. I went to your site and you said you had forums "on the way"... What if we were to set you up a forum here, would that suffice?

"The digital pimp, hard at work."

Digby:

When I wrote my first engine, I called it the Frog Engine. Reason being that I'm a french canadian and english peoples used to (and sometime still do) call french "frogs". Why? Because French are delighted to eat frog legs and English are disgusted by it.

When I moved to the Pocket PC, I kept the name Frog. Unfortunately, www.frog.org, www.frog.net and www.frog.com are all taken! *sigh*.


Chris:

Thanks for offering. I am not sure I like the idea of having a site on a host and the forum on another. On the other hand, your forum are really nice. Let me think a little about it and I will get back to you?

I was looking at the PocketFrog Dithering code and I noticed that you used a lookup table to find the nearest color. Is there a reason why you can't just mask off the lower 5 bits (or 6 bits for blue) of the 8-bit color component value? With a 332 palette that should give the same results, shouldn't it? Or did you do this so it can be extended to use custom palettes?

I would think (correct me if I'm wrong) that a lookup table would be slower than a bit-mask, due to caching issues, in addition to requiring more memory.

Billcow:

There is two reasons I use a LUT:

1) I am not sure that using shifts and masks gives the closest matching color in a 332 palette. It will return a pretty close color, but not the closest one. The results looked better this way. I am not sure about the mathematical proof though. I think that handling each color component separately gives a bigger error term. Anyways, continue reading.


2) Is is actually faster with the LUT! This is the results I've got on my desktop PC. I don't have access to a palettized Pocket PC to check it, but it makes sense: a simple memory access is usually faster then using 3 masks with immediate values (3 memory accesses!) + 3 shifts + 2 logical ors.

I have no doubt that this dithering code could be faster, I just don't have the time / need to do it myself. I am pleased with the current result. If someone wants to experiment some more, be my guest.

Here is the proof that using a LUT looks better then using shift/masks when converting to 332:

Suppose you have the color 0007h which you want to conver to 332. A naive implementation would use a shift and map this to the value '00b':

(00111b >> 3) = 00b

But intuitively, this color is closer to palette entre 01b then 00b.

Let's verify by computing the error when selecting palette entry 0 and 1:

Effective blue for entry 0 is 00000000b
Effective blue for entry 1 is 01010101b

Error for entry 0 is 00111001b - 00000000b = 0111001b
Error for entry 1 is 01010101b - 00111001b = 0011100b

This prooves that the closest color can't be obtained by using shifts/masks alone.

Thanks, that seems to make sense

plan9:hmm, althrought I don't understand much from this effective blue thingy(huh, what is it about?!?) I can tell you that you're pretty false about your assumptions that a shift won't do to change a 565 into 332.
You can achieve it like this:
bad way:
0011b >> 2 = 00b
good way:
(0011b+0010b) >> 2 = 0101b >> 2 = 01b

How it works? we simple added half of the number representing 1 , and therefore a (will use floats) 0.9f won't become 0, but will become 0.9f+0.5f=1.4f so 1.

Conclusion? one simlpe add and you can still live pretty nicely with some shifts/ands, which might be better then your version (no concerns about trashing cache, not finding a value in cache which then starts a slow sysmem read etc etc)

hope it helps:)