Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CF0.91.8??/lighting code ideas
Awk. My mailer is spasming out again. 1 more try :) ....
>
> I assume by darkness you mean blackness?
Yeah. I agree greyscale graphics would be cool, but would add
a deal of coding complication and really slow the execution loop
(as you pointed out). Varying light source power can be
simply simulated by an 'illumination' radius. Candles get 1
square away, lanterns get 2 and bonfires get 3, and etc...
The greater the radius size allowed, the slower the line of
sight calculation will get however, :<
> > This would also add in uses for varying intensity light sources. If you are
> > carrying an arc lamp through those dense bushes, you will still have light
> > for a few spaces. But a candle even in some open area won't do you much
> > good.
>
For now, I think it is best to 'ignore' the issue of variable
transparentness of objects. Again, this really will slow down
execution.
> This touches on another feature of Crossfire which I think could use some
> work--namely map scale. I see (primarily) 3 scales in existing maps, which I'll
> term building, city and world. These seem to correspond (roughly) to 10, 100,
> and 1000 feet per square. Adding a scale attribute to a map would enable
> lighting code (and perhaps spell ranges?!) to be adjusted based on where
> the user is (i.e. a torch should not light the entire left half of the
> continent, but it should light a whole room.)
Yeah a good point. I would suggest for now that only the insides of
structures be dark -- ie dungeons, buildings, and deep dark jungles (etc,etc).
Designation of these dark areas would be in the map field, say
whether map->unlit == 1 or 0. If the map isnt 'unlit' then all light
sources would automatically be ignored in the line of sight calculation.
This global map lit/unlit would save headaches that would occur
with local 'day' and 'night' areas in a map- ie the assumption of
a map being *either* all dark or all lit squares really would speed up
things. If you wanted a lit room in a 'dark' map then embbeding a
few light sources (wall torches) in the map should fix things. Of course,
the more embedded light sources - the slower the execution loop
would get. Intelligent map construction/linking would be required not
to goof up the game (alas...:)
Hmm. This lighting code reminds me of some particle code stuff I did
a while back... I am thinking of perhaps a lighting code that works
like this:
1 - While loading the map determine map lighting status,
if lit use the regular code. If unlit - search the
map for permanent light sources and put into an array
noting all the squares which fall into light source
lighting radii for later fast access.
2 - Player (and temporary) light sources would be addressed
by a player lighting array (only something like 14x14 -
each player has one). This array is updated with every
few ticks in the line of sight loop. Probably don't want
players to have light sources brighter than 1 or 2
square radii.
2 - Characters with pl->map->unlit get modified line of
sight. Probably, there are fewer lit squares than
potential squares viewable (if were all lit) So...
determine all lit squares in players 'viewing box'
(from the map + player lighting arrays) -- including
light sources > 5 squares distant whose lighting radius
does fall into view. On this reduced set of viewable
squares calculate the line of sight. Minor flaw: unlit
areas between two viewable light sources would remain unlit.
Pending the speed of this 'beta' loop, more features could be added in,
like allowing monsters to have light sources, fireballs, lightning, etc
could light up rooms, addition of player 'infravision', and monster
modified line of sight (the above loop is only calculated for players!!
all monsters were assumed to see in the dark!!), and so on....
> This raises another question...
> why is it always daytime in Crossfireland?
>
Good point here. Tangentially, (also) why is there no weather? No seasons?
(I actually tryed coding in seasonal changes to the CF0.91.4 code a while
back....it was horribly slow. Maybe I will pick this up sometime again)
b.t.