Path: chuka.playstation.co.uk!news From: Chris Chadwick Newsgroups: scee.yaroze.programming.2d_graphics Subject: Re: debug font image size Date: Tue, 03 Mar 1998 00:18:29 -0800 Organization: PlayStation Net Yaroze (SCEE) Lines: 39 Message-ID: <34FBBCD5.6785@dial.pipex.com> References: <6de02s$q6o1@emeka.playstation.co.uk> NNTP-Posting-Host: al164.du.pipex.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Win95; I; 16bit) Lewis_Evans@Playstation.sony.com wrote: > > From: Lewis_Evans@Playstation.sony.com > To: news@playstation.co.uk > > From looking at VRAM after some token loop, > it looks like the text font pixels go in at 960, 256 and occupy a 32x32 32x32? > area; > however there is also a CLUT, albeit a very small one (a single white dot > by > the look of it), at position 960, 384 or thereabouts. > > If you make two small 16-bit TIMs, of the right sizes for the areas taken > up by the font, and add these to your project in TimTool, you can see what > is taken > up visually, and by checking the 'overlap' area. > > Lewis > I had a feeling it was down to some CLUT corruption. If the CLUT goes in at 960x384, this is the position of the 'space' character in my own font image and so wipes the CLUT with 0's causing no debug font text to show. It's a bit annoying having to relocate my own font to make room for a *tiny* CLUT... Actually, thinking about it, I could re-define the debug CLUT in my own fonts image as I never actually use the 'space' character - it's just included for easier image indexing using ASCII codes. Hmmm...... Sorry, just thinking out loud :) Thanks, Lewis! -Chris