GMLscripts.com

Discuss and collaborate on GML scripts
Invert

You are not logged in.

#81 2011-06-11 02:07:06

xot
Administrator
Registered: 2007-08-18
Posts: 1,239

Re: Yet Another Idiotic Light and Shadow Engine

Like I said, the entire point of the topic was to get others to try it.

I would reconsider any strategy that requires the creation and deletion of surfaces every step. Beyond any sort of glitching, it's unnecessarily slow. Why can't you just reuse your surface each step?

Some of the drawing functions change drawing settings. For instance, drawing a sprite will disable texture repeating. Targeting a surface will probably change the screen projection. You may be experiencing similar issues. You may have to ensure your drawing settings are reset correctly after using certain functions. You certainly should not be trying to manipulate surfaces during the draw event.

I have to wonder how querying the dimensions of non-existent surfaces could ever be useful. I can't really fault Game Maker for that "issue". laugh


Abusing forum power since 1986.

Offline

#82 2011-06-12 01:43:57

Rani_sputnik
Member
Registered: 2011-04-24
Posts: 18

Re: Yet Another Idiotic Light and Shadow Engine

Lmao okay to defend my seemingly idiotic coding practises just for a second... biggrin

Creating/deleting in each step - If I'm writing a script I like to make it as self contained as possible, therefore it's nice just to set up a temp surface, it's no problem for this situation where I'm writing the engine for my own use, but it could hit me again in the future, I'll come nagging to you xot if it does tongue tehe

I have to wonder how querying the dimensions of non-existent surfaces could ever useful. I can't really fault Game Maker for that "issue".

Okay I know how it looks *hands in air in protest* but at the time I didn't know the surface was non-existent, probably should've mentioned that...

Some of the drawing functions change drawing settings. For instance, drawing a sprite will disable texture repeating. Targeting a surface will probably change the screen projection. You maybe experiencing similar issues. You may have to ensure your drawing settings are reset correctly after using certain functions. You certainly should not be trying to manipulate surfaces during the draw event.

Oooh more stuff I didn't know. The surfaces/draw event thing I was aware of but I had no idea drawing spites changed texture repeating. Interesting... I am in awe of how much you know about Gamemaker, just wow. I found something out though! I don't know if this is already common knowledge or not but I was having some issues with flickering around the shadows, turned out it was rounding error from mouse_x and mouse_y, it seems that using window_mouse_get_x is way more accurate than mouse_x, I was proud of myself for discovering that so can we all pretend that nobody else knew? Haha.

On topic - Engine is going okay, I have stuff working fine, except for when I try to draw a sprite for the lighting, some kind of scaling issue. I might try get something uploaded tonight for anyone who's interested.

Cheers!

EDIT: Not at all proud of my work yet, it's horribly un-optimised, but have at it. I'm not gonna be able to work on it til after exams anyways...

Last edited by Rani_sputnik (2011-06-13 03:53:53)

Offline

#83 2011-06-18 02:56:51

xot
Administrator
Registered: 2007-08-18
Posts: 1,239

Re: Yet Another Idiotic Light and Shadow Engine

Oh, you uploaded something. I hadn't noticed that.

Looking good so far. Nice and simple and easy to understand.

I look forward to seeing any future versions. Keep it up!


Abusing forum power since 1986.

Offline

#84 2012-01-07 15:10:16

Daniel
Member
Registered: 2011-05-04
Posts: 25

Re: Yet Another Idiotic Light and Shadow Engine

Looks like you inspired someone.

Offline

#85 2012-01-09 15:44:38

xot
Administrator
Registered: 2007-08-18
Posts: 1,239

Re: Yet Another Idiotic Light and Shadow Engine

Cool! I haven't looked at the demo yet, but from the discussion it sounds like a similar technique must be being used. Curious to see if any non-block-based geometry is used.

If I did indeed inspire it, that's very gratifying.


Abusing forum power since 1986.

Offline

#86 2012-01-10 13:40:54

xot
Administrator
Registered: 2007-08-18
Posts: 1,239

Re: Yet Another Idiotic Light and Shadow Engine

I checked it out -- thoroughly. Very amusing.

Clearly my work was the starting point. The most interesting bits have been completely rewritten but some of the boring bits are still in there. Some sort of acknowledgment should have been given. I guess "copyright (c) 2009, John Leffingwell" doesn't have much meaning if the copying isn't obvious. Not really bothered, but it does limit my gratification.


Abusing forum power since 1986.

Offline

#87 2012-01-17 23:03:26

Rani_sputnik
Member
Registered: 2011-04-24
Posts: 18

Re: Yet Another Idiotic Light and Shadow Engine

If it helps, your reply had me in fits. About as subtle as a brick through a window biggrin And fair enough too.

Offline

#88 2015-11-18 23:26:38

Juju
Member
Registered: 2015-10-01
Posts: 45

Re: Yet Another Idiotic Light and Shadow Engine

Continuing the theme of "Juju updates the lighting engines", here's a 2D implementation of the general approach. Uses a couple of vertex buffers, because they're trendy, one screen-space surface and a surface for every light. I'm not overjoyed with the VRAM usage as a result but I am happy with the performance.

There are a few areas that could be worked on. Firstly, my method for updating dynamic shadow casters seems a bit gross. Secondly, the blend mode(s) I'm using probably aren't the most useful for bright n' cheery games and I do wonder if my compositing step is the best way to do it (or if it's even necessary). Thirdly, you could totally integrate normal/bump mapping into this though that's, technically, a bit beyond me.

Last edited by Juju (2015-11-19 12:23:22)

Offline

#89 2015-11-19 22:49:15

xot
Administrator
Registered: 2007-08-18
Posts: 1,239

Re: Yet Another Idiotic Light and Shadow Engine

Nicely done. I've not look too deeply into your system yet but the speed seems pretty good.

You shouldn't need more than one work surface for any number of lights if you use a system that iterates through the lights and accumulates the lighting (with additive blending) onto a final lighting surface.

Is there a special reason for each light having its own surface that I'm missing?

Again, as in the other topic, it has been years since I worked on this stuff (and I had to do some really weird, obsolete tricks due to GM7 limitations) so my memory and understanding could easily be off.


Abusing forum power since 1986.

Offline

#90 2015-11-20 09:28:23

Juju
Member
Registered: 2015-10-01
Posts: 45

Re: Yet Another Idiotic Light and Shadow Engine

At the moment, I'm plopping down the light sprite onto a surface, then rendering the shadows (d3d_projection and 2x vertex submit for static-frozen + dynamic), then transferring *that* onto another (screen-sized) surface. I do all the lights first then do the compositing afterwards because surface_set_target() and surface_reset_target() are pretty expensive operations, at least for my GPU.

I couldn't think of a way to draw a light and, within the same draw call/operation, occlude using the casting geometry. To be honest, I was working off someone's implementation (Joseph?) rather than your original work because I ain't got time to wade through the old-school hacks! If there's a trick that you're using that he wasn't, I will certainly have missed it too. I'm using subtractive blend modes which may further complicate things.

I prefer this system to NAILS, to be honest. It's way faster and we don't have to rely on janky shaders to perform casting. Another extension of the system would be to smooth the geometry generation with a sprite-to-polygon converter. I swear I used to have one of those lying around but I can't find it any more...

Last edited by Juju (2015-11-20 09:30:39)

Offline

#91 2015-11-22 22:15:10

xot
Administrator
Registered: 2007-08-18
Posts: 1,239

Re: Yet Another Idiotic Light and Shadow Engine

surface_set_target() and surface_reset_target() are pretty expensive

Hmmm. I guess you can save about half of the surface_set/reset() calls doing it that way. If it's getting to the point where those calls are causing slowdown, I would image you would be gobbling enormous amounts of texture memory to do it the other way. Not really worked out the trade-off math but it seems decadent.

I'm using subtractive blend modes

The reason I suggest additive blending because colored light mixing is an additive process (alternatively, colored pigment is subtractive). Clear your accumulator surface to black, render each light to a second black surface, render the shadows on top of that in black, add each masked light surface to the accumulator  (bm_one, bm_one). At the end, multiply your scene by the accumulated light (bm_zero, bm_src_color).

sprite-to-polygon converter

A long time ago, EricDB made a sprite edge tracing thing that could be extended to make a sprite-to-polygon converter. I have a mirror of it here.

http://host-a.net/u/xot/sprite_outline.gmk

http://gmc.yoyogames.com/index.php?showtopic=330800


Abusing forum power since 1986.

Offline

#92 2015-11-23 06:53:34

Juju
Member
Registered: 2015-10-01
Posts: 45

Re: Yet Another Idiotic Light and Shadow Engine

I remember helping out a guy called marbs/Sam Hooke with a physics platformer years ago that used this exact script. Thanks xot.

Offline

Board footer

Powered by FluxBB