Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (524)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (592)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Collision detection for 2d/planar textured polys  (Read 1738 times)
0 Members and 1 Guest are viewing this topic.
Offline Bombadil

Senior Devvie





« Posted 2004-05-10 05:35:18 »

Hi. I use Jogl to draw some 2d "sprites" (like explained in Kev's nice Space-Invaders tutorial): a sprite consists of a planar quad polygon with z=0, texture mapped. Usually a texture has got an alpha layer, so it can be blended with an 8bpp mask on the background (RGBA texture).

When it comes to collision detection I could probably use some bounding boxes in the form of circles or ellipses. However in the good old home computer days, there's been some sprite chips which allowed detection of pixel wise collision.
Would pixel collision detection work with alpha textured quad polygons in Jogl (or OpenGL), too? Right now I couldn't imagine how this could work, but maybe you smart guys out there know more.

PS: Sprites will need to rotate around the z-axis, too.
Offline kevglass

« JGO Spiffy Duke »


Medals: 208
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2004-05-10 06:12:44 »

Just throwing this around in my head and wondered if you could something like rendering in select mode.

* Render everything that you might collide with one name and with the stencil buffer set to write
* Render the collision target with a second name with the stencil buffer setup only to draw where it was previously written
* Check the GLSelect response for drawing of the collision target.

I'm not sure if GLSelect counts a poly as rendered if it wasn't actually written due to a stencil filtering. I'm also not sure if this would be quick.

Also, I'm pretty sure you'd want to do a bounding box check first.

Kev

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #2 - Posted 2004-05-10 06:19:44 »

Someone from round these parts (zparticle?) had a bitmask collision testing routine that was pretty damn fast. Basically AND'ing some pre-created boolean arrays together at the correct offsets. Not sure how you'd cope with rotations, but I suppose you could also pregenerate those as well if you wanted.

Should be in the forum archives somewhere...

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #3 - Posted 2004-05-10 07:33:12 »

Search for a software rotation tutorial (256 colors "mode x" would be a good starting point). Take the alpha channel and rotate it that way. Then you can check against those rotated alpha pixels (>127).

However, it's rather slow - therefore precheck with bounding boxes. Oh and pixel accurate collision detection is overrated Wink

弾幕 ☆ @mahonnaiseblog
Offline Bombadil

Senior Devvie





« Reply #4 - Posted 2004-05-10 10:35:32 »

Thanks people for the ideas.
If possible, I'd prefer Kev's idea of hardware (stencil) testing. However it's yet unclear if it works. :-)
Software detection seems slow to me: I intend to have <i>lots</i> of sprites on the screen, and many of them will be rotated at any angle all the time.

Bounding rects will of course be used as pre-selection. However, if bounding rects / circles only will do, I can't judge yet. A friend of mine says it must be pixel accurate, and well, we both played Xenon (II) in the old days and damned the inaccurate collision detection. ;-)
Offline kevglass

« JGO Spiffy Duke »


Medals: 208
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #5 - Posted 2004-05-10 12:04:46 »

I'm only blathering, so if someone with lots of OpenGL knowledge could chime in I'd appreciate it..

I'll try and rough something up if I get a chance, to see if it works

Kev

Offline kevglass

« JGO Spiffy Duke »


Medals: 208
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #6 - Posted 2004-05-10 13:06:26 »

Thinking about it, I'm not sure you'd be able to tell what you'd hit.

Kev

Offline kevglass

« JGO Spiffy Duke »


Medals: 208
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #7 - Posted 2004-05-10 14:39:22 »

Oeer, change my mind again. If you stencil in the target of the collision (say the spaceship) then draw all the targets in the area against that alpha stencil they only draw if their intersect the orignal sprite.

The GL_SELECT might then return the list of hits as only the things that have intersected with the target...

That might even work,

Kev

Offline kevglass

« JGO Spiffy Duke »


Medals: 208
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #8 - Posted 2004-05-10 16:55:26 »

Bad news, seems GL_SELECT ignores stencilling. So it don't work, sorry.

Kev

Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #9 - Posted 2004-05-10 20:28:54 »

> Software detection seems slow to me

It's faster than it looks like. Keep in mind that you don't draw that rotated thingy. So no ram -> vram delay.

However it's ofcorse slower than hitboxes. Btw don't forget that you can also just use hitboxes wich are a bit smaller than the sprites (own hitbox smaller/enemy hitbox bounding - in favor of the player).

Also those (vs alpha) checks can be optimised in several ways. Eg scanline-ish. But, as I already pointed out, it's slow and overrated. Really. Even the newest games doesn't use per pixel col. Just use in favor of the player collision detection and everything is ok Wink

弾幕 ☆ @mahonnaiseblog
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

toopeicgaming1999 (55 views)
2014-11-26 15:22:04

toopeicgaming1999 (48 views)
2014-11-26 15:20:36

toopeicgaming1999 (8 views)
2014-11-26 15:20:08

SHC (24 views)
2014-11-25 12:00:59

SHC (24 views)
2014-11-25 11:53:45

Norakomi (26 views)
2014-11-25 11:26:43

Gibbo3771 (23 views)
2014-11-24 19:59:16

trollwarrior1 (36 views)
2014-11-22 12:13:56

xFryIx (75 views)
2014-11-13 12:34:49

digdugdiggy (52 views)
2014-11-12 21:11:50
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!