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)

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)

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).

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.

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)