Light Sources
Tags:
- Development
- Light
- Games
- Video Games
Last response: in Video Games
Anonymous
July 5, 2005 2:16:28 PM
Archived from groups: rec.games.roguelike.development (More info?)
I've got a graphical tilemap that I want to add the ability to handle
multiple static and dynamic light sources with LOS (as opposed to simply
lighting a whole room). Instead of the normal on/off lighting status of a
single tile, I want to allow the intensity to vary between 0 (dark) to 100
(fully lit). Precomputed lighting tables are just about out of the question
for this, right?
Another question:
I think it would be cool for some monsters to carry their own light sources,
but I don't see other games doing this. Is this because it is
computationally prohibitive to do this?
A third question:
Can anyone recommend a lighting algorithm that can handle multiple (many)
light sources, both fixed to a wall, or carried by NPCs? It seems to me like
maybe there should be a clever solution for this involving shuffling
calculations off to the GPU (since it's great at realtime lighting), though
I don't want to require programmable shaders to play my game.
This looks something like my final goal (with only one light):
http://ivan.sourceforge.net/img/Holyscreen33.png
I'm sure I can cook up something that works, but I want something that is
fast.
--
Blog:
Shedletsky's Bits: A Random Walk Through Manifold Space
http://www.stanford.edu/~jjshed/blog
I've got a graphical tilemap that I want to add the ability to handle
multiple static and dynamic light sources with LOS (as opposed to simply
lighting a whole room). Instead of the normal on/off lighting status of a
single tile, I want to allow the intensity to vary between 0 (dark) to 100
(fully lit). Precomputed lighting tables are just about out of the question
for this, right?
Another question:
I think it would be cool for some monsters to carry their own light sources,
but I don't see other games doing this. Is this because it is
computationally prohibitive to do this?
A third question:
Can anyone recommend a lighting algorithm that can handle multiple (many)
light sources, both fixed to a wall, or carried by NPCs? It seems to me like
maybe there should be a clever solution for this involving shuffling
calculations off to the GPU (since it's great at realtime lighting), though
I don't want to require programmable shaders to play my game.
This looks something like my final goal (with only one light):
http://ivan.sourceforge.net/img/Holyscreen33.png
I'm sure I can cook up something that works, but I want something that is
fast.
--
Blog:
Shedletsky's Bits: A Random Walk Through Manifold Space
http://www.stanford.edu/~jjshed/blog
More about : light sources
Anonymous
July 5, 2005 2:41:40 PM
Archived from groups: rec.games.roguelike.development (More info?)
Ok, so I just thought of a way that I might be able to swing this using
basic 3d graphics hardware. I take my tilemap, subtracting out all the tiles
that don't block light. This results in a 2d map of just the opaque tiles.
Now I create a "light mask geometry", which is this 2d map extruded out to
infinity (or some large distance), so that I now have a 2d map of long 3d
boxes that represent opaque tiles. I set these boxes up so that they are not
rendered to the screen, but they are involved in lighting calculations. Then
I put point light sources where I want them on my map. Then I render with
shadow volumes.
If you missed all that because you don't know much about 3d graphics or I
explained it poorly, I'm suggesting building a 3d copy of my map for the
purpose of doing hardware-accelerated light, shadow, and LOS processing. The
only real problem I can see with this is that I'm limited to 8 lights in
hardware and each requires a separate rendering pass. I can always resort to
the accumulation buffer to get additional lights, but it doesn't scale well.
On the up side, I could get light attenuation for free. On the downside, it
might be difficult to control the light radius in terms of tile units.
I don't suppose anyone has tried this.
--
Blog:
Shedletsky's Bits: A Random Walk Through Manifold Space
http://www.stanford.edu/~jjshed/blog
Ok, so I just thought of a way that I might be able to swing this using
basic 3d graphics hardware. I take my tilemap, subtracting out all the tiles
that don't block light. This results in a 2d map of just the opaque tiles.
Now I create a "light mask geometry", which is this 2d map extruded out to
infinity (or some large distance), so that I now have a 2d map of long 3d
boxes that represent opaque tiles. I set these boxes up so that they are not
rendered to the screen, but they are involved in lighting calculations. Then
I put point light sources where I want them on my map. Then I render with
shadow volumes.
If you missed all that because you don't know much about 3d graphics or I
explained it poorly, I'm suggesting building a 3d copy of my map for the
purpose of doing hardware-accelerated light, shadow, and LOS processing. The
only real problem I can see with this is that I'm limited to 8 lights in
hardware and each requires a separate rendering pass. I can always resort to
the accumulation buffer to get additional lights, but it doesn't scale well.
On the up side, I could get light attenuation for free. On the downside, it
might be difficult to control the light radius in terms of tile units.
I don't suppose anyone has tried this.
--
Blog:
Shedletsky's Bits: A Random Walk Through Manifold Space
http://www.stanford.edu/~jjshed/blog
Anonymous
July 5, 2005 3:01:37 PM
Archived from groups: rec.games.roguelike.development (More info?)
Shedletsky wrote:
> Ok, so I just thought of a way that I might be able to swing this using
> basic 3d graphics hardware. I take my tilemap, subtracting out all the tiles
> that don't block light. This results in a 2d map of just the opaque tiles.
> Now I create a "light mask geometry", which is this 2d map extruded out to
> infinity (or some large distance), so that I now have a 2d map of long 3d
> boxes that represent opaque tiles. I set these boxes up so that they are not
> rendered to the screen, but they are involved in lighting calculations. Then
> I put point light sources where I want them on my map. Then I render with
> shadow volumes.
>
> If you missed all that because you don't know much about 3d graphics or I
> explained it poorly, I'm suggesting building a 3d copy of my map for the
> purpose of doing hardware-accelerated light, shadow, and LOS processing. The
> only real problem I can see with this is that I'm limited to 8 lights in
> hardware and each requires a separate rendering pass. I can always resort to
> the accumulation buffer to get additional lights, but it doesn't scale well.
> On the up side, I could get light attenuation for free. On the downside, it
> might be difficult to control the light radius in terms of tile units.
>
> I don't suppose anyone has tried this.
>
> --
> Blog:
> Shedletsky's Bits: A Random Walk Through Manifold Space
> http://www.stanford.edu/~jjshed/blog
Wouldn't it be far simpler just to calculate a normal los type
lightmap, then for every non-black square, assign a value based on it's
distance from the origin?
Shedletsky wrote:
> Ok, so I just thought of a way that I might be able to swing this using
> basic 3d graphics hardware. I take my tilemap, subtracting out all the tiles
> that don't block light. This results in a 2d map of just the opaque tiles.
> Now I create a "light mask geometry", which is this 2d map extruded out to
> infinity (or some large distance), so that I now have a 2d map of long 3d
> boxes that represent opaque tiles. I set these boxes up so that they are not
> rendered to the screen, but they are involved in lighting calculations. Then
> I put point light sources where I want them on my map. Then I render with
> shadow volumes.
>
> If you missed all that because you don't know much about 3d graphics or I
> explained it poorly, I'm suggesting building a 3d copy of my map for the
> purpose of doing hardware-accelerated light, shadow, and LOS processing. The
> only real problem I can see with this is that I'm limited to 8 lights in
> hardware and each requires a separate rendering pass. I can always resort to
> the accumulation buffer to get additional lights, but it doesn't scale well.
> On the up side, I could get light attenuation for free. On the downside, it
> might be difficult to control the light radius in terms of tile units.
>
> I don't suppose anyone has tried this.
>
> --
> Blog:
> Shedletsky's Bits: A Random Walk Through Manifold Space
> http://www.stanford.edu/~jjshed/blog
Wouldn't it be far simpler just to calculate a normal los type
lightmap, then for every non-black square, assign a value based on it's
distance from the origin?
Related resources
- ASUS VG248QE light/colour bands in the sky and around light sources. - Forum
- HD6850 with bad blending from light sources? - Forum
- Annoying lines in light sources - Forum
- Light sources and line of sight - Forum
- EQ2 light sources - Forum
Anonymous
July 5, 2005 5:07:51 PM
Archived from groups: rec.games.roguelike.development (More info?)
Shedletsky wrote:
> I want to allow the intensity to vary between 0 (dark) to 100
> (fully lit).
For tile based game you probably wont need that many levels.
My game has 9 intensity levels and it seems to be enough.
> I think it would be cool for some monsters to carry their own light
> sources, but I don't see other games doing this.
Kaduria does
Or at least the engine has support for that.. You
can also throw lit torches into darkness to see what is in there.
It's a cool feature
> Is this because it is computationally prohibitive to do this?
Lighting routine will slow down things.. you have to experiment
and see it yourself.
> I'm sure I can cook up something that works, but I want something
> that is fast.
For now I've left out FOV/LOS(?) from my lighting, the light areas
are just circular data copied over pre-calculated static light map.
Pre-calculating light map for static objects is something you
want to do, it will make things much faster. Then just add any
dynamic lighting and display the final result.
Shedletsky wrote:
> I want to allow the intensity to vary between 0 (dark) to 100
> (fully lit).
For tile based game you probably wont need that many levels.
My game has 9 intensity levels and it seems to be enough.
> I think it would be cool for some monsters to carry their own light
> sources, but I don't see other games doing this.
Kaduria does
Or at least the engine has support for that.. Youcan also throw lit torches into darkness to see what is in there.
It's a cool feature
> Is this because it is computationally prohibitive to do this?
Lighting routine will slow down things.. you have to experiment
and see it yourself.
> I'm sure I can cook up something that works, but I want something
> that is fast.
For now I've left out FOV/LOS(?) from my lighting, the light areas
are just circular data copied over pre-calculated static light map.
Pre-calculating light map for static objects is something you
want to do, it will make things much faster. Then just add any
dynamic lighting and display the final result.
Antoine
July 5, 2005 5:58:15 PM
Archived from groups: rec.games.roguelike.development (More info?)
Shedletsky wrote:
> I've got a graphical tilemap that I want to add the ability to handle
> multiple static and dynamic light sources with LOS (as opposed to simply
> lighting a whole room). Instead of the normal on/off lighting status of a
> single tile, I want to allow the intensity to vary between 0 (dark) to 100
> (fully lit). Precomputed lighting tables are just about out of the question
> for this, right?
>
> Another question:
>
> I think it would be cool for some monsters to carry their own light sources,
> but I don't see other games doing this. Is this because it is
> computationally prohibitive to do this?
I do this in Guild. It shouldn't be computationally difficult if the
radius is reasonably small.
A.
Shedletsky wrote:
> I've got a graphical tilemap that I want to add the ability to handle
> multiple static and dynamic light sources with LOS (as opposed to simply
> lighting a whole room). Instead of the normal on/off lighting status of a
> single tile, I want to allow the intensity to vary between 0 (dark) to 100
> (fully lit). Precomputed lighting tables are just about out of the question
> for this, right?
>
> Another question:
>
> I think it would be cool for some monsters to carry their own light sources,
> but I don't see other games doing this. Is this because it is
> computationally prohibitive to do this?
I do this in Guild. It shouldn't be computationally difficult if the
radius is reasonably small.
A.
Anonymous
July 5, 2005 9:00:57 PM
Archived from groups: rec.games.roguelike.development (More info?)
Shedletsky wrote:
> I've got a graphical tilemap that I want to add the ability to handle
> multiple static and dynamic light sources with LOS (as opposed to simply
> lighting a whole room). Instead of the normal on/off lighting status of a
> single tile, I want to allow the intensity to vary between 0 (dark) to 100
> (fully lit). Precomputed lighting tables are just about out of the
> question for this, right?
>
> Another question:
>
> I think it would be cool for some monsters to carry their own light
> sources, but I don't see other games doing this. Is this because it is
> computationally prohibitive to do this?
Probably not. BTW, quite a few Angband variants do that already.
> A third question:
>
> Can anyone recommend a lighting algorithm that can handle multiple (many)
> light sources, both fixed to a wall, or carried by NPCs? It seems to me
> like maybe there should be a clever solution for this involving shuffling
> calculations off to the GPU (since it's great at realtime lighting),
> though I don't want to require programmable shaders to play my game.
>
> This looks something like my final goal (with only one light):
> http://ivan.sourceforge.net/img/Holyscreen33.png
>
> I'm sure I can cook up something that works, but I want something that is
> fast.
Crossfire has per pixel lighting effects if you want. And it's just a simple
2D game, no 3D acceleration or something.
Shedletsky wrote:
> I've got a graphical tilemap that I want to add the ability to handle
> multiple static and dynamic light sources with LOS (as opposed to simply
> lighting a whole room). Instead of the normal on/off lighting status of a
> single tile, I want to allow the intensity to vary between 0 (dark) to 100
> (fully lit). Precomputed lighting tables are just about out of the
> question for this, right?
>
> Another question:
>
> I think it would be cool for some monsters to carry their own light
> sources, but I don't see other games doing this. Is this because it is
> computationally prohibitive to do this?
Probably not. BTW, quite a few Angband variants do that already.
> A third question:
>
> Can anyone recommend a lighting algorithm that can handle multiple (many)
> light sources, both fixed to a wall, or carried by NPCs? It seems to me
> like maybe there should be a clever solution for this involving shuffling
> calculations off to the GPU (since it's great at realtime lighting),
> though I don't want to require programmable shaders to play my game.
>
> This looks something like my final goal (with only one light):
> http://ivan.sourceforge.net/img/Holyscreen33.png
>
> I'm sure I can cook up something that works, but I want something that is
> fast.
Crossfire has per pixel lighting effects if you want. And it's just a simple
2D game, no 3D acceleration or something.
Anonymous
July 5, 2005 10:23:45 PM
Archived from groups: rec.games.roguelike.development (More info?)
Shedletsky wrote:
> Can anyone recommend a lighting algorithm that can handle multiple (many)
> light sources, both fixed to a wall, or carried by NPCs? It seems to me like
> maybe there should be a clever solution for this involving shuffling
> calculations off to the GPU (since it's great at realtime lighting), though
> I don't want to require programmable shaders to play my game.
One thing to realize is that lighting calculations are exactly the same
as visibility calculations. So if you have a fast LOS algorithm (and
there are several) it shouldn't be hard to calculate that for each
point light (fixed lights are the same) within a certain radius of the
visible window.
I've coded this up myself (although everything is opaque/not, lit/not)
and it doesn't seem like it is too slow at all. (You could make light
level change based on distance from the light like NIm suggested and
then sum up all the lights.)
Shedletsky wrote:
> Can anyone recommend a lighting algorithm that can handle multiple (many)
> light sources, both fixed to a wall, or carried by NPCs? It seems to me like
> maybe there should be a clever solution for this involving shuffling
> calculations off to the GPU (since it's great at realtime lighting), though
> I don't want to require programmable shaders to play my game.
One thing to realize is that lighting calculations are exactly the same
as visibility calculations. So if you have a fast LOS algorithm (and
there are several) it shouldn't be hard to calculate that for each
point light (fixed lights are the same) within a certain radius of the
visible window.
I've coded this up myself (although everything is opaque/not, lit/not)
and it doesn't seem like it is too slow at all. (You could make light
level change based on distance from the light like NIm suggested and
then sum up all the lights.)
Anonymous
July 5, 2005 10:25:07 PM
Archived from groups: rec.games.roguelike.development (More info?)
At Tue, 5 Jul 2005 10:16:28 -0400,
Shedletsky wrote:
> Can anyone recommend a lighting algorithm that can handle multiple (many)
> light sources, both fixed to a wall, or carried by NPCs? It seems to me like
> maybe there should be a clever solution for this involving shuffling
> calculations off to the GPU (since it's great at realtime lighting), though
> I don't want to require programmable shaders to play my game.
I can tell you how The Wish did it -- it supported multiple light sources
all right.
First, you need precomputed lookup tables similar to those for Angband.
If you don't know what I mean, here's quick explanation:
/#
/##
/###
/####
+-----
You need two tables. Every table records only one octant, so they are
really triangles -- you can feet both tables in a single 2D array.
First you cast many rays from the corner of your octant. The rays can be
evenly distributed, but you get better results with other distributions --
you can experiment with it a little. For the best accuracy you need one
ray for every combination of tiles it can pass trough. Number the rays
from bottom to top.
The first table, let's call it min_ray[x][y], records the smallest number
of a ray that passes trough tile (x,y). The table max_ray[x][y] records
the largest number of ray that passes trought tile (x,y).
Ok, once you've got the tables, you can write your algorithm. It's similar
to the one used in Angband, but uses several additional tricks.
For every tile you need three values:
The ambient light tells you how 'light' is the tile by itself, without any
additional light sources. You can use it to make rooms lighter than
corridors, and tiles under a hole in the roof even lighter.
The visibility tells you how well you see the tile.
The obfuscation (???) value tells you how well the tile blocks vision.
You start with all the tiles having visibility = 0, and ambient and
obsfuscation set to the value depending on the map itself.
You'll also need an array indexed by the ray numbers, lets call it rays.
You set it all to 255 at the beginning.
I'll describe the algorithm for one octant only -- the others are
analogous. Let's take the octant I drew above.
You start from the + and move to the right tile-by-tile, then row-by-row.
For every tile you:
Check which rays pass by this tile (using the min_ray and max_ray
table).
you count the maximum value of rays[ray] for all those rays that pass
by this tile
if the value is nonzero, you set the visibilty of the tile to ambient
+ this maximum
you decrease the values rays[ray] for every ray that passes the tile
by the value of the tile's obfuscation
And that's all.
The ambient values of the tiles are only calculated on the level
generation, and then wehenever any static light source changes, or any
light-blocking tile becomes unblocking (or vice versa), and even this
needs to be calculated only on a limited area around the change.
HTH
--
Radomir `The Sheep' Dopieralski @**@_
(: ) 3 Snap!
. . . ..v.vVvVVvVvv.v.. .
At Tue, 5 Jul 2005 10:16:28 -0400,
Shedletsky wrote:
> Can anyone recommend a lighting algorithm that can handle multiple (many)
> light sources, both fixed to a wall, or carried by NPCs? It seems to me like
> maybe there should be a clever solution for this involving shuffling
> calculations off to the GPU (since it's great at realtime lighting), though
> I don't want to require programmable shaders to play my game.
I can tell you how The Wish did it -- it supported multiple light sources
all right.
First, you need precomputed lookup tables similar to those for Angband.
If you don't know what I mean, here's quick explanation:
/#
/##
/###
/####
+-----
You need two tables. Every table records only one octant, so they are
really triangles -- you can feet both tables in a single 2D array.
First you cast many rays from the corner of your octant. The rays can be
evenly distributed, but you get better results with other distributions --
you can experiment with it a little. For the best accuracy you need one
ray for every combination of tiles it can pass trough. Number the rays
from bottom to top.
The first table, let's call it min_ray[x][y], records the smallest number
of a ray that passes trough tile (x,y). The table max_ray[x][y] records
the largest number of ray that passes trought tile (x,y).
Ok, once you've got the tables, you can write your algorithm. It's similar
to the one used in Angband, but uses several additional tricks.
For every tile you need three values:
The ambient light tells you how 'light' is the tile by itself, without any
additional light sources. You can use it to make rooms lighter than
corridors, and tiles under a hole in the roof even lighter.
The visibility tells you how well you see the tile.
The obfuscation (???) value tells you how well the tile blocks vision.
You start with all the tiles having visibility = 0, and ambient and
obsfuscation set to the value depending on the map itself.
You'll also need an array indexed by the ray numbers, lets call it rays.
You set it all to 255 at the beginning.
I'll describe the algorithm for one octant only -- the others are
analogous. Let's take the octant I drew above.
You start from the + and move to the right tile-by-tile, then row-by-row.
For every tile you:
Check which rays pass by this tile (using the min_ray and max_ray
table).
you count the maximum value of rays[ray] for all those rays that pass
by this tile
if the value is nonzero, you set the visibilty of the tile to ambient
+ this maximum
you decrease the values rays[ray] for every ray that passes the tile
by the value of the tile's obfuscation
And that's all.
The ambient values of the tiles are only calculated on the level
generation, and then wehenever any static light source changes, or any
light-blocking tile becomes unblocking (or vice versa), and even this
needs to be calculated only on a limited area around the change.
HTH
--
Radomir `The Sheep' Dopieralski @**@_
(: ) 3 Snap!
. . . ..v.vVvVVvVvv.v.. .
Anonymous
July 6, 2005 3:47:21 AM
Archived from groups: rec.games.roguelike.development (More info?)
In article <dae4nr$bds$1@news.Stanford.EDU>, "Shedletsky" <mylastname@stanford.edu> wrote:
>Can anyone recommend a lighting algorithm that can handle multiple (many)
>light sources, both fixed to a wall, or carried by NPCs? It seems to me like
>maybe there should be a clever solution for this involving shuffling
>calculations off to the GPU (since it's great at realtime lighting), though
>I don't want to require programmable shaders to play my game.
One cheap and nasty way: Circle bitmap overlays with radial gradient
alphas.
Alan
In article <dae4nr$bds$1@news.Stanford.EDU>, "Shedletsky" <mylastname@stanford.edu> wrote:
>Can anyone recommend a lighting algorithm that can handle multiple (many)
>light sources, both fixed to a wall, or carried by NPCs? It seems to me like
>maybe there should be a clever solution for this involving shuffling
>calculations off to the GPU (since it's great at realtime lighting), though
>I don't want to require programmable shaders to play my game.
One cheap and nasty way: Circle bitmap overlays with radial gradient
alphas.
Alan
Anonymous
July 6, 2005 7:41:45 PM
Archived from groups: rec.games.roguelike.development (More info?)
[a_bit_OT]
>Can anyone recommend a lighting algorithm that can handle multiple
(many)
>light sources, both fixed to a wall, or carried by NPCs? It seems to me
like
>maybe there should be a clever solution for this involving shuffling
>calculations off to the GPU (since it's great at realtime lighting),
though
Try doing what I'm doing in my RL, each tile "on fire" is a light source
with a low radius; without good optimization it's a *big* strain od my
CPU when half the map is on fire.
http://hakendslasz.boo.pl/woops.gif
[/a_bit_OT]
Cheers,
Kronikarz
--
Sent via Gamer Newsgroups
http://www.gamernewsgroups.com
[a_bit_OT]
>Can anyone recommend a lighting algorithm that can handle multiple
(many)
>light sources, both fixed to a wall, or carried by NPCs? It seems to me
like
>maybe there should be a clever solution for this involving shuffling
>calculations off to the GPU (since it's great at realtime lighting),
though
Try doing what I'm doing in my RL, each tile "on fire" is a light source
with a low radius; without good optimization it's a *big* strain od my
CPU when half the map is on fire.
http://hakendslasz.boo.pl/woops.gif
[/a_bit_OT]
Cheers,
Kronikarz
--
Sent via Gamer Newsgroups
http://www.gamernewsgroups.com
Anonymous
July 6, 2005 8:13:01 PM
Archived from groups: rec.games.roguelike.development (More info?)
Quoting Shedletsky <mylastname@stanford.edu>:
>I've got a graphical tilemap that I want to add the ability to handle
>multiple static and dynamic light sources with LOS (as opposed to simply
>lighting a whole room). Instead of the normal on/off lighting status of a
>single tile, I want to allow the intensity to vary between 0 (dark) to 100
>(fully lit).
Why?
Seriously, it's going to be maddening in a non-realtime game to have data
available but in low contrast.
>I think it would be cool for some monsters to carry their own light sources,
>but I don't see other games doing this.
NetHack does it; some monsters like fire elementals _are_ light sources,
the player can light lamps and leave them lying on the floor, and
acquisitive monsters might pick them up and carry them around.
--
David Damerell <damerell@chiark.greenend.org.uk> Kill the tomato!
Today is Second Wednesday, Presuary.
Quoting Shedletsky <mylastname@stanford.edu>:
>I've got a graphical tilemap that I want to add the ability to handle
>multiple static and dynamic light sources with LOS (as opposed to simply
>lighting a whole room). Instead of the normal on/off lighting status of a
>single tile, I want to allow the intensity to vary between 0 (dark) to 100
>(fully lit).
Why?
Seriously, it's going to be maddening in a non-realtime game to have data
available but in low contrast.
>I think it would be cool for some monsters to carry their own light sources,
>but I don't see other games doing this.
NetHack does it; some monsters like fire elementals _are_ light sources,
the player can light lamps and leave them lying on the floor, and
acquisitive monsters might pick them up and carry them around.
--
David Damerell <damerell@chiark.greenend.org.uk> Kill the tomato!
Today is Second Wednesday, Presuary.
Anonymous
July 6, 2005 10:10:55 PM
Archived from groups: rec.games.roguelike.development (More info?)
SC Skipsey wrote:
> On Wed, 6 Jul 2005, David Damerell wrote:
>
> > Quoting Shedletsky <mylastname@stanford.edu>:
> > >I've got a graphical tilemap that I want to add the ability to handle
> > >multiple static and dynamic light sources with LOS (as opposed to simply
> > >lighting a whole room). Instead of the normal on/off lighting status of a
> > >single tile, I want to allow the intensity to vary between 0 (dark) to 100
> > >(fully lit).
> >
> > Why?
> >
> > Seriously, it's going to be maddening in a non-realtime game to have data
> > available but in low contrast.
> >
>
> While the OP doesn't state this, I assume that he is intending for there
> to be other effect from low- or high-light levels. (For example, some
> monsters may
> be hard/impossible to see in tiles with lighting below a certain
> threshold, or may be pained by being in tiles with high lighting values.)
> There is no reason (and, in fact, it would be silly to attempt) to
> represent each lighting level as a separate brightness level with such a
> detailed representation, so I also assume the OP will stick with (say) 3
> or 4 visible "brightnesses" of tile. More levels of representation would,
> I agree, become extremely hard to use at the dark end of the scale.
>
> Sam
An interesting effect that would be really simple, once a system like
this is implemented, would be to base the cut-off for the various
visible light levels on some player stat. So the underlying wouldn't
have to change but, slowly, the visible radius would increase.
SC Skipsey wrote:
> On Wed, 6 Jul 2005, David Damerell wrote:
>
> > Quoting Shedletsky <mylastname@stanford.edu>:
> > >I've got a graphical tilemap that I want to add the ability to handle
> > >multiple static and dynamic light sources with LOS (as opposed to simply
> > >lighting a whole room). Instead of the normal on/off lighting status of a
> > >single tile, I want to allow the intensity to vary between 0 (dark) to 100
> > >(fully lit).
> >
> > Why?
> >
> > Seriously, it's going to be maddening in a non-realtime game to have data
> > available but in low contrast.
> >
>
> While the OP doesn't state this, I assume that he is intending for there
> to be other effect from low- or high-light levels. (For example, some
> monsters may
> be hard/impossible to see in tiles with lighting below a certain
> threshold, or may be pained by being in tiles with high lighting values.)
> There is no reason (and, in fact, it would be silly to attempt) to
> represent each lighting level as a separate brightness level with such a
> detailed representation, so I also assume the OP will stick with (say) 3
> or 4 visible "brightnesses" of tile. More levels of representation would,
> I agree, become extremely hard to use at the dark end of the scale.
>
> Sam
An interesting effect that would be really simple, once a system like
this is implemented, would be to base the cut-off for the various
visible light levels on some player stat. So the underlying wouldn't
have to change but, slowly, the visible radius would increase.
Anonymous
July 6, 2005 11:09:08 PM
Archived from groups: rec.games.roguelike.development (More info?)
On Wed, 6 Jul 2005, David Damerell wrote:
> Quoting Shedletsky <mylastname@stanford.edu>:
> >I've got a graphical tilemap that I want to add the ability to handle
> >multiple static and dynamic light sources with LOS (as opposed to simply
> >lighting a whole room). Instead of the normal on/off lighting status of a
> >single tile, I want to allow the intensity to vary between 0 (dark) to 100
> >(fully lit).
>
> Why?
>
> Seriously, it's going to be maddening in a non-realtime game to have data
> available but in low contrast.
>
While the OP doesn't state this, I assume that he is intending for there
to be other effect from low- or high-light levels. (For example, some
monsters may
be hard/impossible to see in tiles with lighting below a certain
threshold, or may be pained by being in tiles with high lighting values.)
There is no reason (and, in fact, it would be silly to attempt) to
represent each lighting level as a separate brightness level with such a
detailed representation, so I also assume the OP will stick with (say) 3
or 4 visible "brightnesses" of tile. More levels of representation would,
I agree, become extremely hard to use at the dark end of the scale.
Sam
On Wed, 6 Jul 2005, David Damerell wrote:
> Quoting Shedletsky <mylastname@stanford.edu>:
> >I've got a graphical tilemap that I want to add the ability to handle
> >multiple static and dynamic light sources with LOS (as opposed to simply
> >lighting a whole room). Instead of the normal on/off lighting status of a
> >single tile, I want to allow the intensity to vary between 0 (dark) to 100
> >(fully lit).
>
> Why?
>
> Seriously, it's going to be maddening in a non-realtime game to have data
> available but in low contrast.
>
While the OP doesn't state this, I assume that he is intending for there
to be other effect from low- or high-light levels. (For example, some
monsters may
be hard/impossible to see in tiles with lighting below a certain
threshold, or may be pained by being in tiles with high lighting values.)
There is no reason (and, in fact, it would be silly to attempt) to
represent each lighting level as a separate brightness level with such a
detailed representation, so I also assume the OP will stick with (say) 3
or 4 visible "brightnesses" of tile. More levels of representation would,
I agree, become extremely hard to use at the dark end of the scale.
Sam
Anonymous
July 7, 2005 12:21:34 PM
Archived from groups: rec.games.roguelike.development (More info?)
David Damerell wrote:
> Quoting Shedletsky <mylastname@stanford.edu>:
>
>>I've got a graphical tilemap that I want to add the ability to handle
>>multiple static and dynamic light sources with LOS (as opposed to simply
>>lighting a whole room). Instead of the normal on/off lighting status of a
>>single tile, I want to allow the intensity to vary between 0 (dark) to 100
>>(fully lit).
>
>
> Why?
>
> Seriously, it's going to be maddening in a non-realtime game to have data
> available but in low contrast.
>
>
>>I think it would be cool for some monsters to carry their own light sources,
>>but I don't see other games doing this.
>
>
> NetHack does it; some monsters like fire elementals _are_ light sources,
> the player can light lamps and leave them lying on the floor, and
> acquisitive monsters might pick them up and carry them around.
Now, these are interesting things that add to the gameplay. One could
also imagine demons or other nasty creatures that instead of cast light,
cast darkness around them, effectively cancelling lightsources around them.
--
Björn Bergström
roguelike development [http://roguelikedevelopment.org]
dweller - cellphone roguelike [http://roguelikedevelopment.org/dweller]
David Damerell wrote:
> Quoting Shedletsky <mylastname@stanford.edu>:
>
>>I've got a graphical tilemap that I want to add the ability to handle
>>multiple static and dynamic light sources with LOS (as opposed to simply
>>lighting a whole room). Instead of the normal on/off lighting status of a
>>single tile, I want to allow the intensity to vary between 0 (dark) to 100
>>(fully lit).
>
>
> Why?
>
> Seriously, it's going to be maddening in a non-realtime game to have data
> available but in low contrast.
>
>
>>I think it would be cool for some monsters to carry their own light sources,
>>but I don't see other games doing this.
>
>
> NetHack does it; some monsters like fire elementals _are_ light sources,
> the player can light lamps and leave them lying on the floor, and
> acquisitive monsters might pick them up and carry them around.
Now, these are interesting things that add to the gameplay. One could
also imagine demons or other nasty creatures that instead of cast light,
cast darkness around them, effectively cancelling lightsources around them.
--
Björn Bergström
roguelike development [http://roguelikedevelopment.org]
dweller - cellphone roguelike [http://roguelikedevelopment.org/dweller]
Anonymous
July 7, 2005 1:14:42 PM
Archived from groups: rec.games.roguelike.development (More info?)
David Damerell was puzzled:
> > Why?
> >
> > Seriously, it's going to be maddening in a non-realtime game to have
data
> > available but in low contrast.
The intention of my game is to punish the player. My over-arching strategy
is to let the player sink 50 hours into leveling up and collecting cool
items, then instakill him. Not being able to fully see the dungeon is just
one of the more subtle techniques I am using to break the player's spirit.
"Björn Bergström" <bjorn.bergstrom@roguelikedevelopment.org> wrote in
message news
aihnn$udo$1@domitilla.aioe.org...
> Now, these are interesting things that add to the gameplay. One could
> also imagine demons or other nasty creatures that instead of cast light,
> cast darkness around them, effectively cancelling lightsources around
them.
That was actually the idea that inspired me to begin thinking about light
intensity levels. That, and I wanted a way to slowly increase the vision
radius of my ranger character as he gains levels (at every level), and
increasing it in integer amounts made it get too large too fast.
--
Blog:
Shedletsky's Bits: A Random Walk Through Manifold Space
http://www.stanford.edu/~jjshed/blog
David Damerell was puzzled:
> > Why?
> >
> > Seriously, it's going to be maddening in a non-realtime game to have
data
> > available but in low contrast.
The intention of my game is to punish the player. My over-arching strategy
is to let the player sink 50 hours into leveling up and collecting cool
items, then instakill him. Not being able to fully see the dungeon is just
one of the more subtle techniques I am using to break the player's spirit.
"Björn Bergström" <bjorn.bergstrom@roguelikedevelopment.org> wrote in
message news
aihnn$udo$1@domitilla.aioe.org...> Now, these are interesting things that add to the gameplay. One could
> also imagine demons or other nasty creatures that instead of cast light,
> cast darkness around them, effectively cancelling lightsources around
them.
That was actually the idea that inspired me to begin thinking about light
intensity levels. That, and I wanted a way to slowly increase the vision
radius of my ranger character as he gains levels (at every level), and
increasing it in integer amounts made it get too large too fast.
--
Blog:
Shedletsky's Bits: A Random Walk Through Manifold Space
http://www.stanford.edu/~jjshed/blog
Anonymous
July 7, 2005 1:34:31 PM
Archived from groups: rec.games.roguelike.development (More info?)
> Try doing what I'm doing in my RL, each tile "on fire" is a light source
> with a low radius; without good optimization it's a *big* strain od my
> CPU when half the map is on fire.
>
> http://hakendslasz.boo.pl/woops.gif
Hey that's a neat idea! What optimizations did you use? Seems like for small
light radii you might be able to ignore shadows and just do lightmaps and
get a good/fast result. Looked at the screenshot - it's pretty neat. If I
might make a suggestion, it looks like you have three intensities levels
that you draw: {fully lit, half-tone, unlit}. Seems to me if you are doing
so much work with the lighting calculations, you should leverage that in a
way that the player will notice. The lower right tiles that are on fire
don't seem to emit any light at all - probably because the level is low
enough that it gets averaged done to zero when drawn. Just my 2c. Like I
said, it looks pretty cool as it is.
--
Blog:
Shedletsky's Bits: A Random Walk Through Manifold Space
http://www.stanford.edu/~jjshed/blog
> Try doing what I'm doing in my RL, each tile "on fire" is a light source
> with a low radius; without good optimization it's a *big* strain od my
> CPU when half the map is on fire.
>
> http://hakendslasz.boo.pl/woops.gif
Hey that's a neat idea! What optimizations did you use? Seems like for small
light radii you might be able to ignore shadows and just do lightmaps and
get a good/fast result. Looked at the screenshot - it's pretty neat. If I
might make a suggestion, it looks like you have three intensities levels
that you draw: {fully lit, half-tone, unlit}. Seems to me if you are doing
so much work with the lighting calculations, you should leverage that in a
way that the player will notice. The lower right tiles that are on fire
don't seem to emit any light at all - probably because the level is low
enough that it gets averaged done to zero when drawn. Just my 2c. Like I
said, it looks pretty cool as it is.
--
Blog:
Shedletsky's Bits: A Random Walk Through Manifold Space
http://www.stanford.edu/~jjshed/blog
Anonymous
July 7, 2005 5:40:54 PM
Archived from groups: rec.games.roguelike.development (More info?)
"NIm" <bladedpeng...@gmail.com> wrote:
>
>Wouldn't it be far simpler just to calculate a normal los type
>lightmap, then for every non-black square, assign a value >based on it's distance from the origin?
Sure -- except that this doesn't account for shadows cast by, say,
large monsters that block part (but not all) of a square. If there's a
troll between me and a floor tile, I can still see the floor tile, so
it's within my LOS -- but if I'm carrying a torch, it makes sense that
the light from my torch striking said floor tile would be dimmer than
if the troll wasn't there blocking part of the light.
"NIm" <bladedpeng...@gmail.com> wrote:
>
>Wouldn't it be far simpler just to calculate a normal los type
>lightmap, then for every non-black square, assign a value >based on it's distance from the origin?
Sure -- except that this doesn't account for shadows cast by, say,
large monsters that block part (but not all) of a square. If there's a
troll between me and a floor tile, I can still see the floor tile, so
it's within my LOS -- but if I'm carrying a torch, it makes sense that
the light from my torch striking said floor tile would be dimmer than
if the troll wasn't there blocking part of the light.
Anonymous
July 7, 2005 6:10:40 PM
Archived from groups: rec.games.roguelike.development (More info?)
Quoting David Damerell <damerell@chiark.greenend.org.uk>:
>Quoting Shedletsky <mylastname@stanford.edu>:
>>I've got a graphical tilemap that I want to add the ability to handle
>>multiple static and dynamic light sources with LOS (as opposed to simply
>>lighting a whole room). Instead of the normal on/off lighting status of a
>>single tile, I want to allow the intensity to vary between 0 (dark) to 100
>>(fully lit).
>>I think it would be cool for some monsters to carry their own light sources,
>>but I don't see other games doing this.
Oh, I missed something here; these aims work against each other. In a
system with lit/unlit binary states, a monster with a light has only to
affect a few squares around it. With a gradual gradient, you can expect
that the very edge of the affected area is much further out, increasing
the computation needed, which discourages many light sources.
However, if you must do this, an optimisation would be to calculate the
information for unmoving light sources once and squirrel it away,
recaclulating it only if the set of them changes.
--
David Damerell <damerell@chiark.greenend.org.uk> Kill the tomato!
Today is Second Thursday, Presuary.
Quoting David Damerell <damerell@chiark.greenend.org.uk>:
>Quoting Shedletsky <mylastname@stanford.edu>:
>>I've got a graphical tilemap that I want to add the ability to handle
>>multiple static and dynamic light sources with LOS (as opposed to simply
>>lighting a whole room). Instead of the normal on/off lighting status of a
>>single tile, I want to allow the intensity to vary between 0 (dark) to 100
>>(fully lit).
>>I think it would be cool for some monsters to carry their own light sources,
>>but I don't see other games doing this.
Oh, I missed something here; these aims work against each other. In a
system with lit/unlit binary states, a monster with a light has only to
affect a few squares around it. With a gradual gradient, you can expect
that the very edge of the affected area is much further out, increasing
the computation needed, which discourages many light sources.
However, if you must do this, an optimisation would be to calculate the
information for unmoving light sources once and squirrel it away,
recaclulating it only if the set of them changes.
--
David Damerell <damerell@chiark.greenend.org.uk> Kill the tomato!
Today is Second Thursday, Presuary.
Anonymous
July 7, 2005 9:02:13 PM
Archived from groups: rec.games.roguelike.development (More info?)
Shedletsky wrote:
> The intention of my game is to punish the player. My over-arching strategy
> is to let the player sink 50 hours into leveling up and collecting cool
> items, then instakill him. Not being able to fully see the dungeon is just
> one of the more subtle techniques I am using to break the player's spirit.
The instakill is one of the most cursed behaviours of every roguelike
under the sun that feature it. Implementing it in your project will
break the player's spirit along the will to continue playing your game.
Im my humble opinion, that is it.
--
Kaleth, writing from a realm deep into the mountains...
Shedletsky wrote:
> The intention of my game is to punish the player. My over-arching strategy
> is to let the player sink 50 hours into leveling up and collecting cool
> items, then instakill him. Not being able to fully see the dungeon is just
> one of the more subtle techniques I am using to break the player's spirit.
The instakill is one of the most cursed behaviours of every roguelike
under the sun that feature it. Implementing it in your project will
break the player's spirit along the will to continue playing your game.
Im my humble opinion, that is it.
--
Kaleth, writing from a realm deep into the mountains...
Anonymous
July 10, 2005 1:54:11 AM
Archived from groups: rec.games.roguelike.development (More info?)
On Thu, 7 Jul 2005 09:14:42 -0400, "Shedletsky"
<mylastname@stanford.edu> wrote:
>The intention of my game is to punish the player.
Clearly, you have issues.
--
R. Dan Henry = danhenry@inreach.com
On Thu, 7 Jul 2005 09:14:42 -0400, "Shedletsky"
<mylastname@stanford.edu> wrote:
>The intention of my game is to punish the player.
Clearly, you have issues.
--
R. Dan Henry = danhenry@inreach.com
Anonymous
July 10, 2005 9:31:17 PM
Archived from groups: rec.games.roguelike.development (More info?)
"Shedletsky" <mylastname@stanford.edu> wrote in message
news
aj9s6$l75$1@news.Stanford.EDU...
> David Damerell was puzzled:
>> > Why?
>> >
>> > Seriously, it's going to be maddening in a non-realtime game to
>> > have
> data
>> > available but in low contrast.
>
> The intention of my game is to punish the player. My over-arching
> strategy
> is to let the player sink 50 hours into leveling up and collecting
> cool
> items, then instakill him. Not being able to fully see the dungeon is
> just
> one of the more subtle techniques I am using to break the player's
> spirit.
>
See, and here I was thinking the point was to make a fun game.
--
Glen
L
yt E+++ T-- R+ P+++ D+ G+ F:*band !RL RLA-
W:AF Q+++ AI++ GFX++ SFX-- RN++++ PO--- !Hp Re-- S+
"Shedletsky" <mylastname@stanford.edu> wrote in message
news
aj9s6$l75$1@news.Stanford.EDU...> David Damerell was puzzled:
>> > Why?
>> >
>> > Seriously, it's going to be maddening in a non-realtime game to
>> > have
> data
>> > available but in low contrast.
>
> The intention of my game is to punish the player. My over-arching
> strategy
> is to let the player sink 50 hours into leveling up and collecting
> cool
> items, then instakill him. Not being able to fully see the dungeon is
> just
> one of the more subtle techniques I am using to break the player's
> spirit.
>
See, and here I was thinking the point was to make a fun game.
--
Glen
L
yt E+++ T-- R+ P+++ D+ G+ F:*band !RL RLA-W:AF Q+++ AI++ GFX++ SFX-- RN++++ PO--- !Hp Re-- S+
Anonymous
July 10, 2005 11:34:01 PM
Archived from groups: rec.games.roguelike.development (More info?)
Shedletsky wrote:
> The intention of my game is to punish the player...
Surely he's being sarcastic.
-Aaron
Shedletsky wrote:
> The intention of my game is to punish the player...
Surely he's being sarcastic.
-Aaron
Related resources
- Flicker shadows / light source problem (Using x2 HD 4850 crossfired) Forum
- YANI - carrots - a possible light source? Forum
- Best light source for inkjet print evaluation? Forum
- Studio Light Dimmers -Source? Forum
- Canon scanner light source scanning element dirfferences Forum
- [40k] [paint] [diorama] Artificial light source with illum.. Forum
- SolvedOne headphone solution for two audio input sources Forum
- SolvedHooking up HDMI and DVI to the same monitor from separate sources Forum
- SolvedHow to split audio between sources. Forum
- SolvedMaverick Audio Tubemagic D1 Plus sources Forum
- SolvedIssue playing back 720p & 1080p sources - Intermediate Stuttering and Lag Forum
- SolvedIs it possible to have two audio sources connected to two different devices on the same PC? Forum
- SolvedCan my PC run Borderlands 2 with high PhysX? Links and/or sources, please. Forum
- SolvedCan my PC run Borderlands 2 with high PhysX? Links and/or sources, please. Forum
- SolvedFront panel audio connected to two sources? Forum
- More resources
Read discussions in other Video Games categories
!