Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!milton!yoda.eecs.wsu.edu!pcooper
From: pcooper@eecs.wsu.edu (Phil Cooper - CS495)
Newsgroups: comp.sys.amiga.programmer
Subject: Superbitmaps
Message-ID: <1991Mar20.214447.7754@eecs.wsu.edu>
Date: 20 Mar 91 21:44:47 GMT
Organization: Electrical and Computer Engineering, WSU
Lines: 50


    I have a bunch of questions for the experts on this net.  I am
currently working on a wargame, and I have run into several problems
using the superbitmap window type.  A little background here.  The
superbitmap is being used to hold a small part of a very large map.
This is shown graphically below:

       --------------------------------------------
       |                                          |
       |            MAP                           |
       |                                          |
       |              ------------------------    |
       |              |  Superbitmap         |    |
       |              |                      |    |
       |              |         -----------  |    |
       |              |         | Display |  |    |
       |              |         |         |  |    |
       |              |         |         |  |    |
       |              |         -----------  |    |
       |              ------------------------    |
       --------------------------------------------

    I have chosen this approach because the entire map cannot be held in
chip memory.  So, the superbitmap is held in memory and the display window
scrolls around in it until a border is reached.  At that time, the 
superbitmap window is redrawn to contain a different part of the map.
At least, that is the way it is supposed to work.  My problem is how do
you keep track of the current position of the display in reference to the
superbitmap?  Also, when the the superbitmap window is initially opened,
where is the display located on the superbitmap?  I know these are basic
questions, but I have yet to find any answers in the RKM's about them.
I'm trying desperately to be intuition friendly, but scrolllayer() and
scrollraster() are pitifully, PITIFULLY slow.  Any suggestions?
    One other question while I'm at it.  I want to change the default color
palette so that I can use different colors.  I am using 640x200 mode, so
I'm limited to 16 colors.  So, I declare a USHORT array with 16 hex entries
like:  USHORT palette[16] = { 0x0FFF, 0x0F40,...} and call LoadRGB4 passing
the address of the screen's viewport , the palette array, and 2**DEPTH.
The palette does get changed, but not to the colors I want.  Gadgets in
particular are drawn in colors not even in the palette.  What gives?  I know
the hex numbers are correct for the colors I want, so I am at a loss.

     Thanks in advance...
         -Phil-

-- 
/********************************************************************\
*   Real Life:   Phillip R. Cooper                                   *
*       Email:   pcooper@yoda.eecs.wsu.edu                           *
*  Disclaimer:   Disclaimer?? I don't need no stinkin' disclaimer!!! *