Path: chuka.playstation.co.uk!news From: Chris Chadwick Newsgroups: scee.yaroze.programming.2d_graphics Subject: Re: Dim bloke with a TIM Date: Tue, 29 Sep 1998 01:29:14 -0700 Organization: PlayStation Net Yaroze (SCEE) Lines: 30 Message-ID: <36109A5A.4A15@dial.pipex.com> References: <3600BC16.1B1AD4F9@cwmail.com> <36015389.64776317@shell.jps.net> <360247CD.3E78@manc.u-net.com> <36040312.1FBE@dial.pipex.com> <360CF436.13A8@manc.u-net.com> NNTP-Posting-Host: userm502.uk.uudial.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Win95; I; 16bit) James Shaughnessy wrote: > > 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. What I do is first make 2 copies of the CLUT entries I want to cycle, side-by-side in VRAM. Then I copy the required amount of CLUT entries from this into the correct area of the true CLUT. Then, for the next colour cycle, simply increment the .x member of the source RECT used to MoveImage() the entries into the true CLUT. Of course, a check also has to be made so that the .x member can be reset to the beginning of the 2 copies, so that the process can continue over. Hope that makes sense! I also prefer this method as it keeps all activities in VRAM, which I assume is more efficient i.e. faster than shifting stuff in and out of main mem; although, I havent done any testing of this. Cheers, -Chris