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