pcooper@eecs.wsu.edu (Phil Cooper - CS495) (03/21/91)
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!!! *farren@sat.com (Michael J. Farren) (03/22/91)
pcooper@eecs.wsu.edu writes: > > 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. > ... how do you keep track of the current position of the display in > reference to the superbitmap? Maintain an absolute coordinate relative to the big map. When you're filling the superbitmap, set a couple of variables to the offset of the superbitmap with respect to the "big" map. Your current display position with respect to the big map can be figured by something like this: AbsoluteCoord - SuperBitMapOffset - DisplayOffset = DisplayCoord. >Also, when the the superbitmap window is initially opened, >where is the display located on the superbitmap? Should be at 0,0, I would think. Might could be that you can pre-initialize the OffsetX and OffsetY coords in the superbitmap's Window struct, I don't know right offhand. >I'm trying desperately to be intuition friendly, but scrolllayer() and >scrollraster() are pitifully, PITIFULLY slow. Any suggestions? Well, you don't really need them, do you? These routines actually move the pixel data around in memory, and the point of a superbitmap is that you can cause the screen to scroll by simply changing the offsets - no data need move. There's a nice Leo Schwab hack that's pretty old that demonstrates using a superbitmap - it's on an early Fish disk, can't remember the name. As for your LoadRGB4 problem, I haven't a clue - that routine has always worked as advertised for me. -- +-----------------------------------------------------------------------+ | Michael J. Farren farren@sat.com | | He's moody, but he's cute. | +-----------------------------------------------------------------------+
pcooper@eecs.wsu.edu (Phil Cooper - CS495) (03/26/91)
In article <1991Mar21.185704.25773@sat.com> farren@sat.com (Michael J. Farren) writes: >pcooper@eecs.wsu.edu writes: >> >>Also, when the the superbitmap window is initially opened, >>where is the display located on the superbitmap? > >Should be at 0,0, I would think. > That's right. I checked it out today. Too bad nothing in the RKM's mention this. >>I'm trying desperately to be intuition friendly, but scrolllayer() and >>scrollraster() are pitifully, PITIFULLY slow. Any suggestions? > >Well, you don't really need them, do you? These routines actually move >the pixel data around in memory, and the point of a superbitmap is that >you can cause the screen to scroll by simply changing the offsets - no >data need move. > If I understand the RKM's examples, the entire superbitmap is scrolled *underneath* the display. You are not scrolling the display over the superbitmap. Besides being slow, the ScrollLayer() command flashes the display while scrolling vertically. It appears very jerky, and hardly eye-appealing. Now, my question for the day: Is it possible to have true fine scrolling while running under intuition? I want to use menus and gadgets, so I have to remain Intuition-friendly. >As for your LoadRGB4 problem, I haven't a clue - that routine has always >worked as advertised for me. >-- I already found the problem. Thanks anyway... >+-----------------------------------------------------------------------+ >| Michael J. Farren farren@sat.com | >| He's moody, but he's cute. | >+-----------------------------------------------------------------------+ -- /********************************************************************\ * Real Life: Phillip R. Cooper * * Email: pcooper@yoda.eecs.wsu.edu * * Disclaimer: Disclaimer?? I don't need no stinkin' disclaimer!!! *