Just curious, any reason why you used 'move at angle' for the player instead of a behavior?[/QUOTE] No particular reason. I'm just used to do it this way if I'm in a hurry. The cap was a quick&dirty product :)
Now this, you solved if I were to have another object blocking the vision but the problem is that I need to know:
Is any "Wall&EnemySprite" blocking the line of sight to any other "wall&EnemySprite"?
What "Wall&EnemySprite"s can the "PlayerSprite" see, and what "Wall&EnemySprite is blocked by other "Wall&EnemySprite"s?.
I don't know how well I explained it, but I really only have 2 "Active objects" in the game; a PlayerSprite and a sprite representing enemies AND obstacles. (And I need it that way, as walls need to change to enemies and vise verse in my game)[/QUOTE] This is what I mean by "think too complicated".
For every game there comes a time when you have to optimize your code/thoughts. Even the biggest game developers wouldn't be able to constantly check roughly 1 million times per tick without dramatically slowing down their game. So it is about tricking. Like in 3D games high poly models are exchanged by low poly ones when they are displayed far away.
1) You don't need to test all instances. Limit the tests to the range that your player sprite will "see".
2) Don't loop 360 times to get a full circle. Instead create one circle sprite and set it to the radius you want the player to be able to see. Select all blocks that overlap that sprite (Or use no object at all and select those blocks with math only). Now loop through those blocks and check with sample points every blocksize against the angle to the player sprite if there are other blocks in the way. If so, set it to invisible, else set it to visible.
This should speed up a lot. I didn't have a look at JayJay's cap. Maybe it is exactly doing so. If not, I might do a cap, if I find the time.tulamide2011-09-10 14:03:14