Hey fundation2000,

The effect shown in the image looks to be a per-pixel light ray shader.

If you have some familiarity with shaders, you can actually make your own using the Construct 2 SDK. Construct 2 shaders are coded in GLSL.

I've been making shaders off and on for a while, so If I end up building that shader myself at some point, I'll let you know.

You can also try creating a very similar effect with C2's built in lighting system, but I suspect that it won't have the same per-pixel fidelity seen in the image above. That is because the C2 system casts shadows based on collision polygons instead of individual pixels.

That said, using C2's built in lighting, you could create a lighting system on it's own white layer, such that you're casting black shadows onto a white background. You could then use effects to invert the layer colors, so you're now casting white shadows onto a black background, and finally "Screen" blend that into the final scene, and adjust the layer opacity to make it more subtle. Screen blending will make the black area appear transparent, and the white rays will act like an illuminated haze.

One approach is to use two images, one for the faint Shield (full-circle 360° arc), and one for the bright Impact arc area on the Shield (say about a 90° arc of the circle).

Making the images

The key is that you create both images, the Shield and the Impact arc, so that they are the same size, and both with the hotspot at the center of the image.

The easiest way to do this is to start by making both the Shield and the Impact image full circles. Each image should have its hotspot centered in the circle. Then for the Impact image, which is just a bright circle so far, we soft erase away everything but the right-most quarter of the circle, so that the result is a mostly blank image with a hotspot in the middle, and a bright quarter circle arc on the right edge of the image.

Behaviors & Events

Now if you snap both the Shield sprite and the Impact sprite to your ship, the Impact arc should line up perfectly with the right edge of the Shield bubble, as if the ship had been hit from the right. If you click the Impact sprite and grab the rotation handle, rotating the image should make the Impact arc slide around the edge of the Shield.

Now to make it stick to the Shield bubble as the ship moves, and also fade out over time.

For the Impact image, add the behaviors "Pin" and "Fade".

In the event sheet create the following setup:

When a projectile hits the Shield bubble:

* Have the Shield spawn a new object, the Impact sprite. (The Impact sprite should automatically be centered on the Shield.)

* Set the Impact sprite's angle towards an object, the projectile. (If you need to destroy the projectile, do it somewhere after this step.)

* Pin the Impact sprite to the Shield. (This way when the ship moves, it won't leave the Impact sprite behind.)

The fade will run automatically, and destroy the Impact sprite after fading out.

Final optimization

Finally, if you have everything working the way you want, you can crop the Impact sprite image using the crop button at the top of the image editor. This will cut the image size down to just the actually image area, and leave the hotspot in the correct relative position. Just a minor optimization.

Hope that helps out.

The replace feature, (as far as I know), has loosely two modes.

If there's only one object available to replace:

Pops up an object browser, and whatever you choose will replace the original object.

If there are two or more objects that can be replaced:

Pops up an object browser showing the objects that can be replaced, and whatever you choose will be designated as the object type to be replaced.

Then you will be presented with another object browser, and whatever you choose will replace the object designated on the previous step.

Hey Ashley,

Thanks for the reply. I figured that might be the case. It makes sense that it would be set up to work just on the 100% parallax layers, as that's going to be pretty much all the practical cases.

As for setting all layers to 50% parallax, I agree that that would be pointless, I was just using it as a simple example of paired layers with matching parallax.

I actually happened to be faced with a special case that is related to that example, but a little more complicated, in which I would have several layers that would have variable parallax rates, but the parallax rates would always all be the same value across all the layers, or at least all the layers for which collision detection matters.

Reason being, I figured out a way to scroll layers completely independently of each other, which I've been interested in for a while, but the method involves keeping the scroll coordinates fixed and adjusting the parallax scales of each layer instead. The parallax scales for each layer become the individual scroll coordinates for that layer. It works, but I was worried that the weird parallax values would break the collision optimization, and it sounds like they would. In this case the game world layers would all have the same parallax scales, and would stay lined up, but they wouldn't always be set to 100%.

The main reason I've been interested in scrolling layers independently is that I'd like to be able to have a "game" world that scrolls normally, and an overlay-able "menu" system that can scroll from page-to-page independently of the game world. Currently there's no way that I know of to decouple the scrolling of the menu layers from the scrolling of the game world layers.

I'm aware that it's technically possible to make a system that kind of approximates the en-mass coordinate shifting that layers can do, but it seems a bit tricky to make it play well across multiple object types, and with anything else that effects coordinates, like behaviors, or for that matter Particle object particles, which don't move with the source object.

I've seen some other threads talking about independently scrolling layers, and it sounds like it's not currently planned. For what it's worth, I think it would be a cool feature, but I can also definitely understand why it might not be a priority.

In any case, thanks again for the info.

Thanks for the reply jobel,

Yeah, I don't plan to have misaligned layers with collisions between them, I agree that could get ugly.

What I mean is if I have, for instance, just one layer, and it's parallax is set to 50%, will that disable optimized collision detection for everything on that layer?

And the slightly more complex scenario is, if I have two layers both set to 50% parallax, so both layers are still always in alignment at all times, will the 50% setting disable optimized collision detection for everything on both layers?

I'm just not quite sure what situations cause C2 to forgo optimized collision detection. I think it might only use the optimization for layers at 100% parallax, and will brute-force anything else. That might kind of make sense, as there may be only one data structure handling spatial binning, instead of one data structure for each parallax configuration found in the layout.

I gather that C2 does some kind of spatial binning based on the project's window dimensions to optimize collision detection.

If I set all layers to use a 50% X and Y parallax rate, all layers will still always be in alignment, but will this disable optimized collision detection across all layers?

That is, will layers use optimized collision detection between each other if they line up, or only if they are at exactly 100% X and Y parallax rate?

Hey again tunepunk,

As blackhornet and Magistross mentioned, recursion is likely not what you want for this situation.

I gave my example in terms of the opacity scenario you mentioned only for illustrative purposes, I wouldn't recommend actually using recursion to handle opacity.

My fault, I misunderstood.

I understood you were interested in having a function act in a self-contained manner over time, but I didn't realize you were interested specifically in controlling opacity.

As Magistross mentions, with too much recursion you can run out of call stack space. This is what I meant in my first post when I mentioned the "Maximum call stack size exceeded" error.

Triggering smooth transitions

To trigger a smooth change over time, you can use an extra instance variable to store the desired target value, (such as "100" for opacity), and then every tick, move the actual opacity value towards that target value by an increment, (such as 2).

So if you have a sprite that starts with 0 opacity, and the target is set to 0 as well, the sprite stays at 0 opacity.

If you then set the target value to 100, the sprite's opacity will start counting up to 100, at a rate of 2 per tick.

As Blackhornet mentioned you can use families to make it easier to get this behavior to work across a variety of similar objects.

Layers, Sprites, & Families

A single family will only work on a set of objects that all belong to the same plugin type, such as Sprite.

To get a family that affects sprites to affect layers, you can create a sprite object called "layerTool" (or whatever you want) and put a layerTool object on each layer you wish to control. Set the "Visibility" of the layerTool objects to 0 and then create events for them that set their corresponding layers to match their opacity every tick.

Now you should be able to control layer opacity with the same family events that control sprite opacity.

If you're using the physics behavior, you can apply a torque to the arrow to make it straighten out towards the direction it's moving.

This torque should be greater the faster the arrow is moving. So, if it's sitting on the ground, no torque. If it's flying fast, lots of torque.

You can use the "Apply torque towards angle" action to get this effect.

It would look something like the following:

Apply torque towards angle:

• Torque: 0.001 * arrow_speed
• Angle: arrow_movement_angle

(The "0.001" just scales the amount of torque used to correct the arrow angle. You can experiment with it.)

Of course there are no "arrow_speed" or "arrow_movement_angle" values by those names, so you'll need to calculate that information, but fortunately that's not too hard.

We can get the speed by finding the length of the Physics behavior's velocity vector. We get the angle by finding the angle of the velocity vector.

Apply torque towards angle:

• Torque: 0.001 * distance( 0 , 0 , arrow.Physics.VelocityX , arrow.Physics.VelocityY )
• Angle: angle( 0 , 0 , arrow.Physics.VelocityX , arrow.Physics.VelocityY )

This should make arrows fly head first, but will still allow them to topple end-over-end if they bounce off of something and lose most of their speed.

This is not a perfect simulation of arrow flight, as it doesn't account for linear off-axis forces resulting from the separate center of gravity, and center of pressure, but for it's simplicity it is pretty close.

I actually just uploaded an update of a game I made that uses this exact method for handling arrow flight.

ArcherOpteryx: http://gamejolt.com/games/archeropteryx/45519

(note: Firefox runs it a little slow, but every other browser, and the desktop version run fine.)

Hope that helps out <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Thanks for the replies all.

I thought that might be the case.

I have a possible, limited case solution, but I haven't tried it yet.

I might be able to make a shader that will multi-sample a large image, and give roughly the same effect as C2's native multi-sampling.

The drawbacks are that the image would have to fit in frame at it's large size as any part of it off screen can't be sampled I believe. That means that it's size orientation and position would all need to be handled by shader. That said, it could conceivably give multi-sampled results in a "point sampled" project, so it could be handy if it works out the way I think it might.

Is there a way to change between Point & Linear sampling at runtime?

Or is there a way to start some layouts in Point mode and others in linear mode?

Just curious if there's any way to change between the two modes in a single project.

One option, though it can get tricky, is to have the function conditionally call itself after a short delay.

On "fade_in":

--- IF opacity < 100:

--- --- Add 1 to opacity.

--- --- Wait 0.5 seconds.

--- --- Call function "fade_in"

When the function is first called, it will do nothing if the opacity is 100, but if opacity is less than 100, it will increase the opacity by 1, and queue itself to be called again in half a second.

This situation, where a function calls itself, is called a "recursive" function call, or just "recursion".

This can be a really handy way of doing things, but just as you need to be careful with loops, to avoid infinite loop bugs, you also need to be careful with recursive function calls, to avoid infinite recursion. If you get an infinite recursion problem, you'll usually get an error message mentioning something along the lines of "Maximum call stack size exceeded".

This isn't the only way to get functions to act repeatedly over time, but it is one that can be pretty useful in the right situations.

Hope that helps out

Hey glitchyghost,

I think what may be happening is that the bullets are always being set to spread relative to the angle "0", but specifically the angle "0" relative to the world, instead of relative to the player.

Angle 0 always points to the right.

0 = Right

90 = Down

180 = Left

270 = Up

360 = Right

The second issue is that using the Mirror action on a sprite will change the orientation of it's image, but if I recall correctly, it won't change the sprite object's actual angle.

So you could try splitting the spread event into two events.

If player is NOT Mirrored: random( -playerProjectile.spreadFactor , playerProjectile.spreadfactor )

If player is Mirrored: 180 + random( -playerProjectile.spreadFactor , playerProjectile.spreadfactor )

When the player is Mirrored, you can add 180 to the angle so the bullets fire to the left, plus or minus a random spread factor.

Hope that helps out.