Crosshair from Gun

My method draws a line from Player to Mouse.
If the Line is overlapping and Obstacle, 2 fastLoops are triggered in this order:

FAST LOOP A
- Halves the length of the line untill Line is no longer overlapping Backdrop ( also stores the length halved )
- If Line is no longer overlapping Backdrop, the Line is increased by 1/10 of the last line halving
- As the line is increased and overlapps a backdroop, the line is reduced by 1/10 of the last line halving, and the loop ends

FAST LOOP B
- This loop simply increases the Line length by 1 untill it hits an Obstacle, in wich case the Line is reduced by 1 and the loop ends

...
The idea behind this is to get as close to the Obstacles as possible by using big steps before starting to fine tune by moving 1 pixel at a time.
Ill uppload a new example wich has a counter displayong exactly how many loop ( accounting for both loops ) iterations are run for each execution.

If you stay inside the Frame the number of loops run is about 2 - 20 for each execution, but if you start moving outside the frame however the number of iterations increase.

Yeah my method works in a similar fashion but I'll use your example probably for the fourth weapon I hadn't designed yet, making it have a laser pointer-type aim instead of a crosshair. Thanks. :)

King_Cool, why are you increasing the line by 1/10 when it is no longer overlapping an obstacle? It'd be faster and more efficient to increase by 1/2 still. That particular method of obstacle detection is called a Binary Search, which I believe is the most efficient method.

Quote:

---

Originally Posted by Jacob

King_Cool, why are you increasing the line by 1/10 when it is no longer overlapping an obstacle? It'd be faster and more efficient to increase by 1/2 still. That particular method of obstacle detection is called a Binary Search, which I believe is the most efficient method.

---

Thanks, i didnt know this was called binary search :)
Jacob, I just tried your suggestion wich is not faster. The method yireld 3 - 5 times as many fast loops per execution.

I can explain in detail and provide examples if you want.

You must be doing something wrong. Imagine you are at the ordinate 35 and want to get to 194

Add 256 -> 291

291 is over 194, so subtraction is required
Subtract 128 -> 163

163 is less than 194, so addition is required
Add 64 -> 227

Subtract 32 -> 195
Subtract 16 -> 179
Add 8 -> 187
Add 4 -> 191
Add 2 -> 193
Add 1 -> 194

Required 8 operations to solve. This will work for any number within 256 (2^8) from the origin. In 9 moves, there is a range of +-512 (2^9)

There is no possible way your search algorithm could get an accurate result in 1 to 3 loops, so I'm not sure what you mean by mine causing 3-5 times as many loops.