PhiHo,

There is no real answer to your question. Performance is extremely 
dependent upon the problem you are trying to solve, the nature of your 
implementation and the constraints you are willing to live with. One of my 
goals was that I could build a game world that would be competitive in 
performance with anything I might be able to do in C++. With that in mind, 
I designed the system to have direct access to the OpenGL calls at any 
level, yet still be very much a retained mode engine. Very flexible, yet 
you can usually let it do most of the work for you. On the other hand, I 
wanted general purpose solutions to most of these same problems, hence, the 
picking and floor following method is extremely clean and general. I know a 
way that would run about 1000 times faster for floor following (using 
bitmap height fields), but it simply isn't general purpose enough at this 
stage. That doesn't mean I won't use it later for specific environments - 
or that you can't do the same. I just haven't got to that point yet.

Most of graphics programming is dealing with large data sets with simple 
transforms. To that end, we will be incorporating our general purpose 
n-dimensional Matrix class which is intended to be used to access the VPUs 
in a clean way. The goal here is to exceed the performance of C++. That 
will probably be a project for next year.

I simply don't know what the final performance of the system will be, as it 
is very dependent upon what you do with it. My goal is to make it extremely 
competitive. The current engine has not been optimized in any way (though I 
am looking at a few things right now), and frankly, I am quite excited 
about the performance I am getting now. I attribute this to a number of things:

- Squeak is pretty fast - faster than you might think.
- We try to push as much into the hardware as we can - with decent results.
- The traversal and picking mechanisms are fundamentally sound.

All this means is that performance is pretty good, and should get a lot 
better. The architecture should not change much, so you should be able to 
build some things without too much fear that I will break it - though I 
reserve the right to do so :-)

Regards,

David




At 02:19 AM 12/4/2002 -0500, you wrote:
>Hi David,
>
> >  I don't expect the graphics engine to change much
>
>     How would you compare, performance-wise, Croquet to
>
>         1/- RuneScape http://www.runescape.com
>
>         2/- WildTangent http://www.wildtangent.com
>
> > but the addition of the TeaTime collaboration object model/protocol
> > and the new scripting architecture will have a dramatic impact
> > on the nature of how you program for the system.
>
>     Does it have any impact on performance ?
>
>     Cheers,
>
>     PhiHo.
>
>----- Original Message -----
>From: "David A. Smith" <davidasmith at bellsouth.net>
>To: <squeak-dev at lists.squeakfoundation.org>
>Sent: Tuesday, December 03, 2002 9:25 AM
>Subject: Re: Croquet alpha release(s?)
>
>
> > Joshua,
> >
> > Current plan is to have a true alpha release sometime early next year. I
> > don't expect the graphics engine to change much, but the addition of the
> > TeaTime collaboration object model/protocol and the new scripting
> > architecture will have a dramatic impact on the nature of how you program
> > for the system. If it looks like the release gets pushed out too much, we
> > may have an interim release along the lines of the previous one.
> >
> > Regards,
> >
> > David
> >
> >
> >
> > At 12:48 AM 12/3/2002 -0500, you wrote:
> > >Dear Croqueteers,
> > >
> > >How closely does the Croquet update stream track Croquet development?
> > >Are there large rewrites (particularly within the graphics
> > >architecture) going on behind the scenes that will replace the code
> > >that is currently there?  Or will code that I write be able to evolve
> > >along with the update stream?
> > >
> > >Do you plan to make available other alpha releases of Croquet, or is
> > >this the only tantalizing taste that we get until the Big Release?
> > >
> > >Thanks,
> > >Joshua
> >
> >
> >