Path: chuka.playstation.co.uk!news From: alex@teeth.demon.co.uk (Alex Amsel) Newsgroups: scee.yaroze.programming.2d_graphics Subject: Re: Yaroze - was I right to buy ? Date: Thu, 24 Apr 1997 12:44:17 GMT Organization: Into Beyond Lines: 81 Message-ID: <33604eb2.1463847@news.playstation.co.uk> References: <01bc5030$6f732280$2f19e8c3@cma> 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 23 Apr 1997 21:49:27 GMT, "Chris Allmark" did quoth at me: >When a *large* texture (like 3 x 2 texture pages) which contains sprite >animation "frames" and I want to access (for instance) the bottom right >frame do I need to use GetTPage against the texture page co-ordinates of >the original graphic, or the texture page that the frame falls within ? Texture Pages are bit confusing at first as they are not clearly described. In fact they are nothing more than a very 'loose' coordinate system. There are '32' basic pages in the PlayStation, although tpage values also contain some other info too. A point can be in multiple texture pages because you can have a new tpage every 64 16bit pixels or 128 8bit ones, but you can still refer to a u value up to 255 pixels from the start of the tpage. This is only true horontally. Vertically the texture pages cannot overlap since a new one is calculated only at y >= 256, and v cannot be > 255. e.g. 16 bit texture starts at 64,0 in vram You could refer to tpage (64,0) with u=0, v=0 or You could refer to tpage (0,0) with u = 64, v = 0 If the texture is 8 bit and not 16 bit then u = 128. Obviously your start and end u,v coords must fit into the same texture page. >Am I right in thinking that I can only map textures to sprites which are >held within VRAM ? This can't possibly be the case for commercial Yes. >applications - are the graphics "cached" or background loaded directly from >CD directly when required ? If I am limited to using graphics that can be >held within VRAM space then how the hell can I do anything other than small >test programs ? ? Space is small I know, but there is enough room for most stuff. Remember that 8-bit textures take half the room, and 4 bit ones half again. You'd be surprised how much graphics can be reduced sometimes. The PlayStation works in 16 bit normally, and you can have dithering on too - it does actually make a difference in some apps - you don't notice textures pixelating nearly as much in one demo I have done. The PlayStation is also VERY fast at LoadImage so you can swicth in a new texture page in realtime if a texture is refered to from a tpage not currently in vram. It is even fast enough to do realtime special effects using the main memory (in RISC probably) then doing a LoadImage to copy the buffer directly to the screen. >...and if that's the case then the Yaroze is a real waste of time and >money. It has some very bad points because I think it has been aimed at the wrong market. But it is still a lot better than nothing and you can do some nice things is you play around with it. I still think Sony should release the OT primitive data since I thin it very unfair not too. But that must be their decision. Personally I'm enjoying it :) I think there are 2 full dev kits. One is 2.5k but requires a normal blue ps-x which has the same ram as us. the other is 10k and has a lot more ram which is very important for most development and comes on a board. And don't worry, the full kit apparently has plenty of problems too and it isn't just us with a few bugs by a long way! The N64 too has plenty of probs as did the Sony when it first hit developers. And the manuals for these things are always crap - a friend of mine reckons the N64 ones are a complete joke. * Alex Amsel * Into Beyond Web Design & JAVA Programming * * http://www.intobeyond.com * WWFC Utter Rubbish 1996-7* MM - "Steve Corica is every bit as good as that Kinkladze"