Ahem. Not trying to sound obnoxious, but having this feature would help a lot. The topic had drifted out of immediate sight.

Then there's this too.

Edit: Nevermind lucid fixed everything, will be in the next CC build

Eh, we're still working on this I guess.

Obviously WIP

<img src="http://dl.dropbox.com/u/326175/111213ss1.png" border="0" />

<img src="http://dl.dropbox.com/u/326175/111214ss2.png" border="0" />

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

GPU KILLER

You can make use of Daiz's Flood Shooter, it has an infinitely scrolling background among other useful things. The trick is to use the texture offsetting feature to make an illusion of a moving background.

Edit: fixed bbcode

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.

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

Fallout 2, Deus Ex Human Revolution, Ocarina of Time, LURK (STALKER mod), Jet Set Radio, Half-Life 2

Construct doesn't render anything that's offscreen so you're only left with the memory footprint. If you're reusing a lot of sprites you might be able to work with huge layouts tho it's not guaranteed that every plugin can handle humongous dimensions, for example I remember the box2d physics having a limitation of 20000 by 20000 pixels per layout in the past, no idea if there's such a limit currently.

Here you go, Construct Classic r1.2 example, it uses predetermined sets and gives questions in a random order. The answer is the file name, files are png images, sets are defined in txt files. You'll have to figure out a sequential order yourself.

Mouse left click to reveal the answer, right click to show the quiz lists, middle click to hide said lists.

http://up.servut.us/31076

Well, you'd need quite a bit of Construct know-how to pull a stable large project.

This a thousand times. We're on our fourth rewrite of our most ambitious project so far and we've narrowed the scope every iteration but finally we're starting to get the results we want. Some plugins can cause crippling flaws that can end the development in an instant but as long as you separate your test builds from your actual project builds you're on a safe territory.

Experiment experiment experiment and make separate test builds, figure out a good development cycle and you'll be able to get the most out of Construct. You'll quickly notice that working with a team might become complicated because of the nature of the binary project files so I encourage you to get Dropbox or a proper piece of project management software to dodge that issue.

Edit: fixed a minor typo

You can try using the light object with a blank graphic, then create a sprite at the centre of the light object with the image you want (and decrease it's opacity).

The shadows should still cast (the light range isn't dictated by the graphic I think)

The light object's graphic itself is required to handle multi-level shadows on a single layer such as in this example:

<img src="http://dl.dropbox.com/u/326175/asdqwesd-light-2.jpg">

You can do single-level shadows in that exact way though, but that's not what we're looking at. Besides creating objects dynamically would still require differentiation through private values in our implementation.

Except for the little fact that shadow casters work with the Light objects.