Path: chuka.playstation.co.uk!news
From: Chris Chadwick <xjk18@dial.pipex.com>
Newsgroups: scee.yaroze.programming.2d_graphics
Subject: Re: CLUT troubles!
Date: Thu, 07 Aug 1997 01:23:58 -0700
Organization: PlayStation Net Yaroze (SCEE)
Lines: 53
Message-ID: <33E9861E.E27@dial.pipex.com>
References: <33E1AB7A.1DEE@dial.pipex.com> <33E1CBFC.42D@interactive.sony.com> <33e82e2d.20050422@news.scea.sony.com> <33E83D6D.31EF@interactive.sony.com>
NNTP-Posting-Host: an099.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)

Developer Support wrote:
> 
> Jamin Frederick wrote:
> >
> >         Does doing a MoveImage() and DrawSync() often bad for
> > performance?  Is it ok to be doing this for say palette cycling?  How
> > about StoreImage() for manipulation in memory every few frames?
> > Is there problematic overhead or can it be done freely?
> >
> > Jamin Frederick
> 
> Yes it is bad for performance. If you are using MoveImage, StoreImage
> and LoadImage its best to rearrange things so they're done just before
> you normally call DrawSync.

Fa' sure!

> 
> You can use StoreImage pointing to an array and change CLUT values
> there, and then do a LoadImage.

This is what I tried to do originally to implement palette cycling on
a section of 32 CLUT entries. I couldn't get it to behave properly,
however, because LoadImage didn't seem to like me giving it a pointer
which didnt point to a 32-bit aligned address (oh no, not *that*
problem again!)...

The problem: each CLUT entry is 16-bit but LoadImage takes 
a pointer to u_long (32-bit) - presumably so LoadImage can copy
data into VRAM in pixel-pairs, along the 32-bit bus.

The upshot: LoadImages were ignored (or the pointer was re-aligned)
when ever I gave it an un-aligned address (i.e. every alternate call
when trying to cycle by a single CLUT entry each time). So:
	call 1) ok
	call 2) nothing happens :(
	call 3) CLUT section is cycled by *2* entries

I tried making the appropriate casts etc. with no success, so I dumped
that idea and decided to keep a copy of the CLUT in VRAM and use MoveImage
to copy sections into the original CLUT. This is when I fell victim
to the dreaded 'buffered CLUT' syndrome (see above threads).

Now this prob has been sorted, all is OK. Anyway, keeping everything
in VRAM should be more efficient than using main mem :)

Hope some of this is useful

Chris


> 
> Stuart