PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum

Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: spenoza on December 18, 2011, 03:49:33 AM

Title: Sprite collision revisited
Post by: spenoza on December 18, 2011, 03:49:33 AM

So, here's how Mike Daily handles collisions. He uses Gamemaker as a starting point because he argues it does things horribly. How does his method compare to your own?

http://dailly.blogspot.com/2011/06/collision-detection.html

Title: Re: Sprite collision revisited
Post by: touko on December 18, 2011, 04:39:32 AM

I have already red this ..

Personaly i'am using bouding box, this methos is IMO the more simpliest,and give very good results in most cases.
I have also used hardware sprite detection + bouding boxes on pce.

Pixel perfect is the best, but also more CPU consuming,and difficult to implement.

Title: Re: Sprite collision revisited
Post by: Arkhan on December 18, 2011, 04:44:50 AM

Quote from: touko on December 18, 2011, 04:39:32 AM

I have already red this ..

Personaly i'am using bouding box, this methos is IMO the more simpliest,and give very good results in most cases.
I have also used hardware sprite detection + bouding boxes on pce.

Pixel perfect is the best, but also more CPU consuming.

the hardware collision isn't so great if the sprites aren't taking up the whole box lol.


I use bounding boxes too, as it makes the most sense and offers great flexibility.

Title: Re: Sprite collision revisited
Post by: touko on December 18, 2011, 04:51:25 AM

Yes but you lunch a bounding test ONLY when an hardware collide interrupt is set ..
you avoids more collisions tests for nothing  .

But i admit for PCE this is very very limited .

Title: Re: Sprite collision revisited
Post by: Arkhan on December 18, 2011, 04:53:28 AM

Quote from: touko on December 18, 2011, 04:51:25 AM

Yes but you lunch a bouding test ONLY when an hardware collide interrupt is set ..
you avoids more collisions tests for nothing  .

But i admit for PCE this is very very limited .

I suppose you could do that, but is the gain really worth a damn?

Title: Re: Sprite collision revisited
Post by: touko on December 18, 2011, 04:56:41 AM

i don't know really, i think so, and i confirm if you're using HuC for testing .
Because you probably use arrays for sprites coordinates.

This method is only usefull if sprite 0 is assigned (for exemple), for player shoot,and can shoot one at the same time  ..

Title: Re: Sprite collision revisited
Post by: Arkhan on December 18, 2011, 05:11:35 AM

Quote from: touko on December 18, 2011, 04:56:41 AM

i don't know really, i think so, and i confirm if you're using HuC for testing .
Because you probably use arrays for sprites coordinates.

This method is only usefull if sprite 0 is assigned (for exemple), for player shoot,and can shoot one at the same time  ..

I don't use arrays, period.

Title: Re: Sprite collision revisited
Post by: touko on December 18, 2011, 05:23:04 AM

Separates variables ??, or the use of spr_get ???

Title: Re: Sprite collision revisited
Post by: Arkhan on December 18, 2011, 03:46:06 PM

Neither.

;)

Title: Re: Sprite collision revisited
Post by: touko on December 18, 2011, 06:29:40 PM

Lol,stack ???
printer??
3D storage ???
Aliens system ???
 :mrgreen:

Title: Re: Sprite collision revisited
Post by: Arkhan on December 19, 2011, 12:46:52 AM

Magic and violence.

Title: Re: Sprite collision revisited
Post by: touko on December 19, 2011, 02:01:39 AM

 :lol: