Archived

This topic is now archived and is closed to further replies.

DekuTree64

Per-pixel obstructions

Recommended Posts

Well, I figured it''d be easier to ask here before actually doing this. In a tile-based game, would it be too slow to have an obstruction layer on the map, which is just like the normal tile layer, except the tiles are black and white (black=can''t walk on it, white=can), and have each sprite with an obstruction layer too, so when you push an arrow, it checks every pixel of the sprite''s obstruction area to see if there''s an obstruction pixel in that direction on the map? I could just have my tile class with a variable to tell if it''s an obstruction or not, and have a rect for each sprite''s obstruction area, but it''d be nicer to have it more accurate.
-Deku-chan DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^) "I'm dropping like flies!" - me, playing Super Smash Bros. (and losing) "What fun!" - me, playing Super Smash Bros. (and beating the crap out of somebody)

Share this post


Link to post
Share on other sites
This method of testing each pixel probably won''t work with games that include very many units... a nice alternative might be to create a collision polygon (although that only seems an option when using relatively large sprites)

Another nice method is creating a bounding box... that averages the dimensions of the units... this is probably the best way to do it.

Greetz, Dark

Share this post


Link to post
Share on other sites
I suggest you use bounding boxes, and if the arrow pass trough a bounding box, test at the pixel level of that bouding box.

I also suggest you to use a boolean table or bitplane to avoid consuming too much memory.

I heard that many people used a byte per pixel, because they use many values to store if there is an object on the ground (what kind of), the type of ground to slow units...

just my 0.02$ since I wrote a 2D engine a while back.

-* So many things to do, so little time to spend. *-

Share this post


Link to post
Share on other sites
Dark: A collision polygon would work, since I''m using D3D anyway (texture each tile onto a little polygon, then render (so I can use alpha-blending and move the camera around for easy mode7-type effects^_^)). Only problem is I have no idea how to check polygon collisions... As for the bounding box thing, I don''t understand what you mean my averaging the dimensions of the units.

Ingenu: That sounds like a good idea, if I get what you mean. Like, have each sprite with a square obs area, then if the square intersects another obstruction, check each pixel?
Oh, and memory shouldn''t be a problem. I was planning to have each obs tile just be an array of bools the size of the tiles (I''m planning to use variable tile sizes) so it should only take 1/24 the amount of memory as the actual tiles. Erm, bools are just 1 bit each, right? Or can the computer only allocate RAM in whole bytes?

Anyway, thanks for the tips, I''ll try the box idea.



-Deku-chan

DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)

"I'm dropping like flies!" - me, playing Super Smash Bros. (and losing)
"What fun!" - me, playing Super Smash Bros. (and beating the crap out of somebody)

Share this post


Link to post
Share on other sites
I agree that bounding boxes are the best way to do it. Like Ingenu suggested, make a box the size of your units, then test if they are colliding/overlapping, and if so, then test pixel-by-pixel.

For the pixel-by-pixel algo, a BOOL table might not be the fastest way, so I''d suggest the bitplane. Just make your units 2^n in size (32x32 seems the standard nowadays), so that you could fit all those pixels in an array of long ints:

int bit_table[32];

or long int, doesn''t matter if you code in Windows, though this could change with time..

Each int in the table represent a row, and the int itself represents the 32 pixels on that row (1 bit per pixel).

There are a few articles on that subject on the net, just make a search for "collision detection" or something similar.

.(Trancelucid).

Share this post


Link to post
Share on other sites
quote:
Original post by DekuTree64
Erm, bools are just 1 bit each, right? Or can the computer only allocate RAM in whole bytes?



Bools are 1 byte, since the computer can''t allocate in bits.

Share this post


Link to post
Share on other sites
If memory is at a premium, you could use an array of ints (4 bytes each) and use the & and | operators to use individual bits. If you used this, a sprite which is 64x64 could be represented in an array of 128 ints, which would take up 512 bytes, which is an eigth the size of one using BOOLs.

------------------------------
#pragma twice


sharewaregames.20m.com

Share this post


Link to post
Share on other sites
quote:
Original post by furby100

If memory is at a premium, you could use an array of ints (4 bytes each) and use the & and | operators to use individual bits. If you used this, a sprite which is 64x64 could be represented in an array of 128 ints, which would take up 512 bytes, which is an eigth the size of one using BOOLs.


Yea, I think that''s what I''ll do. could probably get away with bools, but don''t wanna soak up all the RAM on the sprites and not have anough for big magic graphics and stuff. Thanks everybody for all the tips^^





-Deku-chan

DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)

"I'm dropping like flies!" - me, playing Super Smash Bros. (and losing)
"What fun!" - me, playing Super Smash Bros. (and beating the crap out of somebody)

Share this post


Link to post
Share on other sites