Forum_account wrote:
The lighting is always tile based even when movement is pixel based. The lighting should update when the mob's center moves to a different tile.

Oh x.x
Pro
Forum_account wrote:
The lighting is always tile based even when movement is pixel based. The lighting should update when the mob's center moves to a different tile.

This has been changed. Now, by default, the light source's position will take into account the step_x and step_y of the mob it's attached to. Illumination is still tile-based and still uses a discrete number of shades so it doesn't look perfect, but this makes the tile-to-tile transition much less drastic.

You can enable the old behavior by setting: lighting.pixel_movement = 0
Wow, actually it looks really nice to me. If I could slap a giant star on this libraries forehead I would. lol
Any chance to update the icon generator to support isometric mode?
Jmurph wrote:
Any chance to update the icon generator to support isometric mode?

I could but I don't think it's possible for the library to decently support isometric maps. It could work on completely flat isometric maps, but for maps with walls and different elevations I don't think it's easily possible.

It wouldn't be the most efficient way to generate the icons, but you can probably find a utility that'll turn regular 32x32 icons into diamond-shaped isometric tiles and apply that to the lighting icons generated by the library.
Fair enough- its just a 45 degree flip followed by a 50% vertical shrink :-)
I was hoping to use this in MLAAS, but unfortunately MLAAS has several elements that rely on the built-in opacity system (such as blocking sight beyond walls). I don't think this library supports what I need at the moment. Guess I'll stick with Shadowdarke's ugly one.
Nadrew wrote:
I was hoping to use this in MLAAS, but unfortunately MLAAS has several elements that rely on the built-in opacity system (such as blocking sight beyond walls). I don't think this library supports what I need at the moment. Guess I'll stick with Shadowdarke's ugly one.

I was hoping it'd be able to support opacity by using step_x/y instead of pixel_x/y, thinking that the client might display an obj if you can see at least one turf in its locs list, but apparently that's not the case.

To make it work with opacity you need to make two changes:

dynamic-lighting.dm, roughly line 143, remove these two lines:
    pixel_x = -16
pixel_y = -16


light-source.dm, roughly line 129, make this change:
                // change this
__x = opx
__y = opy

// to this:
__x = opx - 0.5
__y = opy - 0.5
That definitely helps, still gotta work on things though but it definitely looks nice, so far. Next step, light shining through walls. I imagine your shadow-casting thing probably handles this part.
Another thing, how possible is it to change the light level of the entire game? I was looking over everything and didn't catch something that did this outside of small light sources.
Nadrew wrote:
Another thing, how possible is it to change the light level of the entire game? I was looking over everything and didn't catch something that did this outside of small light sources.

Currently there's no easy way to do that, you'd have to update every turf in the game. I didn't intend for this to be used for day/night effects but that seems like a common thing people will use it for. I'll try to work on a demo showing how to do this and include it in the next update.
There was once a season change and day/night engine that only updated the turfs visible to the player(plus extra on the sides). It turned out to be much, much faster than updating every turf in the world.

However, you can't do something like "teleport the player to 123,123,1 if that turf is lit" unless you update that turf beforehand. But that probably won't happen.
Kaiochao wrote:
There was once a season change and day/night engine that only updated the turfs visible to the player(plus extra on the sides). It turned out to be much, much faster than updating every turf in the world.

However, you can't do something like "teleport the player to 123,123,1 if that turf is lit" unless you update that turf beforehand. But that probably won't happen.

That's essentially all I'd do. It'd end up being a constant that gets added to all illumination values and the update takes effect the next time that location is re-evaluated.
See, what I was trying to do was having a few "sun" objects that moved across the maps lighting them up, but after a few rounds the thing started lagging out pretty seriously.
I just posted an update which has a day/night demo.
Not sure if you know but you should make the minimum radius 1, when you decrease it below that you get 0 and then something ends up being divided by zero, giving an infinitely long answer. This causes some sort of crash or something.

But otherwise very cool.
My original plan was that a radius of 1 meant that tiles in range(1,src) would be illuminated, so a radius of zero would mean that only the light source's location was lit up. But the way the math works out it ends up more like tiles in range(radius-1,src) get illuminated, so you're right that the lower limit should be 1. Thanks for pointing this out =)
No problem. I'm actually using this in a game I'm making now, helps me create the perfect atmosphere.
Liking the new stuff, gonna take some thinking to make it work as needed but I think it'll make things easier. You should probably be making atom/light a tmp variable by default.
Page: 1 2 3