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.)

Hey Sykarion,

One possible approach might be to create two objects for each on-screen character; a "Position" Sprite object that moves along the ground platform, and a "Graphic" Sprite object, that is pinned to the Position Sprite, but with a small randomized vertical offset. The Position Sprite would be made invisable in-game, so the player would only see the Graphic Sprite objects.

Finally, to make sure that the Graphic Sprites overlap each other correctly, (front to back), you just need to move each newly created Graphic Sprite to the correct Z-index relative to the other Graphic Sprites. To do this, you can re-sort them each time you create a new sprite, or you can move the new one to the correct Z-index on creation.

Both methods will amount to placing the Larger Y values (southward on screen) in front, and the smaller Y values (northward on screen) in back.

Sometimes I derp my way through manuals and miss handy stuff.

Below are some really handy shortcut keys I wish I'd known about when I started working with C2.

I'm posting them just in case anyone else missed them the first time around, as I did.

Replace

In the event editor...

R = Replace an object in the currently selected actions or conditions, with another object of your choice. The new object must be the same basic type, e.g. Sprite, and must have any necessary behaviors and private variables of the object it's replacing.

Back & Next

In the event editor, in a condition or action dialog...

Alt + Left arrow = Back to previous page.

Alt + Right arrow = Forward to next page. (Or "Done" when on last page.)

When you are editing events, (e.g. adding an Action), often you click through several pages in sequence, choosing objects, picking actions, and entering parameters.

At the bottom of each of these pages are "Back" and "Next" buttons. The above shortcut keys have the same effect as pressing these buttons, and can save time if you need to make similar changes to a bunch of actions or conditions.

Hope this helps someone out.

Hey YetAnotherSuperhero,

If I understand what you're looking for, I think you can do this with a combination of the System object's "Canvas Snapshot" action, and the Browser object's "Invoke Download" action.

Basic Idea

To get a snapshot with a transparent background, you'll need to ensure that when you snapshot the canvas, the entire canvas has a transparent background. I believe this can be done by making sure that the bottom layer of your game has its "Transparent" property set to "Yes".

(Strictly speaking all layers should be set to transparent, but usually it's only the bottom layer that's opaque in the first place.)

In the Construct2 editor, the backdrop of your layout should now appear gray (just like the margins) instead of white, as gray is the color the C2 editor puts behind your entire project. You are now seeing through your project's transparent canvas, down to the gray editor background color.

Example

So now, to see a practical example of this in action, we'll open one of C2's built in tutorial projects and modify it.

1. Open Construct 2, and From the main menu choose New.

2. In the search area, type "snap" to filter the list, and open "Example: Taking screenshots" project.

(Or just look through the list to find and open the "Example: Taking screenshots" project.)

3. In the "Layers" panel, select "Layer 0".

4. In the "Properties" panel, in the "Layer properties" section, set "Transparent" to "Yes".

(The background of the project should now look gray, just like the margins.)

5. Run the project. (It should open in your default browser.)

6. Click the "Take screenshot" button, and notice that the screenshot you took now appears above the button.

7. Click and drag one of the pig sprites to that screenshot image in the bottom-right corner. Notice that the pig passes "under" the image, and that the image's background is transparent.

8. Click the "Download" button to download the screenshot as a PNG with a transparent backdrop.

Hope that's along the lines of what you're looking for, and thanks for asking this question.

When I started writing this reply I was pretty sure there was a way to download a screen-cap but not with transparency.

It took some experimentation, but I learned something new.