Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!rutgers!njin!limonce From: limonce@pilot.njin.net (Tom Limoncelli) Newsgroups: comp.sys.amiga Subject: Re: JrComm 1.0 Message-ID: Date: 20 Jul 90 22:39:08 GMT References: <31705@cup.portal.com> <23847@uflorida.cis.ufl.EDU> <833.26a02388@desire.wright.edu> <2610@corpane.UUCP> <15664@s.ms.uky.edu> Distribution: na Organization: Drew University/NJIN Lines: 25 In article <15664@s.ms.uky.edu> phoenix@ms.uky.edu (R'ykandar Korra'ti) writes: > In article <2610@corpane.UUCP> sparks@corpane.UUCP (John Sparks) writes: > Q: How about, instead of scrolling, say, two of four complete screen > bitplanes at a time, scrolling four bitplanes for half the screen each time? > You'd have a momentarily duplicated line, but it's a lot cheaper than double- > buffering, no? Didn't someone once post a message about allocating bitplanes in contiguous memory so that the entire scroll of 2-5 bitplanes could be done in one call to the blitter? It reduced this problem almost completely. The only problem was that you had to have a lot of contiguous memory. A program could try to allocate the memory that way and if it fails default to the "standard" method. (And a nice feature would be to make it possible to fail completely if it couldn't allocate it all in one shot). -Tom -- tlimonce@drew.edu Tom Limoncelli tlimonce@drew.uucp +1 201 408 5389 tlimonce@drew.Bitnet "You'd better move ovah limonce@pilot.njin.net ...here comes a supernova" -The B-52's.