eink algorithmic art shell scripting

[geekmaster]

Originally Posted by PoP

Sure. In its time I liked APL too though it bit me more than once.

I just want to plead innocence and point that on my KK v3.3 (blame it on an older or perhaps buggy shell interpreter) I had to expand constructs such as

while [[ $x0 -ne $x || $y0 -ne $y ]];do

into

while [[ $x0 -ne $x ]] || [[ $y0 -ne $y ]];do

to make the script work (loop would otherwise fail with an error message).

I started with much more modern shell constructs (double-paren conditionals, etc.) and I had to apply forced regression to my code to backport it to the old busybox shell used in the kindles. This was not tested on a K3 yet, so thanks. I would probably shorten that line by changing "]] || [[" to "-o" though, which was the "old fashioned" way of dealing with compound arithmetic comparisons. Apparently even older kindle firmware versions will require even more shell feature regression.

The K3 also needs to be adjusted for 300 byte wide lines and the opposite color. This script has $MX $MY $HX and $HY vars to adjust, but you probably need to adjust other scale factors in the "draw3d" function as well.

P.S. I still have an APL option ROM for my old Centronix printer. Of course, PRINTING an APL program was generally a waste of time, because APL was considered (even by those who used it) to be a "write-only" language.

EDIT: I *do* use in-line comments in places where it aids readability. Also, I reverted to "-a" and "-o" for compound conditionals in rippleweave 1.0a in its first post (but not the .gz file yet), for K3 compatibility.

EDIT 2: Because this reply wrapped to a new page in this thread, I wish to mention that we are discussing the "rippleweave" script that generates 3D function plot images like this:

click image to see the script

P.S. Thanks PoP for the animated GIF shown above (and on the first post)!

[lukeroge]

I tried this out and it looked really neat, thanks for posting it :3

[geekmaster]

When I get back, I hope to see the following games running in #!/bin/sh using scripts from this thread as a guide:

* HINTS:

Spoiler:

We can draw filled circles by controlling the "count=" param of "dd", using distance between left and right x-coords on each row, in a "filled midpoint circle agorithm". We can draw up to 600 consecutive white pixels like this:

initvar () {
  W=$(echo -e '\xff');W=$W$W$W$W$W$W;W=$W$W$W$W$W;W=$W$W$W$W$W;W=$W$W$W$W # 600px white
}
...
echo -n $W|dd of=/dev/fb0 bs=1 count=$((x1-x0+1)) seek=$((y0*VX+x0)) 2>/dev/null

And we can draw black pixels from /dev/zero, as shown in previous scripts in this thread.

For fastest eink screen updates, we should use only all-white or all-black pixels (no gray pixels). We can use dithering for grayscale pixels (shadows). A 2x2 checkerboard makes a nice gray fill pattern.

We can make a nice blitter using "dd" to iteratively copy individual scan lines from a rectangular (or circular) portion of a raw image file to a portion of the eink screen. We can use this to copy sprites, game tiles, and bitmap text characters from a character font map and game resources image file.

We can use "hexdump" to read pixels from the framebuffer, if we want to try OCR techniques or other image processing of framework graphic content place onscreen by kindlets or framework menus. We can see how to process binary files with "hexdump" in the touchpaint script here:

https://www.mobileread.com/forums/sho....php?p=1989102

Good luck!

[aditya3098]

a simple 3d modeling tool for the kindle?

[geekmaster]

Originally Posted by aditya3098

a simple 3d modeling tool for the kindle?

The whole point is to show that you can do a lot more than people think with whatever tools you have available.

You are only limited by your imagination.

Shell scripts are used in kindle debricking and jailbreaks (RUNME.sh), and for beginners who may not know what to type at a command line, shell scripts can provide a GUI.

Shell scripts do not need a native compiler, or a cross compiler. Although we could have used lua or awk, those are not installed on many embedded devices, but they all have /bin/sh.

And despite multiple claims on the net that you cannot process binary files with sh, you can see from my scripts that you can. I read binary event data in touchpaint, and I output binary data to the framebuffer in the other scripts.

An additional thing is that I show how to do math functions using shell scripts.

Of course, these programs can be translated to C for more speed, but /bin/sh makes a fine "language" for quick prototyping.

[aditya3098]

you know, kt comes with /bin/bash built-in

[geekmaster]

Originally Posted by aditya3098

you know, kt comes with /bin/bash built-in

As I understand this implementation of busybox, bash is just a synonym for sh, so scripts can include either shell on the shebang line without failure.

Now, the reason I chose to do this in shell script is BECAUSE it is the WORST POSSIBLE tool for the job, but also has UNIVERSAL availability on ALL busybox distros. Things like awk and lua are not in all distros, but sh is (and even bash is not always there). I did this to show that anything is possible and you do not need to be limited by your tools if you master them.

So this will work on a bricked kindle as long as you have ssh from main or diags (on the k4 they have different busybox versions with different built-in commands).

Now that I have shown that you can do anything you want with /bin/sh (but with a speed penalty), I plan to add a few finishing touches (touchscreen button support and onscreen keyboards for k4 and touch), then move to the other extreme of C with optimized assembler code for the inner loops (graphics blitting and custom decompression).

But when I have time. I have many things demanding my time in big ways right now...

Anyway, even with the worst of tools, you can do useful and interesting things, if you set your mind to it. Computers are so fast compared to what I grew up with, that even crude and slow tools such as /bin/sh are MUCH faster than hand-crafted assembler language was back in the day. The limiting factor on graphics is that eips does full screen updates (which are just as slow called from C with ioctl() as they are here). The way to speed up graphics is to do partial screen updates. I am not sure how to do that with eips (if even possible).

[kaminkatze]

Pixel based, kindle 3 game of life.

Spoiler:

#!/bin/sh

#===========================
# initvar - init global vars
# usage: initvar w h
#---------------------------
initvar() {
  DZ=/dev/zero DN=/dev/null DF=/dev/fb0 BF=/tmp/fb0
  FW=$1 FH=$2 MX=$(($1-1)) MY=$(($2-1))
  LL=300 D='0' L='F'
}

#===========================
# usage: load x y name
#---------------------------
load() {
  local x=$1 y=$2 name=$3
  case "$name" in
  glider)
    setpix $DF $((x+1)) $y $L
    setpix $DF $((x+2)) $((y+1)) $L
    setpix $DF $x $((y+2)) $L
    setpix $DF $((x+1)) $((y+2)) $L
    setpix $DF $((x+2)) $((y+2)) $L ;;
  esac; eips ''
}

#===================================
# usage: setpix f x y v
#-----------------------------------
setpix() {
  local x=$((($2+$FW)%$FW)) y=$((($3+$FH)%$FH))
  local b=$(hexdump -s $(($y*LL+$x/2)) -n 1 -e '"%02X"' $1)
  { [[ $(($x%2)) == 0 ]] && echo -en "\x$4${b#?}" || echo -en "\x${b%?}$4"; } \
  | dd of=$1 bs=1 count=1 seek=$(($y*LL+$x/2)) 2>$DN
}

#===================================
# usage: getpix f x y
#-----------------------------------
getpix() {
  local x=$((($2+$FW)%$FW)) y=$((($3+$FH)%$FH))
  local b=$(hexdump -s $(($y*LL+$x/2)) -n 1 -e '"%02X"' $1)
  [[ $(($x%2)) == 0 ]] && echo ${b%?} || echo ${b#?}
}

#===================================
# update - update field
#-----------------------------------
update() {
  local bl=0 bm=0 br=0 cl=0 cm=0 cr=0 tl=0 tm=0 tr=0 c
  cat $DF > $BF
  for x in $(seq 0 $MX); do
  for y in -1 0; do
    tl=$cl tm=$cm tr=$cr cl=$bl cm=$bm cr=$br
    bl=$(getpix $BF $((x-1)) $y | tr 'F' '1')
    bm=$(getpix $BF $x $y | tr 'F' '1')
    br=$(getpix $BF $((x+1)) $y | tr 'F' '1')
  done
  for y in $(seq 0 $MY); do
    tl=$cl tm=$cm tr=$cr cl=$bl cm=$bm cr=$br
    bl=$(getpix $BF $((x-1)) $((y+1)) | tr 'F' '1')
    bm=$(getpix $BF $x $((y+1)) | tr 'F' '1')
    br=$(getpix $BF $((x+1)) $((y+1)) | tr 'F' '1')
    c=$((bl+bm+br+cl+cr+tl+tm+tr))
    v=$(getpix $BF $x $y)
    [[ $c -lt 2 -o $c -gt 3 ]] && v=$D
    [[ $c -eq 3 ]] && v=$L
    setpix $DF $x $y $v 
  done; done; eips ''
}

#===================================
# loop - update loop
# usage: loop steps
#-----------------------------------
loop() {
  local c=$1 p=0
  while [[ $p -lt $c ]]; do
    update; p=$((p+1))
  done
}

eips -c
initvar 8 8
load 0 0 glider
loop 1

(Hope I haven't violated to many of your style constrains.)

[geekmaster]

Originally Posted by kaminkatze

Pixel based, kindle 3 game of life.
...
(Hope I don't have violated to many of your style constrains.)

My style is just so I can "absorb" as much code as possible on an 80x25 display without interrupting my thoughts with vertical scrolling. You did great in that respect.

I especially like how you are caching the framebuffer on ramdisk. I considered storing random access data in a file on /tmp to use as a large array. Shell arrays do not seem to work in my busybox version, so I was planning to fake it with "dd".

Some minor tips:
1) Inside $(( )) expressions, vars do not need $ except when numeric parms $1 $2, etc. You can see in my examples. I see that you left the $ off in some cases, but kept it in others.

2) I originally had a setpixel function, but testing showed that it was quite a bit faster on my 5.0.0 firmware to put the "dd" inline, and wrapping a single line dd call in a function actually consumes more screen space. But it *does* make it more readable though, and in your case it allows you to pipe it to other commands, so it may well be worth the speed trade-off here if simple to understand code is the goal (which is what I aim for in tutorials like this thread).

3) I do not know if you noticed, but when you have multiple inline variable assignments (with no ';'), you cannot use a value earlier in the same line. This is why I sometimes do "; local " in the middle of a line. The "local" statements prevent a function from changing values that belong to its parent.

This does not seem to do anything other than clear the screen on my K3 with firmware 3.3, and I do not have time to study your code in any detail right now. Are there any special requirements to run this?

P.S. "Hope I don't have" should be "Hope I haven't", and I bumped your karma to 2600 for the great hack.

[kaminkatze]

Originally Posted by geekmaster

2) I originally had a setpixel function, but testing showed that it was quite a bit faster on my 5.0.0 firmware to put the "dd" inline, and wrapping a single line dd call in a function actually consumes more screen space. But it *does* make it more readable though, and in your case it allows you to pipe it to other commands, so it may well be worth the speed trade-off here if simple to understand code is the goal (which is that I aim for in tutorials like this thread).

The goal was to access single pixels. With 4 bits per pixel one dd call set 2 pixels. "setpix" reads 2 pixels, modifies one side and writes them back. But a 2x2 pixel grid and dd updates would be the better choice.

Originally Posted by geekmaster

This does not seem to do anything other than clear the screen on my K3 with firmware 3.3, and I do not have time to study your code in any detail right now. Are there any special requirements to run this?

You should see the glider in the top left corner. At the moment only a 8x8 pixel field is updated. Change the last line to "loop 100" so it runs more iterations.

[geekmaster]

Originally Posted by kaminkatze

The goal was to access single pixels. With 4 bits per pixel one dd call set 2 pixels. "setpix" reads 2 pixels, modifies one side and writes them back. But a 2x2 pixel grid and dd updates would be the better choice.


You should see the glider in the top left corner. At the moment only a 8x8 pixel field is updated. Change the last line to "loop 100" so it runs more iterations.

Yes, I can see it when I get out my stereo microscope.

I was planning to try a different approach when I get around to supporting the K3. There are two options. The easiest is to ASSUME that the kindle has 300 byte-wide pixels per line, with values "dd if=$DZ of=$DF ..." or "echo -e '\xff'|dd of=$DF ...". Another option I thought of was to use a 600-byte wide /tmp/buffer (to hold a scan line for both touch/k4 8-bit pixels or the k3/dx 4-bit pixels) and then for the k3/dx draw 4 different pixel pair bytes to the framebuffer based on the values (\x00 \xf0 \x0f \xff). Either of my methods should be faster than yours. Also, updating the screen too fast will make the eink drivers not even bother to update the display, which could need a "usleep 80000" call added after the eips '' call.

[PoP]

Originally Posted by geekmaster

...
The K3 also needs to be adjusted for 300 byte wide lines and the opposite color. This script has $MX $MY $HX and $HY vars to adjust, but you probably need to adjust other scale factors in the "draw3d" function as well.
...

done:

#!/bin/sh
######################################
# rippleweave - algorithmic art script
# version 1.0a           by geekmaster
######################################

#===========================
# initvar - init global vars
#---------------------------
initvar() {
  DN=/dev/null DF=/dev/fb0 MX=599 MY=799 HX=300 HY=400
  set $(eips -i|grep line_length); VX=$4
  FP=1000 # fixed-point scale factor
  FH=500 # FP/2 (for rounding)
  PI=3142 # PI (scaled)
  P2=6283 # 2*PI (scaled)
  PN=-3142 # -PI (scaled)
  KQ=2 # K3 pixels per byte
}

#==================================
# line - Bresenham's line algorithm
# usage: line x0 y0 x y
#----------------------------------
line() {
  local x0=$(($1/$KQ)) y0=$2 x=$(($3/$KQ)) y=$4; local dx dy sx sy e e2 xw xp=$x0
  if [[ $x -gt $x0 ]];then dx=$((x-x0));sx=1; else dx=$((x0-x));sx=-1;fi
  if [[ $y -gt $y0 ]];then dy=$((y0-y));sy=1; else dy=$((y-y0));sy=-1;fi
  e=$((dx+dy)); echo -en "\xff${b#?}" | dd of=$DF bs=1 count=1 seek=$((y*VX+x)) 2>$DN
  while [[ $x0 -ne $x -o $y0 -ne $y ]];do
    xw=$((x0-xp)); [[ $xw -lt 0 ]]&& xw=$((-xw))
    echo -en "\xff${b#?}" | dd  of=$DF bs=1 count=1 seek=$((y0*VX+x0)) 2>$DN
    e2=$((e+e))
    if [[ $e2 -gt $dy ]];then e=$((e+dy));x0=$((x0+sx));fi
    if [[ $e2 -lt $dx ]];then
      xp=$x0;e=$((e+dx));y0=$((y0+sy))
    fi
  done;
}

#=================================
# line3d - draw 3D line to (x,y,z)
# usage: line3d x0 y0 x y z cx cy
#   x,y:-50..50 z:-150..150
#   cy,cy:center graph coords
#   x0,y0:old graph coords
# STDOUT: xg yg (new graph coords)
#---------------------------------
line3d() {
  local x0=$1 y0=$2 x=$3 y=$4 z=$5 cx=$6 cy=$7; local xg yg
  xg=$((cx+x*6+(y*2))); yg=$(((cy-y*4+x*2)-z))
  [[ $x0 -ge 0 -a $y0 -ge 0 ]]&& line $y0 $x0 $yg $xg
  echo $xg $yg
}

#==================================
# sin - Taylor series sine function
# usage: sin x  (-PI..PI)
# STDOUT: sin(x)  (0..1K)
# O(5) @ +-90 deg, O(7) @ +-180 deg
# 1K fixed-point scale factor 
#----------------------------------
sin() {
  local x=$1
  while [[ $x -gt $PI ]];do x=$((x-$P2));done
  while [[ $x -lt $PN ]];do x=$((x+$P2));done
  local a=$x xs=$(((x*x+FH)/FP))
  local xn=$(((x*xs+FH)/FP)) fn=6 # O(3)
  a=$((a-(xn+fn/2)/fn)) xn=$(((xn*xs+FH)/FP)) fn=$((fn*20)) # O(5)
  a=$((a+(xn+fn/2)/fn)) xn=$(((xn*xs+FH)/FP)) fn=$((fn*42)) # O(7)
  a=$((a-(xn+fn/2)/fn)); echo $(((a+FP+1)/2))
}

#==============================
# mexhat - mexican hat function
# usage: mexhat x y  (-50..50)
# STDOUT: mexhat  (*1K)
#------------------------------
mexhat() {
  local x=$1 y=$2; local yf yx xf xs rs s
  yf=$((y*FP/13)); ys=$(((yf*yf+FH)/FP))
  xf=$((x*FP/13)); xs=$(((xf*xf+FH)/FP))
  rs=$((xs+ys)); s=$(sin $rs)
  if [[ $rs -gt $((FP*8/10)) ]];then echo $((s*FP/rs))
  else echo $((FP*18/10-rs));fi
}

#================================
# rippleweave - 3d function plot
# mexhat 8-way symmetry graph
# (800x600 landscape mode)
#---------------------------------
rippleweave() {
  local cx=$HY cy=$HX y1 y2 y3 y4 y5 y6 y7 y8
  line 0 0 $MX 0; line $MX 0 $MX $MY; line $MX $MY 0 $MY; line 0 $MY 0 0
  for y in $(seq 0 2 50);do
    y1=-1 y2=-1 y3=-1 y4=-1 y5=-1 y6=-1 y7=-1 y8=-1
    for x in $(seq 0 2 50);do
      f=$(mexhat $((x-50)) $((y-50))); fg=$((-150*f/FP))
      set $(line3d $x1 $y1 $((x-50)) $((y-50)) $fg $cx $cy); x1=$1 y1=$2
      set $(line3d $x2 $y2 $((x-50)) $((50-y)) $fg $cx $cy); x2=$1 y2=$2
      set $(line3d $x3 $y3 $((50-x)) $((50-y)) $fg $cx $cy); x3=$1 y3=$2
      set $(line3d $x4 $y4 $((50-x)) $((y-50)) $fg $cx $cy); x4=$1 y4=$2
      set $(line3d $x5 $y5 $((y-50)) $((x-50)) $fg $cx $cy); x5=$1 y5=$2
      set $(line3d $x6 $y6 $((y-50)) $((50-x)) $fg $cx $cy); x6=$1 y6=$2
      set $(line3d $x7 $y7 $((50-y)) $((50-x)) $fg $cx $cy); x7=$1 y7=$2
      set $(line3d $x8 $y8 $((50-y)) $((x-50)) $fg $cx $cy); x8=$1 y8=$2
      eips '' # update display (removed from line function for speed)
    done
  done
}
                    
# lipc-set-prop com.lab126.powerd preventScreenSaver 1
# killall -stop Xorg cvm # pause framework

eips -c
initvar # init global vars
rippleweave # 3d function plot

dd if=/dev/fb0 bs=1K count=512 of=/mnt/us/rippleweave.raw
# killall -cont cvm Xorg # resume framework
# lipc-set-prop com.lab126.powerd preventScreenSaver 0

[geekmaster]

tangle

Here is a little "something" for the K3 I whipped up, inspired
by the K3 graphical exploits of PoP and kaminkatze:

...tangle:

Spoiler:

PHP Code:

#!/bin/sh
######################################
## tangle - triangle fun for the K3 ##
## version 1.0        by geekmaster ##
##----------------------------------##
## WARNING: K3 eips '' very slow... ##
## so use eips only in OUTER loops! ##
######################################

#=================================
# initvar - initialize global vars
#---------------------------------
initvar() {
  B=$(echo -e '\xff');B=$B$B$B$B$B;B=$B$B$B$B$B;B=$B$B$B$B;B=$B$B$B
  DZ=/dev/zero DN=/dev/null DF=/dev/fb0 VX=300
}

#========================
# bangle - black triangle
# usage: bangle x y h
#------------------------
bangle() {
  local x=$1 y=$2 h=$3
  for i in $(seq 0 1 $h); do
    echo -e $B|dd of=$DF bs=1 count=$i seek=$(((y+i)*VX-i/2+x)) 2>$DN
  done; eips ''
}

#========================
# wangle - white triangle
# usage: wangle x y h
#------------------------
wangle() {
  local x=$1 y=$2 h=$3                                                                                                                      
  for i in $(seq 0 1 $h); do                                                                                                                
    dd if=$DZ of=$DF bs=1 count=$i seek=$(((y+i)*VX-i/2+x)) 2>$DN                                                                       
  done; eips ''                                                                                                                                      
}   

#=================================
# tangle - triangle fun for the K3
#---------------------------------            
tangle() {
  bangle 150 250 284
  wangle 150 275 242
  bangle 150 300 100
  bangle 100 400 100
  bangle 200 400 100
  wangle 150 320  66
  wangle 100 420  66
  wangle 200 420  66
  bangle 150 400  50
  bangle 125 400  25
  bangle 175 400  25
  bangle 150 450  25
  wangle 150 416  25
  bangle 150 335  42
  bangle 100 435  42
  bangle 200 435  42
  eips 19 28 "Tangle  1.0"
  eips 18 30 "by Geekmaster"
}

eips -c # clear screen
initvar # init vars   
tangle # triangle fun for the K3 


[B]

WARNING: K3 eips '' very slow...
so use eips only in OUTER loops!

....FAQ:

Spoiler:

Q1) Why is geekmaster always editting his old posts?
A1) Severe typophrenia: .. http://justinharder.la/stills/item/typophrenia/

Q2) Can this guy be cured?
A2) No way! The difference between genious and insanity is a very fine line:

.....http://www.answerbag.com/q_view/266525

EDIT: I did this as a quick demo, to show that we can do fast framebuffer graphics by using a larger "dd count=" value for large area fills, as I did here. I recommend modifying the midpoint circle algorithm to use a similar method for filled circles, to be used in Conway's Life, Reversi (Othello) or other "go"-based games, checkers, bingo, and just pure graphic artworks. Amazing what we can do with simple shell scripting and a little imagination, isn't it?

[geekmaster]

Originally Posted by PoP

done:

PoP! Thanks for backporting rippleweave to the K3 using the "double-width pixel" method. It works great! (Now we need a version for the DX and DXG ).

[geekmaster]

Originally Posted by lukeroge

I tried this out and it looked really neat, thanks for posting it :3

You are welcome! I appreciate the feedback! It keeps me going (and going... and going... like the energizer bunny.)