Originally Posted by kiri87
Impressive, as always!
The cosmegg demo looks SO much better in 16 colors, and the screen flashing adds up to the hypnotic effect. Awesome!
The "goodbye" part of the demo is cool. First, I thought that the binary contained extra things than the code attached, but then I realized that the trick is in sv. Very clever!
Well done for implementing this! Your code really does incredible things with the e-ink display, showing not only that it's possible to display animations, in a decent framerate, but in 16 dithere colors, too.
I had some issues compiling this on my Kindle 3.
First, the files einkfb.h & mxcfb.h were missing. The I read I should find them in the Amazon Source codes
; to compile, I needed the files from Kindle_src_5.1.0.
Second, I received a
undefined symbol '__invalid_size_argument_for_IOC'
error, which I fixed by adding
unsigned int __invalid_size_argument_for_IOC;
I hope this may help someone, especially any other Linux noob like me.
I did notice, though, there's some unusual issues with the dithering, at least on my Kindle3. That part of code is too complex for me to try fixing it.
First, the dither16 (screen attached, no 2) shows some black where there should be white (on the top, for example)
Second, the dither2 (screen attached, no 3) has a very subtle bug, that can observed easily for grays close to 50%. I attached a resized & cropped a portion of the screenshot to show the bug (screen attached, no 4). Basically, one column in 8 is off by 1 pixel.
This is the code used to generate these screens:
for (x = 0; x < MX; x++)
for (y = 0; y < MY; y++)
setpx(x, y, y%256);
Keep up the good work, Geekmaster!
I noticed a subtle bug in the cosmegg 256-color (dithered from 16) mode, at a boundary, but I was too tired to fix it. I plan to optimize that code more. The ARM processor is much better at 32-bit operations, and as you can see I changed one of the dither modes to do a multiply instead of logic, and got that working (as proof of concept). Now with multiply I can dither 4 pixels at the cost of one pixel (or perhaps even faster), by runninng 32bits (4 pixels) through the formula as a DWORD.
Anyway, kindle3 dither was horribly broken before due to compiler OVER-optimization making bad code, and when I got that fixed I decided to publish even though a little "off-by-one" issue still seems to exist. That will get fixed -- you need to catalog and fix these things as you find them, so thanks for adding detail. I did see that bug but it is subtle and for many things not annoying, and it will get fixed soon.
After dithering, the result is 256 color. In essence, you add the upper four bits of dither to the bottom four bits of the pixel value, which might round up the top four bits to the next higher 16-bit color, then you zero out the bottom four bits or the pixel so the result is pure 16-bit hardware colors with no bottom bits to shift the cutoff point. That hardware cutoff point shifting took a lot of experimentation to figure out.
That signature in the last demo was captured with my (unpublished) Touchpaint-2.0 script on the K5(touch). I have a lot of captured text in my collection. ANd yes, "sv" is the "signature vector", as you figured out, and it contains packed scalable coordinates rescaled (0-255x = 0-599 original, 0-255y= 0-799 original. Not only does scaling to 8 bits allow two coords/word, but you can rescale up or down as I did in the demo (actually started out much reduced in size and growing to 1.5x original size). Scalable vector graphics, with the line drawing function calling the "shaded circle" function to draw the signature with the same tubes used in the hoser demos.
But the point is to show what CAN be done AND HOW TO DO IT. This is just a hint of things to come from me, and HOPEFULLY others too.