Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com
From: mperdue@iquest.net (Mario Perdue)
Newsgroups: scea.yaroze.programming.2d_graphics
Subject: Re: Many, Many sprite questions  (long)
Date: Thu, 01 May 1997 12:37:07 GMT
Organization: SCEA Net Yaroze News
Lines: 57
Message-ID: <336882b5.752704@205.149.189.29>
References: <5k92j6$9a35@scea>
NNTP-Posting-Host: filter-hrtc1.nortel.net
X-Newsreader: Forte Free Agent 1.1/32.230

>1.  What is the maximum size of a sprite? It looks to be 256x256. One
>texture page? Are there any other limitations for sprites not
>mentioned in the manuals?

The maximum size of a GsSPRITE is 256x256. You're right that it
doesn't say that anywhere (at least not anywhere that I've found.) The
fact that the offsets (u, v) are defined as unsigned 'char' is a dead
giveaway though. I'm unaware of any other undocumented limitations or
features.

>2. What exactly defines a texture page for a sprite?  In the "User
>Guide - Polygon Drawing"  p.17, images and texture patterns are
>stored in 256x256 pixel pages. But according to the API function
>GetTPage, texture pages are 64x256?

The TPages are 256x256 pixels in size. However, when you're working
with a color depth less than 16 bits, the image takes less frame
buffer space. An 8 bit image that is 256x256 only uses a 128x256 area
in the 16 bit frame buffer. An 8 bit image only uses a 64x256 area.
Spacing the TPages at 64x256 intervals in the frame buffer allows you
to avoid wasting a lot of frame buffer memory when using 4 and 8 bit
images.  

Remember that the software looks at the frame buffer as a 16 bit,
1024x512 area. Any time a location in the frame buffer is specified,
it's relative to this definition. TPages can be 4, 8 or 16 bit images,
so their offsets are relative to thier own color depth.

>3. Does sprites overlapping across a 64x256 texture page slow
>down drawing? e.g.   Specifing a GetTPage texture addres of (0,0)
>then using a high (u,v=255,255)  value for the sprite.

I have not noticed any slowdown. One of my examples, SpaceGuy, does
this and seems to run at a fairly consistant rate.

>4. What is a typical/proper method of copying a static full screen
>background per game loop?  Many samples I've seen load RGB 
>data/TIM file to the display buffer, and "GsSortSprite" based on the
>loaded area.  An obvious method would be "MoveImage" to the non-
>seen area of the GPU buffer. Yet I haven't seen any examples.

I've been using the GsSortSprite method; it's convienient (I've got to
sort everything else anyway), and it works. I'm sure other methods
could be worked out. If you come up with something that works well,
please share it with us.

>Alot of the above questions arised when I was working a tile map 
>function like GsSortFixBg16 which supports any size tile of a power of
>two (2,4,8,16,32...). The function worked fine when I was testing it
>with one of my tiles. When I  tried with any other tile, I noticed a
>big decrease in performance.

Without seeing your code, I would GUESS that there is probably a logic
problem. I say this because I havn't noticed the same type of
slowdown. Without more information, it's hard to tell.

Mario