That's it, my last deadline of 2009 has been met. It's rather too tempting to spend the day making ice cream, playing TF2 (team Demo!) and going out on the town, so that is precisely what I'll do. But only today!
Tomorrow, however... that is when I start my Coder series on
Building a raytracer in Lua
Serving both as the solution to one of my assignments and a diary of my experiences learning a new-to-me, yet very promising language, and one that receives wide usage in the games industry already. I'd do well to know it, especially since MMF2 has a Lua interpreter extension.
Raytracers are very computationally intensive, which is why they're generally written in C(++). As far as performance is concerned, LuaJIT appears to be doing reasonably well for itself, and you get the benefits of dynamic typing, closures and first-class functions. You also have a rather flexible object system - as in, there isn't really one, but the language features plus a little syntactic sugar give you the tools to develop a model that fits your particular circumstances. You know, like Perl, except without the feeling you're filling your source code with censored profanity.
A raytracer might not need all that flexibility, being one of the most naturally-object-oriented applications you can make, but I certainly don't intend to make raytracers all my life. Or ever again.
Plus, since I'm not Steve Yegge, the lack of braces isn't a turn-off. Besides, the benchmarks I've seen put the V8 JavaScript engine slower than LuaJIT - though I have no idea whether that holds once you make a more substantial program.
At the very least, compared to Win32 C programming, Lua will be quite the welcome break. Once you've had a taste of functional programming, writing in C again seems nearly as painful as if you'd lost your compiler and had to resort to typing COPY CON: OHGODWHY.EXE (and believe me, typing italics into a command prompt is tricky stuff). Time will tell whether it's all I've cracked it up to be.
Tomorrow, however... that is when I start my Coder series on
Building a raytracer in Lua
Serving both as the solution to one of my assignments and a diary of my experiences learning a new-to-me, yet very promising language, and one that receives wide usage in the games industry already. I'd do well to know it, especially since MMF2 has a Lua interpreter extension.
Raytracers are very computationally intensive, which is why they're generally written in C(++). As far as performance is concerned, LuaJIT appears to be doing reasonably well for itself, and you get the benefits of dynamic typing, closures and first-class functions. You also have a rather flexible object system - as in, there isn't really one, but the language features plus a little syntactic sugar give you the tools to develop a model that fits your particular circumstances. You know, like Perl, except without the feeling you're filling your source code with censored profanity.
A raytracer might not need all that flexibility, being one of the most naturally-object-oriented applications you can make, but I certainly don't intend to make raytracers all my life. Or ever again.
Plus, since I'm not Steve Yegge, the lack of braces isn't a turn-off. Besides, the benchmarks I've seen put the V8 JavaScript engine slower than LuaJIT - though I have no idea whether that holds once you make a more substantial program.
At the very least, compared to Win32 C programming, Lua will be quite the welcome break. Once you've had a taste of functional programming, writing in C again seems nearly as painful as if you'd lost your compiler and had to resort to typing COPY CON: OHGODWHY.EXE (and believe me, typing italics into a command prompt is tricky stuff). Time will tell whether it's all I've cracked it up to be.
Leave a comment