Path: chuka.playstation.co.uk!news From: Robert Swan Newsgroups: scee.yaroze.programming.2d_graphics Subject: Re: Caches Date: Tue, 18 Aug 1998 09:41:09 +0100 Organization: I wish! Lines: 20 Message-ID: <35D93E25.6A66@mdx.ac.uk> References: <35C81A30.4ACB@club-internet.fr> <35C82DDB.3E12E37C@scee.sony.co.uk> <01bdc061$2c186980$f30b0a0a@Angela1.intelligent-group.com> <35D2E01D.5CA1@mdx.ac.uk> <6r0vps$n7i6@chuka.playstation.co.uk> <35D43404.282A@mdx.ac.uk> <35D438D2.908C3316@ndirect.co.uk> <35D43F08.36BA@mdx.ac.uk> <35D44CBE.1FA95769@ndirect.co.uk> <35D46843.5DF5@mdx.ac.uk> <35D83E4D.32BA4E05@scee.sony.co.uk> NNTP-Posting-Host: nova.mdx.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5 sun4u) Ok, just to finally try to sort myself out. I have a feeling that I wasnt sure ot begin with, and I misunderstood something Alex Herbert said earlier (not his fault, just me being to quick to try to understand it). Ok, in 256x256 texture that is being drawn on the screen without subdivision, it starts drawing one line on screen at a time (for sake of argument) from the top left of the texture, so the top left is cached. If it has to draw a pixel that is off the cache it loads in the correct bit of the texture. This line by line approach (at its worst) leads to upto a possible of (for 16 colours) (256/64) = 4 texture cache updates per row of the texture (thus 4*256) which sounds abysmal. In a nice subdivided environment as each primitive it has to draw is 64x64 pixels of the texture, this texture cache update would only happen 4x4 times... thats not including trivial off screen rejects or stuff like that. Am I hot yet? :) Rob