PocketFrog v0.4.5 release

[Kzinti]

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.

[Digby]

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?

[Chris Edwards]

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?

[RICoder]

"The digital pimp, hard at work."

[Kzinti]

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?

[billcow]

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.

[Kzinti]

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.

[Kzinti]

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.

[billcow]

Thanks, that seems to make sense

[MirekCz]

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:)

[Kzinti]

[Kzinti]