Path: chuka.playstation.co.uk!scea!peter_alau@playstation.sony.com From: Ed Federmeyer Newsgroups: scea.yaroze.programming.2d_graphics Subject: Re: Basic 2d Questions Date: Sun, 31 May 1998 10:56:49 -0500 Organization: (no organization) Lines: 99 Message-ID: <35717DC1.A79@charlie.cns.iit.edu> References: <35703AF2.41AD@mindspring.com> Reply-To: fedeedw@charlie.cns.iit.edu NNTP-Posting-Host: charlie.cns.iit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0C-GZone (Win95; I) Jonathan Calvert wrote: > Anyway, I am doing some really basic things like loading 4bit sprite > images. I have noticed that some of my images load (display correctly) > and some do not. > > I am using a frame area of (320 x 240). It's important to note if you are doing double-buffering or single buffering. And where your buffers are in the VRAM. Generally, you'll have one 320x240 buffer located at (0,0) in VRAM, and another 320x240 buffer located physically just below it at (0,240) for double buffering. Remember, the Yaroze automatically flips back-and-forth between these two display buffers to generate the TV picture. You can't put any image data or CLUTs in this area, since it is constantly being erased and redrawn with current display data. > A typical texture page for my 4bit image is: > (x = 768, y = 76, w = 16, h = 64) > > Question 1 - I almost always have to change the x value to 640 and the > y value to 0 to get the image to display correctly. Why? Make sure there is no other texture loaded there. An easy thing to forget is that the "FntLoad()" function loads a texture (256x128x4bit), so make sure that isn't colliding with your image data. Also, in the sprite data structure, in addition to specifying a texture page, you also specific OFFSETS (u,v) within the texture page in question, so that the physical image doesn't need to allign on a texture page boundary. If your u,v values are set to (0,0), you shoule note that 76 is not at the start of a texture page (which are always 256 pixels tall) That might be why you need to move the image to "0". Or, you could leave the texture where it is, and specify a "v" value of 76. > Question 2 - I always have to multiple my w value by 4. I have seen > this > in various sample programs, but I have not seen an explanation. Why > multiply by 4? > > Question 3 - If the image was a perfect square (64x64 pixels) why does > the w value come up reduced by a factor of 4? It looks like 8bit images > are reduced by a multiple of 2. I guess this is a pattern. Remember, there are TWO widths to consider: The "pixel" width, and the "memory" width. Rememeber also that the VRAM is 16bit, unlike what most of us are used to thinking of. Texture pages are always 256 pixels by 256 pixels. So, a 64x64 pixel image that uses 16 bits per pixel fits into the 16bit VRAM as-is. No tweaking of the w value is needed, since the texture pages map 1:1 to the VRAM. A 64x64 pixel image that uses 8 bits per pixel only takes up 1/2 the space in the VRAM, so it effectivly gets compressed (or squashed if you perfer) and you need to make your w value twice as big, since when talking 8bit, texture pages map 2:1 into the VRAM. You get twice as many (256 pixel x 256 pixel) texture pages, since each one is only 128 bytes x 256 bytes)! Same thing is true for 4 bits per pixel, only now, the image only takes 1/4 of the space, and the texture pages map 4:1 to the VRAM. Wow! Four times more texture pages! Since they are only 64 bytes x 256 bytes! It's important to remember that some functions want the "pixel" width (64 in this case), and some want the "memory" width. (16 in this case) The truly impressive thing (IMHO), is that the PlayStation can mix and match all these modes and image types in each frame! > A typical image CLUT is: (x = 0, y = 480, w = 16, h = 1). > > Question 4 - If my y value is more than 480 then the image will not > display. > Why? Am I limited to twice my frame area (i.e. 640 x 480)? Again, make sure something else isn't colliding with the CLUT. And make sure if you change the location of the CLUT, the sprite data structure you are using points to the new location of the CLUT also. I know I typically put all my CLUTs just below the frame buffers, (0,480) down to (0,511). So as far as I know, there is no limit to where you can put your CLUTs. Wait: I think they might need to start at a texture page boundary! (Like, you can put a 4bit CLUT at x values of 0, 16, 32, etc, but NOT at 1,2,3,4...etc, an 8bit CLUT needs to start at 0, 256, 512, etc) Since all CLUTS are 1 pixel "deep" (in the Y direction), they can go on any y value. Good luck, I hope this helps clear things up, rather than confuse the issue! :-) EdF