So some time ago I was wondering about writing a language agnostic graphics terminal.My plans fell a bit short and I was only able to product a display device.

This is not complete yet but supports drawing.Right now it just reads a file with commands and produces the shapes.Eventually I will enable the program to receive "piped" commands so you'll not need to produce a file.

Q: Why did I make this?A: Well some languages (especially very old or archaic ones) were designed before graphics terminals were popular. This gives people a way to draw static graphics (think science data) without having to resort to building libraries at the system level.

Q: Why are you not blitting shapes to a canvas?A: I'm using LTK, it's canvas object demands shapes be stored in memory. (might move to displaying bitmaps later)

Q: But we can already draw shapes in CL right? This isn't really needed.A: Yes but this goes beyond that, any language can now draw shapes without libraries. Even horrible ones.

Q: Ok you're just loading shapes from a file. Not a spectacular feat.A: For now yes, however eventually I will enable command piping for Linux/Unix OS's.This means you can just pipe the commands into the display rather than have to export them to file.

Here are the commands for drawing, (each one must be on it's own line in the source file)Also, please only use whole numbers in drawing commands. I've not yet accounted for floats and fractions. Use ROUND or FLOOR if need be before feeding commands in.

Preface: Every program you write for learning something is a good and neccessary program, even if others disagree.

I think I do not need to explain that (load "ltk.fasl") is not a really good idea, because the ".fasl" extension is implementation dependent and there is no guarantee that CL can find the file at all. But the project is still very small, an ASDF system definition can be written later on.

A more serious issue is that writing code in the :LTK package can easily clobber important LTK definitions so you should better write:

(:use :cl :ltk) means that you can still use all CL and LTK functions with no need for cl: or ltk: prefixes.

But instead of nagging around I wanted to tell a copletely different story.

Here is what I meant with "you can have pixel access if you put a Tk photo object on the canvas" in the #lisp irc channel a while ago. This is the standard trick if you want to write a freehand drawing program in Tcl/Tk.

Every Tcl/Tk version on every operating system can read PBM (1-bitplane), PGM (greyscale), PPM (color with more than 1 bitplane), and GIF images, where PPM is a particularly simple image format:

Pixel_Outlaw wrote:Much of my time on the week is take up by my day job...

Same problem here...

Some hundred years ago (at least it seems so to me) I had an Amstrad PPC 512 MS-DOS machine with a 320x200 pixel LCD display. At that time I had lots of fun by writing little BASIC programs drawing lines and circles and similar stuff on the screen. But I also remember how limited the capabilites of such simple graphics langages were compared to OpenGL or similar 3d-rendering languages today. But nontheless I think it sounds like real fun to have a Tk plotting widget that could be remote-controlled from Common Lisp.

I just remember in the context of math notation that there is a book Turtle Geometry by Hal Abelson (author of SICP) and others that explains math and computer programming by simple turtle graphics programs. Do not laugh, the book evolves from simple turtle moves to 2d and 3d geometry and finally in the last chapter to a turtle graphics simulator of Einstein's Theory of Relativity, and everything explained in an understandable language.

If you look in the internet there are floating around PDF copies of outdated versions of the book (outdated in the sense that they aren't sold anymore, the math and the programs are still 99% the same in the newer versions).

I'm from Germany and not a native english speaker, so I'm not sure if "cords" is a typo, because usually I read "coords" (with "oo") as abbreviation for "coordinates". Of course you are free to name your variables whatever you want.

If the programs becomes larger, the *shape-lookup* alist should be replaced by a hash-table or a string parser (if the shape has more than one character), but this not really important at the moment.

I will try to find a way to implement some LOGO-like turtle commands in the next few days, what needs additional handling of the turtle position and rotation angle. I don't want the program to become LOGO-specific, but I think it would be fun to be able to run vector-oriented LOGO commands as well as plotting commands using rectangular x/y-coordinates.

Thank you for cleaning up my code!I've replaced my old copy with your additions.Odd that you mention LOGO. It was actually my first language as a small grade school boy.Without knowing I was programming. We entered LOGO commands into the Apple ][e computers in school following instructions to make things like houses and stars in LogoWriter. I recall there being a lot of green, purple and white on those machines.

I've toyed with LOGO and CL before. At one point I was making functions for turtle cursors that responded to your usual LOGO commands. I had it export some very crude XML as SVG for viewing.Never got around to proper control structures just simple one line commands.

Forgive this crude code, it was very early work. (turtles store their trails internally via a series of points not sure if all commands are implimented)

Since two days I'm trying to find a way how to keep the REPL working while the canvas window is open. There is a :SERVE-EVENT keyword that works with WITH-LTK and MAINLOOP, but no matter what I try, LTK throws errors at me. I've already asked on the ltk-user list, but no response yet.