   tile based lighting
  Currently I'm working on a 2d top down version of minecraft, although was wondering how feasible a lighting algorithm I'm proposing will be. The overall intention is to be able to add/remove light sources, allow that light to spread, and make solid tiles block the light.The general idea was for each tile to get their light value calculated from the surrounding tiles, e.g. use the maximum of the surrounding then subtract one unit. For solid tiles that may or may not be lit simply take their value as zero.The update process of this is what I'm worried about however. The idea is that whenever a tile's light value changes it will add the 4 surrounding tiles to an update list. So for example when a light is placed on one tile it will be updated and cause the 4 surrounding tiles to be put on the list for pending update. These 4 tiles then would be updated, and thus more put on the list. This would repeat until the tiles no longer change brightness value.does the above process sound costly, and if so is there any way I could improve it?   
  Cannot you just draw each tile independently and handle lighting as normal on a per-frame basis?Seriously, everything that is at least GeForce 6600 will handle 20+ lights with ease. Supposing each tile is 10x10 pixels and 4 vertices this should be doable.But this isn't what you're trying to do I suppose, it seems you really want the tiles to appear "pixelated".A way to do so would be to keep a CPU-side of the tile list (which you have already) and compute a grid of lighting values as you think.Each light would add its contribution to each tile independantly (lights shading a tile rather than tiles getting shaded by a light). Then map a dynamic texture with eye-space texture coordinate gen (this info is available in the pixel shader), fetch the value and multiply.This should be able to deal with a fairly high amount of lights (perhaps even 100+, depending on the number of tiles to shade/update).Ideally you should keep two maps, one with "constant" lights and another with flickering ones.Note this might eventually require to be optimized for screen movement, but supposing each tile is 10x10 pixels (which seems fairly overkill) this seems feasible.Are you targeting portables?Anyway, I suggest against your idea of "spreading the light". It requires to build a list of the already shaded cells to not re-shade an already shaded cell. In line of concept, it could be a regular grid of bools but using the "light" approach seems to be just cleaner to me.   ;  each tile is 32x32px by the way, and I'm just targeting desktops etc atm I think I understand your ideas though. To start with I have a grid of lighting values, all set to 0 (darkness). I then loop through each light adding the appropriate values to the grid (maybe from another predefined image [could allow for many light types too]). When I come around to drawing the tiles I can then draw the tiles initially, then take the lighting values and use the multiply blend mode on the already drawn tiles.The actual map is in theory infinite, and is divided into chunks 32x32 tiles in size. That means that one light from one chunk could potentially influence another chunk. This does seem a minor problem to sort out however since I will only be loading 4 chunks at any one time, so could probably get away with having each light update 4 times instead of just once (and culling will be fairly easy too if necessary). Also the lights will only be updated when the player places/removes a source (or new chunks are loaded), so it's not like it's going to happen very often.Thanks for the ideas, I'm not sure where I was going with the spreading idea (apart from to implement shadows which tbh I'm not too bothered about now). once I get it working I'll post an update of my progress.Thanks again,Sam   