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.

Hey, Sup with that?

Thanks for the reply. Unfortunately an effect isn't quite what I'm looking for, as effect's to my knowledge, can only affect imagery that is rendered within the screen boundary.

On an unrelated note, there's something kind of surreal about having "Sup with that?" recommend "Somebody".

I'm about to reprogram all the scrolling in my game to allow for arbitrary independent scrolling of individual layers.

The workaround I came up with is kind of ugly and unintuitive to work with, so before I start I figured I'd ask if there's any built in C2 feature, or plugin, that already does this, that I might be overlooking.

I've looked around the system object and manual for a while now, and to my knowledge the only layer parallax related thing you can adjust at runtime is the layer's parallax percentage.

The workaround I came up with is to set the global scroll position to (-100, -100), never move it, and then I can set the scroll position of individual layers independently by setting their scroll percentage to the number of pixels I want to offset them by X and Y.

It's ugly, and it makes the code harder to understand at a glance, but it does work. From there I can recreate the basic global scrolling behavior C2 normally does, but with the benefit that, for the few layers I need to scroll in slightly more specialized ways, I can use any formula or logic I want.

Any suggestions are welcome.

Hey Radulepy,

If I understand, it sounds like you might be interested in how to get 8 direction movement, but properly transformed for an isometric perspective; such that if a player holds the left and down keys, their character will walk at an appropriately shallow diagonal, rather than a perfect 45 degree diagonal.

Model world / Display world

One approach is to have two worlds.

A "Model" world, which is invisible to the player.

And a "Display" world, which is what the player sees.

(Prepare to see those colors a lot. Sorry in advance...)

The key is that the Model world is a flat 2D straight-top-down representation of your game world. And the Display world is the isometric view of your game world.

We build the 2D Model world first.

We then make a "renderer" (using events) which looks at all the objects in the Model world, and creates their Display world versions, positioning them to create an isometric view.

All of the game logic, (character movement, collisions, projectiles), will be handled in the Model world where movement and collisions are simple, as everything can be done with the standard 2D features already built in to Construct 2.

For each 2D object in the Model world, our renderer will create an isometric version, and use some math to convert its 2D world coords to isometric world coords.

Example

As a practical example, let's say there's a playable character with the "8 Direction" Behavior in our Model world. When the player presses the Move-Right key for one second, and then the Move-Down key for one second, the Model character moves rightward in the Model world, from pixel-coord (0,0) to (100,0), and then moves downwards to (100,100).

Remember though, the Model world is invisible to the player.

So the renderer takes that Model character and makes an isometric Display version of the character move rightward from pixel-coord (0,0) to (100,0), and then downward to (100,50).

Notice that the Model character is at (100,100) but the isometric character is at (100,50). Converting from 2D Model coords to isometric Display coords is one of the jobs the renderer will do.

In this case we are just dividing the Y coord by 2, and leaving the X coord alone.

Essentially, to create the Display world, we are just squishing the Y axis of the Model world to half it's normal height.

Thus, in the Model world, a 400 x 400 pixel patch of dirt in a field of grass, would be represented as a 400 x 200 pixel patch in the Display world.

So far so good, but what we just created is sometimes called an "Oblique" perspective, which is not quite the same as the more traditional "isometric" perspective.

Oblique vs Isometric

Imagine a camera pointing straight down at a treasure map, on the map the compass rose's North to South axis is oriented vertically in the camera view.

If we lower the camera's elevation angle from 90 degrees (straight down), to 30 degrees (shallow downward diagonal), we get the oblique view described above.

In this oblique perspective, a cube shaped building would have its southern edge (not a corner) closest to the camera.

To get a traditional isometric projection, we'd also then need to rotate the map 45 degrees, so that the camera is looking diagonally across the compass rose, such that (for example) the rose's North-West to South-East axis is oriented vertically in the camera view.

In this isometric perspective, a cube shaped building would have its south-eastern corner closest to the camera.

The math for converting from the Model world's 2D coords to the Display world's isometric coords is a bit trickier than the simpler oblique view, but still just some trigonometry.

Edit view (Model) vs Runtime view (Display)

So one problem you may have noticed is that with this Model-world/Display-world approach, when building your levels, you'll be editing the Model world, not the Display world.

Editing the Model world means arranging a bunch of 2D placeholder rectangles in the Construct layout editor, knowing that the "renderer" will turn it into a nice isometric view that you can't see while editing.

There is a workaround though, which can allow you to build your world directly using the isometric assets. Essentially, you would have to make a reverse-renderer, which will take an the isometric assets and their coordinates, and convert that to a Model world. After that the game would run normally off the Model.

If you're familiar with the concept of a Model-View-Controller, that's loosely what you would have with this Display-to-Model-to-Display setup.

Depth sorting

Finally, there's the issue of making sure things in the Display world are depth sorted correctly, so that a distant object doesn't overlap a nearer object.

I recently talked about this in another post on isometric depth sorting.

Again, this is not the only way to handle isometric worlds (and movement in them), but it's an approach I think might work well with Construct 2 specifically.

I hope that helps out.

Hey oceldot,

I haven't worked with the path finding system very much, but one thing that might work is forcing the path to recalculate when you change posture.

This way, if you stand up, the solid will reappear, the path finder will be forced to recalculate a path to the last destination given, and the path will no longer be valid.

If you try this method out, for obvious reasons, it's important to make sure that the path is getting recalculated only after the solid reappears. Behaviors and event sheets can sometimes execute their effects in an order you aren't expecting. IF this becomes an issue, you can place the path recalculation action after a wait( 0 ) action, to delay the recalculation to the end of the frame.

Hey otaconnor,

I'm not sure if there's an elegant solution to this issue with the default Physics behavior, but there's a 3rd party physics plugin, based on the Chipmunk physics engine, that specifically has the ability to separate objects into different "collision layers" which won't interact with each other.

You can find it at the post linked below.

Hey phoenix71717,

Just tried it, and no, it looks like collisions still work like they always do even if the layer is set to invisible.

I tried both setting the layer to be invisible from the property panel, as well as setting the layer to be invisible via events, and neither seems to affect collisions.

No problem

I took a look at Cartoon Wars 2, and from what I saw the Platform behavior with collision and overlap checks should work just fine.

Though you could also try using the "Is overlapping at offset" condition. It will temporarily move your object to an offset from it's current position and test to see if it's overlapping something there, then move the object back to it's original position before any other events run. This is a nice cheep way to avoid having to make invisible detector objects. Though invisible detector objects can also be handy.

The "Is overlapping at offset" condition could allow units with ranged attacks to sense when an enemy is close enough to hit with said ranged attack.

e.g. If ArcherUnit is overlapping EnemyUnit at offset X +200, then hold position and start firing arrows.

This would make the ArcherUnit attack an enemy when they got within a 200 pixel range.

Hey ErekT,

One way is to, at the start of the layout, get the difference between NWjs's OUTER window measurements and C2's INNER window (canvas) measurements.

Save the resulting values in two global variabls.

osWindowMarginWidth

osWindowMarginHeight

Then when you set the window's OUTER size via the NWjs actions, give the INNER pixel size you want, plus the extra margin size you stored in the global variables earlier.

I've included a commented example capx showing the solution in action.

Download example capx

(In the capx, you can press "1" or "2" on the keyboard to set either the OUTER or INNER window size to 256 x 256.)