Path: chuka.playstation.co.uk!news From: SCEE Developer Support Newsgroups: scea.yaroze.programming.2d_graphics Subject: Re: More GsBG questions Date: Thu, 24 Apr 1997 10:08:13 +0100 Organization: Sony Computer Entertainment Europe Lines: 120 Message-ID: <335F22FD.35@interactive.sony.com> References: <335F08E0.7758@charlie.cns.iit.edu> 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) Ed Federmeyer wrote: > > Okay, I've done some more experimenting with the order that I call the > GsSort() routines, etc. Its working a lot better now, thanks Mario! > > BUT I've come across even more things I don't understand: > > 1) Why are 4-bit CLUT images reversed? If you look at the image > definitions > for my tile1_image_data[] array, you'll see that I needed to do some > wierd > byteswapping to get the image to display the way I wanted it to. I > started > experimenting with 15bit-direct images (with sprites), and they were > stored > intuitively, not requiring byteswapping. > Hi Ed, 8 bit and 4 bit textures are stored packed into GPU words (16 bit) in left to right order. - Big Endian/ Not little endian > 2) Performance: Is there a general difference in the performance of > working with 4bit vs. 8bit CLUT vs 15bit vs 24bit direct images? > Just a generalization is all I'm after at this point. I would assume > that the CLUT images are slower, since the routines or GPU must > translate > the CLUT info into real RGB values before the image is painted into the > display buffer. > The CLUT lookup is transparent, so it doesn't waste any draw cycles except for 16/256 reads if the CLUT changes. 24 bit mode doesn't allow any polygon stuff - It's only there for static images. For speed - 4 bit textures make the best use of both VRAM and the texture caches, so most games use them. > 3) You'll notice in the attached code, when I define the second cell, > which > LoadImage() puts his texture right next to the texture of the first > cell, > I need to define it's ".u" value as being 16, even though it is > physically > in VRAM 4 pixels to the right of the first cell. Apparently the > routines/(GPU?) automatically adjust the ".u" member depending on if it > is > a 4bit/8bit CLUT or 15bit direct texture? Is that right? > Yup, uv coords are based on the 256x256 TPAGE - which takes 256x256y Vram for 16bit, 128x256y for 8 bit, and 64x256y for 4 bit, So a 4bit U of 16 references 4 extra in X. > 4) Why is GsSortClear() somehow different than the other GsSort() > functions? > All the GsSort functions do is add a command to the list of GPU commands > in the given OT, right? They don't actually set the GPU into action, > right? > Then later you tell the GPU to start working on the complete list of > commands, > right? > > Well, it's almost as if when preparing the commands, the GsSort() funcs > don't > need to know about the current display buffer (the GPU will figure out > where > exatally in VRAM the drawing commands should write to when the time > comes), > but GsSortClear() seems to peek at the current display buffer to figure > out > what VRAM area to create a clear command for. I don't get it. > I'll break this down into double buffer ops.. > Works: Gives Black Screen: > Clear OT Clear OT empty ot > Call GsSort() funcs Call GsSort() funcs ot contains polys > VSync/SwapBuffer Call GsSortClear() Swap buffers Ot contains polys + clear for current draw screen > Call GsSortClear() VSync/SwapBuffer Ot contains polys + clear for NEW draw screen Swap buffers > Draw OT Draw OT Clears draw screen, draw polys. Clear old draw screen ( now display ): Erase last frames polys!!!! Draw polys on new draw screen ( ready to be cleared next frame ) > > 5) When I define the second of my double buffers via GsDefDispBuf() to > be > on the VRAM y-location of 256 (as is done in some examples), rather than > *immediatly* below the first buffer (at 240), the GsSortFixBg16() > routines > draws the BG 16 pixels lower on the odd frames!!! > I think that the 256y display stuff is more for PAL.. ie: you probally have to have 256 for the display Y in the initgraph stuff... > Below is a more full-blown version of code I'm testing with. It puts up > a tiled background, and a sprite in front of it. The way it is now, > the image is "jumpy", because the BG jumps up and down 16 pixels every > frame, so tiles that are different are flickery. > > See the comments for ways to "fix" the code. Any ideas why the code > (GsSortFixBg16() in particular) behaves this way? > > Thanks, > EdF have fun with Yaroze... Colin. ( SCEE )