LÖVE

Hi,

Yes since there is no graphic card it hurts ! I test now Luven on my MacBook Air and I feel the slow.

Thanks a lot for your example ! Very inspiring, but I wonder, actually I can manage light powers dynamically and give the user the possibility to add flickering lights that Luven manage for them.

How could this be achievable with your example ? And I read about the fact that canvas switching was not so good for performance either. What could you tell me on that ?


Many many thanks for your insights.


Regards

ChicoGameDev wrote: ↑Sun Feb 24, 2019 8:42 am I can manage light powers dynamically and give the user the possibility to add flickering lights that Luven manage for them.

How could this be achievable with your example ?

It's just a quick sketch, designed to be simple and run fast. How you render the lights is up to you: static textures are fast and allow for hundreds of light sources, fully dynamic is slow and requires powerful hardware when using more than a few lights. You could cache different light source types in a Canvas, that way it only slows down when a light's parameters change (which you want to avoid).

Flickering can be achieved by modulating the color when drawing a light. Light power can be approximated with brightness modulation and scaling. Finding a compromise between quality and speed is key.

And I read about the fact that canvas switching was not so good for performance either.

A few switches are inevitable for any non-trivial rendering. It's still a lot faster and more flexible than your approach. By rendering to a lightmap, you have also decoupled lighting from the rest of the graphics, gaining flexibility and allowing the use of the shaders for other effects.

The biggest optimization for the canvas approach is a lower resolution canvas for the lightmap - it's probably rendered over the final display using filtering anyway, so you may get away with way lower resolutions than your actual display, saving huge amounts of bandwidth on the GPU.

Thanks grump,

I'll work on a new update and this will probably be better for everybody !

Nelvin wrote: ↑Sun Feb 24, 2019 9:27 am The biggest optimization for the canvas approach is a lower resolution canvas for the lightmap - it's probably rendered over the final display using filtering anyway, so you may get away with way lower resolutions than your actual display, saving huge amounts of bandwidth on the GPU.

You mean having a canvas of the size of the camera ?

Thanks for participating !


Regards

What I meant was a canvas of a size that's enough for your requirements, whatever that means depends on the game.

I've just added the changes to grumps sample to show what I mean.
Scaling the lightmaps width/height to 10% in this sample still does not look that bad and the number of pixels of the canvas was reduced by 99%, i.e. the update of the lightmap itself consumes very little bandwidth on the GPU.

Hi again,

That's great, thanks for sharing !

Have a nice day !


Regards

ChicoGameDev wrote: ↑Sat Feb 23, 2019 5:29 am

Yeahyay wrote: ↑Sat Feb 23, 2019 2:04 am Would you be able to implement cone lights as well?

Hum, it would be useful only on 2d side-scroller no ? Could you please elaborate a little bit ?

The light would have a controllable width with a max value essentially being a normal light. This would allow for directional lighting such as flash lights.

Hi,

Yeahyay wrote: ↑Sun Feb 24, 2019 3:31 pm The light would have a controllable width with a max value essentially being a normal light. This would allow for directional lighting such as flash lights.

Maybe later yeah! Please feel free to make an feature request in the repo : https://github.com/chicogamedev/Luven/issues (So I keep a trace )

I'm actually making great progress on optimization on the experimental branch, and it's my top priority for the moment.

Nelvin wrote: ↑Sun Feb 24, 2019 11:56 am Scaling the lightmaps width/height to 10% in this sample still does not look that bad and the number of pixels of the canvas was reduced by 99%, i.e. the update of the lightmap itself consumes very little bandwidth on the GPU.

I tried to implement your idea of scaling but with, on top of that, a camera that have already scaling. I'm a bit lost in all those differents coordinates system... Have you something to tell me to help me making order in all that ?

Thanks in advance.


Regards

ChicoGameDev wrote: ↑Sun Feb 24, 2019 7:28 pm

Nelvin wrote: ↑Sun Feb 24, 2019 11:56 am Scaling the lightmaps width/height to 10% in this sample still does not look that bad and the number of pixels of the canvas was reduced by 99%, i.e. the update of the lightmap itself consumes very little bandwidth on the GPU.

I tried to implement your idea of scaling but with, on top of that, a camera that have already scaling. I'm a bit lost in all those differents coordinates system... Have you something to tell me to help me making order in all that ?

Hm, not sure - I don't use camera alike systems alot or transform objects at all (my project is using Löve 0.10.2).

But in the end, what's required would be to transform any light on the screen to just the scaled down canvas so I guess what you'd have to do is to add the scaling to your camera transform and use the resulting transform to render all the lights to the canvas, then pop the transform (including the one used by the camera) and render the lightmap scaled to the full screen.

Hmmm since it has camera, what if don't render or process light when outside the camera boundaries?

Also, does it really have to integrate camera to lighting system? What if users use other full-featured camera?