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.