Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!pacbell.com!tandem!netcom!mcmahan
From: mcmahan@netcom.COM (Dave Mc Mahan)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: SuperBitMap Layers, etc.
Keywords: SuperBitMap, Layers, Graphics
Message-ID: <27367@netcom.COM>
Date: 8 Mar 91 07:28:00 GMT
References: <27D2B7A7.3CE7@ibma0.cs.uiuc.edu>
Organization: Dave McMahan @ NetCom Services
Lines: 66


 In a previous article, menelli@sunc7.cs.uiuc.edu (Ron Menelli) writes:
>I've got a bit of a dilemma that I hope someone can assist me with. Here is
>some background...
>
>I need to have four completely borderless, full screen windows on a custom
>screen. They are intended to act as "pseudo screens". Also, I need to write
>pixel by pixel onto this screen. I tried WritePixel(), which worked but
>was abysmally slow. I've spent much time attempting to replace it with
>something of my own that is faster...

Yeah, I found this out too.  I did some timing analysis on WritePixel() and
there is some room for improvement.  The downside is that you have to start
going at the window BitMap and SuperBitmaps directly.  It's a bit dangereous
and not really a good idea if you have things like menu bars, requesters, or
other things that can asynchronously 'pop' onto your screen at any time.
It's also NOT gauranteed to work in future revs or models of the amiga.  It
is, however, fast.


>What I did was write a bit of code that writes directly to a BitMap structure
>in hopes that this was what I was looking for. It turned out to be a good
>four or five times faster than WritePixel(), but unfortunately, due to my
>lack of knowledge of the workings of low-level Amiga graphics, I was quite
>surprised to find out that writing to any of the four stacked windows resulted
>in the image being displayed on the frontmost window.
>
>My next attempt was trying to write to a SUPER_BITMAP (instead of 
>SMART_REFRESH) window, so I could write to the superbitmap instead of the
>common screen bitmap like I was doing before. This resulted in nothing being
>displayed at all. After paging through the AutoDocs, I found the
>CopySBitMap() function that updates layer information after a write to the
>superbitmap structure. This made everything work, but it was MUCH slower than
>WritePixel.

What I did was open a SuperBitMap screen with one window.  I knew where on the
SuperBItMap I wanted to place the pixel, so I did a bit of math to determine if
that area falls within the window being displayed or outside the window and is
therefor in the SuperBitMap.  I then picked the desired spot and banged the
BitPlanes directly from my program.  Pulling down a menu bar resulted in my
program writing right across the menu items, so I put in a 'hook' that would
turn off this type of writing when the menu is activated BEFORE I let
neverintuition make the menu bar.  It ain't pretty, but then writing 2000+
pixels/sec never is.  When using this technique, you have to be careful about
refreshing the window being displayed from the SuperBitMap.  AmigaDos thinks
that ALL the info resides within the SuperBitMap and will wipe out all your
hard work if you try and scroll things around.  To avoid this, you have to
ScrollLayer(0,0...) first to force AmigaDos to copy the stuff in the window
to the SuperBitMap.  Like I said, it ain't pretty.  It's been a while since
I did this, but if you have interest, I'll look up the details in the code I
wrote.

Please, no religious commentary on why I shouldn't do this.  I know I
shouldn't, but there just isn't any way to do it fast enough otherwise.



>Ron Menelli
>menelli@cs.uiuc.edu
>menelli@sumter.cso.uiuc.edu

   -dave

-- 
Dave McMahan                            mcmahan@netcom.com
					{apple,amdahl,claris}!netcom!mcmahan