Collision Detection with ID3DXSprite
Author
I''m using DirectX8''s ID3DXSprite interface to create a tile-based RPG. I''m making nice progress so far with the engine, however there''s one thing that''s bogging me: how should I handle pixel-perfect collision detection? Any directions or code would be GREATLY appreciated!
Thanks in advance
I am also working on 2D pixel perfect collision detection using D3DXSprite. So far I've been leaning towards using stencil buffers, But not sure if and how this would work.
[edited by - rambo_bill on September 8, 2002 10:18:54 AM]
[edited by - rambo_bill on September 8, 2002 10:18:54 AM]
Suggestion:
Maybe you could lock the surface upon loading and generate a bit collision map ''image'' (0''s and 1''s) - a 1 wherever the alpha is above a certain threshold value.
I have never done this, but am hoping to do something like it soon.
Maybe you could lock the surface upon loading and generate a bit collision map ''image'' (0''s and 1''s) - a 1 wherever the alpha is above a certain threshold value.
I have never done this, but am hoping to do something like it soon.
stevenmarky has the right idea I think, except for the slight alteration that I would make a tool that can take a list of files or something and generate a file that contains a "map" of the image. Then you can simply load it at start up, as it might take a while to generate those maps when loading, depending on the size and amount of them.
But, do you think you would gain anything from pixel perfect collision detection for a tile based rpg? I mean, sure do it anyway as it''s a great learning experience, but it might be more firepower than you need.
But, do you think you would gain anything from pixel perfect collision detection for a tile based rpg? I mean, sure do it anyway as it''s a great learning experience, but it might be more firepower than you need.
I have the exact same problem.
What I need to know is how to find out if a pixel is transparant or not, and then generate a ''collision-map'' from that.
Only problem is that I cant figure out how to do this ''check if pixel is transparant thingy'' with a dx8 sprite interface.
From what I found out this must be done in loading-stadge or be pre-generated to work speedwise.
If someone has a solution it would be very welcome.
What I need to know is how to find out if a pixel is transparant or not, and then generate a ''collision-map'' from that.
Only problem is that I cant figure out how to do this ''check if pixel is transparant thingy'' with a dx8 sprite interface.
From what I found out this must be done in loading-stadge or be pre-generated to work speedwise.
If someone has a solution it would be very welcome.
The problem with the pre-generated map idea for me is that I rotate my sprites using the D3DXSprite draw function at runtime. Now if I could have a single map and some how rotate it with the sprite that would work. Right now I'm thinking of defining shapes that outline the image, then test if these shapes collide. This way the shapes could be rotated with the sprite and provide for fast accurate collision detection. Of course pixel collision detection would be less headaches than this method.
[edited by - rambo_bill on September 9, 2002 7:05:08 AM]
[edited by - rambo_bill on September 9, 2002 7:05:08 AM]
Author
Those are the two options I was considering, a pixel-map or tile-based collision, I just posted this so I could get some ideas, thanks for the replies.
Don''t forget you could also try a collision routine where you define multiple rects for every animation. Still doesn''t help too much with on-the-fly rotation though.
I''ve used the method Redline suggested, but then again, I haven''t tried it on Mirrored and/or Rotated objects. hmmmm.
-----------------------------
kevin@mayday-anime.com
http://www.mayday-anime.com
-----------------------------
kevin@mayday-anime.com
http://www.mayday-anime.com
Thinking about it some more you would probably have to rotate each point of the rectangle for multiple rects if using D3DXSprites rotation ability. Either that or use multiple frames of animation for rotation (each with it''s own rects).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
