Michael Naunton wrote:
Thanks, this looks really promising as a video game development environment:
Yes. I am fast (specifically, at around 30fps) losing interest in finishing the GUI to do educational software. Lisp always does this to me.
o Cells gives us MVC for free. o Cello looks pretty good as a platform-independent GUI o Lisp gives us the abstractions we need to hide OpenGL's complexity.
And boy does it need hiding. But once hidden, the user can really have some fun. At 25-35fps.
o Lisp makes so many tasks (asset management, etc) easy. o Sound is lurking in the wings.
With 3d effects, no less. This should be one of the easier bolt-ins (famous last words). But I am getting so busy now it is hard to justify. Maybe after a good day (like today?) I'll treat myself to adding OpenAL.
The big win is, of course, Cells. Cello demonstrates it's power.
Yep. I always figured Cells would not catch on without a "demo" GUI, though Cells transcend GUIs. But the GUI would have to be fast.
With the abstraction (A depends on B,) many software reuse issues just vanish.
With a few good examples on line, many newbie programmers are going to want to try this environment out.
...and serious gamers, too, perhaps. We've had a couple of newbies land on our shores in the past because Lisp is always being mentioned favorably on same gamers forum or other. Gotta remember to make an announcement over there when Cello gets a little polish.
Speaking of polish, I am hoping that is all we need. The groovy 340-widget Light Panel now runs at 25-35fps. The variation now comes from the complexity of the shape being displayed! That used to be noise compared to the cost of re-rendering each frame the entire window. Now if I am just watching the thing spin I just need to re-render the spinning shape. Working a slider means that also needs to be re-rendered. Otherwise display lists (after a subtle tweak to the Cello imaging algorithm) do all the work. And they are almost working properly as well as fast. :)
No jumping up and down yet. Interactions with FTGL are spotty, but I think that is simply because FTGL caches its own display lists, and I think I am pulling the rug out from under it on each run by re-initializing OpenGL and not re-initializing FTGL. So it sits there happily using display list numbers OpenGL does not recognize (an NOP). It is really neat because as I click around individual letters disappear one or two at a time. Kinda Vanna White in reverse. Hang on. That can't be initialization then, because they always start out fine. We'll see.
Also, I am not sure the current rates will hold up. It may be that refreshing a display list requires refreshing all display lists above it in the tree. We'll see. That would still be mad fast I think. I am not refreshing up now and it works, but I think it should not, so no champagne yet.
-- Michael (resisting the urge to port to CMUCL this second.)
Just curious: how did you reach all these conclusions? Don't tell me you actually read the code?! :)
kenny