Taken from Flickr
In case you have not realised it yet, I’m a pretty prolific reader. Online reading (and having an iPad) have slowed down the number of books I read in a given year, and I don’t go to the lengths of my girlfriend (who is about to reach her goal of reading 102 books in this year,) I’m nevertheless a frequent reader.
This year I’ve read several good books that I’d like to share with you, after all, if you are reading this probably our tastes overlap.
Today, while I was thinking of the best implementation solution for the vector operations, I realised that I am just not motivated by writing a raytracer in Forth. I’ll have to find something more interesting, or at least, more Forth minded to work on.
If I want to raytrace, better to improve the Lisp raytracer, which is sitting idly in my Code/Lisp folder. Steps that will follow in the raytracer path:
As I wrote in a previous post, I’m on my way to learn forth, and to do so, rewrite my Lispy raytracer into a.. Forthy raytracer. Of course, the first steps are deciding on some implementation ideas.
I decided to allocate a few global variables (for “current point”, “current vector”, “light source”, etc), to avoid too much clutter in the stack. This way it will be cleaner, maybe even cleaner than my Lisp version.
After following a twitter feed about programming, I got overwhelmed by FORTH related posts. I had already read something about forth before (stack-based, somewhat fast, good for embedded devices), but so many bit.ly links pointing to webs of implementations of FORTH and FORTH things made me decide to, well, take a deeper look.
Looks like a nice language, having something I enjoy about Lisp (interactivity) and something I like about PostScript (stack based).