Re: Bitmap collision detection in VB6
- From: Mike Williams <gagamomo@xxxxxxxxxxx>
- Date: Wed, 12 Dec 2007 09:33:47 -0800 (PST)
On 12 Dec, 15:03, Brigand <markash...@xxxxxxxxxxx> wrote:
Currently, my game does collision detection as
the standard, good ole'fashioned intersecting
rectangles calculation - simple enough, and not
too processor intensive for the most part.
Actually intersecting rectangles has always been the mainstay of
sprite collision detection, and it is *very fast* in a compiled exe
almost to the point of taking no time at all, and if (as it seems) you
are happy with the results then you can leave it at that. Otherwise if
you want to add pixel collision detection you can add a further
routine to check in more detail any "rectangle collision" that is
flagged by the intersecting rectangles technique to see if it actually
contains two or more overlapping sprite pixels. You only need to pass
this routine the actual rectangle that is formed where the two sprite
rectangles overlap (a rectangle that is usually very much smaller than
either of the two sprite rectangles themselves) and perform a couple
of blit operations on them and you'll end up with a small white
rectangle that may or may not contain one or more black pixels. If it
does contain a black pixel then the actual sprite pixels are touching,
representing a "pixel to pixel" collision has occurred between the
sprites. This technique works fine for all sorts of multi coloured
sprites. However, if what you are currently doing suits your purposes
then you can of course just stick with that (rectangle collisions are
often all that is required in many games).
This works GREAT for sprites. But not so great
for the ground/background/environment. The
downside is that I have to basically map
rectangles to every part of my environment,
over the top of whatever image I draw for the
background. It works.....but is not very
elegant, and requires a mind numbing amount
of work mapping rectangles and checking each
and every one of them for collisions on each
screen. What I would LIKE to do is draw my
background, and import it as a bitmap, and
use some sort of algorithm to determine
collisions with the bitmapped image.
To be honest it is ages since I've done any serious games programming
(about 20 years ago on my C64 and Amiga) and I've forgotten most of
what I knew then! The best I can think of at the moment is to perhaps
load your background image (either a drawn image or a photograph or
whatever) into a VB Autoredraw Picture Box, making sure that your
design environment is running on a full colour display (your game is
not required to run on a full colour display, just your design
environment) and to run some code to set every black pixel in the
image to "near black" (perhaps RGB 1,1,1) and then save it out as a
bmp file (separate from the original bmp picture file). You can then
load that bmp file into your favourite image editor (even MS Paint
would do) where it will look virtually identical to the original and
you will then be able to use a "pure black" pen to draw over every
part of the image that you want to be a "collision area", so that the
collision area is black (it doesn't matter what colour is under the
black you are drawing). Then save the file from the image editor as a
separate bmp file. This bmp will have pure black in every area which
you want to be a collision area, and nowhere else will be pure black
because of the RGB (1,1,1) thing you did in the first step. You can
then load that bmp into a VB Autoredraw Picture Box and write code to
set every pixel that is "not pure black" to white and save it out as a
bmp file. You will then end up with a bmp file that contains only the
"black collision areas" with the rest of the bmp being white. This
"mask" can then be used in your game. You move your sprites over the
original photo or drawing or whatever in the game but you test for
background collisions only on the "black collision mask" (which of
course is in an off screen DC or Picture Box).
You can extend this idea to as many different background collision
areas as you wish. For example if you want two different "collision
areas" (perhaps black means you have hit some water and red means you
have hit a building) then at the first step I have mentioned your code
would set all black pixels in the original photo to "nearly
black" (1,1,1) and all red pixels to "nearly red" (254,0,0) and save
it out as a bmp. Then load that bmp into MS Paint (as before) but this
time use a black pen to fill in all the "water" and use a red pen to
fill in all the "buildings" and proceed as before, loading it into VB
and running some code on it and saving it out again. You will then end
up with a "background collision mask" for use in your game with the
mask being pure white expect for some black and some red areas, and it
is this mask (rather than the actual background image) that you would
check in your game for background collisions. In this way you can have
any background you wish, a full colour photo for example, and the
background will display exactly on the screen as it is in the original
because none of this "nearly black" and "nearly red" stuff will in an
way affect your original image. It is required only as a step in
producing the mask.
I'm not sure if I've explained all this properly, but I think you'll
get the gist of it. Also, as I've already said, it's a long time since
I've done any serious games programming and others here may have some
better ideas, but this should get you started.
Mike
.
- References:
- Bitmap collision detection in VB6
- From: Brigand
- Bitmap collision detection in VB6
- Prev by Date: Re: Bitmap collision detection in VB6
- Next by Date: Re: Bitmap collision detection in VB6
- Previous by thread: Re: Bitmap collision detection in VB6
- Index(es):
Relevant Pages
|
