I have doubts this would provide any tangible benefits. I've attempted similar techniques in MonoGame while trying to eek out extra performance on mobiles, but the results were generally worse than doing things the normal way. Running parts of a game at different resolutions still requires everything to be drawn to the screen at the highest resolution at some point. This would be felt hard when rendering lots of layers at a smaller resolution, then rendering them individually again(from the small render result) scaled up on the screen.

Granted, I'm not aware of how the Construct 2 renderer handles things, but I'm certain it wouldn't lend itself well to this kind of technique.

I doubt there's much(if any) symbolic meaning behind which side of the screen the players appear on. After all, in later Final Fantasy Games -- such as those on the Super Nintendo -- there were back and pincer attacks, both of which changed up where on the screen the players ended up.

Honestly, it's just a matter of convention at this point. Because of this, some folks might find it odd to see the player on the opposite side they would expect, though I wouldn't worry about it. If a lot of people start commenting on it, then you might have a problem, but I see no harm in leaving it as is for now.

There are two methods I can think of off the top of my head:

1. Split the enemy vertically into two sprites(left and right sides), one half above the sword, the other below it.

2. Use a separate sprite for the blade. Using some basic maths, adjust the length of the blade such that it doesn't extend beyond the horizontal center of the enemy sprite.

Number 1 is the simplest in some respects(no math) and allows the blade to appear out the other side. On the other hand, splitting the enemies like that could complicate other things. Neither one will be truly simple, of course.

Okay I did that, and it DID fix the per frame issue, so that's out of the way. However, there's still often a one frame jump that occurs when the loop is executed.

If you're referring to the shaking, this is because you're pushing out before moving the object and handling it's controls, so it's essentially pushing out of the wall only to move right back in in the same frame. You should push out after movement and controls -- also remember to update your sensor positions before pushing out if you do this.

I'm aware of this. I setup conditions that check which speed is faster as to which loop to execute, but it's very faulty. I toggled those conditions for now but left them in so you can see what I did.

This looks about right, although I advise pushing out in the path of least resistance, which I'll explain in a minute.

I reordered the loops so that x ejection runs first, and what happens is, every frame that the player is inside the solid, it runs the y ejection loop once, so holding shift while running into a wall causes the player to climb one pixel every other frame. You'll see what I mean. The goal is to remove that one frame skip altogether so this wouldn't happen at all.

The climbing is because whenever you push your player and then call "PlayerReposition", you're only repositioning the colliding sensor. So when going fast, all three sensors could be in the wall. The side ones are checked first, pushing the object -- and side sensors -- out of the wall horizontally. Then you check the down one, which is still inside the wall. This sensor sees itself in the wall, so it pushes up once and is then repositioned based on the position of the object, where it's no longer overlapping. Try calling the function while forgetting picked objects so they all reposition rather than just the one that was picked by the event from which the function is called.

Well, if the player gets stuck in a wall, I don't know how to find which direction requires the least number of steps before picking which ejection routine to run.

This is a matter of trial and error. You need to push out in a direction, counting the amount of steps taken, then reset to the original position and check push out in another direction, repeating the pattern. At the end, pick the direction with the lowest amount of steps necessary and push out in that direction. Since you already know how many steps it takes, you don't need to check overlap anymore.

I'm not sure I understand this... do you mean a check AHEAD prediction system instead of a check BEHIND ejection system? If so, I'm not sure how to accomplish that in Construct.

Yes, the concept boils down to this:

1. Calculate based on velocity how many pixels the object will move that frame(for X and Y separately)

2. Using a loop, move the object in increments of one each loop

3. If the object hits an obstacle, move back one pixel and break from the loop; else, break from the loop when you've moved the amount of pixels calculated in step 1

It looks like While is simply broken in this case, although I doubt that's the answer you wanted to hear. If you place While in an event by itself and then do your collision checking as a sub-event to that -- using, of course, an else statement to break from the current loop so it doesn't loop forever -- then you'll achieve the results you want. Example:

While

--sensor overlaps solid: Do stuff

--else: Break current loop

Unfortunately, what you want this to do and what it actually does may differ, because as you have it setup now, if you run horizontally into a wall at high speed and the "down" sensor overlaps the ground, you're automatically pushed up through the obstacle, winding up on top. Horizontal and vertical speeds need to be accounted for when determining in which direction you want to push out.

As another tip on the matter -- I apologize if this has strayed too far from the original topic -- you generally want to be pushing out in the direction that requires the smallest number of steps, rather than arbitrarily pushing out in each direction systematically. Expanding on the previous point, this is because as you always push out up first, then you will never end up pushing out right or left.

One more thing to think about is how fast you want your player to go. At some point, your player may move so fast they might skip through obstacles. In this case, you need to move from a "move then push out" system to a "push to new position" system, whereby you incrementally push your object and check for collisions until you've either hit a non passable wall or have pushed as far as the objects speed allows it to move in one frame.

Going back to the original problem, it honestly sucks that While seems to be broken as it is, but at this point nobody is maintaining Classic, so it's unlikely to get fixed.

That was a lot more long winded than I anticipated. If you need clarification on any of the points, I'll be happy to help out.

You're making use of a non-standard "Dropshadow2" effect, so I can't open the file. I'll help you out if you can either remove this effect or include it with your CAP file.

As far as I'm aware, you can't explicitly set Z-order -- the reasons for this, I couldn't answer.

Using lots of layers should perform fine, though working with that many could become bothersome.

By "replacing" a tile, are you saying that you're destroying one and then creating a new one in its place? If that's the case, you should be able to use the "Move to object" action under "Z Order" after creating your new tile, but before destroying the old one, using said action to place the new tile just in front of or behind the old one.

mrexcessive - This is a five year old thread concerning Construct Classic, but I presume you're using Construct 2. You'd be much better off asking your question in the Construct 2 help section.

Please be sure you check how old(and relevant) a thread is before asking questions in the future.

Yeah, I just found that, but it appears to work differently for plugins and behaviors. Plugins call it tick2 and you need to call runtime.tick2Me(), whereas behaviors call it posttick and it gets called automatically.

Thanks.

If I recall correctly, Construct Classic allowed plugins to have two tick methods - one called before processing events, and another called after processing events but before drawing - which allowed plugins to account for changes to objects arising from events processed before the frame was rendered. Is there anything similar in Construct 2?

I feel I should mention that my plugin - MagiCam, specifically - is not drawn, so running my tick logic in the draw method is out of the question.

shinkan I'm pretty sure I know what's going on with the shaking. I'll try to take a look over the weekend if possible, but failing that, I don't know when I'll be able to look at it again. Fingers crossed.

Also, I was wondering if you could elaborate on your previous post about easing. Camera transitions already have an easing effect on them, although perhaps not as pronounced as one might like. Are you wanting to choose different types of easing?