Steffest Digitale Pulptuur

2026

2 berichten

Boox E-Ink Draw

booxdraw.png

As you might already have deduced: I like to draw.
And maybe harder to believe for a Nerd like me. I also enjoy sitting outside in the sun.

Combining these 2 proves a challenge though ... The best drawing experience I find on the iPad, but that is totally not suited to be used outside: the screen is barely visible.
I solved that by using a device with an eInk display: a Boox Note Air 4C.
Lovely device - except; it doesn't have a good drawing app.
Which is a bit weird because the internal note taking apps on the Boox offer a surprisingly pleasant drawing experience: zero-latency, a few good brush presets .... it would be ALMOST doable to use those as drawing tools.
Except: they store every stroke as vector object, and when the image gets more and more complex, the speed goes down the drain and you're staring at a loading screen half of the time.

The devices runs on Android.
There are a few good drawing apps on Android, but let's be honest ... it is not even a pale shadow of the super smooth drawing apps that an iPad has... sometimes, the closed garden of IOS pay off in app quality...
To be blunt: drawing on Android SUCKS.
It's just to sluggish and slow to be any fun.
Some devices solve that by just throwing more horsepower at the problem, but not my eInk device ...
My browser based dpaint.js also runs on the device, and not even worse then any other generic Android drawing app, but still to slow.

But how do the Boox native apps manage to offer that super-smoot zero-latency drawing in their apps?
The answer is as simple as it is brilliant: they bypass the Android layer and talk directly to the screen controller.
The screen controller has a few embedded system brushes, and a native library that translate those hardware brushes to software.
So when you draw; they freeze the Android screen, and release it again when you stop drawing. Brilliant !!!

Of course this only works on their devices, but that's good enough for me.
I want that, but then in my own app.

Only... documentation is incomplete, missing, outdated, or just plain wrong, and the system libraries needed are exatly that: system libraries that a 3rth party app can't access.
Boooohhhh!!

But of course, it Android and Android runs of top of a linux-like system, which are all open so ....
Enter the hacking mentality.

Decompiling and reverse-engeneering system apps is quite easy in this age of AI agents.
So after a few days of hacking ...

Here is "Boox E-Ink Draw"
It uses the device specific system-brushes to get that zero-latency drawing that we all love so much.
And it does slow down because the strokes are 
baked into a bitmap layer, not stored as a ever growing pile of vectors.

I only tested in on a Note AIR 4C, because that's the only Boox device I have, so it would be good to collect some feedback from users on other devices.

It's open source, free, simple but functional, and most of all: it offers a zero-latency drawing experience.

Source code and download links to the APK at: https://github.com/steffest/Boox-EinkDraw/

So here's a warm shoutout to ONYX or BOOX, the company:

you offer best-in class e-Ink writing and drawing tech. Your zero-latency strokes are the reason we love and buy your products. There are developers out there who want to pour their resources into developing for your platform, but for *peeps" sake... why do you make it so hard to get the information we need to do so? Please, pretty please - update your dev channels with some up-to-date info and code samples, so we don't have to guess and/or decompile your apps just to see how things work.


Oh, and the best part: it saves files in the same format as Dpaint.js , so if you need more advanced graphic stuff that is not present in this Android app, you can ping-pong between the 2 to get the best of both worlds.

SideQuest completed!
Back to the main game.

Happy drawing !

Graphics, in English, ProgrammingReacties (1)

Rubbur

Another RSync - another demo.

I made "RUBBUR"



Released at RSYNC 2026


The starting point was this track I made in Ableton Live.
I was playing around with the very nice "The Mouth" VST plugin, not knowing what I was doing, and suddenly out came this funky wobble bassline with this rubbery synth on top.
I couldn't reproduce it if I wanted too, haha.
I made a track around it and was bobbing my head on the beat.
Bam! Demo idea!

I have been exploring the Amiga hardware recently, from a software developer point of view, trying out what you can do with BPLCON1 etc. (Hey! you can set the horizontal offset for the odd and even planes separately! cool!) and finally wrapped my head around how to use switching bitplane pointers each scanline to do all these vertical stretching and scrolling things you see so often in Amiga demos.

After converting the song to tracker format, it turned out the be HUGE (in terms of diskspace) and I had quite a hard time trimming it down. I already had build some batch-sample squeezing features in my own BassoonTracker, but OpenMPT - the Swiss army knife for tracker files - has a much more finer control - and proved to be the perfect tool to get the size down, obviously in exchange for some audio quality, but hey ... it's Amiga! It can be crunchy!

I landed on 290kb for the tune. Still large, but doable.
Here's the tune in Bassoontracker

Vamos

Another thing I discovered is vamos - it's kind of like Wine (the windows emulator, not the drink) but then for Amiga.
It allows you to run Amiga command line applications directly on Windows or Mac at lightning speeds.
And low and behold! It works perfectly fine with the SAS/C compiler.
Sweet!
Now I can compile for Amiga on all platforms - including the Amiga itself - using the exact same compiler and setup.

Build System.

Having fast iteration times make all the difference.
I ended up using this "autorun" setup.

On the amiga side, I run this script.

LAB loop
IF EXISTS run.flag
DELETE run.flag
smake
a
ENDIF
WAIT 1 SEC
SKIP loop BACK

This checks for a file: "run.flag", and if it exists, it compiles and runs the program.
Then, whenever I save a source file on my mac/windows; a filechange-listener writes to this this "run.flag" file.
The Amiga picks it up, compiles and runs the demo.

So, whenever I save a file, a second later, the program runs on Amiga.
cool!

And I was pleased to find I'm getting more fluent at writing C.
I don't mean "better", per se, but at least I wasn't fighting compiler and syntax errors all the time, so I could focus on getting something done, not HOW to get it done.

And - hip hip hooray! - I made the step to actually include some assembler code in my project.
Baby steps, but it's a plasma like effect that ran far too slow in C.



I still can't believe that actually worked. Yay!
So now I have a good example how to move performance critical code to an assembler function and call that function from C.
Nice!

To recap:

Things I learned

  • how to flip an image horizontally using code
  • how to use functions in assembler to speed up operations and call them from C
  • how to scroll a screen horizontally
  • how to use vamos to run the SAS/C compiler on osX and windows
  • I moved from shrinkler to cranker for compression. Shrinkler compresses better, but cranker is faster to decompress.
  • in the end, I avoided compression alltogether. If all assets fit on a single floppy, it's simpeler and visualy nicer to keep them uncompressed.
  • another thing I figured out but did't use, was how to use the assembler INCBIN thing to include binary data in the executable. Good to know if I ever want a single file demo. For now, the approach to have a light startup exe to display a loading screen and post-load the data is fine.

Things I want/need to improve in future productions

  • get a hold of timing ... Sync is all over the place and behaves differently on different machines. No doubt my code is still too slow, but at the VERY least I should measure how many cycles each part of the code takes. This is the reason why most effects run a bit faster on a 1200. I beat-synced the thing to be in sync on my machine, but the timing will be slighty of on other machines. This sucks ... To be improved in the next production.


Reacties (2)