Collision detection with pixels
4 Message(s) by 4 Author(s) originally posted in java games
| From: maugister |
Date: Tuesday, December 30, 2003
|
Hi!
I've been working on a
network arcade shooting game where players
control ships and battle each other in small levels and gravity plays
big part in the gameplay. If somebody remembers Gravity
Force for
Amiga, this is basically made in same spirit.
I use
SWT instead of
AWT and the game
engine itself is now quite
ready, but I've been trying to think of way to get the bullets act
like they do in another Gravity Force -like game
named Auts. In Auts,
each bullet was able to cause small holes in every
bit of material the
level was made of. So basically as soon as the bullet
hit any other
color than black, it disappeared and painted that area as small black
dot. Because the basic
collision idea'd be that wherever there is
black, the ship and the bullets can fly, but any other
colour and they
can not, with this kind of rule one could tunnel your ship through any
material quite easily by shooting yourself a road. The ships collision
will be detected by only one
coordinate , so it can use as small as
one-
pixel -wide tunnels.
Now the problem is that first I tried to use AWT's PixelGrabber tool,
but it seemed to be very heavy to use and I could not do decent check
for one ship without causing the game to slow
down heavily. Then I
changed to SWT and I was able to do nice collision detection for the
player's ship. But when it comes to the bullets, it's still too heavy
to do a pixel grabbing check for every bullet on every loop. There can
easily be more than 100 of bullets on the air at the same time.
So I was just wondering if there is some other, more efficient way to
check the color value in some arbitrary coordinate of an Image? Or is
there some other way of thinking this whole problem through? The nice
thing with this colour-check is that you can do very easily very cool
levels by just painting them straight away without working around with
level editors and
object s which represent walls and blocks, because
the
image itself contains all the information, pixels and colors,
which are needed to know where one can fly and where one can not. And if
the pixel grabbing is efficient enough then one can make the whole
damn
environment destroyable, which is really cool thing, it was the
main thing I liked in auts.
This is the checkCollision
method I've in the
current version, which
works fine for the ship and as long as there are less than 20 bullets
in the air. It is made using coordinates the ship/bullet will be if it
is allowed to take next step:
public boolean checkCollision(
int row, int line, int x, int y) {
pixel = map.pictures[row][line].getImageData().getPixel(x,y);
red = (0xff & (pixel 16));
green = (0xff & (pixel 8));
blue = (0xff & pixel);
if(red==0&&green==0&&blue==0)
return false;
return true;
}
-Matti Paalanen
| From: Bob Harris |
Date: Tuesday, December 30, 2003
|
Howdy, Matti,
Without thinking about this too much (in other words, without checking the
nitty gritty JAVA details), is not it possible to grab the pixel
array once
instead of every time you need it? In other words, does not the graphics
object that you draw into have a pixel map that it is using, that never
changes location, and which you could get access too?
If not, could you perhaps make your own graphics object that *does* behave
that way?
Bob H
From: maugister@xxxxxxxxxxx (Matti Paalanen)
Organization: http://groups.google.com
Newsgroups: alt.comp.lang.JAVA-games
Date: 30 Dec 2003 13:17:04 -0800
Subject: Collision detection with pixels
Hi!
I've been working on a network arcade shooting game where players
control ships and battle each other in small levels and gravity plays
big part in the gameplay. If somebody remembers Gravity Force for
Amiga, this is basically made in same spirit.
I use SWT instead of AWT and the game engine itself is now quite
ready, but I've been trying to think of way to get the bullets act
like they do in another Gravity Force -like game named Auts. In Auts,
each bullet was able to cause small holes in every bit of material the
level was made of. So basically as soon as the bullet hit any other
color than black, it disappeared and painted that area as small black
dot. Because the basic collision idea'd be that wherever there is
black, the ship and the bullets can fly, but any other colour and they
can not, with this kind of rule one could tunnel your ship through any
material quite easily by shooting yourself a road. The ships collision
will be detected by only one coordinate, so it can use as small as
one-pixel-wide tunnels.
Now the problem is that first I tried to use AWT's PixelGrabber tool,
but it seemed to be very heavy to use and I could not do decent check
for one ship without causing the game to slow down heavily. Then I
changed to SWT and I was able to do nice collision detection for the
player's ship. But when it comes to the bullets, it's still too heavy
to do a pixel grabbing check for every bullet on every loop. There can
easily be more than 100 of bullets on the air at the same time.
So I was just wondering if there is some other, more efficient way to
check the color value in some arbitrary coordinate of an Image? Or is
there some other way of thinking this whole problem through? The nice
thing with this colour-check is that you can do very easily very cool
levels by just painting them straight away without working around with
level editors and objects which represent walls and blocks, because
the image itself contains all the information, pixels and colors,
which are needed to know where one can fly and where one can not. And if
the pixel grabbing is efficient enough then one can make the whole
damn environment destroyable, which is really cool thing, it was the
main thing I liked in auts.
This is the checkCollision method I've in the current version, which
works fine for the ship and as long as there are less than 20 bullets
in the air. It is made using coordinates the ship/bullet will be if it
is allowed to take next step:
public boolean checkCollision(int row, int line, int x, int y) {
pixel = map.pictures[row][line].getImageData().getPixel(x,y);
red = (0xff & (pixel 16));
green = (0xff & (pixel 8));
blue = (0xff & pixel);
if(red==0&&green==0&&blue==0)
return false;
return true;
}
-Matti Paalanen
| From: Claus L. Petersen |
Date: Friday, January 09, 2004
|
snip>
public boolean checkCollision(int row, int line, int x, int y) {
pixel = map.pictures[row][line].getImageData().getPixel(x,y);
red = (0xff & (pixel 16));
green = (0xff & (pixel 8));
blue = (0xff & pixel);
if(red==0&&green==0&&blue==0)
return false;
return true;
}
How about making your
code more efficient??
insted off all your bit shifting and AND'ing you could proberly do something
like this:
public boolean checkCollision(int row, int line, int x, int y)
{
pixel = map.pictures[row][line].getImageData().getPixel(x,y);
return ((pixel && 0xffffff == 0) ? false : true);
}
this should give you less calculations, and therfor faster code
hope it helps
Claus Petersen---
Outgoing
mail is certified Virus Free.
Checked by AVG anti-
virus system (
http://www.grisoft.com).
Version: 6.0.556 / Virus Database: 348 - Release Date: 26-12-2003
| From: nobody important |
Date: Tuesday, January 13, 2004
|
And let's hope somewhere the
compiler removes the redundant ternary
operator, fixes the boolean AND-operator (&&) to a integer bitwise
AND-operator (&) and someone flicks the returnvalue :o)
// returns true if any of the
RGB values are set
return pixel & 0xffffff != 0;
snip>
> public boolean checkCollision(int row, int line, int x, int y) {
> pixel = map.pictures[row][line].getImageData().getPixel(x,y);
> red = (0xff & (pixel 16));
> green = (0xff & (pixel 8));
> blue = (0xff & pixel);
> if(red==0&&green==0&&blue==0)
> return false;
> return true;
> }
>
How about making your code more efficient??
insted off all your bit shifting and AND'ing you could proberly do
something
like this:
public boolean checkCollision(int row, int line, int x, int y)
{
pixel = map.pictures[row][line].getImageData().getPixel(x,y);
return ((pixel && 0xffffff == 0) ? false : true);
}
this should give you less calculations, and therfor faster code
hope it helps
Claus Petersen
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.556 / Virus Database: 348 - Release Date: 26-12-2003
>
Blogs related to Collision detection with pixels
Java shooting games
SonyEricsson Z600 uc someone knows a thousand free online
Java and Family Guy vs.
... Page - Shots, Current Page -
Collision detection like Space Wars allows
... THE SHOOTING GALLERY is 480
pixels wide . Check out our classic games like
...
software releases and upgrades for august 14, 2006 - macintosh
starlogo tng 1.0pre3 [requirements: mac os x 10.4.6 or later.
java 5
... faster
collision detection (no computation for breeds without a
collision block)
... tolerance needed to select one particular
pixel. now it does. short said: when
...
Tech aconyms
CSMA-CD Carrier Sense Multiple Access with
Collision Detection ... JAAS
Java Authentication and Authorization Services
... PIXEL Picture Cell. PKCS Public Key Cryptography Standards
... RED Random Early
Detection - Cisco ®
...
Multithreaded Concurrent Game Design and Architectures
Purely functional core (Physics,
collision detection, require some localized
... hopefully implement some of the techniques using the
Java Monkey Engine. I’m also reading a great book specifically on concurrent programming
Java, called,
...
Latest Additions - 17.07.06 (389 new tips)
How to use PixelGrabber class to acquire
pixel data from an Image object; Calculation of the mean value of an
... How to make a file read only through
Java program
... Collision detection - NeHe Tutorial JOGL Port; Blitter function,
...
A Glossary of Computer Oriented Abbreviations and Acronyms
CSMA/CD Carrier Sense Multiple Access/with
Collision Detection CSMS Customer Support Management
... JTAPI
Java Telephony Application Programming Interface JZ Jump if Zero
... TWIP Twenty In Point (as in 20 twips/
pixel) [Microsoft]
...