pfratar@watserv1.waterloo.edu (Paul Frattaroli - DCS) (09/11/90)
Hi,
I have some questions regarding a very large graphic or bitmap
image. I am programming a game which will have a large map surface
displayed on the screen. This map will be larger than the displayable
screen size, so it will need to scroll. Much like a spreadsheet.
First of all, I would like to give some info on architechture
and graphics so I can put people in the right context when answering
this posting. The program will be for an IBM PC or compatible
runnning DOS 3.x or later. I am planning on using the MCGA
320x200x256 color mode (I can't remember the mode number) for the
graphics display. I will be programming in TURBO C version 2.01 using
the BGI stuff.
I am not sure about the best way to do this. I have thought
about the following ways. These may be "out to lunch".
- A bitmap image - This could get very large, not good.
- An encoded bitmap: I don't need an extremly good amount
of resolution, so I could encode the bitmap in chunks. I
could have a byte-value represent a color, and a routine that
would actually display a chunk of that color that may be
say 3 pixels x 9 pixels.
- A tiling effect: similar to the encoded bitmap, but with
larger chunks that are more like tiles. A two byte code, one
for color, one for pattern. Separate routine to decode and
display tiles.
If I use a bitmap like image or data, I am trying to decide
whether to include the data in the executible or in a separate file.
As to scrolling, I think that the only acceptable method may
be direct screen memory writes. Unless someone can direct me
otherwise.
For all I know I'm probably doing this all the wrong way.
Also, if anyone can suggest some good books that might help I would
greatly appreciate it.
Thanks in advance,
....Paul
--
Paul Frattaroli - Department of Computing Services University of Waterloo Waterloo, Ontario Canada N2L-3G1
< pfratar@watshine.UWaterloo.ca > < pfratar@watserv1.UWaterloo.ca > [129.97.128.171] [129.97.129.140]
NeXT Mail: < pfratar@magpie.uwaterloo.ca > [129.97.32.42]brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/11/90)
In article <1990Sep10.183857.15821@watserv1.waterloo.edu> pfratar@watserv1.waterloo.edu (Paul Frattaroli - DCS) writes: [ wants to display a *huge* map, IBM PC, MCGA ] [ real question, about how to store the bitmap, deleted ] > As to scrolling, I think that the only acceptable method may > be direct screen memory writes. Unless someone can direct me > otherwise. Years ago, just to see that the CGA really worked the way the 1.00 Tech Ref and other manuals said, I wrote a very simple text-mode maze game. You would move your happy face around the screen, dig through walls, suspect (correctly) that the game was changing the maze behind your back, and search for the exit. I don't remember the exact dimensions of the maze, but it was somewhat wider than the screen and much longer. Anyway, scrolling was truly instantaneous: the CGA had something to set the byte offset of the screen within its many screenfuls of memory, and *blip* everything shifted. (The maze was really on a torus. Think about it.) I don't remember many of the details, but I think you could do the same thing in graphics mode---except that you didn't have extra screens to play with, and couldn't easily change the horizontal dimensions. (How many of you know how to program a CGA for what was called ``low res'' graphics? I liked it, anyway.) The MCGA probably lets you use similar tricks, and may have removed some of the CGA's limitations---I dunno. The moral of this story is that you should look in the MCGA docs for a way to set the byte offset of the screen, then use that intelligently. ---Dan
gudeman@cs.arizona.edu (David Gudeman) (09/12/90)
In article <20299:Sep1114:53:0290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
]... I don't remember the exact dimensions of
]the maze, but it was somewhat wider than the screen and much longer.
]Anyway, scrolling was truly instantaneous: the CGA had something to set
]the byte offset of the screen within its many screenfuls of memory, and
]*blip* everything shifted...
I suspect that you are dis-remembering the dimensions and the actual
width was the same as the screen width. I don't know of any way to
use this technique with a map width different from the screen width.
But if you do, please describe it.
--
David Gudeman
Department of Computer Science
The University of Arizona gudeman@cs.arizona.edu
Tucson, AZ 85721 noao!arizona!gudemanbrnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/12/90)
In article <25223@megaron.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes: > In article <20299:Sep1114:53:0290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > ]... I don't remember the exact dimensions of > ]the maze, but it was somewhat wider than the screen and much longer. > I suspect that you are dis-remembering the dimensions and the actual > width was the same as the screen width. I don't know of any way to > use this technique with a map width different from the screen width. > But if you do, please describe it. I'm quite sure it was wider than the screen (the game would have been really silly otherwise). The CGA let you set the virtual text screen width to practically any number. I think small values messed up the horizontal retrace, but large values were fine. I'll go find the code if you'd like. (What, don't you have a Technical Reference from DOS 1.00? Ya know, back in the days when the manual had a full BIOS listing? [grin]) ---Dan
ekalenda@cup.portal.com (Edward John Kalenda) (09/12/90)
> I have some questions regarding a very large graphic or bitmap > image. I am programming a game which will have a large map surface > displayed on the screen. This map will be larger than the displayable > screen size, so it will need to scroll. Much like a spreadsheet. > > ... verbage removed > > As to scrolling, I think that the only acceptable method may > be direct screen memory writes. Unless someone can direct me > otherwise. Having just finished an animated educational game for a client, I'll say a few things about this. The MCGA mode has only one page, cannot have it's starting address changed, and is best dealt with by direct memory writes (you don't have to worry about synching to the retrace). Panning (it's not scrolling) will have to be a matter of copying the portion of the screen which will remain visible to it's new location and filling in the area which was "off screen". If you do "smooth panning" by moving things a small number of pixels (<5 or so), it shouldn't look to bad. Your biggest headache, after you get the code to scribble on the screen, will be managing the pixel data which is off screen. A single screenful is all you will be able to store per memory allocation since 64K is the limit. Taking a peice from this block and a peice from that block will need some very careful program design. THINK it through BEFORE you start writing. Sorry, but I can't give you any examples of how I wrote it since coding for money generally means the finished product is their's, not mine. Ed ekalenda@cup.portal.com