Path: chuka.playstation.co.uk!news
From: sceetech <ps_yaroze@interactive.sony.com>
Newsgroups: scee.yaroze.programming.3d_graphics
Subject: Re: 3D engines
Date: Thu, 10 Apr 1997 14:34:58 +0100
Organization: SCEE
Lines: 42
Message-ID: <334CEC82.13C2@interactive.sony.com>
References: <3347dd19.3248416@news.playstation.co.uk> <3348D38C.1DC1@interactive.sony.com> <334A3648.1873@micronetics.com> <3349266B.7BD4@interactive.sony.com> <3349a345.33045335@news.playstation.co.uk> <334A3058.218B@interactive.sony.com> <334b3a68.199522@news.playstation.co.uk> <334B7A3E.D59@micronetics.com> <334e8f46.1862969@news.playstation.co.uk> <334BA0FE.43B8@micronetics.com> <01bc4554$03b82360$b756dec2@algorithm> <334e5a3c.10502709@news.playstation.co.uk>
Reply-To: ps_yaroze@interactive.sony.com
NNTP-Posting-Host: 194.203.13.10
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01 (Win95; I)

Alex Amsel wrote:
> 
> On 10 Apr 1997 02:03:25 GMT, "Russ Williams"
> <russ@algorithm.demon.co.uk> did quoth at me:
> 
> >You could try writing to an array in 'real' memory, LoadImage-ing this to
> >VRAM and then using it as a texture/sprite. This way, you'd get cached
> >pixel plotting, and therefore quite a big speed increase :)
> 
> Only problem with this is the speed overhead. Err, not sure what I can
> say regarding primitives available in the OT (there are some of use,
> put it that way) but using a GsSprite or polygon will incur
> unnecessary overheads. I haven't checked on the GsSprite
> implementation (i.e. if it uses 'hardware' sprites if appropriate).
> 
> 
> * Alex Amsel * Into Beyond Web Design & JAVA Programming *
> * http://www.intobeyond.com  *  WWFC Play off ****ers'97 *
> MM: "Hand the opposition the lead, the supporters love it"


The GsSPRITEs are very fast if you don't use rotation, scaling, etc;
i.e. use GsSortFastSprite. If you look at the <check> or <balls>
demo, you can see that you can get a HUGE number on screen
before frame rate drops below maximum. One texture holding
a pixel (and maybe small squares and rectangles) with either a
neutral CLUT for changing colour via sprite.r,g,b fields,
or overwriting CLUT itself using LoadImage/MoveImage,
should provide pretty rapid pixel plotting.
-Not fast enough to implement your own sprites on a pixel
basis I'm sure, but I can't see why anyone would want to do that
given the speed of GsSPRITEs.

One alternative: MoveImage is apparently very fast indeed,
can use this for pixels or any other 2d business.

The ftptest demo uses a VAST number of sprites and pixels,
all flowing at very high frame rate,
and while I haven't seen the source I'm almost certain it
makes good use of GS and nothing else.

Lewis