If that asset uses a shader then it would have to be completely combined with many of the eclipse shaders. They use an extra transform that their special shader uses.
The only simple method would be to draw it first to a surface then draw it normally from that surface with the eclipse stuff. That also means getting the current shader, current MRT surfaces, etc. Then after drawing it, restore those.
I've been tinkering with the system all day. I've fixed the black box and I figured I would make this post to just let anyone know if they want to use this add_on or draw_sprite_pos. So, what I've done is create a new prefab le_game_pos, which is just like le_game, except that it draws differently in the order. All it has for drawing is a draw function which uses draw_sprite_pos_fixed() (the asset I linked above).
Then, in light_engine, on the pre-composite (MRT) event (and pre-composite event), and AFTER it draws normal surface/material surface for other objects (e.g., le_game), I have it draw the normals and material for le_game_pos to each surface (surface_normal / surface_material) WITHOUT the shaders. For example, the normal code looks like:
if (!surface_exists(surface_normal)) surface_normal = surface_create(_s_width, _s_height);
surface_set_target(surface_normal);
with (__le_game_pos){ //draw script here}
surface_reset_target()
...do same for material map.
Now, since I'm not putting shaders in, the sprites may not getting the full shaders, but the lighting still applies to some extent and it does not look bad.
Sounds, good and thanks for sharing.
Note that I use the depth buffer to sort the depth of everything when drawing the normal and material maps. If not using the depth buffer things will simply draw in order, which may be ok depending on your own game.
One reason this type of drawing isn't supported directly by Eclipse is because it would be far simpler to just do it in full 3D. For normal map to display correctly after applying a transform such as draw_sprite_pos_fixed() you need to use tangent space to create a TBN matrix. The efficient way to use that matrix is to transform the actual light positions by the transpose. Since Eclipse is more or less a 2D lighting solution (using some 3D maths) that entire process is skipped because the normal maps all sit on a plane facing upward toward the viewpoint. Its cheaper and works well with how default GM drawing works.
So, doing full 3D transformed sprites would really be easier in a normal 3D lighting solution.
Some other things to note, when drawing normal maps I use the alpha channel to encode the emissive value of that pixel. So, you would actually want to draw in 0 alpha if there would be no emissive. That can be done for the entire normal map sprite, or per-pixel in the normal map itself.
That makes a lot of sense. I was just trying to add some cool top down parallax effects to add more of a 3d feel in addition to the 3d lighting. It's very impressive what this light system can do for 2d graphics. I did not want to touch 3D in GML, so I'll pass on figuring any of that out, ha!
"Some other things to note, when drawing normal maps I use the alpha channel to encode the emissive value of that pixel. So, you would actually want to draw in 0 alpha if there would be no emissive. That can be done for the entire normal map sprite, or per-pixel in the normal map itself."
I was just using the alpha setup from the other object normal draw events, which uses LE_NORMAL_ANGLE for the draw events in the events I listed. I could always have it send the emissive variable instead.
