Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Instead of converting to polar and back again, could you do something similar by "raytracing" a 2d line from each tile to the players position backwards; starting in the middle and stepping out toward the target tile in a bresenheim-type stepping, marking as shadows after touching an obstacle? If you start by stepping around the outer edges, you'd fill most of the tiles in one pass, and then you could probably interpolate or re-trace for any missing pixels?

(Edit: I guess you'll lose the nice shades-of-grey effect that the article's bitmap processing technique yields)



I assume you mean for generating the shadow map before it is scaled and pixelized? I'm not familiar with techniques for doing such a thing. You could probably step through each object and draw lines from the corners based on the angle between the player tile and the object. The approach I listed would actually save you from testing every single object—as soon as a black pixel is detected in an algorthm, it moves to the next line, meaning that the number of objects that may exist in that direction at a greater distance is completely irrelevant.


I guess I was thinking something like this: http://roguebasin.roguelikedevelopment.org/index.php/Eliglos...

(the second example, "raycasting"). You'd work on the "native tile resolution".

I.e. you just "swipe" lines starting at the player position to the edge of the map, in a circle; as soon as you hit an obstacle tile, you stop marking the tiles ("pixels") on the line as lightened. No need to do any per-object iteration (as long as the tile map contains object references in tile positions)


This works, but gives you no indication of whether the tile is partially visible or not, much less how visible. An accurate indication of this would require many more rays and a lot of processing.


Right.

I was thinking about whether there could be a way to apply your technique, without having to do the polar + cartesian conversions.


Agreed. But I think you could still do the shades of grey. Just need to determine the amount a cell is occluded.


"Just need to determine the amount a cell is occluded."

That's the trick isn't it? How do you determine the amount? That is more or less what I set out to figure out when this started. Sure you can do a calculus/math-based approach, but it is slow and done entirely on the CPU.


This is an interesting problem, good luck!

Here's where I'd start:

1. See what resolution you need to get the level of grays you want. Your example shows 29x29 pixels for a cell be for it's resampled down. (2900%) so 841 possible shades of grey, (minus the artifacts from converting to polar and back. (the stair stepped edges)) but if you only need 12 shades of grey, render it at 400%, 4x4 pixels and add up the results for each cell. (But with shadow maps, you need a larger render to reduce the effects of the polar conversion.)

2. See if your shadow map approach or ray casting (or this http://www.redblobgames.com/articles/visibility/ ?) is faster to get this type of result: http://www.jasonnall.com/polar/images/Scale.png With your shadow mapping you are processing every pixel several times. With ray casting you can optimize and and only process what the player sees, and you don't have the polar conversion artifacts.

I'm betting on ray casting/ this http://www.redblobgames.com/articles/visibility/ and I bet there's a quick test for partially occluded cells, then chop in half and get the percentage exposed. Yeah, it may be more work to figure out, and not worth it. But you can still super sample only the the partially exposed cells 4x4 for 12 shades, 5x5 for 25 shades etc... and just render what you see instead of everything.


Thanks for reading!


You can get pretty good results with just a little trigonometry. For example, in the diagram below, the ratio of angles A/(A+B) tells you how shaded the blue tile should be. You can apply this method recursively.

http://i.imgur.com/0rz69.png


I hadn't thought of that! Thank you for sharing!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: