itch.io

I'm happy to help, so no worries.  Anyone who purchases one of my assets should certainly get all the support I can provide.

Keep things like you have it, but also on your building, put the following in the create:

shadow_depth = y / room_height;

Sorry if this adds more confusion, but there are two places where depth plays a role and it is on purpose to give designers the option of how light and objects/shadows interact separate from the regular old depth sort.  

The rest is just for information purposes:

The normal depth value which you are setting fine and then using update_depth() after is what sorts the normal and material maps during pre-composition.  Then the shadow_depth is where a lights depth is compared to the current pixel's shadow depth.  This value is stored in the material map when drawn to the surface.

Hopefully this can help illustrate things better on how Eclipse renders everything.  Here is a deferred renderer I wrote in WebGL (warning large texture loading): https://badwrongg.github.io/webgl-deferred-pbr/

On the left you can see those four areas that are each part of the G-buffer (graphics buffer).  From top to bottom they are color, normal, material, and position.  In Eclipse everything is just like this, minus the position buffer because we can cheat in 2D with just a matrix during lighting.  So, when you set the shadow_depth its writing to one of those buffers and the light compares its own depth to that.

So, Eclipse is a 3D PBR renderer, but from a 2D orthographic perspective.  The extra parts that seem complicated are there to make it work well with GameMaker's default draw calls.  In other assets for GM that try to do similar things it is actually far more complicated and you have to deal with your own vertex buffers and other things for every draw call.  Once you get the hang of the shadow, light, and depth stuff the rest shouldn't be a big problem.

Lastly, for the texture packer asset you could go and get some normal maps from just any PBR texture and use them for your sprites.  On the tool you set the clip sprite which should be the same as your regular character sprite.  This will clip the normal map to fit exactly to your sprite.  Then in GM on your object just set the normal_map to point to the normal map that matches the current sprite.  What I do is create a struct that just stores all three and adds them by having a standard naming convention.  So, if the base sprite is "spr_player_run" then it simply grabs "spr_player_run_m" for the material and "spr_player_run_n" for the normal automatically.  Cuts down a ton of extra work.