Kaiochao, tell us. I think, it's something with image or blend mode.
In response to Kaiochao
I'm taking a shot in the dark that you're using images for the shadows and modifying blend_mode to achieve it.

Am I close?

edit: ninja'd
Albro come on man don't just steal what Marek said not cool.
Hints: the shadow is a simple overlay, no blend_mode, and its color is "black" (no alpha).
The shadow doesn't exist. It's just an illusion that the master kaichao the great God illusionist has pulled

All hail kaichao
In response to Kaiochao
Kaiochao wrote:
Hints: the shadow is a simple overlay, no blend_mode, and its color is "black" (no alpha).
Matrix skewing (for the slanted shadow effect anyway)
Can we post games that we are making but NOT using BYOND for? If so, I have something I'd like to share :)
In response to Kaiochao
I don't know if it is how you did it but...

You can add an alpha layer over your ground turfs that is a layer above your shadow layer. All your shadows would be the same color and not use alpha, because there is no alpha involved in the shadows.. there is no blending and you get the look you showed. Objects you want to be above the shadows would be on higher layers.

That's one way.

EDIT:I explained this weird... LOL
In response to Akto
Akto wrote:
I don't know if it is how you did it but...

You can add an alpha layer over your ground turfs that is a layer above your shadow layer. All your shadows would be the same color and not use alpha, because there is no alpha involved in the shadows.. there is no blending and you get the look you showed. Objects you want to be above the shadows would be on higher layers.

That's one way.

EDIT:I explained this weird... LOL

Omgyaasss. I know what I'm working on tonight. (:
I've been dabbling in HTML/CSS/JavaScript lately and came up with this:

http://i.imgur.com/dN5S0AT.gifv

It's basically a Quest Log that shows your In-Progress, Completed, and Failed quests. Quests have a name, description, and reward(s). The quest lists can update seamlessly with JavaScript and can be expanded and collapsed.
By the way, the shadows work on an idea that D4RK3 54B3R (or was it DarkCampainger? I always mix them up) told me months ago. Basically, turfs are transparent, shadows are solid black underneath turfs, and beneath shadows is a layer of solid gray.

And yes, Goober, they use matrix shear. I'm pretty sure it makes more sense than rotation alone in a 4:3 perspective. At least shrink it in the y-axis.
If you're up for a more elaborate lighting system, like what I use here:

None of this works in the webclient as of now unfortunately...

Turfs are all on BLEND_MULTIPLY. Ambient lighting is a flat rectangle that is drawn across the screen with a uniform color at the lowest layer. For me, this layer is 0.1. Next, shadows are just placed on layer 0.2. Then, local light sources that are intended to cancel out shadows, like the campfire here, are placed on layer 0.3.

For all objects with a perceived height, like trees or people, I just update their atom.color whenever they move or whenever any lightsource that affects them has a changed parameter.

This is akin to how Darkcampainger's demo works.
Forum_accounts lighting library has a shadow example, but it is only shadows for mobs based on light sources. Not shadows for trees or players themselves. Maybe it could spark an idea.
This one does work in the webclient.

Suppose I should post my project as well (showing off Kaiochao's zoom library @ about half way, freshly added to Pondera and Forum_accounts lighting/shade library (not completely dark yet, this was an evening shot)):
While the intuitively-overlapping shadows are really, really neat - it unfortunately seems like an impractical hack. I wish there were just a blend_mode setting for it.


Here's the start of a project I'm working on.



And here's an old video to get some discussion rolling.
Ha! I was right... what do I win!
We're doing lighting?



This was something I experimented with for about 6 hours while talking to Yut Put about weird ways of handling lighting. This was about 3 months ago now.

I had an interesting idea for handling lighting with a 4-color palette and decided to chase it down.



I started with a 12-color black and white palette.

Then I created lighting profiles using our four colors:



Then I passed it through a bit of code that would generate lighting variations for each individual icon state in the file.

#ifdef DEBUG
var
list/ramp_colors = list(rgb(53,57,40),rgb(98,105,73),rgb(145,154,109),rgb(191,197,171))
list/normal_colors = list(rgb(0,0,0),rgb(25,25,25),rgb(50,50,50),rgb(75,75,75),rgb(100,100,100),rgb(125,125,125),rgb(150,150,150),rgb(175,175,175),rgb(200,200,200),rgb(225,225,225),rgb(250,250,250),rgb(255,255,255))
list/light_palettes = list(list(1,1,1,1,1,1,1,1,1,1,1,2),
list(1,1,1,1,1,1,1,1,1,2,2,2),
list(1,1,1,1,1,1,1,1,2,2,3,3),
list(1,1,1,1,1,2,2,2,3,3,3,4),
list(1,1,1,2,2,2,2,3,3,3,4,4),
list(1,1,1,2,2,2,3,3,3,4,4,4),
list(1,1,2,2,2,3,3,3,4,4,4,4),
list(1,1,2,2,2,3,3,4,4,4,4,4),
list(1,2,2,3,3,3,4,4,4,4,4,4))

client/verb
LightIcon(icon/I as icon)
var/list/output = list()
var/icon/J
for(var/count=1;count<10;count++)
J = new(I)
for(var/pos=1;pos<13;pos++)
J.SwapColor(normal_colors[pos],ramp_colors[light_palettes[count][pos]])
output += J
var/list/states = icon_states(J)
var/icon/K = icon()
K.Crop(1,1,J.Width(),J.Height())
for(var/pos=1;pos<=states.len;pos++)
for(var/count=output.len;count;count--)
J = icon(output[count],states[pos])
K.Insert(J,"[count-1][states[pos]]")
usr << ftp(K)

MakeNormals(icon/I as icon)
var/level = -1
while(level<0||level>8)
level = floor(input("What light level is this icon? \[0-8]","MakeNormals \[icon] \[num]") as num|null)
if(level==null) return
level++
var/icon/J = new(I)
var/firstpos = 0
var/lastpos = 0
var/list/l = light_palettes[level]
for(var/count=1;count<5;count++)
firstpos = l.Find(count)
lastpos = firstpos + 1
if(firstpos)
while(lastpos<13)
if(l[lastpos]==count)
lastpos++
else
break
firstpos += floor((lastpos-firstpos)/2)
J.SwapColor(ramp_colors[count],normal_colors[firstpos])
usr << ftp(J)
#endif


The result looks something like this:



Then I wrote a bit of code that managed lighting at the turf level:

atom
var
base_icon_state
proc
setIconState(state)
base_icon_state = state
icon_state = state
movable
var
receive_light = 1
tmp/disp_light = 0

Move()
. = ..()
if(.&&receive_light)
var/high = 0
for(var/turf/t in locs)
high = max(high,t.disp_light)
icon_state = "[high][base_icon_state]"
disp_light = high

area
var
ambient_light = 0

var
obj/turf_edge = new/obj{icon='graphics/turf_edge.dmi';pixel_x=-4;pixel_y=-4;layer=1;mouse_opacity=0}()

turf
icon = 'tiles.dmi'
var/tmp
light = 0
extra_light = 0
disp_light = 0
proc
UpdateLight()
if(extra_light)
disp_light = min(floor(light),7)+min(floor(extra_light),1)
icon_state = "[disp_light][base_icon_state]"
else
disp_light = min(floor(light),7)
icon_state = "[disp_light][base_icon_state]"
New()
..()
var/area/a = loc
light += a.ambient_light
underlays += turf_edge
UpdateLight()

var
mob/__vismob = new()
datum/void = new()

light
parent_type = /obj
luminosity = 10
receive_light = 0
var
dynamic = 0
intensity = 4
tmp/list/turfs
proc
TurnOn()
if(turfs) return
__vismob.loc = loc
__vismob.step_x = step_x
__vismob.step_y = step_y
__vismob.see_in_dark = luminosity
turfs = oview(__vismob,luminosity)
__vismob.loc = null
var/tx
var/ty
var/d
var/lsq = luminosity*luminosity
for(var/turf/t in turfs)
tx = t.x-x
ty = t.y-y
d = 1 - (tx*tx + ty*ty) / lsq
if(d>0)
t.light += d * intensity
t.UpdateLight()
else
turfs -= t
if(!dynamic) turfs = void

TurnOff()
if(turfs)
var/tx
var/ty
var/lsq = luminosity*luminosity
for(var/turf/t in turfs)
tx = t.x-x
ty = t.y-y
t.light -= (1 - (tx*tx + ty*ty) / lsq) * intensity
t.UpdateLight()
turfs = null

Move()
if(!dynamic) return 0
TurnOff()
. = ..()
if(.)
TurnOn()

New(loc,lum=null,dyn=0)
. = ..()
dynamic = dyn
if(lum) luminosity = lum
if(loc&&luminosity)
spawn(TICK_LAG)
TurnOn()


Profiling results:



That's about 30 million lighting updates over about 8 minutes. It generates a ton of network communication if you do it rapid-fire like my test. CPU utilization was about 28% through the entire test, and updates per frame was around 1500 tiles.

Basically, I can do batch lighting transitions with around 5K tiles per frame at 40fps on my machine before CPU starts to become problematic. That puts me around a maximum number of tiles updated per second at 200,000, so a full 1000x1000 map would take me about 5 seconds to fully process if you needed to update the lighting of every tile.

This was a pretty simplistic approach, and optimization is needed before multiplayer fielding would be viable.
In response to Ter13
This is pretty much how half of my old lighting system worked. World initialization would pregenerate icons for everything under different lighting conditions.

I found that this didn't work so great in multiplayer, mostly because anything tile-based has too many updates to send to the client if there are certain lighting effects, like flickering or moving lights.
This is pretty much how half of my old lighting system worked. World initialization would pregenerate icons for everything under different lighting conditions.

I pre-generate prior to compilation.

I found that this didn't work so great in multiplayer, mostly because anything tile-based has too many updates to send to the client if there are certain lighting effects, like flickering or moving lights.

Lummox changed the turf update messages. It used to be that a change to a turf would refresh the entire viewport.

Now, that's not the case unless a significant number of turfs in the viewport of the client have been changed.

This works mighty fine in multiplayer. I've tested it. In my case, I'm not actually recalculating updates based on the client's position. I'm only recalculating lights that actually move or change luminosity on demand.

So as long as you keep your moving lights very small, and avoid lighting flicker, it handles in multiplayer just fine.
In response to Ter13
Ter13 wrote:
I found that this didn't work so great in multiplayer, mostly because anything tile-based has too many updates to send to the client if there are certain lighting effects, like flickering or moving lights.

Lummox changed the turf update messages. It used to be that a change to a turf would refresh the entire viewport.

That's unfortunate. My system could only either use /area to display shading/lighting, or turf overlays.

Recalculating updates in my system only happens upon movement or change in brightness or change in radius. For dynamic shadows, opaque objects' movement would also cause light sources to recompute lighting.
Page: 1 2 3 4 5 ... 349 350 351