Time will tell.  Id's latest games tend to run on OpenGL engines, so at 
the end of the day, most modern rendering is done "under the sheets."  
The more games trend in that direction, the more clearly wrong Jon's 
prediction will be.

However, let me make an important observation.  The capacity to code a 
"state of the art" 3-D simulation product is hardly the same as "Game 
Programming."  As an old-fart gray-hair hall-of-fame game designer, I 
can tell you that, IMHO, game designing stopped almost concurrently with 
the advent of the first person shooter.  For a ten year period beginning 
in the late eighties, products denominated as games were defined as Jon 
would have it.  Ninety to one hundred percent of the computer resources 
dedicated to driving pixels, there was no way to design a game -- it was 
all in the visual heat.  And a larger percentage of financial resources 
dedicated to the art than to the coding.  In short, much eye-candy, 
little game.  Mid-nineties began a sea-change away from that.  Hardware 
assisted cards generating far better and deeper rendering than the most 
Abrashed of optimized code, game makers used the hardware.  Suddenly, 
they had resources they didn't know what to do with.  Lo, and behold, 
they started making games again.

The hardware will likely stay way ahead of software mechanics for quite 
awhile, and thus a premium will soon be placed on Game Programming 
rather than rendering mechanics.

Here is where Squeak and comparable languages can shine.  Better, 
deeper, more perfect games are possible in a language where better, 
deeper more perfect ideas can be better expressed.

Game Programming in Squeak will DEFINE the state of the art, in a way 
that pixel pushing of the past could never conceivably accomplish.

On Wednesday, October 31, 2001, at 03:06  PM, Jon Hylands wrote:

> On Wed, 31 Oct 2001 10:10:57 +0100, Bruce ONeel <beoneel at bluewin.ch> 
> wrote:
>
>> Along these lines there was a fairly funny post on comp.lang.c a
>> few years ago between someone who KNEW that it was impossible
>> to write DOOM in ANSI Standard C because ANSI C was way way way
>> to slow.  He got a response from some one named dmr at research.att.com
>> who was complaining that it had absorbed all of the leisure
>> time in his lab and yes it built with their ansi c compilers.
>
> Be that as it may, I still stand by my (corrected) post saying that you
> will probably not be able to write a "state of the art" first person
> shooter (i.e., one that is directly comparable with id's latest game) in
> Squeak, at least not unless Squeak gets an order of magnitude faster 
> than
> it is now (through software, not hardware).
>
> Yes, hardware and graphics hardware gets better exponentially. But 
> "state
> of the art" is a moving target, and as the processors and graphics chips
> get faster, the best games out there use it all up.
>
> It wouldn't surprise me at all if you could write Doom right now in 
> Squeak
> on today's hardware. When Doom came out, it ran really well on a 66 Mhz
> 486. A 1.5 GHz PIII is probably, what, 50 times faster?
>
> I'd even be willing to bet you could write the original Descent game in
> Squeak right now. When it came out, it screamed on my Pentium 166.
>
> But, like I said before, Doom and Descent are hardly state of the art...
>
> Later,
> Jon
>
> --------------------------------------------------------------
>    Jon Hylands      Jon at huv.com      http://www.huv.com/jon
>
>   Project: Micro Seeker (Micro Autonomous Underwater Vehicle)
>            http://www.huv.com
>
>