Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com
From: mperdue@l4software.com (Mario Perdue)
Newsgroups: scea.yaroze.programming.2d_graphics
Subject: Re: Sprite widths, why does this work????
Date: Sat, 10 Jan 1998 05:28:41 GMT
Organization: L4 Software
Lines: 30
Message-ID: <34b7045f.2737133@205.149.189.29>
References: <01bd1d9c$4c2d9000$4454eccd@nsantos>
NNTP-Posting-Host: firewall.hrtc.net
X-Newsreader: Forte Free Agent 1.11/32.235

On 10 Jan 1998 04:41:24 GMT, "Nelson Santos" <nsantos@total.net>
wrote:

> [snip]
>
>
>First I load a 320x80 image into the Frame Buffer.  It's a 4-bit image. 
>After the GsGetTimInfo, WarningImage.pw is actually equal to 80, not 320! 
>This probably has something to do with the fact that the image is a 4-bit
>image, but the picture itself is still 320 pixels wide.  Why does it return
>80??

You're right, it has to do with the fact that you are using a 4-bit
image. The frame buffer is a 1024x512 area of 16-bit pixels. When you
load your 4-bit image it only requires 1/4 the space that a 16-bit
image would require. The value for pw is adjusted to reflect the
actual memory used.

>Next, I create two sprites, one for the first 256 pixels, and the second
>sprite handles the rest of the sprite, 64 pixels.  However, the GetTPage
>command for the second sprite must be GetTPage(0,0,384,0) for it to work
>properly, rather than GetTPage(0,0,576,0), to skip the 256 pixels in the
>first TPage.  I have no idea why this is so.

Same as above. The texture page is 256 pixels wide. A 4-bit image that
is 256 pixels wide will use a 64 bit wide area in the 16-bit frame
buffer. Locations in the frame buffer are relative to a 16-bit pixel.
You need to adjust for other color depths.

Mario