I know there was a thread about this a while ago, but I don't think the problem was really solved.

Basically I need to do an insane but manageable number ray-casts each frame. The problem is that I can't use something "simple" like Bresenham's line algorithm, because I need it to check all tiles touched by the line, similar to conservative rasterisation. My current implementation pretty much sucks, since it relies on lots of special cases and the direction of the line. For now I only need a boolean result, so computing the actual intersection point is not necessary. Any code someone is willing to share? I've been scratching my head about this for way too long now...

EDIT:Forgot some requirements... - Checks all tiles touched by line - Line start and end coordinates are doubles, and cannot be rounded to ints before ray-casting. - Well, it has to be pretty fast. Most lines are <10 tiles long though.

The Rectangle/Circle idea is interesting, I would still have to solve the ray-casting problem for actually querying the quadtree containing the circles, so I don't think it's a very good solution performance-wise in my case...

I looked through the Line Logic thread again. I must've fallen asleep when it was about to die, because I think it was actually solved. However, Cylab's solution (and Counterp's too) take int arguments, not floats. I'll see what I can do to change that tomorrow, but damn, I need to sleep now...

The Rectangle/Circle idea is interesting, I would still have to solve the ray-casting problem for actually querying the quadtree containing the circles, so I don't think it's a very good solution performance-wise in my case...

The nice thing of such a hierarchy is that you don't need to write something intelligent: write your rect/circle/line intersection and recurse into the tree.

And don't tell me it's too slow before you actually tried it. It should take 10 minutes to implement this stuff. Remember you only need to check rect/line intersections in the deepest nodes of your tree. With circle/line there will will be some false positives but it will still be faster.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

staticvoidfindCells(Linel) {finaldoublestartXShift = l.xshift * (l.start.y - floor(l.start.y));//amount of x delta in the first tile of the linefinaldoubleendXShift = l.xshift * (ceil(l.end.y) - l.end.y);//amount of x delta in the last tile of the linedoublex = l.start.x;doubley = l.start.y;x = printTiles(x, x + startXShift, y);//gets all Tiles, in the row of the start point, which the line passesy = floor(y) - 0.5;while (y > ceil(l.end.y))// iterates over all rows which lie between the start and end point of the linex = printTiles(x, x + l.xshift, y--);//gets all Tiles in the row which the line passesprintTiles(x, x + endXShift, y);//gets all Tiles, in the row of the end point, which the line passes }

The Rectangle/Circle idea is interesting, I would still have to solve the ray-casting problem for actually querying the quadtree containing the circles, so I don't think it's a very good solution performance-wise in my case...

The nice thing of such a hierarchy is that you don't need to write something intelligent: write your rect/circle/line intersection and recurse into the tree.

And don't tell me it's too slow before you actually tried it. It should take 10 minutes to implement this stuff. Remember you only need to check rect/line intersections in the deepest nodes of your tree. With circle/line there will will be some false positives but it will still be faster.

I think the real problem is the performance characteristics. If I'm raycasting through a diagonal corridor for example, I would be checking a lot more tiles since the corridor walls may be solid rock for 10+tiles. What I'm afraid about is a worse case scenario that's worse than actually "rastering" a line between the two points. Maybe I'm wrong, but it seems kind of far-fetched to expect it to be better than rastering. Then again, it might not be that much worse and actually faster in many cases. Still, rastering seem to have more predictable performance, since the Rect/Circle algorithm depends on both line length and the number of nearby walls, while rastering is only dependent on distance (both may end quickly if a wall is encountered though).

@Danny02 Nice! I like your scan-line-like approach to the problem! Seems like a very nice solution, but I'll have to test it before being able to tell. And after writing this, I pretty much have 10 minutes to get dressed, eat, go shopping and come back before my parents come here. Well, SHIT.

Danny02, I tested your ray-casting method a lot now. It has some problems... T__T It explodes when start.y = end.y but worst of all, for vertical lines it causes an extra tile to the right or the line being covered. However, the way you tackled the problem has lead me on the right way to solving the problem, so thanks a lot for the code!!!

EDIT: If anyone's interested, here is my perfect quality raycaster with special cases and directions. Like I said, based on Danny02's code.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org