[solved] Custom shape shadow caster problem

It seems that the custom shadow caster shapes don't display correctly in Construct Classic r1.2. The caster seems to treat the bounds of the custom shape incorrectly and leaves the entire outer bounds 'unused' leaving a 'hole' with shape of the object in the shadow. I haven't tried this in any of the previous Construct Classic versions but seeing how the shadow caster behavior has seen little change in any of the recent releases I'd expect that the problem occurs in many of those versions too.

Here's a cap displaying the unwanted results: Construct Classic r1.2 cap

Here's two examples in a more complex implementation. On the left you'll see the actual render and on the right a sketch of how the shadow was expected to be rendered.

<img src="http://dl.dropbox.com/u/326175/customshad1.PNG" border="0">

<img src="http://dl.dropbox.com/u/326175/customshad2.PNG" border="0">

Using the bounding box as the caster shape does not come into question with the said implementation as we'd have to create tricky workarounds involving invisible collision boxes to prevent ugly artifacts due to the nature of the sprites. That way we'd also lose, duh, the custom shape of the shadow we wanted to begin with.

Sorry I didn't make a report to the tracker, Sourceforge is giving me a http error 500. :(

I'd also like to point out that this problem that prevents setting Light-object's height and width in the runtime has yet to be solved and it's hindering our development of the lighting code.

Edit: fixed the image urls and linkified the cap url

Edit 2: A solution presented below

I find that cap really odd, as I was able to do this without any problems.

A little pinpointing and I came up with a solution presented in this CC r1.2 cap

In this example I switched the places of the opposing corners resulting in a seemingly identical shadow caster shape.

The end result of the render is identical to one using bounding box thus solving the problem. Could this simply be a result of using a counterclockwise "drawing order" of the shadow caster shape which creates an inside out caster mask?

All in all it was a very logical problem with a, duh, very logical solution. Hardly a bug but seeing how easily it's run into it might be worth looking at at some point.