Path: chuka.playstation.co.uk!news From: James Shaughnessy Newsgroups: scee.yaroze.programming.2d_graphics Subject: Re: Dim bloke with a TIM Date: Sat, 26 Sep 1998 15:03:34 +0100 Organization: PlayStation Net Yaroze (SCEE) Lines: 37 Message-ID: <360CF436.13A8@manc.u-net.com> References: <3600BC16.1B1AD4F9@cwmail.com> <36015389.64776317@shell.jps.net> <360247CD.3E78@manc.u-net.com> <36040312.1FBE@dial.pipex.com> Reply-To: james@manc.u-net.com NNTP-Posting-Host: manc.u-net.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0 (Win95; I) Chris Chadwick wrote: > The only way I found of getting round this problem with cached CLUTS, > was to add a dummy sprite to the OT that has different .cx/.cy values, > thus forcing a CLUT cache reload... A nifty hack there yes, and it saves taking up more vram which was what I am doing. As for actual palette cycling do you use two MoveImages directly on the Frame Buffer, or have the palette cycle in main memory and then do a single LoadImage to VRAM? The former saves slightly on memory but is over twice as slow, and doing palette manipulation in main RAM means you can do much more fancy stuff to it than just cycling. I guess the best way is to store the palette like this: short Palette[256]; RECT clut; setRECT(&clut, cx, cy, 256, 1); StoreImage(&clut, &Palette); and in the main program do the cycling/manipulation on the Palette[] array and then just: LoadImage(&clut, &Palette); // Load new clut GsSortFastSprite(&dummy, &WorldOT[activeBuff], 1);// renew clut cache Using the dummy sprite is a better method than toggling two clut areas of vram to renew the cache? I guess that depends on how many cluts you want to cycle -- if there's a few then for the sake of VRAM I'd use the dummy, but if it's only one then I'd stick with the toggle. Cheers, Jim -- ----------------------------------------- James Shaughnessy james@manc.u-net.com http://www.netyaroze-europe.com/~shaughnj -----------------------------------------