Path: chuka.playstation.co.uk!news From: alex@teeth.demon.co.uk (Alex Amsel) Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: Texture Wrapping Date: Fri, 08 Aug 1997 15:37:56 GMT Organization: Into Beyond Lines: 62 Message-ID: <33ec384e.9980891@news.playstation.co.uk> References: <33E7381E.E55C5787@micronetics.com> <33E84C2C.6C25@interactive.sony.com> <33E8560F.BD1E57C1@micronetics.com> Reply-To: alex@teeth.demon.co.uk NNTP-Posting-Host: teeth.demon.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent .99g/32.335 On Wed, 06 Aug 1997 11:46:39 +0100, Jim did quoth at me: >Could I set up the gpu to say draw one 400x800 polygon (for example) but >wrap the texture at 400x400 so the result would be the same as drawing >two planar connected 400x400 polys? Don't think so no. >As an aside is there any noticable speed difference between 16 direct, 4 I was told there was, but was also surprised with what I could get away with. >and 8 bit textures? I would assume 4 and 8 bit a tad slower because of >the clut lookup before it translates into a 16 direct in the frame >buffer as it draws the textured poly. 4 and 8 bit means less but activity though - the clut will be read into a cache I should think, and then everything will be dereferenced very fast. So the larger the texture, the larger the performance gain. >Another aside, how does texture caching work? It is best to group polys >with the same textures together to avoid texture cache misses? Is it Texture cache is not that much help, but you can be clever. Remember that the ps-x runs from an OT basis, so whatever order you throw your objects to the 3d libs the individual polys will be approximately sorted, and usually end up a mish mash. However, by using multiple OTs of different resolution and combining them you can ensure that certain objects get drawn 'whole'. In fact I mark off certain objects (floors, and others) as being 'draw first' objects. These get rendered into their own mini-OT and get placed in the OT in a position to get rendered before all other stuff. This depends on a nice convex/flat shape and it never being able to hide other objects, but is very useful. Especially as with floors you can keep your texture size to suit the cache and hey presto it'll render all its polygons using the texture cache. A few other tricks you can do too, as long as you appreciate how the OT works. Reordering how your objects get thrown to the 3d libs also can affect clipping positively - objects entered in the OT later are rendered later if the Z values of its polygons match an object already present in the OT. If you get what I mean (things are rendered on a per polygon basis and not a per object basis though). >true I can only cache 32x32 16bit direct textures? So would I see more >of a speed increase if I make the textures 32x32, than when I went from >128x128 to 64x64, because it will now fit in the cache? No, you can have 16x64 16 bit, 32x64 8 bit and 64x46 4 bit. Even the N64, so I understand, likes things in 4 bit. Most textures look fine in 4 bit, especially smaller ones. Regards, Alex Amsel + Tuna Technologies + Windows 95/NT, Console and Internet + + The PC/PS-X Game Tools and Game Development Specialists + + Flibbley flobble wab tiggle sa lable ly pibbley Obblers +