Register Guidelines E-Books Search Today's Posts Mark Forums Read

Go Back   MobileRead Forums > E-Book Readers > Amazon Kindle > Kindle Developer's Corner

Notices

Reply
 
Thread Tools Search this Thread
Old 04-28-2012, 05:20 AM   #1
geekmaster
Carpe diem, c'est la vie.
geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.
 
geekmaster's Avatar
 
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
Arrow newtrix - geekmaster's new tricks

Eink controller documents were studied. Code was written to take advantage of Samsung Broadsheet eink controller for K3 and older kindles (using einkfb device driver) and Freescale SoC-integrated eink controller (using mxcfb device driver), plus the funky hybrid K4 booted from main, with its mxcfb hardware emulation layer using the K3 einkfb device driver. K4 diags is also supported (and I STRONGLY recommend you watch this demo from there to see better performance, but main is not too shabby either). The new code contains a multi-stage demonstration showing what can be done using new interface methods.

All eink updates use ioctl() calls for all kindle models in all modes. New dithering code was written that is MUCH simpler and MUCH faster, and supports full 256-color 8-bit mode (which requires dithering despite the fact that the Freescale hardware has unused dithering support).

The demo shows WHAT you can do. The source code shows you HOW to do it.

The second stage of the demo is very hardware dependent on speed and what effects you see. It is rather slow on the DX, but it gets interesting near the end, and it is followed by MUCH more interesting demo stages.

Be sure to watch this multi-stage demo all the way to the end. There is a special bonus that *I* think is worth the wait.

We are just barely scratching the surface on capabilities here. There is some VERY interesting eink controller hardware here, mostly going unused. Look for GREAT things in the future.

Now, time for the show!

Teh Codez:
Spoiler:
PHP Code:
//====================================================
// newtrix 2.0 - "new tricks" animation demo
// Copyright (C) 2012 by geekmaster, with MIT license:
// http://www.opensource.org/licenses/mit-license.php
//----------------------------------------------------
// This was tested on DX,DXG,K3,K4(Mini),K5(Touch).
//----------------------------------------------------

#include <stdio.h>      // printf
#include <stdlib.h>    // malloc, free
#include <string.h>   // memset, memcpy
#include <unistd.h>  // usleep
#include <fcntl.h>  // open, close, write
#include <time.h>  // time
#include <sys/mman.h>   // mmap, munmap
#include <sys/ioctl.h> // ioctl
#include <linux/fb.h> // screeninfo
typedef unsigned char u8;
#include <linux/einkfb.h>
#include <linux/mxcfb.h>

//#define FBIO_EINK_UPDATE_DISPLAY_AREA 0x46dd
enum GMLIB_op GMLIB_INIT,GMLIB_CLOSE,GMLIB_UPDATE };
//typedef unsigned int u32;

// function prototypes
void circle(int,int,int);
void line(int,int,int,int,int);
int gmlib(int);
inline void setpx(int,int,int);
void dblit(void);
int getmsec(void);

// gmlib global vars
static int sv[424]={
    
2330,1048,17,776,2309,2828,2580,3092,5134,6663,7168,5889,5385,
    
5396,5664,5673,4910,4135,5407,7198,8484,9263,8761,7485,7221,7469,
    
9514,11052,11575,11584,10316,8275,8275,10056,12094,13370,12867,
    
12618,12115,12888,14164,14413,13127,13380,15173,16456,16720,15963,
    
16479,18008,18265,17762,19040,20315,19555,19051,20327,21860,23143,
    
22384,22649,24187,24188,23161,22897,23657,25191,25456,25464,26224,
    
27507,27259,26755,27274,29065,30083,29820,28281,29819,30848,31370,
    
30868,29853,29852,30866,32139,33673,34704,35226,34722,33441,33688,
    
35219,36501,37022,37031,38567,39840,41378,41386,40880,0,29332,
    
30621,31654,0,0,};

static 
__u8 dt[64]={
    
3,129,34,160,10,136,42,168,192,66,223,97,200,73,231,105,50,
    
176,18,144,58,184,26,152,239,113,207,81,247,121,215,89,14,
    
140,46,180,7,133,38,164,203,77,235,109,196,70,227,101,62,188,
    
30,156,54,180,22,148,251,125,219,93,243,117,211,85}; // 0-255 dither table
__u8 *psave=NULL;     // screensave pointer
__u8 *fb0=NULL;      // framebuffer pointer
__u8 *wb0=NULL;     // workbuffer pointer
__u32 mpu=100;     // msec/update
int fdFB=0;       // fb0 file descriptor
int fdWB=0;      // wb0 file descriptor
__u32 fs=0;     // fb0 stride
__u32 fb=0;    // fb0 bytes
__u32 MX=0;   // xres (visible)
__u32 MY=0;  // yres (visible)
__u8 ppb=0// pixels per byte
int bs=340// border size
__u8 gs=0// 8-bit grayscale
__u32 teu=0// eink update time
__u32 tpu=0// physics update time

//===============================================
// hoser - eink demo showing all-new dither design
// This works on all kindle eink models.   Enjoy!
//-----------------------------------------------
void hoser(void) {
    
__u32 i,x,y,c,px1,py1,vx1,vy1,dx,dy,cc,cu,cl,cb,wd,nt;
    
c=0,px1=100,py1=MY-40,vx1=1,vy1=-9,cc=31,cl=16,cb=11,nt=0,wd=3;
    for (
cu=0;cu<60000;cu++) { 
        if (
0==cu%3000) { // periodic background display
          
gmlib(GMLIB_UPDATE); teu+=400+gs*400;
          if (
cbcb--;
          for (
y=0y<=MY/2y++) for (x=0x<=MX/2x++) {
            
dx=MX/2-xdy=MY/2-yc=255-(dx*dx+dy*dy)*255/(MX*220);
            
setpx(x,y,c); setpx(MX-x,y,c);
            
setpx(x,MY-y,c); setpx(MX-x,MY-y,c);
          }
        }
        for (
i=12;i<33;i++) { circle(px1,py1,i); }
        
px1+=vx1py1+=vy1;
        if (
px1>MX-40 || px1<40) { vx1=-vx1; }
        if (
py1<40) { py1=40vy1=-vy1; }
        if (
py1>MY-40) { py1=MY-40vy1=-vy1wd+=3nt=1; }
        if (
0==cu%cl) { vy1++; }
        if (
1==nt && cb) {
            
nt=0gmlib(GMLIB_UPDATE); teu+=360+gs*240;
        } else if (
0==cu%wd && wd<100) { gmlib(GMLIB_UPDATE); teu+=120; }
    }
}

//==========================================
// sparkle - eink spatiotemporal dither demo
//------------------------------------------
void sparkle(void) {
    
int x,y,c,px1,py1,vx1,vy1,dx,dy,cc,cu,cl;
    
int i,j,n,d,wbytes,wb2,fdin,wdin,rc// ,once=0;
    
__u8 *start,*end,*half,*pbyte,*psave,*pln;

    
int yoff=320,xoff=240,bbx=MX/2,bby=MY/6,bbvx=21;
    
int bbvy=3,wbx=MX/2,wby=MY/2,wbvx=-18,wbvy=-12;

    for (
y=0;y<MY;y++) for (x=0;x<MX;x++) setpx(x,y,0);
    for (;;) {
        
yoff=340-bs,xoff=yoff*3/4;

//### fill screen with grays
        
for (y=0;y<(MY-yoff*2)/3;y++) for (x=0;x<MX-xoff*2;x++) {
            if (
rand()%(MX-xoff*2)<x/2setpx(x+xoff,y+yoff,0); else setpx(x+xoff,y+yoff,255);
        }
        for (
y=(MY-yoff*2)/3;y<(MY-yoff*2)*2/3;y++) for (x=0;x<MX-xoff*2;x++) {
            if (
rand()%(MX-xoff*2)<x/2setpx(x+xoff,y+yoff,255); else setpx(x+xoff,y+yoff,0);
        }
        for (
y=(MY-yoff*2)*2/3;y<MY-yoff*2;y++) for (x=0;x<MX-xoff*2;x++) {
            if (
rand()%(MX-xoff*2)>xsetpx(x+xoff,y+yoff,0); else setpx(x+xoff,y+yoff,255);
        }

//### big ring
        
for (y=25;y<51;y++) circle(bbx+50,bby+50,y);

//### small ball
        
for (y=1;y<26;y++) circle(wbx+25,wby+25,y);

//### animate
        
bbx += bbvxbby += bbvywbx += wbvxwby += wbvy;
        if (
bbx>MX-xoff-120) { bbx=MX-xoff-120bbvx=-bbvxbs-=(bs/50+1); }
        if (
bbx<xoff+20) { bbx=xoff+20bbvx=-bbvxbs-=(bs/50+1); }
        if (
bby>MY-yoff-120) { bby=MY-yoff-120bbvy=-bbvy; }
        if (
bby<yoff+20) { bby=yoff+20bbvy=-bbvy; }
        if (
wbx>MX-xoff-60) { wbx=MX-xoff-60wbvx=-wbvx; }
        if (
wbx<xoff+20) { wbx=xoff+20wbvx=-wbvx; }
        if (
wby>MY-yoff-60) { wby=MY-yoff-60wbvy=-wbvy; }
        if (
wby<yoff+20) { wby=yoff+20wbvy=-wbvy; }
        if (
bs<0) { break; }
        
gmlib(GMLIB_UPDATE); teu+=80;
    }
}

//===============================================
// cosmegg - kindle cosmic egg demo
// This works on all kindle eink models.   Enjoy!
//-----------------------------------------------
void cosmegg(void) {
    
int x,y,c,dx,dy,cu;
    for (
cu=100000;cu>100;cu-=(cu/32)) {
        for (
y=0y<MYy++) for (x=0x<MXx++) { dx=(x-MX*2/5); dy=(y-MY/2);
            
c=((dx*dx+dy*dy-(x*y-4*x)/4)*256/cu)%256setpx(x,y,c);
        } 
gmlib(GMLIB_UPDATE); teu+=300;
    }
}
//===============================================
// goodbye - goodbye demo
//-----------------------------------------------
void goodbye(void) {
    
int i,j,c,v,pv,px=0,py=0,x,y,dx,dy,k;
    for (
i=0;i<15000;i+=17) {
        for (
y=0y<=MY/2y++) for (x=0x<=MX/2x++) {
            
dx=MX/2-xdy=MY/2-yc=(dx*dy/4-i)&255;
            
setpx(x,y,c); setpx(MX-x,y,c);
            
setpx(x,MY-y,c); setpx(MX-x,MY-y,c);
        }
        if (
i>1000 && i<40000) {
            for (
k=0;i<30000;k++) {
                
v=sv[k]; x=((v&255)-95)*i/6000y=((v/256)-70)*i/6000;
                if (
0==v+pv) { break;
                } else if (
0==v) { pv=0;
        } else if (
pv) { line(px+MX/2,py+MY/2,x+MX/2,y+MY/2,3*i/6000); }
                
pv=vpx=xpy=y;
            }
        }
        
gmlib(GMLIB_UPDATE); teu+=80;
    }
}

//====================================
// gmlib - geekmaster function library
// op (init, update, close)
//------------------------------------
int gmlib(int op) {
    static 
struct update_area_t ua={0,0,600,800,fx_invert,NULL};
    static 
struct mxcfb_update_data ur={
        {
0,0,600,800},WAVEFORM_MODE_AUTO,0,1,TEMP_USE_AMBIENT,0};
    static 
int eupcode; static void *eupdata=NULL;
    
struct fb_var_screeninfo screeninfo;
    if (
GMLIB_INIT==op) { teu=getmsec();
        
// save original screen
        
fdFB=open("/dev/fb0",O_RDWR); // open eink framebuffer fb0
        
ioctl(fdFB,FBIOGET_VSCREENINFO,&screeninfo);
        
ppb=8/screeninfo.bits_per_pixel;  // pixels per byte
        
fs=screeninfo.xres_virtual/ppb;  // fb0 stride
        
fb=screeninfo.yres_virtual/ppb// fb0 bytes
        
MX=screeninfo.xres;            // max X+1
        
MY=screeninfo.yres;           // max Y+1
        
ua.x2=MXua.y2=MY;
        
ur.update_region.width=MXur.update_region.height=MY;
        
fdWB=open("/tmp/wb0",O_RDWR|O_CREAT); // open work framebuffer wb0
        
lseek(fdWB,MY*MX-1,SEEK_SET); write(fdWB,"",1); // create work buffer file
        
fb0=(__u8 *)mmap(0,MY*fs,PROT_READ|PROT_WRITE,MAP_SHARED,fdFB,0); // map fb0
        
wb0=(__u8 *)mmap(0,MY*MX,PROT_READ|PROT_WRITE,MAP_SHARED,fdWB,0); // map wb0
        
if (fb>MY) { eupcode=MXCFB_SEND_UPDATEeupdata=&urur.update_mode=0; }
        else { 
eupcode=FBIO_EINK_UPDATE_DISPLAY_AREAeupdata=&ua; }
        
psave=malloc(fs*MY); memcpy(psave,fb0,fs*MY);
        
memset(wb0,0,MY*MX); gmlib(GMLIB_UPDATE); teu+=300;
        
memset(wb0,255,MY*MX); gmlib(GMLIB_UPDATE); teu+=80;
    } else if (
GMLIB_UPDATE==op) {
        while (
teu>getmsec()); // async update needs time
        
dblit(); ioctl(fdFB,eupcode,eupdata);
    } else if (
GMLIB_CLOSE==op) {
        
gmlib(GMLIB_UPDATE); sleep(3);
        
memcpy(fb0,psave,fs*MY); // restore display
        
free(psave);
        
gmlib(GMLIB_UPDATE);   // update display
        
munmap(wb0,MY*MX);    // unmap wb0
        
close(fdWB);         // close wb0
        
remove("/tmp/wb0"); // remove wb0
        
munmap(fb0,MY*fs); // unmap fb0
        
close(fdFB);      // close fb0
    
} else { return -1; }
    return 
0;
}

//========================================
// setpx - draw pixel to 8-bit work buffer
// x,y:screen coordinates, c:color(0-255).
//----------------------------------------
inline void setpx(int x,int y,int c) {
    
wb0[y*MX+x]=c;
}

//==========================
// dblit - dither wb0 to fb0
//--------------------------
void dblit(void) {
    
int x,y,ys
    
__u8 p,d,*pi,*po,*pd;
    
pi=wb0-1po=fb0-1;
    if (
gs) { // 16-color dither
      
if (ppb/2) { // 2 px/byte
        
for (y=0;y<MY;y++) { pd=dt+(y&7)*8+7;
            for (
x=0;x<MX;x+=8) { pd-=8;
                
p=*pi++; d=*pd++; 
                *
po++=((p&240)+(d-(*pi&15)*255/15>>4&16)-16)&240|
                    ((*
pi++&240)+(*pd++-(*pi&15)*255/15>>4&16)-16)/16&15;
                
p=*pi++; d=*pd++; 
                *
po++=((p&240)+(d-(*pi&15)*255/15>>4&16)-16)&240|
                    ((*
pi++&240)+(*pd++-(*pi&15)*255/15>>4&16)-16)/16&15;
                
p=*pi++; d=*pd++; 
                *
po++=((p&240)+(d-(*pi&15)*255/15>>4&16)-16)&240|
                    ((*
pi++&240)+(*pd++-(*pi&15)*255/15>>4&16)-16)/16&15;
                
p=*pi++; d=*pd++; 
                *
po++=((p&240)+(d-(*pi&15)*255/15>>4&16)-16)&240|
                    ((*
pi++&240)+(*pd++-(*pi&15)*255/15>>4&16)-16)/16&15;
            }
        }
      } else { 
// 1 px/byte
        
for (y=0;y<MY;y++) { pd=dt+(y&7)*8+7;
            for (
x=0;x<MX;x+=8) { pd-=8;
//                *po++=(*pi++&240)+(*pd++-(*pi&15)*255/15>>4&16)-16;
                
*po++=(*pi++&240)+(((*pi&15)*4080>>8)+*pd++>>4&16)-16;
                *
po++=(*pi++&240)+(((*pi&15)*4080>>8)+*pd++>>4&16)-16;
                *
po++=(*pi++&240)+(((*pi&15)*4080>>8)+*pd++>>4&16)-16;
                *
po++=(*pi++&240)+(((*pi&15)*4080>>8)+*pd++>>4&16)-16;
                *
po++=(*pi++&240)+(((*pi&15)*4080>>8)+*pd++>>4&16)-16;
                *
po++=(*pi++&240)+(((*pi&15)*4080>>8)+*pd++>>4&16)-16;
                *
po++=(*pi++&240)+(((*pi&15)*4080>>8)+*pd++>>4&16)-16;
                *
po++=(*pi++&240)+(((*pi&15)*4080>>8)+*pd++>>4&16)-16;
            } 
po+=(fs-MX);
        }
      }
    } else { 
// 2-color dither
      
if (ppb/2) { // 2 px/byte
        
for (y=0;y<MY;y++) { pd=dt+(y&7)*8+7ys=(y&7)*8;
            for (
x=0;x<MX;x+=8) { pd-=8;
                
p=*pi++; d=*pd++; *po++=d-p>>4&240|*pd++-*pi++>>8&15;
                
p=*pi++; d=*pd++; *po++=d-p>>4&240|*pd++-*pi++>>8&15;
                
p=*pi++; d=*pd++; *po++=d-p>>4&240|*pd++-*pi++>>8&15;
                
p=*pi++; d=*pd++; *po++=d-p>>4&240|*pd++-*pi++>>8&15;
            }
        }

      } else { 
// 1 px/byte
        
for (y=0;y<MY;y++) { pd=dt+(y&7)*8+7;
            for (
x=0;x<MX;x+=8) { pd-=8;
                *
po++=*pd++-*pi++>>8; *po++=*pd++-*pi++>>8;
                *
po++=*pd++-*pi++>>8; *po++=*pd++-*pi++>>8;
                *
po++=*pd++-*pi++>>8; *po++=*pd++-*pi++>>8;
                *
po++=*pd++-*pi++>>8; *po++=*pd++-*pi++>>8;
            } 
po+=(fs-MX);
        }
      }
    }
}

//==============================================
// circle - optimized midpoint circle algorithm
//----------------------------------------------
void circle(int cx,int cy,int r) {
    
int e=-r,x=r,y=0;
    while (
x>y) {
        
setpx(cx+y,cy-x,255); setpx(cx+x,cy-y,159);
        
setpx(cx+x,cy+y,95); setpx(cx+y,cy+x,31);
        
setpx(cx-y,cy+x,0); setpx(cx-x,cy+y,63);
        
setpx(cx-x,cy-y,127); setpx(cx-y,cy-x,191);
        
e+=yy++; e+=y;
        if (
e>0) { e-=xx-=1e-=x; }
    }
}

//==================================
// line - Bresenham's line algorithm
//----------------------------------
void line(int x0,int y0,int x1,int y1,int c) {
    
int dx,ny,sx,sy,e,e2;
    if (
x1>x0) { dx=x1-x0sx=1; } else { dx=x0-x1sx=-1; }
    if (
y1>y0) { ny=y0-y1sy=1; } else { ny=y1-y0sy=-1; }
    
e=dx+ny;
  for (;;) { 
circle(x0,y0,c);
        
e2=e+e;
        if (
x0==x1 && y0==y1) { break; }
        if (
e2>ny) { e+=nyx0+=sx; }
        if (
e2<dx) { e+=dxy0+=sy; }
    }
}

//====================================
// getmsec - get msec since first call
// (tick counter wraps every 12 days)
//------------------------------------
int getmsec(void) {
    
int tc;
    static 
int ts=0;
    
struct timeval tv;
    
gettimeofday(&tv,NULL); tc=tv.tv_usec/1000+1000*(0xFFFFF&tv.tv_sec);
    if (
0==tc) { ts=tc; }
    return 
tc-ts;
}

//==================
// main - start here
//------------------
int main(void) {

    
gmlib(GMLIB_INIT);

    
hoser(); // hoser demo :D
    
sparkle(); // sparkle demo :D
    
gs=1// grayscale dither
    
hoser(); // hoser demo
    
cosmegg(); // cosmegg demo
    
gs=0// binary dither
    
goodbye(); // goodbye demo

    
sleep(5);

    
gmlib(GMLIB_CLOSE); // close geekmaster functions

    
return 0;



NOTE: To compile the source code, you must copy the eink header files from the gpl source code to your compiler include/linux folder (as seen in the source code #include statements). If using TCC, then copy the header files into /mnt/us/tcc/include/linux/. I plan to include these header files in the next release of the tcc compiler package.

And by the way, I hand-optimized the dither routines to work better when compiled with TCC. The demos are no longer 5 times faster when compiled with a cross-tool. But I had to deal with a gcc compiler optimization bug that required that I use a couple of extra temporary variables to prevent bad code generation. NOT fun chasing that one down!

I hope to see interesting things from you people, using this code that required significant study and experimentation to perfect. Good luck, and let's not see my efforts wasted. Do good stuff with this.

UPDATE: I just noticed an obsolete comment in the dither code. Ignore the "broken code" warning. That was fixed by adding temporary vars (the compiler optimization bug). Weird stuff happens when you OR complex logic terms together that NO amount of parantheses can fix.) All better now. [I removed the comment from the code above, but it is still in the download file.]
Attached Files
File Type: gz newtrix.tar.gz (14.2 KB, 550 views)

Last edited by geekmaster; 04-28-2012 at 05:56 AM.
geekmaster is offline   Reply With Quote
Old 04-28-2012, 05:32 AM   #2
geekmaster
Carpe diem, c'est la vie.
geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.
 
geekmaster's Avatar
 
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
I need feedback. Please leave some.

Come on! 88 page views and ZERO feedback?

What chance do I have that people will actually CREATE new stuff, stimulated by and using my code that I worked so hard on, when they cannot even create simple feedback?

Should I even BOTHER to invest more of my time and effort into creating a USEFUL code base that I give to you out of simple love of the art of technology? I am tempted to move on to iPad 3 development and leave all 9 of my kindles behind me (in the dust, so to speak). Is that what you want, when I have SO MUCH working (but unfinished) proof-of-concept code in many different aspects of kindle development (custom kernels, development and end-user tools, graphics and animation, input device sensor fusion, and so much more)? I was even working on a video game... People do not seem all that excited here -- perhaps I should move on to a "bigger pond" where I can make a bigger "splash"...

In MY opinion, the BEST part of the code above is the new 256-color grayscale RENDERING mode (to support povray or other apps that do not need pre-dithered images like the screensavers and other images on the kindle). In fact, I have a "mostly done" mandelbrot program that uses my new full 256-color (grayscale) rendering mode. Is ANYBODY even interested?



Last edited by geekmaster; 05-13-2012 at 07:49 PM.
geekmaster is offline   Reply With Quote
Old 04-28-2012, 02:15 PM   #3
qlob
Official Lurker
qlob ought to be getting tired of karma fortunes by now.qlob ought to be getting tired of karma fortunes by now.qlob ought to be getting tired of karma fortunes by now.qlob ought to be getting tired of karma fortunes by now.qlob ought to be getting tired of karma fortunes by now.qlob ought to be getting tired of karma fortunes by now.qlob ought to be getting tired of karma fortunes by now.qlob ought to be getting tired of karma fortunes by now.qlob ought to be getting tired of karma fortunes by now.qlob ought to be getting tired of karma fortunes by now.qlob ought to be getting tired of karma fortunes by now.
 
qlob's Avatar
 
Posts: 1,050
Karma: 7096675
Join Date: Apr 2012
Device: Kindle 3.4
I love it!!

I am trying it out as I type this. The beginning reminds me of the McDonalds logo.I really like it and the effort you put into this community. Even if no one else does, I APPRECIATE YOUR WORK!

qlobthehorse
qlob is offline   Reply With Quote
Old 04-28-2012, 02:29 PM   #4
giorgio130
Time Waster
giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.giorgio130 ought to be getting tired of karma fortunes by now.
 
Posts: 422
Karma: 289160
Join Date: May 2011
Device: Kobo Glo and Aura HD
I think the issue here with slow development is the site's audience, not much the device itself. Just have a look at the Nook Simple Touch section at XDA developers, they've done amazing stuff:
http://www.youtube.com/watch?v=JDk8a0leP4U

Nonetheless I always try your demos I plan to play with the code as soon as I have the time...
giorgio130 is offline   Reply With Quote
Old 04-28-2012, 04:33 PM   #5
kiri87
Member
kiri87 knows what's going on.kiri87 knows what's going on.kiri87 knows what's going on.kiri87 knows what's going on.kiri87 knows what's going on.kiri87 knows what's going on.kiri87 knows what's going on.kiri87 knows what's going on.kiri87 knows what's going on.kiri87 knows what's going on.kiri87 knows what's going on.
 
Posts: 16
Karma: 25544
Join Date: Feb 2012
Device: Kindle 3
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
Code:
undefined symbol '__invalid_size_argument_for_IOC'
error, which I fixed by adding
Code:
unsigned int __invalid_size_argument_for_IOC;
I hope this may help someone, especially any other Linux noob like me.

Quote:
Originally Posted by geekmaster View Post
New dithering code was written that is MUCH simpler and MUCH faster, and supports full 256-color 8-bit mode.
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:
Code:
for (x = 0; x < MX; x++)
		for (y = 0; y < MY; y++) 
			setpx(x, y, y%256);
Keep up the good work, Geekmaster!
Attached Thumbnails
Click image for larger version

Name:	wb0.png
Views:	447
Size:	3.3 KB
ID:	85823   Click image for larger version

Name:	dither16.gif
Views:	406
Size:	40.9 KB
ID:	85824   Click image for larger version

Name:	dither2.gif
Views:	431
Size:	13.7 KB
ID:	85825   Click image for larger version

Name:	dither2-edit.gif
Views:	389
Size:	2.2 KB
ID:	85826  

Last edited by kiri87; 04-28-2012 at 04:36 PM.
kiri87 is offline   Reply With Quote
Old 04-28-2012, 06:35 PM   #6
thatworkshop
hub
thatworkshop ought to be getting tired of karma fortunes by now.thatworkshop ought to be getting tired of karma fortunes by now.thatworkshop ought to be getting tired of karma fortunes by now.thatworkshop ought to be getting tired of karma fortunes by now.thatworkshop ought to be getting tired of karma fortunes by now.thatworkshop ought to be getting tired of karma fortunes by now.thatworkshop ought to be getting tired of karma fortunes by now.thatworkshop ought to be getting tired of karma fortunes by now.thatworkshop ought to be getting tired of karma fortunes by now.thatworkshop ought to be getting tired of karma fortunes by now.thatworkshop ought to be getting tired of karma fortunes by now.
 
thatworkshop's Avatar
 
Posts: 715
Karma: 2151032
Join Date: Jan 2012
Location: Iranian in Canada
Device: K3G, DXG, Kobo mini
Quote:
Originally Posted by giorgio130 View Post
I think the issue here with slow development is the site's audience, not much the device itself. Just have a look at the Nook Simple Touch section at XDA developers, they've done amazing stuff:
http://www.youtube.com/watch?v=JDk8a0leP4U

Nonetheless I always try your demos I plan to play with the code as soon as I have the time...
Same with me Geekmaster! Thanks for all your efforts.
Nook Simple Touch looks so good. The videos, for example this one, shows it's really responsive... Well, in terms of hardware specification, it's as good as Kindle Touch but Kindle seems way slower. ?!!!

Last edited by thatworkshop; 04-28-2012 at 07:26 PM.
thatworkshop is offline   Reply With Quote
Old 04-28-2012, 06:50 PM   #7
geekmaster
Carpe diem, c'est la vie.
geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.
 
geekmaster's Avatar
 
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
Quote:
Originally Posted by kiri87 View Post
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
Code:
undefined symbol '__invalid_size_argument_for_IOC'
error, which I fixed by adding
Code:
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:
Code:
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 of 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.

Last edited by geekmaster; 04-15-2016 at 02:33 AM.
geekmaster is offline   Reply With Quote
Old 04-28-2012, 08:25 PM   #8
jmseight
Zealot
jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'
 
Posts: 130
Karma: 10000
Join Date: Mar 2012
Device: Kindle 3G, Kindle Touch 3G, iRiver Story HD, Sony Reader
Hi Geekmaster,

Excellent demo! I was looking at the code and wondering what sv[] was. It was worth running to the end.

Anyway, I run into the header issue when I tried to compile it with tcc. I alway compile you code and run using tcc.

I notice the diterh code is different this time and will try to figure it out.

I was thinking about making a fractal demo with your code...

Also, when I saw the speckle demo, I remember when I was going to school one of my classmates made a random dot stereogram http://en.wikipedia.org/wiki/Random_dot_stereogram.

Thanks,
James

Last edited by jmseight; 04-28-2012 at 08:27 PM.
jmseight is offline   Reply With Quote
Old 04-28-2012, 09:08 PM   #9
jmseight
Zealot
jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'
 
Posts: 130
Karma: 10000
Join Date: Mar 2012
Device: Kindle 3G, Kindle Touch 3G, iRiver Story HD, Sony Reader
Hi Geekmaster,

I understand why one has to dither a 256 color (8-bit) image to 1-bit image, so during update there is no flash.

Would you please explain why you need to dither 256 color (8-bit) to 16 color (4-bit) grayscale?

If you need this, would you not simply chop off the last 4 bits? And there will be the flash during update, correct?

Thanks,
James
jmseight is offline   Reply With Quote
Old 04-28-2012, 09:37 PM   #10
geekmaster
Carpe diem, c'est la vie.
geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.
 
geekmaster's Avatar
 
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
Quote:
Originally Posted by jmseight View Post
Hi Geekmaster,

Excellent demo! I was looking at the code and wondering what sv[] was. It was worth running to the end.

Anyway, I run into the header issue when I tried to compile it with tcc. I alway compile you code and run using tcc.

I notice the diterh code is different this time and will try to figure it out.

I was thinking about making a fractal demo with your code...

Also, when I saw the speckle demo, I remember when I was going to school one of my classmates made a random dot stereogram http://en.wikipedia.org/wiki/Random_dot_stereogram.

Thanks,
James
tcc is great for utility apps, but for SOME of the graphics demos you pay a large performance penalty. Some apps run up to 5 times faster compiled with GCC instead of TCC.

Although tcc can compile 5x to 9x faster than gcc, the final code is much less optimized. In this demo, I hand-optimized some of the code (batching the dither per-page instead of per-pixel, loop unrolling, splitting common logical expression phrases and moving outside loop body, etc.). These are things done for you by a good optimizing compiler, but I did them in the code (adding to its size and complexity) to make it work better with tcc.

For most of my demos that run WIDE OPEN (no delays), it is worth running BOTH the gcc and tcc versions and comparing. The speckle demo (sparkle) is one such case -- you should see it run on the version I provided.

I compiled the gcc version like this:

arm-linux-gcc -O3 -o newtrix newtrix.c

The -O3 option tells it to do extra optimization.

I have a 256-color mandelbrot demo in progress. It is the original reason I began work on the 256-color dithering down to the 16-color hardware palette. But I used mostly existing code for a testbed, and kept that in the final program to provide various test "stages".

For my unreleased "kindlebrot - kindle mandelbot demo" I am holding off until I have a menu to select from the nice looking default parameter sets. I also need an input method to provide custom navigation in the mandelbrot set. The kindle is not so fast using floating point, so eventually I was thinking of an integer mandelbrot re-write.

By the way, you can use tccmake to link the math library like this:

tccmake kindlebrot -lm
geekmaster is offline   Reply With Quote
Old 04-28-2012, 10:07 PM   #11
geekmaster
Carpe diem, c'est la vie.
geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.
 
geekmaster's Avatar
 
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
@kiri87: Regarding your images showing the kindle 3 comparison of color palettes between wb0 (raw color values), dithered 16-color, and dithered 2-color, I see a clear off-by-one error. In retrospect it is obvious that for "inverted color" devices I need to SUBTRACT the dither offset instead of adding it.

This happens because the "normal" method of 8-bit and higher graphics is 0=black and 255=white, and this is how the new mxcfb device driver for the Freescale iMX508 integrated eink controller behaves. But for the older einkfb device driver used in the K3 and earlier that use the external epson broadsheet eink controller chip, the einkfb device driver assumes that color value zero is white instead of black (inverted color). A complication is the K4. Because it comes with SSH factory-installed in diags, I was doing my initial testing in an UNMODIFIED K4 (factory partitions, and not registered). When booted from diags, the K4 uses the new mxcfb eink driver to get full speed and power from the integrated eink controller. BUT (and this is a HUGE) when booting the K4 from main (with cvm and desktop framework) it runs in K3 compatibility mode using the old einkfb device driver. Not only is this eink compatibility mode slower and a lot more limited, it also uses the old inverted color palette (even when using its 8-bit framebuffer).

When handling inverted color in my older code, I immediately inverted the color value (~color) and processed all pixels as black 0. But for this NEW demo, now that all my code uses ioctl() calls for all eink updates, I instead use the "inverted color update" for the inverted color devices.

Now that I had a chance to sleep on what I thought looked like an "off by one" error at the top/bottom palette transition in the cosmegg demo, and taking the above information into account, it is plain to see that the color inversion affects the dithering so that instead of ADDING one to the 16-color palette when the "unused" bottom bits are greater than the dither threshold (in order to make the color MORE WHITE), we need to SUBTRACT one to make the color MORE WHITE on an inverted color palette. The inversion is now done at the last possible moment by the eink device drivers using the "inverted color update".

So the dithers need to ADD only for the normal color dithers but need to SUBTRACT for the inverted color dithers. I may have already compensated for this in the 2-color dithering... I will compare the two methods and fix it.

Thanks for giving me this feedback that helps me examine this from new directions.

UPDATE: I see while inspecting this code that the "right thing to do" is not to make the code conditional on white zero or black zero (like for K4main and K4diags), but to use dither tables that contain positive or negative values. One thing I realized while writing this is that 256-color mode requires that the bottom half-byte become zero, but the previous content dithers the bottom bit of the top half-byte. Dithering 4-bits can be done with a smaller 4x4 dither table with values 0-15.


Last edited by geekmaster; 04-29-2012 at 12:02 PM.
geekmaster is offline   Reply With Quote
Old 04-28-2012, 10:40 PM   #12
geekmaster
Carpe diem, c'est la vie.
geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.
 
geekmaster's Avatar
 
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
The list of numbers in sv[0] is called in the computer graphics industry a "display list". It contains commands and data that render an image when the list is "executed". The display list used in this newtrix demo only implements commands for "move", "line-to", and "exit". The value zero is an "escape" which can be followed by a command. This simple version only implements an "exit" command (a second value zero). Any command does an implicit "pen-up", and in this code any non-zero value after a zero is assumed to be a "line-to" with implicit "pen-down" AFTER the command executes.

You can think of a display list as a simple "machine language" executed by a software "graphics processor". The display list "language" can contain graphics commands that define one or more objects built from graphics primitives (2D: dot, line, circle, XY position, velocity, acceleration, 3D: sphere, tube, cube, XYZ position, velocity, acceleration, and you even define things like texture, transparency, and reflectivity). Display lists can also contain "subroutines" that display complex objects, and can be told to draw their object in different size, orientation, color, texture, and more. Display list subroutines can control animation using collision detection and particle physics (like gravity in the hoser demos). It is a custom language you define, so you can add what you want to it. When you add a new command to the display list language, you need to add code to the display list interpreter code to process that new command. You are only limited by your imagination. You could even script a feature length "animated motion picture" defined completely by a display list commands, which would give HUGE compression (a feature film in only a few KB, for example, but would grow a lot as you replace simple algorithmic textures and motion with detailed texture and motion capture).

At the end of the sv[] table you can see three zeros. The first zero is "command" (and pen-up), which is followed by a second zero "exit". The third zero is for segfault prevention when modifying the display list driver. A little farther up in the table you can see a solitary zero, which behaves as a "pen-up" command, used to cross the letter "t" in the touchscreen-captured "geekmaster" signature.

The "pen" draws with the same "shaded tubes" as the "hoser" demo, with tube diameter proportional to the same scale factor as the the signature dimensions. For those who have not watched it, the signature "scalable vector graphic" is displayed in the final "goodbye" demo after its animation has been running for awhile, starting so small it is barely visible at first, slowly growing until it covers a large part of the display. Because the background is doing continuous "color palette animation", and the signature is rendered on top of every background frame just before calling the eink update, the signature appears to "hover" above the animated background image while it slowly grows in size. You really need to see this effect. Perhaps I should post just the final stage of this demo, which I created specifically for a final "wow" effect for this program (close the show with a "bang").

EDIT: I added some links to external web pages. I recommend clicking the underlined links above and reading at least a little of the linked pages. Good stuff!

I have unfinished code that converts these display lists into "Hershey code" variant so that it can be rendered by my (also unfinished) "Hershey vector fonts" code. That way the above table can be converted into a simple character string, and rendered by the vector font code.

I also have some unfinished "Z-Buffer Device" code.



Last edited by geekmaster; 04-29-2012 at 12:43 PM.
geekmaster is offline   Reply With Quote
Old 04-28-2012, 11:27 PM   #13
xueyou2
Connoisseur
xueyou2 can eat soup with a fork.xueyou2 can eat soup with a fork.xueyou2 can eat soup with a fork.xueyou2 can eat soup with a fork.xueyou2 can eat soup with a fork.xueyou2 can eat soup with a fork.xueyou2 can eat soup with a fork.xueyou2 can eat soup with a fork.xueyou2 can eat soup with a fork.xueyou2 can eat soup with a fork.xueyou2 can eat soup with a fork.
 
Posts: 58
Karma: 9096
Join Date: Apr 2012
Device: none
It is awesome.I like to try technical work.It brings surprise.
xueyou2 is offline   Reply With Quote
Old 04-29-2012, 12:37 AM   #14
jmseight
Zealot
jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'jmseight knows the difference between 'who' and 'whom'
 
Posts: 130
Karma: 10000
Join Date: Mar 2012
Device: Kindle 3G, Kindle Touch 3G, iRiver Story HD, Sony Reader
Hi Geekmaster,

Thanks for the explanation about tcc.

I have a couple of questions:

1) I understand that I can compile in the Kindle with gcc with Debian and OptWare. Debian istaking up 500MB in my Kindle and I am seriously thinking about deleting. I am sure I don't want to take another 250MB for OptWare. Is there a more resource efficient way.

2) Would you please explain why you would want to dither 256 colors to 16 colors?

3) Since most non-e-book programs are written with 24-bit colors, I have been converting 24-bit color to 8-bit color, then from 8-bit to 2-bit by dithering. Maybe there is a quick way to combine the dithering with grayscaling in one operation...

4) Motion streogram will be an excellent demo on the Kindle. My classmate made a 3D rotating cube and hypercube on the computer display, and it made quite a impression.

Thanks,
James
jmseight is offline   Reply With Quote
Old 04-29-2012, 02:03 AM   #15
geekmaster
Carpe diem, c'est la vie.
geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.
 
geekmaster's Avatar
 
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
Quote:
Originally Posted by jmseight View Post
Q1) I understand that I can compile in the Kindle with gcc with Debian and OptWare. Debian is taking up 500MB in my Kindle and I am seriously thinking about deleting. I am sure I don't want to take another 250MB for OptWare. Is there a more resource efficient way.
A1) You can start with a much smaller image and just copy in the files you want to use. You can install optware in the same partition with the debian stuff. I started with 64MB but I kept running out of space and I had to keep extending it until it got to 2GB (max size for FAT fs). You can copy the files you really want to the FAT partition, but you need to replace any symlinks with COPIES of the symlinked files, then you do not need a loop mount. I have a bunch of apps that run fine on my kindle from the debian loop mount that run fine on the FAT drive (not using a loop mount). Not all those programs in the debian or optware partitions need a bunch of libraries, and you can always copy the ones you need.
Quote:
Originally Posted by jmseight View Post
Q2) Would you please explain why you would want to dither 256 colors to 16 colors?
A2) Because the einkfb and mxcfb eink device drivers ignore the bottom 4-bits and only display 16 colors (see my paldemo program for a photo from my kindle screen compared to a copy of the framebuffer). As it turns out, when you copy ANY 256-color images from a framebuffer, the contents have also been dithered just like my code does. You can load a raw framebuffer image into a program like IrfanView and do histogram analysis on it, and you will see that only 16 evenly-spaced colors are used in the 256-color palette (a sure sign of dithering). So the kindle programs that display images dither 256 color images into 16 colors, and any 256-color output I want to display correctly after truncating to the 16 hardware colors must also be dithered to those 16 colors. Because wb0 is not dithered, you can copy it to fb0 and do eips '' to see how it looks with the bottom 4-bits truncated, which can be fixed with dithering like I do in newtrix when the "gs=1" flag is set.
Quote:
Originally Posted by jmseight View Post
Q3) Since most non-e-book programs are written with 24-bit colors, I have been converting 24-bit color to 8-bit color, then from 8-bit to 2-bit by dithering. Maybe there is a quick way to combine the dithering with grayscaling in one operation...
A3) There is. In fact, I have some unfinished code that does this for color BMP files (easy to parse image format). Many modern file formats require linking your code to a compression library, and library calls can result in library version dependencies so you need to link different versions of your program for different library versions (not fun). I added BMP input to my "gmlib" functions to avoid such external library dependencies.
Quote:
Originally Posted by jmseight View Post
Q4) Motion streogram will be an excellent demo on the Kindle. My classmate made a 3D rotating cube and hypercube on the computer display, and it made quite a impression.
A4) I have always been fond of 3D. When I was 13 years old, I made my own anaglyph 3D glasses from index cards, cellophane tape, and red and blue colored cellophane salvaged from discarded "Easter basket" wrappers. Then I spent much of that "summer vacation" drawing many 3D images using red and blue colored pencils. I still have them, but the paper has become yellow (and brown around the edges where more air exposure) and brittle with age. When stereograms were new, I bought all the books, then framed posters (I have many) of random dot stereograms. In fact, a frame HELPS to view them -- just look at your reflection in the glass and move away from it until your reflection is at the same distance as the objects in the stereogram. Back in the day, I wrote animated stereogram programs for old DOS computers back when DOS was king... I still love 3D (we bought an LG 55lw5600 for christmas). It would be very easy to do random-dot stereogram animation in the kindle -- try it. My functions are not that difficult to use. I plan to finish my kindlebrot program, then my z-buffer 3d program, then I want to add eink support to a linux kernel bootable from MfgTool (for kindle recovery with GUI). ... But my JOB keeps intruding.


Last edited by geekmaster; 04-30-2012 at 12:33 PM.
geekmaster is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
geekmaster vacation geekmaster Kindle Developer's Corner 2 03-19-2012 09:18 PM


All times are GMT -4. The time now is 11:21 AM.


MobileRead.com is a privately owned, operated and funded community.