scrolling superbitmaps
7 messages in this thread
i'm using ScrollLayer() to move about on a SuperBitMap window. i'd like to
attach some propgadgets to let the user control the scrolling. the intuition
manual suggest using a GIMMEZEROZERO window and positioning gadgets on the edge
of the window, i assume using the GRELRIGHT and GRELBOTTOM flags. i imagine
this is quite simple but i can't seem to get the right combination of offsets
to properly display and use the progadgets. could someone point me in the right
direction on this problem?
Reinhard,
A couple of points. First, if you are specifying the gadget is GRELRIGHT,
then the horizontal position you specify would be negative, since it is
relative to the right edge of the Window. Similar with a GRELBOTTOM gadget,
except here the vertical position specified would be negative (i.e., relative
to the bottom of the window).
Secondly, you will want to specify that the gadgets themselves are part of
the window's borders. There are flag bits in the Gadget structure Flags member
for this too. They're RIGHTBORDER, LEFTBORDER, TOPBORDER, and BOTTOMBORDER.
To quote from the comments in the intuition.h include:
/* if any of the BORDER flags are set in a Gadget that's included in the
* Gadget list when a Window is opened, the corresponding Border will
* be adjusted to make room for the Gadget
*/
This will insure that these gadgets will be part of the Rastport for the
window's borders rather than the Rastport for the window's innerds. (Note that
GZZ windows have two Rastports associated with them). A word of caution: GZZ
windows use A LOT of memory!
Hope this helps…Bob
bob, if it is not too forward or prohibited by your contract, what type of
windowing and scrolling arangement did you use in EMPIRE?
Reinhard,
Guess I can "reveal" a couple of "secrets". Empire's windows are really
pretty basic SimpleRefresh windows. The program's size and memory needs were
sufficiently large to not allow the use of GimmeZeroZero windows and/or
superbitmap. I felt it was much more important for Empire to be able to run in
a 512K Amiga, than to use some of the fancier features and require that the
program run on an expanded system. I did manage to take advantage of the
availability of extra memory if it is present, as you will notice in comparing
the screen rendering on a 512K system versus an expanded system.
..Bob
yes a gzz superbitmap guzzles memory and in large contiguous chunks too.
i've only been fooling with this a few days and have scrammed the system more
than usual.
btw, i've been able to crash 'empire' by attempting to 'lassoe' (sp?) beyond
the edges of the window; i imagine this has been pointed out long ago.
it's a nice port; i think a design decision should have been made to enhance
the (pseudo-)ai though, even beyond what improvements that you did make to the
game. not to comment on your game, but on computer games in general, i think a
really challenging and complex micro-computer war simulation has yet to be
written. i'm only guessing, but i think the problem is inherently difficult
enough as to put off most programmers. simulating a visual environment in a
game such as SGII or F-18 is also difficult, but portions of the problem can be
well defined and the programmer can roughly gauge whether or not and to what
extent particular visual cues can be conjured up by the given hardware. it's
curious that there isn't much discussion specifically on defining decision
making procedures required to allow a game world to take on aspects of
intelligence. this seems like a basic question that, of course, has
implications for other software also.
Reinhard,
Thanks for the compliments about Empire. Yes – that "crash" in the Group
Survey mode is well known and has been fixed for a long time. Upgrades are
available from Interstel (at not cost, I believe) – just contact them. The
address/phone number is in the manual. (You did register your purchase, didn't
you?)
As far as the "computer intelligence" goes, that part of the game was
totally unchanged by me. The nature of the project was to create a version of
Empire for the Amiga that was totally compatible with the existing version on
the ST, and the version that was to be made available on the IBM PC's and
Klones (and is currently available). Consequently, the only areas that I could
safely change were related to the user-interface / machine-specific
presentation. Of course, I did work with the controlling author concerning
some changes that we mutually made, but the "smarts" code is all his <ducking
the issue – 🙂 >.
…Bob
<sheepish grin> turns out my problems were due to my adjusting window/screen
size to accomodate morerows. this was screwing up all of the graphics.