Tiny.magnify(11,7) + Line

You don’t move your mouse across the screen even if it feels like you do. You move your mouse across the table, or your desk, or something equally flat. The computer translates the mouse positions into integer coordinates that best fit the screen. Some positions might not be read, and gaps will manifest as the computer screen renders the path you scribbled. What your perception feels like the continuous motion of your hand will be translated into a scattered rain of tiny squares. I have recently been working on a prototype application for making short animations spawned by the Tiny icon drawing application. It immediately became evident that a 13×13 pixel canvas will never give me enough of a surface to reach the basic functionality I am looking for. I want my animation application to be as limited as possible, but I must deliver enough flexibility to let an experienced animator illustrate the basic principles of animation with ease. 13×13 pixels are just not enough. Something like 143×91 would be fine, if Tiny’s rudimentary drawing tool was to survive the resolution increase. But it didn’t. It felt like a pen that was running out of ink. As much as I dragged my mouse all over the canvas, it would spit a sequence of dashes instead of a line. I would have to squiggle really slow to get a continuos flow of pixels. An easy solution to the problem would be to catch all pairs of consecutive mouse positions, and device a procedure to approximate the line between them with new pixels. A couple of years ago John recommended me an excellent technical book written by dutch professor Leen Ammeraal entitled Computer Graphics for Java Programmers, and I remember the description of a pixel line algorithm at the end of chapter two. I told Brent about it and we engaged in the task of recreating it from scratch. It was a perfect activity for what we call PLW Basic Research, an initiative that aims at discovering (or rediscovering) basic non trivial things. An important constraint we forced on our design was to solve it with integer arithmetics. Some interesting ideas were found in the process. One of them is here. It features our working algorithm, scalable pixel resolution on the fly, and a random color switcher. The principal obstruction of this experiment is the lack of control, because it is impossible to guess what color to expect next. Our algorithm was very close in spirit to the classic Bresenham’s Line Algorithm from 1962, one of the first computer graphics algorithms of history, and the main difference between them is that our version doesn’t work as well as Bresenham’s.

bersenhamgray2.gifbersenhamcolor.gif

Leave a Reply