Path: chuka.playstation.co.uk!news From: James Shaughnessy Newsgroups: scee.yaroze.programming.2d_graphics Subject: Re: Speed of ClearImage & MoveImage Date: Fri, 13 Feb 1998 19:29:06 +0000 Organization: Bacardi Ferrari V12 Lines: 29 Message-ID: <34E49F02.4B34@manc.u-net.com> References: <34DA30A9.1AE@manc.u-net.com> <34DB2739.6DBFCB37@ndirect.co.uk> <34E1E991.7392@manc.u-net.com> <34E35B41.4211@worldaccess.nl> 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) To: wubbels@worldaccess.nl Ivo Wubbels wrote: >Maybe another solution: keep a 320x240 buffer in memory and copy it to >each vblank to the framebuffer. I do not know if it's fast enough, but >it seems the best solution to me. In this case putting a pixel is just >filling an entry in an array: hyper fast! Hey Ivo, The prob with that method is my virtual screen is 640x512x16bit, which means it's 640Kb -- too big and having tried it previously it worked out way too slow. Much quicker using sprites. I can't have my virtual screen in main memory (with the game maps on the frame buffer) because I want it to be wider than the visual screen to get horizontal scrolling (as I'm not using a BgImage map for simplicity). I am now using GsSprites for the bullets which are directly drawn onto the frame buffer vir. screen (relatively very fast) and have a 1-bit 640x512 (only 40k) collision mask in main mem for bullet-background collisions. All other sprite drawing ops are done in the D-Cache using an array the way you describe, for mega fast pixel-perfect collision detection. It all works together pretty well (although I get slow-down when there are about 250 bullets on screen, which is enough I guess) Later, Jim -- ----------------------------------------- James Shaughnessy james@manc.u-net.com http://www.netyaroze-europe.com/~shaughnj -----------------------------------------