Page 1 of 1

tracing sight

Posted: Tue Sep 05, 2006 8:17 am
by lizardkid
Yes, yet another question regarding my little 2-d test game from scratch.

I've googled and searched and looked through what books i have but i can't find a clearcut method of determining if there's a clear path from point A to B. i've tried some very unsuccessful methods (including firing test entities through the game world, and checking their collisions -- bad idea), but nothing was fast enough to be efficient for multiple calculations or clear enough for those "threading-the-needle" shots.

so what i'm asking is, how would i go about creating a sighttrace method in a 2d game? (the Y is inverted against Cartesian graph system).

i know it's no MOH question but i figured i'd probably get some help here ;)

Posted: Tue Sep 05, 2006 3:16 pm
by Rookie One.pl
Well, I think that highly depends on your game's architecture. What you could do is determine the direction and follow it pixel by pixel, checking if anything's on that position, but as I said, it depends on how the game works in general.

Also, try searching for pathfinding rather than sighttracing. ;)

Posted: Wed Sep 06, 2006 2:58 am
by lizardkid
Well the architecture itself is set up pretty simple, and close to MOH. lists for entities npcs and obstacles. all i need to do is check to see if there's a obstacle between point A and B; for a clear line of fire for a bot to fire at his enemy. (there'll only be some 10 or so obstacles in the final)

i'm not looking for pathfinding, i already have working examples of A* and POV i could use, this isn't that involved. i jsut need some way to determine if a bot can see point B from point A.

pixel by pixel wouldn't be that efficient... most of the checks would be completely across the screen to the other side (that could end up being a thousand checks for one sighttrace...).

well i'll google and think on it a bit more.

Posted: Wed Sep 06, 2006 3:56 pm
by Rookie One.pl
lizardkid wrote:pixel by pixel wouldn't be that efficient... most of the checks would be completely across the screen to the other side (that could end up being a thousand checks for one sighttrace...).
And, as far as I can tell by Quake 3's code, that's how it's done in MoH, m8. ;) And you would get scared if you knew just how many traces are done per frame. It's unimaginable amounts of calculation!

Posted: Thu Sep 07, 2006 8:48 am
by jv_map
Yeh but q3 has bsp :)

Posted: Thu Sep 07, 2006 10:47 am
by lizardkid
Well i got a semiworking method, it's not perfect, but it works enough until i get the courage to set up a cellspace partition system... and maybe do some muchneeded optimization :oops:

What i ended up doing was not just making something similer to pixel-per-pixel, but just using large blocks of pixels (in this case roughly 45x30pix) and checking in that range, it's a little buggy because if there's anything in the triangular gap between squares it misses it; but overall it works well enough.

thanks for the advice though ;)