Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[nop]

Well, it's a demonstration of the engine. I completely agree that DF should not contain hundreds of moving objects, but dozens of static lights. But I need 1) a large fortress with dozens of 'light fixtures', succession fortresses do not seem to be impressive enough, 2) to place dozens of light sources within DF, for ex., consider using armor stand as a light source 3) to take a look inside dfhack to obtain the way to export 'light fixtures' into my program. All this takes time.

[hermes]

Wow, trippy videos.   

You mention some features that could be added; here is an older lighting thread with a great summary.

I think this is pretty decent as a proof of concept goes, but the real trick would (it seems to me) be making this work with CP437 and possibly with 16 colours (??).  Shading in 32bit colour is easy, but I reckon if/when lighting does make an appearance in DF, Toady would want a 'simpler' implementation that would work with ASCII, which already has a black background - like adventurer mode's day/night cycle.  I get the feeling the Legacy version of DF is still the base, and that doesn't use SDL.

Also if the performance is good, how about people/animals occluding light rays?

[nop]

> Mechanics of Light
>    Parallel lights with no falloff (sun, moon)
should be ok
>    Point-source lights with inverse-square falloff, stationary unless performance permits
yes, static & moving
>    Each tile lit with a certain amount and color of light, affecting visibility of creatures/items inside it
yes
>    Colored windows can filter colors, apertures like fortifications filter amounts of light
multicoloring should be ok, not sure about performance costs
>    Shadows cast by terrain only -- no creature/item shadows unless performance permits
yes, terrain casts shadows. Creatures \ items can cast shadows, but performance may drop, did not research it with the exception of damned doors
>    Ambient lighting for unlit areas (possibly depending on brightness of sunlight/moonlight, inside/outside, depth underground)
should be ok
>    Diurnal cycle in fortress mode?
should be ok

>Gameplay
engine was designed to be a part of the game, not a paintbrush for ladies for making rooms look cool <^_^>. Period.
>    Creatures work and fight less effectively in darkness (depending on vision attributes)
should be ok, engine calculates lighting for every light, not only for those that are visible to player
>    Light contributes to room value
should be ok
>    Nobles can demand light
well...
>    Effects of light on underground farming
should be ok
>    Dwarves can douse the lights before going to bed
errrrr...
>    Design challenge for the player, and way of beautifying fortress

> Producing Light
>    Fire -- occasional refueling needed
yes, engine was designed with thoughts about fire
>        Torches and tallow candles in holders
should be ok
>        Braziers made of stone or metal, fueled with charcoal or wood
should be ok
>        Lamps filled with plant/animal/mineral oil
should be ok
>        Wildfires
should be ok, but wildfires and any terrain lights \ wide area lights have relatively large performance cost
>    Alternatives
>        Luminescent plants, glowing extracts in glass containers
tested, 3500 plants & shrubs, each of them acting as a very small light source
>        Gem lamps
should be ok
>        Captured fireflies/pixies
should be ok
>        Glowing magma
does not seem to be a good idea because of performance costs, i'll take a look

> Manipulating sunlight
>        Mirror -- reflects beams from parallel sources, can be aimed at a particular target (this apparently has historical precedent)
not supported at this moment. Definitely will produce performance issues as people may want to have 'mirror rooms'
>        Prism -- converts a parallel beam into a point source
the same
>        Mirror and prism can work in concert to shine sunlight deep into the fortress
the same

> Interface
>    "Keep Lit" toggle for rooms, automatic "building" of light sources as needed
hmmm...
>    Automatic refueling (and replacement of torches/candles) based on list of permitted fuels
should be ok
>    All advanced lighting features can be toggled in init, for slower computers
I don't care about slower computers, that's not the problem of the engine. Moore's law states that "the number of transistors on integrated circuits doubles approximately every two years". Engine is designed to use multithreading + OpenCL \ CUDA in future. And CP437 does not make sense to me as well, 21st century is a good reason to go to 32 bit graphics

> Also if the performance is good, how about people/animals occluding light rays?
I'll think about it

[Starver]

>    All advanced lighting features can be toggled in init, for slower computers
I don't care about slower computers, that's not the problem of the engine. Moore's law states that "the number of transistors on integrated circuits doubles approximately every two years". Engine is designed to use multithreading + OpenCL \ CUDA in future. And CP437 does not make sense to me as well, 21st century is a good reason to go to 32 bit graphics

Preceding this I was with you, more or less, but now you've just lost the general block agreement I might have posted.

On the first bit.  Moore's law is being fudged (rather than faster, it's more cores, for example), and I actually like the idea of a game that (while being updated) does not assume you're using bleeding-edge hardware.  (In this respect, DF isn't entirely successful, because it's already doing an awful lot of background stuff and what I would consider an 'acceptable' machine can grind horribly over DF in certain circumstances.)

Dismissing CP437 is not a valid argument.  You're using CP437-like graphics.  (Or, rather, I am, and I like the look, and I find I understand what is presented to me better...  But that's an old and long-standing argument.  YMMV, I have already deduced.)  It's just graphics, though.  A tileset just like the one you're using that is no more nor no less complicated, and thus your engine should have no more nor no less difficulty working with it.  You might as well argue that your engine only supports one particular Tileset (among any number that people use, including their own individually personalised ones) if it is incapable of working with the ANSI-like one.

(If it is an issue that you need to set the renderer up in special ways for certain graphics, that can't be defined by a raw [TAG] of some kind for such an entity if Toady absorbs this into his baby, may I suggest possibly tile-sets could be accompanied by either another integral bit-plane or two (perhaps using another 'reserved' colour, or hijacking the transparency layer under compatible graphics formats?) or a separate (optional?) graphic that contains a mask to prompt the 'darkness' engine to apply the correct darkness effects.  Tileset designers should be able to set up such a parallel graphic (or set a layer) if they need to fine-tune the automatic response to light.  Should there ever be a 'torch' graphic then it could be given a "this is a light-emitter" map (to use or not use, according to whether it is lit?), 'curtains' and other definite light-diminishing obstructions could be indicated, you could officially implement certain glowy plants, etc, that could be visible in darkness while not being especially special or room-lightening in 'daytime' conditions...  And camouflaged beings could blend in brightly in brightly-lit areas while going dark in darkly-lit ones with a judicious use of the light-response prompt.  But all that's said and being suggested without knowing whether you might desire or even need such a feature.)

I won't go into the multithreading thing, because it sounds like you could (if it ever got that far) be doing a Baughn-alike conglomeration of your code into Toady's general engine.  Although I would not deign to presume how or if this would be accomplished.

[nop]

I agree that DF should be moddable and everything should be changable.

Moar images . Cone lights & semi-transparent tiles

[nop]

colors and doors
https://www.youtube.com/watch?v=lA4CC5KbowE

[Cool Guy]

colors and doors
https://www.youtube.com/watch?v=lA4CC5KbowE

All in All. It looks awesome so far. Keep up the good work.

[GreatWyrmGold]

Seriously, have you put this on the Modding subforum yet?

[nop]

Seriously, have you put this on the Modding subforum yet?

You know, code does all the stuff and is implemented as a separate, very fast, small and easy-to-manage library with a few functions... I believe that code IS a suggestion. No need to waste several month to implement someone's idea (like multithreading or religions or anything else), just get a library and integrate it into your system within 10 minutes.

Took a look at adventure mode's way of 'forgetting' areas that are not visible right now but were visible a few moves ago. These tiles become grayed. So, lighting engine will allow a to create the same effect in real-time for the whole fortress very soon (tomorrow, I guess). Also, I believe that game should not gray, but completely hide areas that were not visited by dwarves within a long time (a month, for ex.).

[GreatWyrmGold]

Two things.

1. Toady rarely puts others' code into his game.
2. OP hasn't released the code yet, as far as I've seen.

[nop]

It depends on how good a suggestion is.

ASCII mode
https://www.youtube.com/watch?v=7K_2IBmQswY

Dwarfs forget about their fortress when time passes
https://www.youtube.com/watch?v=6MmgC6TMkjw

[Vattic]

Those last two videos were especially cool.

[hermes]

Props for the ASCII version, that didn't look half bad at all.  But at GWG said it's kind of unknown whether code would be useful/accepted by toady.  Perhaps if you released it under some open license?  But even so, I can't help feeling that lighting isn't really that complex to implement and it'd be better for toady to just write his own code.  No disrespect, I like what you've done here, just thinking out loud.

[Rose]

One thing you could try, if you really wanted to, would be to implement this code into Stonesense, so people could see what a lit fort looks like. Just an idea, though.

[nop]

Finally have found a source of performance problem. Dwarves were running outside, that implies large open areas, tens of thousands cells to process and so on.
I am almost ready to release a tech demo, probably before that I will implement jumping point search pathfinding algorithm as a-star annoys me because of it's sluggishness.
Binary files for Linux. And maybe a dfhack plugin for loading your own fortresses into a demo. also, I plan to use armor stands and other furniture as light sources in demo for you to be able to customize lights. Yes, dwarven memory system is also included.