I added 2 bit-per-pixel (4 pixels-per-byte) rendering to my kindle video player, to support the K1. It is mostly working, but the packed bit order inside the byte is incorrect. Unlike the K4 with most significant bits of a packed byte on the left, on the K1 they must be in reverse order. I also compensated for the negative video.
I also noticed that I only did a screen-centering offset adjustment for 4-bit video (to support large-screen DX and DXG, when this was developed). When the PW1 came out, gmplay worked fine, but it used 8-bit video and gmplay did not bother centering 8-bit video. I added 8-bit centering, so the video should not be pushed into a corner on higher resolution kindles like my new PW3 (on which the ORIGINAL gmplay worked just fine, but just not centered). BTW, I am considering pixel doubling for the PW3, because the 800x600 video only occupies about a quarter of the screen.
My launcher script now runs xzcat and gmplay in the background (with a '&' postfix), and then waits for the K1 'R' key to be pressed (because I found the 'R' keycode in an install script), and then does "killall -9 gmplay", which allows early termination instead of needing to wait for the video to end (which was getting boring during development and testing).
As it turns out, even -4 compression level gets "corruption" errors, and I am running at only -4 compression. However, "xz -z1" is WAY more compressed than "gz -9" compression like I was using in the past (and which also fails on the K1).
Bed time for Bonzo. I will sort out the internal pixel ordering inside K1 framebuffer bytes tomorrow. G'night y'all...
Last edited by geekmaster; 05-15-2016 at 11:30 PM.
|