[cello-devel] Bingo: 30+ fps [was Re: [cells-devel] I'm Back]

[Kenny Tilton]

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

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application