Lage bitmap backgrounds for 2D games

Hi,

Either I don't know how to search properly (a definite possibility) or the search function on this site is kind of weak because I'm sure this has been asked before.

I have a 2D shooter in which I would like the player to be able to walk around a scrolling bitmap background about 3 screens wide by 2 screens high (at 800 x 600 resolution, so 2400 x 1200). I want it to have a hand drawn appearance kind of like Postal's backgrounds had or the Commandos games so a tilemap isn't appealing.

My concern is the massive amounts of memory these images will take up especially since each 800 x 600 "tile" will require a black and white collision image as well.

Am I worried about nothing?
How do these other games get away with such large background plates?
Should I load the background as tiles (ie. 50 x 50 or 800 x 600) or just load one big image?
Has anyone done anything like this in Blitz before?

Lastly, if I'm not mistaken, Postal was actually 3D characters over a 2D background. Is this a better way to go?

Thanks for your help!

Would you be doing this with the 3d commands, even if it's 2d? Because if you intended to do it in pure 2d, some videocards won't let you load an image which is bigger than the screen res. So in that case, I would, at the very least, break it into screen-sized chunks.

You're not worrying about nothing, because Blitz doesn't offer any kind of texture compression and lots of big images will eat up your videoram pretty fast. If you can use tiles, I would highly recommend it. I would be tempted to use 3d for the whole thing, but perhaps just 2d-in-3d ( flat meshes ) for speed of rotation and scaling. It might make it easier to make your maps with tiles that way too.


And yes, the search function on this website is broken.

You could possibly load in only the parts of your background that are visible on screen at the time.
Divide your background into seperate images, each say 320x240 big, and then LoadImage, FreeImage as necessary.

This probably wouldn't work well though if your game will frequently load, free the images.

I have tested single background images bigger than 2400 x 1200 and have yet
to see a modern PC that will not handle it. You know, every game comes with
a set of PC-specs necessary to make it run ok, even a 16MB video-card will
handle that kind of sized images ok. If your beta-testers experience problems
on a smaller card you just upgrade the specs necessary....
"Everybody" have at least 32MB videomemory these days anyway, at some point
you have to let the oldtimers (in this case old Pc's) go !
In one of my games I use a 2500x1000 background and I have yet to see a PC still in use it won't run on.
(Yes I know there *are* older PC's out there but they are few and ready for a museum anyway...)
In the same game I use 3D over 2D to get the best out of both worlds.

So, yes, you worry about nothing.

Also it appears to be a little known fact that Mark has stated himself that he has coded a workaround for large image handling - presumably Blitz hacks large pictures into smaller ones internally, before dumping them on the vid card, and takes care of drawing them properly also internally.

Cancerian, apart from space/memory restrictions you might be placed under, go nuts if you want. Just remember:

800x600=480,000 pixels
16 bit = 2bytes, 32 bit = 4 bytes
480000x4 = 1,920,000 bytes
1920000/1024=1875 KB

Front buffer and back buffer = 2x1875 = 3.7 MB

Which means an 800x600 game in 32 bit screenmode requires a 4MB gfx card before any gfx are even loaded!

A 2400x1200 graphic at 32 bit requires an extra 11megs, so that's almost 15meg gone already. And then I suppose you want to draw other stuff onto that graphic as well ;] I'd say your minimum specs are looking at a 32MB card, maybe even 64MB depending on just how wild you go =]

I used 16 bit on that peticular game.

If that is true, which I assume it is, then he really have nothing to worry about, Mark handles the job :)

And ?.... 4MB is nothing !

My point is, why hassle a lot if you don't have too, if it works it works and if a few vintage PC's can't handle it, so be it......

If Mark's coded a workaround, I hate to be the one to tell y'all but it doesn't work: I've got a P3/700 with an Intel chip that won't take any image larger than screen size without corrupting the image areas beyond the screen res -- and yes, that's the latest version of Blitz. Granted that machine is hardly hi-spec anymore, but if you're targeting low-end audiences, yes, be careful of this.

I guess it's more down to the gfx card than the cpu. I say go for a single image, Cancerian. One thing NOT to do is try pasting an image larger than the the screen size to the screen buffer - use drawblockrect or drawimagerect (use blockrect in preference if u don't need a transparent bg) to draw an 800*600 portion of your image to the screen. I've had no problems doing this and it runs better than a tilemap engine.

Blitz plus would allow you to load your collision map into ram rather than vidmem which would give quicker collisions (I'm guessing) and allow you to save vidmem of course... but I guess from the forum u r using b3d.....
...... upgrade to bmax? ;)

Sorry, I posted and then went away for the weekend :)

Thank-you all for the advice. I guess I will do a number of tests to come up with a good system that works on lower end computers. My minimum spec is a PIII 500 with a 32MB video card. Anyone with less than that isn't interested in playing games anyways (other than solitaire, I mean).

Do you think using a seperate black and white collision map is the best way to go for player to environment collisions?

I also wanted to have another graphics layer so that anything the player kills will remain on the background permanently. Hmmmm....maybe I do need to go to a tile map.

Thanks again!