Easy use of graphics on computers
Nov. 1st, 2023 10:51 amI've been falling down a very deep rabbithole.
A few days ago I'd been wondering if there was an easy way to make simple graphics like I used to all those years ago on my early computers. The thing that really got me started was an interview with Stephen Wolfram I watched on YouTube (https://www.youtube.com/watch?v=4-SGpEInX_c). He is the mathematician who created the (proprietary) "wolfram" computer language and the related Mathematica program and website. He did a lot of the early work on 1D cellular automata.
Anyway, I got a hankering to explore the cellular automata, and some other cool stuff I used to play around with decades ago.
The Tandy Color Computer (CoCo) was the first graphics-oriented computer I owned, so I resurrected my old CoCo emulator on my Linux machine and loaded in a cellular automaton I'd written in 1991. But it turned out I hadn't saved the simplest version. I'd saved one of my experiments playing around with color. So I set about rewriting it. It turns out I'd forgotten a heck of a lot of the old variant of BASIC that the CoCo used, so there was a lot more error in my trial and error process. But I finally had it, and it worked... in just 15 lines! I'm pretty sure I could have made it even more efficient If I could be bothered.
It took about 1 hour and 8 minutes to draw a 256x192 image.
Running it again with the emulator limited only by the speed of my host computer, it took just 5 minutes to draw the same image. Quite a speed increase!

There is a "SmallBASIC" for desktop computers that I used to use a fair amount many years ago. (There are a few SmallBASICs.) I tried writing my cellular automaton in its BASIC, but the command to query pixels is broken, so I had to give up on it.
So now I decided to see what could be achieved with a modern computing language: python. Unfortunately python doesn't do graphics directly. You have to load a module to extend its capabilities. The main module people use to do this is Tkinter, but trying to do anything in that is a nightmare. I wanted something simpler, so that I wouldn't have to spend days and hundreds of lines just to do this simple task.
A guy named John Zelle has written a python library module called "graphics.py". He apparently uses it to teach introductory python programming. Sounded like just the thing. Unfortunately the library module doesn't have a way to query a pixel's color. I needed this for my program, so the internet came to the rescue and I found someone had written a few lines of Tkinter code to do just that, so I adapted and altered the code for my purposes.
Again, the problems of having a sieve for a brain... I found I'd forgotten lots of what I previously knew about python. But I got the job done -- in spite of a subtle bug in the graphics library that I had to compensate for.
So, the program was done in 27 lines. Quite a bit more than the CoCo's code, but much easier to read. The big surprise came when I ran it.
It took 12 and a half minutes to produce the same screen as the CoCo. It took more than twice as long as the accelerated ancient CoCo emulator!!!
Next, I plan to try a much older language: awk. It is tiny and incredibly capable, but like many computer languages doesn't have any graphical commands, and the extension libraries are not suitable (one uses ANSI graphics, which are way too large, and the other I am unable to compile), so I've decided to use awk to write to image files which can then be displayed afterwards. I might even be able to work out a way to periodically update the view of the image while it's being written. So... awk is next. Maybe if I don't get distracted by something else I might try writing it in C after that.
I have to admit I'm puzzled and frustrated by the fashion of making computer languages that can manipulate words and numbers, but not pictures and sounds. It seems like a bizarre waste of potential. Maybe it's a hold-over from the old days of computer snobbery: computers that could use text and numbers were "serious", whereas ones that manipulated pictures and sounds were mere "games" computers -- playthings.
A few days ago I'd been wondering if there was an easy way to make simple graphics like I used to all those years ago on my early computers. The thing that really got me started was an interview with Stephen Wolfram I watched on YouTube (https://www.youtube.com/watch?v=4-SGpEInX_c). He is the mathematician who created the (proprietary) "wolfram" computer language and the related Mathematica program and website. He did a lot of the early work on 1D cellular automata.
Anyway, I got a hankering to explore the cellular automata, and some other cool stuff I used to play around with decades ago.
The Tandy Color Computer (CoCo) was the first graphics-oriented computer I owned, so I resurrected my old CoCo emulator on my Linux machine and loaded in a cellular automaton I'd written in 1991. But it turned out I hadn't saved the simplest version. I'd saved one of my experiments playing around with color. So I set about rewriting it. It turns out I'd forgotten a heck of a lot of the old variant of BASIC that the CoCo used, so there was a lot more error in my trial and error process. But I finally had it, and it worked... in just 15 lines! I'm pretty sure I could have made it even more efficient If I could be bothered.
It took about 1 hour and 8 minutes to draw a 256x192 image.
Running it again with the emulator limited only by the speed of my host computer, it took just 5 minutes to draw the same image. Quite a speed increase!

There is a "SmallBASIC" for desktop computers that I used to use a fair amount many years ago. (There are a few SmallBASICs.) I tried writing my cellular automaton in its BASIC, but the command to query pixels is broken, so I had to give up on it.
So now I decided to see what could be achieved with a modern computing language: python. Unfortunately python doesn't do graphics directly. You have to load a module to extend its capabilities. The main module people use to do this is Tkinter, but trying to do anything in that is a nightmare. I wanted something simpler, so that I wouldn't have to spend days and hundreds of lines just to do this simple task.
A guy named John Zelle has written a python library module called "graphics.py". He apparently uses it to teach introductory python programming. Sounded like just the thing. Unfortunately the library module doesn't have a way to query a pixel's color. I needed this for my program, so the internet came to the rescue and I found someone had written a few lines of Tkinter code to do just that, so I adapted and altered the code for my purposes.
Again, the problems of having a sieve for a brain... I found I'd forgotten lots of what I previously knew about python. But I got the job done -- in spite of a subtle bug in the graphics library that I had to compensate for.
So, the program was done in 27 lines. Quite a bit more than the CoCo's code, but much easier to read. The big surprise came when I ran it.
It took 12 and a half minutes to produce the same screen as the CoCo. It took more than twice as long as the accelerated ancient CoCo emulator!!!
Next, I plan to try a much older language: awk. It is tiny and incredibly capable, but like many computer languages doesn't have any graphical commands, and the extension libraries are not suitable (one uses ANSI graphics, which are way too large, and the other I am unable to compile), so I've decided to use awk to write to image files which can then be displayed afterwards. I might even be able to work out a way to periodically update the view of the image while it's being written. So... awk is next. Maybe if I don't get distracted by something else I might try writing it in C after that.
I have to admit I'm puzzled and frustrated by the fashion of making computer languages that can manipulate words and numbers, but not pictures and sounds. It seems like a bizarre waste of potential. Maybe it's a hold-over from the old days of computer snobbery: computers that could use text and numbers were "serious", whereas ones that manipulated pictures and sounds were mere "games" computers -- playthings.