GMLscripts.com

*cough* sorry if it took a while, but I rewrote a few parts hoping to improve the overall performance but... well, somehow I failed, or reached the limit.
That is: I now make only 1 draw per shadowable object, get a global occlusion mask, and every light source refers to it. Added the required translations/transforms to make everything run with view support and with the possibility to deactivate them to improve performance. In the recent build of Adon I also made the light accomodate their update frequency to mantain an acceptable frame rate.

*BUT*

somehow when I set the "scale" factor to a value less than 1 (always trying to keep the texture size a power of 2. So I'm talking about scale values of 0.5, 0.25, 0.125 and so on with initial light Radius of 256-512), the performance drops.
That's... weird, but probably the d3d_set_scale is less efficient than I thought. Or probably there's something in the math that I'm missing. Probably something like something that scales in an inverse proportion (thus if I set a scale resolution factor of 0.5 I'm actually drawing something 2 times bigger, or 4 times less efficiently since we're in 2D).

Even in your example it's noticeable how the cost in drawing many scaled objects to the shadow map severely decreases the framerate.
That is, using a 0.1 scale factor and 31 objects the frame rate was about 240, that dropped to 100 when I increased the number to 337 shadowcasters.
On the other side, using a scale factor of 1, the frame rate is obviously lower, but even adding >500 shadowcasters it was still about 53-54 fps, it only lost a few frames per second (1-3) in respect of the same test with only 31 objects.

My question is: is it normal? Is the cost of sprite scaling so high, or is it because of the algorithm?
Now that I'm writing... maybe I can just use a 1:1 scaled occlusion mask, resize it once, and use it in the local and scaled maps of each spotlight... I have to try it.

Yes, I know, I could use/write a DLL but... I'm trying to do everything without it for now. It's part of the fun, and somehow using something external makes it feel less... genuine

I'm glad it did!

Let me know if I can be of help with some of the code I wrote (taking in account views, common mask drawing), I'll be deeply grateful if you could manage to improve the performance of the example while still keeping some flexibility.
For what I saw in your code, well, it's hard to improve it, it's really well written, I could just apply a few optimization to accomodate the way GML works but... I'll definitely lose something in readability

Again, I'm glad you enjoyed it, I've been criticized for putting too much developer commentary... but I think it adds an extra value, it's not a trailer afterall!

Btw: I solved the surface problem. I really don't know what it was, but rewriting almost everything from scratch solved the issue
About the blend modes: I added a small filter to restore some of the contrast, but it requires an entire redraw of the scene at the moment.
It also gives a nice incandescent look to the brightest parts
Here are a few pics of it, respectively with the filter OFF and ON. The "5 fps" was forced to take the screenshots

EDIT: duh, seems like the spoiler tag is not working, I'm putting a link instead of directly embedding the pics.

I have to say, your solution is brilliant! ...and sorry about resurrecting a 3 years old post, it's a solution with no time
I'm trying to revamp your code as a full featured lightning system but I stumbled upon a problem: since I'm blending the colored light with bm_add, there are visible seams of the transformation solid (that is, radial and concentrical lines). Simply put, the polygons overlap, and they form brightened points.
Since I'm using a few detailed backgrounds in my project it's not a big problem, with multiple light sources it could be easily considered "light noise":
http://img189.imageshack.us/img189/9467 … gine02.jpg
But on a solid dark background it is:
http://img833.imageshack.us/img833/4803 … gine03.jpg

I tried every possible blending combination, but the seams persist in the very few combinations that gave the desired result.
So I thought it was probably a good idea to have a third surface where to render the opaque (and seamless) final light casting, and then blend it again in bm_add or another similar blend.

The fact is, for some reason I'm not getting the rendered solid on that surface, but for some strange reason only the non-transformed texture that you called "surf".

In the shadows_build script you wrote I appended this code (called in the EndStep Event):

Expand        surface_set_target(surfFinal);
        d3d_transform_stack_push();
        d3d_transform_add_scaling(w,h,1);
        
        texture_set_repeat(true);
        draw_set_color(c_white);
        draw_set_blend_mode_ext(bm_dest_color,bm_zero);
        
        d3d_model_draw(modelR2P,0,0,0,surface_get_texture(surf));
        d3d_transform_stack_pop();
        surface_reset_target();

But when I try to draw surfFinal, I always get a result identical to surf.

Since I'm not very practical with 3D transformations in GameMaker, am I missing something?
I'm using GameMaker Standard v8.1.141.
Are you still working with this code, or have an improved version of it? (I think I'll probably smudge the shadow borders a bit since with using low_res light maps creates a few artifacts during the transformation process)

Thanks for your time!

EDIT: my fault! For some reason I was fiddling with the numbers to see if I could get some neat effect... and I left a y1 = (j + 1.01) / argument1; in the model_polar_rect script. The original value was 1, not 1.01.

Still, I don't get why I can't render on a surface though