Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!satisfied.apocalypse.org!news.mathworks.com!uunet!portal.austin.ibm.com!bocanews.bocaraton.ibm.com!news
From: Larry_Kyrala@bocaraton.ibm.com
Subject: Games performance and Dylan...
Sender: news@bocanews.bocaraton.ibm.com (News Admin ID)
Message-ID: <D4vz27.FIq@bocanews.bocaraton.ibm.com>
Date: Fri, 3 Mar 1995 22:42:07 GMT
X-Nntp-Posting-Host: alterego.bocaraton.ibm.com
Reply-To: Larry_Kyrala@bocaraton.ibm.com
Organization: IBM, Boca Raton, FL
X-Newsreader: IBM NewsReader/2 v1.03
Lines: 84


Hi, I'm new to Dylan and this list, but I couldn't help noticing
the post about:

> > "The measure of how good a programming language is comes down to how good
> > a 'shoot-em-up' game you can produce with it."
> 
> By that metric, assembler is the last word in programming languages.

And I agree with Chris' response that the levels of abstraction
in a language more than make up for run time inefficiency in most
cases (i.e. programming all of DOOM in ASM).

But!

A common "trick" of complex game engines is to rely on high level
abstractions for most of the code, except when dealing with the
extremely time-critical sections.  Then, they drop down into
assembler.


I'm coming from a C++ background, so I'm already sensitive to exactly
the problems with static languages that Dylan attempts to remedy...
my question is this:

In constructing a game, I would prefer to have a view of objects
like:

      Monster          Player

Inevitably in C++ this would lead to low level layers such as:

      BitBlit( view )  or  Bitmap.blit()   etc...

in other words, I have to go through several layers of abstraction before I get
to the hardware.  I want to be able to "drop" down to hardware without overhead
or interference from other layers for that relatively small window of time.

   Monster_________         ___________
   (other layers)_____      ___________
   ___________________      ___________
   _______________   __     ___________
   (final hardware_____________________



Can Dylan support these kinds of "zero" or low overhead objects
while maintaining the flexibility of use for other areas of
an application?   (a form of "empty" encapsulation??)



There is a reason for this.

Yes, CPU speed and memory capabilities are increasing, BUT...
neither is fast enough (or will be fast enough in the near future)
to support a generic descriptional engine whose speed will be
perceptually as "fast" as a specialized descriptional engine.

The cardial rule we have learned is that depending on the nature
of the descriptional data, we can "cheat" to improve performance
in the descriptional engine.  Yes, this "cheating" has a price...
our engines become tightly coupled both to the target platform and
to the chosen descriptional data.  (DOOM's engine cannot and will
not ever perform *true* 3D operations in free coordinate spaces
like Tie Fighter does)

All these games act as though they use descriptional *objects*
which bind the low level implementation and data for the game.



It's been like pulling teeth just to get game developers to even consider OOP
tools and languages...  maybe this is simply an idea whose time hasn't come yet?


How do I convince people that I'm not a raving lunatic?  :)

________________________________________________________________
                                  ______________________________
   Larry Kyrala
   [<]                            Larry_Kyrala@bocaraton.ibm.com
________________________________________________________________

