Path: chuka.playstation.co.uk!news From: Alex Herbert Newsgroups: scee.yaroze.programming.2d_graphics Subject: Re: How do I manipulate Pixels? Date: Wed, 12 Aug 1998 17:16:17 +0000 Organization: PlayStation Net Yaroze (SCEE) Lines: 30 Message-ID: <35D1BFD1.434C188E@ndirect.co.uk> References: <6qfcml$ldg12@chuka.playstation.co.uk> <35D05CE9.7B63@writeme.com> Reply-To: aherbert@ndirect.co.uk NNTP-Posting-Host: dialin2-06.ndirect.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.04 [en] (Win95; I) James Rutherford wrote: > The best way I can think of is by predefining an area in VRAM (size > 128x128?) full of randomly coloured pixels - possibly using a LoadImage > method as outlined above, and then setup smaller GsSPRITES (eg 32x32) to > cover your screen. > > You can then alter the sprite u and v co-ordinates semi-randomly > (slightly faked so that they never point to the same area on consecutive > frames). > > Should be fast and fairly fluid - you can also have fades and > transparency effects. > > If I were you, I'd steer clear of colour cycling - unless you're really > clever about it, it tends to look naff. > Yeah, I've just been experimenting with this. I used the above method except I used a GsBG instead of GsSPRITEs. In the end I found that simply ramdomising the scrollx/y components did the job just fine! Colour cycling looked OK when I used a 256 colour CLUT but looked cack with 16 colors. I opted for the GsBG way in the end 'cos the GPU can chuck a BG full of 4-bit data at the screen quicker than the 8-bit data needed for the colour cycling, let alone the processing time needed to randomise the CLUT. Herbs