next »

[Michael]

Dragons are awakened by your direct presence.  The whispers are a side effect of something else.

Dialog.

[Moonkey]

Dragons are awakened by your direct presence.  The whispers are a side effect of something else.

How much farther can my fangs suck the urge to resist out?

[BigredRm]

My guess is the wispers are the clean up crew species that Paul had mentioned earlier this month.

[Moonkey]

My guess is the wispers are the clean up crew species that Paul had mentioned earlier this month.

That would be beyond cool

[pspeed]

But it's not.  Those _creatures_ will be plentiful land obvious.

You may never actually encounter the whispers... though I have plans to make that a little more possible.

[Moonkey]

But it's not.  Those _creatures_ will be plentiful land obvious.

You may never actually encounter the whispers... though I have plans to make that a little more possible.

You should make a secret item available for accidental forging. Letting you see the whispers... Why am I portraying them as shadows.

[pspeed]

They are 100% visible.

I think I'm going to stop talking now.

[Teknonick]

They are 100% visible.

I think I'm going to stop talking now.

It's too late. We have your posts quoted all over the entire internet. Your plot has failed.

[pspeed]

Any donators releases are going to be delayed a bit. 

I had only stubbed in lighting up until now.  It worked but only propagated within a leaf.  This led to some ugly visuals at the borders some times (really dark areas and stuff).

I had a rough design of how it should work for real but I finally started crunching on the detailed design last night.  I was only going to spend an hour or so on it but there were too many open questions it generated.... and some of them could have affected my whole lighting architecture decisions.  Those are the kinds of things that need to get nailed down sooner rather than later.

So last night I did a deeper design and tonight started implementing it.  It's worth finishing, though as that is one more thing done.  And it's one of those things that I would drag my feet on otherwise.  I have bad memories of how long it took me to get lighting working last time and it was never 100% right as it was.

The old engine did all lighting on the server and persisted it.  The new engine does all lighting on the client and never persists it.  The nice thing is that means mistakes can sometimes be self-correcting... or at the very least I can patch them in future versions without having odd lighting hanging around everywhere.

The other nice thing about doing it on the client is that I could do it differently for different races and abilities.  This was sort of a long-standing requirement of mine and I'm happy to finally be working towards that goal.  For example, races with infrared vision might see lighting and color completely different in the dark.  Low-light seeing races like pantherians may simply see better in dimmer conditions... light may propagate farther for them.  Anyway, universal lighting on the server was never going to allow that.

When I made that architectural decision, I chose to do some different things with my storage space that makes lighting propagation much much simpler.  So far this pays off nicely as all of my issues have been related to other things.  Basic lighting propagation is plenty fast so far.

Tonight I also started the support to do non-smooth lighting.  Ironically, this was trickier than it seems because the design decisions that freed up because of smooth lighting make non-smooth lighting very difficult.  But since lighting is done on the client and I want the light calculations to be very fast, I want the simpler option for lower power machines.  I really really want to get to the point where the lighting calculation is fast enough that I can have moving light sources like player-held torches.  Or objects that have light on them actually casting light, etc..

So if I'm successful with this phase, a bunch of long-standing issues become clearer and much easier to implement.

[Moonkey]

Ah, never knew you had such problems. Will moving lights on non-smooth lighting have gradual fading (Example: Will the lighting become gradually darker instead of having instant change depending on the distance from block) so it looks more natural? Or will it be linear? (When the light gets over the border of a different block the lighting instantly switches instead of the different block getting brighter as the light gets closer) If confused, I don't know how to explain it better.

[pspeed]

Ah, never knew you had such problems. Will moving lights on non-smooth lighting have gradual fading (Example: Will the lighting become gradually darker instead of having instant change depending on the distance from block) so it looks more natural? Or will it be linear? (When the light gets over the border of a different block the lighting instantly switches instead of the different block getting brighter as the light gets closer) If confused, I don't know how to explain it better.

I know what you mean.  Moving lights would still be block based.  But with smooth lighting, I still think it will look ok.

[BenKenobiWan]

I think he was wondering if, without smooth lighting, blocks would increase their brightness gradually or in steps. When you place a light currently, the light looks like:
01210
12321
23432
12321
01210
As a light source moved, would the "numbers" go through fractions/decimals or simply jump from number to number?

[pspeed]

I think he was wondering if, without smooth lighting, blocks would increase their brightness gradually or in steps. When you place a light currently, the light looks like:
01210
12321
23432
12321
01210
As a light source moved, would the "numbers" go through fractions/decimals or simply jump from number to number?

That would be "not block based" since the lighting would have a position other than "block based".

Lighting will be "block based" meaning that a cell only has one light value.  If you move an object within that cell then the light value won't change.  If you move it out of the cell then the next cell gets the light value.

Right now I'm keeping two bytes per cell for lighting.  To do gradual (non-block-based) lighting, I would at minimum have to keep 8 bytes per cell... and that's only if I don't want colored lights anymore.  For colored lights, I would need to keep 16 bytes per cell.

32x32x32x16 is a lot of data just for lighting one leaf.

[Michael]

Hey Paul, has it got to that point that you are going to use 'bytes' and 'shorts', or have you already started using them at the beginning?

[pspeed]

Hey Paul, has it got to that point that you are going to use 'bytes' and 'shorts', or have you already started using them at the beginning?

what else would I have used?

Actually, most of the cell data is stored as integers but that's multiple sub-byte values packed together.  The old version had 4 bits for sunlight, 4 bits for local light and the rest for cell value.