How do I light my character if my scene is not side scrolling but 2d?

I know this probably not question about Sprite DLight. I am new to these light stuff.
So i am trying my luck to get some suggestion here.

My game allow characters to move in 2D. Up/Down Left/Right, so it is possible that the light source is behind my character sprite. In this case my character should not simulate light casting from top because even thought the light has higher screen Y value, it is in fact at the back but not above the character's head.
Any suggestion on how to handle this case?

I think this also occurs to side-scrolling game when character walk to the front of a light source and they get overlapped.





Btw, the SpriteDLight is quite slow when processing my background.
I think there are lot can be done to improve performance.
I notice that if i am correct, its now run with only 1 thread, not utilizing my CPU power.
I don't know how the algorithm works but i am guessing if some techniques like computing a scaled down version of the large image and use the result as hint to further compute the 1:1 normal map would help.
The preview tab is slow too. Is it not using h/w acceleration? e.g. OpenGL

I found the title of this thread somewhat confusing since side-scrolling perspectives are pretty popular for 2D games.
What kind of 2D perspective are you using?

I don't know which engine you are working with, but there should be some kind of way to tell the shader the Z-values of the characters/objects and the light source.
By doing this, you can disable the lighting for a character when it is in front of a light source.


I know the tool can be pretty slow when processing large images.
This is also what uses up most of my time: Experimenting with alternative algorithms and attempts to speed up things.
The bottleneck here is the shape volume algorithm that inflates the overall shape.
This algorithm isn't a good fit for multithreaded programming.
I have tried mip-mapping for the shape volume algorithm, but compared to the depth map algorithm that sucessfully uses a technique similar to mip-mapping, the results were pretty poor.

The preview window is also slow because it doesn't use hardware accelleration.
It was originally planned as a small gimmick to give users a chance to see a preview of what their art could look like with dynamic lighting in a game engine.
Using OpenGL for this (and probably also for the map generation) would of course be the most amazing thing I could imagine.
I found a good library that allows the use of OpenGL with the software Sprite DLight is being developed in, however it only works for Windows so far.