Path: chuka.playstation.co.uk!news From: Andrew Partington Newsgroups: scee.yaroze.freetalk.english Subject: Re: Texturing/bit depth question Date: Fri, 28 Nov 2003 23:15:56 +0000 Organization: PlayStation Net Yaroze (SCEE) Lines: 105 Message-ID: References: NNTP-Posting-Host: public2-ward1-6-cust140.manc.broadband.ntl.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en In-Reply-To: Tnanks Andy, i'll do some experimentation and see what I can do with it. I've had to play with GsDRAWENV when I tried out pixel-perfect collision many moons ago to render zoomed/rotated sprites into a collision buffer, so no worries there. Cheers, Andy P Andrew Murray wrote: > I meant to say I got the info from the scee.yaroze.programming.3d_graphics > newsgroup, there are a few messages there about texture repeating/wrapping. > > Hope this helps. > Andy M. > > "Andrew Murray" wrote in message > news:bq85l8$mh64@www.netyaroze-europe.com... > >>Eureka! the texture window... you have to set the tw member (which is a >>RECT) of the GsDRAWENV global structure to the area on VRAM where your >>texture is. You will have to set it back again after, so store the current >>values of tw in temporary variables, set the texture window, render the >>object (I think), then set the texture window back to the temporary >>variables. >> >>I think that would work, but I'm not sure if the Yaroze makes notes of > > where > >>the texture is for drawing at GPU command entry time or rasterisation > > time, > >>which could effect the textures that appear on textured objects, etc... > > You > >>may get the same problem I had where the last texture window set was the > > one > >>used to render all objects. >> >>You can only try, I suppose, Good luck. >>Andy M. >> >>"Andrew Partington" wrote in message >>news:bq4ohn$mh62@www.netyaroze-europe.com... >> >>>Hi all, >>> >>>Does anyone know if it's possible to tile/repeat a texture over a >>>quad/triangle, instead of having the texture stretched over it? >>> >>>Originally I wanted to put aside a 256*256 area of VRAM, and then >>>MoveImage() the relevant textures into that area, building up a texture >>>strip running horizontally across the area, which would have given me >>>all the flexibility I need. >>> >>>However, that plan seems to have been scuppered because no matter what >>>bit depth you specify for your texture, the U and V coordinates seem to >>>get in the way. >>> >>>What I mean is: if I have a texture 8 pixels wide in 8-bit mode, I still >>>have to set the texture width to 8. However the texture might only be 4 >>>pixels wide in the VRAM area because its in 8-bit mode, and 2 pixels >>>wide in 4-bit mode - it should only be 8 VRAM pixels wide in 16-bit >>>direct mode (I think). Although it was handy to hide that behaviour >>>when I was beginning, it's turning into a bit of a limitation now. >>> >>>The problem here is that I would have to split the polygon at 256 pixel >>>intervals (in real terms, every 4 items of map data), and I want to keep >>>the poly count as low as possible. Is there any way of overriding that >>>behaviour to let me set the "real" texture widths? It'd be nice to be >>>able to use a 1024 pixel wide texture (in effect, in 4-bit mode), while >>>setting the texture width to 256. >>> >>>I know that the U and V values are in the range of 0-255, so i'm not >>>expecting to be able to set any values higher than that - I just want to >>>keep track of the bit depths myself. >>> >>>There's a demo attached of what i've been up to on-and-off - I thought >>>that if I was going to go the polygon route I might as well do some >>>proper collision too and get my head round the maths. Anyone fancy a >>>test to make sure you can't break it too easily? (you can't topple off >>>the edge of a block in this version yet, thats on the to do list). If >>>you do go inside a block, chances are that you would have been killed >>>before that (I can only get it to fail when going at mad speeds). I >>>don't know what it'll do when I texture it, but for now it's vastly >>>quicker than the old GsSPRITE-based map - which is why I want to keep my >>>quad splitting down to a minimum. (P and V are the polygon and vertex >>>counts, in case you are wondering). >>> >>>Cheers, >>> >>>Andy P >>> >> >> > >