1. Tile-engine vs Bitmap-engine, Was: Virtual displaying of images
Warning! LONG post!
>>> I want to create a huge image containing all the map of the game, but
>>> to create that I need a method for "displaying" an image in this big image,
--->8---
>>> or this is the best method ?
>> Don't use a sequence, but allocated memory.
--->8---
>> Hope this helps (It was a bit complicated)
> Thanks, I'll try your code. The method I want doesn't need to be so
> complex, I'm trying to do a game in the Warcraft style, a background that
> scrolls one tile at a time (not like Command & Conquer, that scrolls pixel
> by pixel). I'm testing to see wich is the best method: Reading a map
> variable and displaying tile by tile the current screen or displaying the
> entire region of the map, like a bitmap.
> If I use the last method, I would need a 4096 X 4096 image (if the map size
> if 128 X 128 tiles and each tile is 32 X 32 pixels), but when I fill this
> huge image with the map data, it takes a lot of time using my code.
> I think Warcraft II uses the second method, Am I right ?
Whoa! You're talking about drawing the whole map in memory, and just displaying
a small part of it right? Do the math! You'll need bizzarre amounts of memory
to do that! I quite sure C&C only draws screen+1*tile on a virt-screen, and
copies _that_ out smoothly scrolled... The memory you save (or rather, refrain
from wasting) you can use to have more tile-types, bigger map, etc...
Besides, you'd have to have a virtual screen anyway, to copy in players, etc,
and you'd still have to have a integer-array version of the map to keep the
players "off the grass"...
A good thing about this system, is that you can easily have maps of different
sizes, very, very, large maps, and you can even change the map in-play...
It's a coherent, consistent, simple, memory conservative, and very, very
flexible system!
If that doesn't do it for you, how does this sound:
===================================================
It's only necessary to keep 9 "regions" in memory, at a time, the rest can be
kept on disk! (nine because: the one the player is on, and it's neighbors)
*Disk* size sets limit for map size!!! (With even an antique harddrive, this is
a lot!)
Different regions can have different tile-sets, loaded to memory only when
necessary, of course! (With a limit of max three tile-sets in memory, you must
of course make sure that no 3x3 regions block can have four sets...)
Player can destroy the landscape! Burnt up trees! Bomb craters! (For a
brilliant example of this, try high-explosives in "syndicate wars"!! (or the
craters in C&C))
Let's do the math!: (Clumsy example)
===================
Total mem usage:
----------------
Bitmap style: Map style:
x_tiles*x_tile_size* x_tiles*y_tiles*tile_data_size+
y_tiles*y_tile_size+ virtscreen
x_tiles*y_tiles*
tile_data_size+
virtscreen
To add Q tiles x-wise, memory usage:
------------------------------------
Bitmap style: Map style:
y_pixels*Q*tile_x_size+ y_tiles*Q*tile_data_size
y_tiles*Q*tile_data_size
Obviously, the "bitmap"-method is a real memory hog, but it is not completely
without uses: Tiny-car racing games (seen from directly above) usually have
relatively small maps. In addition, tiles don't make sense here, since
colliding with the scenery is a pixel by pixel affair.
A separate collision-picture is kept in memory. (yes, *picture*) Rocks, oil
slicks, sand, whatever, are represented by different "colors" (only the
developers ever see the picture at all) and collision is tested with this
separate picture before the cars are drawn on the real screen...
Big "maps" suck a lot of memory, but the method is fast and uncomplicated.
The requirements all fit; in short, it makes sense.
> Ricardo Niederberger Cabral <rnc at infolink.com.br>
Anders
Ps. I hope this doesn't sound patronizing! Although I'm very short on actual
coding I make a point of learning the algorithms. A better algorithm beats
better optimized code any day and twice on sunday! While I agree with Packard's
view of think/design first, code later, it makes for big projects. I would
prefer to design and code an "engine" first, separately. This way you can toy
with it, and see some new ideas, and when you know what you want, a big chunk
of the work is already done...
-------------------------------------------------------------------
Anders Eurenius <c96aes at cs.umu.se> ICQ UIN:1453793
Computer Science/Engineering student at the university of Umeaa
-------------------------------------------------------------------
