I saw a request a while back for a way to draw collision polygons, like with a mouse or tablet, right over the editor window.

Colludium Thanks for your data. We definitely want to get as close to Newton as possible.

However, neither my originally-proposed method nor the built-in calculation method is correct. We actually need to add (1/2)*g*t^2.

I made a mistake in my calculations. Due to the discrete/continuous difference Ashley mentioned, I mismatched position and velocity by one tick. When I fixed the error, Platform Minus gave a worse error than the built-in Platform behavior.

However, ADDING (1/2)*g*t^2 seemed to give a smaller error than the built-in calculations. I built a test program in Construct 2 that measures the unchanged, added, and subtracted jump heights.

Thanks to Aphrodite for the max height equation, the actual maximum height for a 650 jump strength and 1000 gravity should be 211.25 pixels.

The Platform behavior yields a 213.958 px jump height.

Subtracting (1/2)*g*t^2 gives a less-accurate jump height: 216.667 px.

But adding (1/2)*g*t^2 gives a jump height very close to the expected value: 211.285 px.

You can find the test .capx here.

To use it, go to debug and select the array. After you jump and land, the third array value will be your jump height. Press 0, 1, and 2 to toggle between the unchanged, subtracting, and adding calculation methods, respectively.

Wow, this is pretty cool! I've always thought collisions would be really difficult, but your explanation makes it sound easy (or at least possible), and in a variety of ways!

Ashley

There’s actually an error in the math for the Platform and 8-Direction behaviors.

The velocity calculates right:

V = V(old) + a*dt

But the position calculates as:

Y = Y(old) + V*dt

So when you substitute the velocity equation in, it comes out:

Y = Y(old) + (V(old) + a*dt)*dt

Y = Y(old) + V(old)*dt + a*(dt)^2

But since the actual physics equation is:

Y = Y(old) + V(old)*dt + (1/2)*a*(dt)^2

Subtracting out (1/2)*a*(dt)^2 puts the position to what the physics equation predicts.

Also, I realize the classic physics equation depends on the total time from t = 0, but it works out if you think of starting a new equation every tick with the last tick’s positions and velocities as the new Y0 and V0. Or, you can think of it as position at time t and time t+dt, then subtract the two from each other to get the change in position.

My change isn’t truly framerate-independent, but it loses accuracy more slowly as the framerate drops.

Aphrodite Is "Platform Minus" taken? It kind of works, since I'm subtracting something from the current equations. Also, I made a demo game with the new events, and it looks like the behavior handles collisions, clipping, etc. just like it normally would.

A while back, I stumbled upon a thread where some game developers noticed pixel-perfect platformers had different jump heights depending on the framerate. I’m pleased to announce I have a solution. Assuming your game doesn’t require changing gravity angles, add the following two events to your event sheet:

EDIT: I originally thought subtracting a value would correct your position. Adding is actually what we want, and I've changed the events accordingly.

Player Platform is falling

System Player.Platform.VectorY < Player.Platform.MaxFallSpeed

Player Set Y to Self.Y + ((0.5*Self.Platform.Gravity)*dt)*dt

(Sorry, I had a little trouble inserting the Screenshot)

I’ve nicknamed this trick “Platform Minus” (because "Platform Plus" is taken). C2’s built-in platform behavior makes an imperfect approximation of the physics equations behind projectile motion. This is usually close enough that the difference doesn’t matter, but it does flatten the top of the jump arc and reduce the jump height by a few pixels, and changing framerates makes the problem more pronounced. This quick fix moves the arc closer to the exact equation and is less sensitive to framerates. I built a test capx to illustrate my point:

Jump Height Testing

In the debug window, look at the array's third value after you jump and land. With the 650 px/sec jump strength and 1000 px/(sec^2) gravity, the jump height should actually be 211.25 px. Press the "0" and "2" keys to switch modes.

Platform movement in the X-direction and 8-Direction movement have the same problem, but it’s much less noticeable because max speeds are usually relatively low, and it’s a little harder to fix because the accelerations aren’t constant. I hope I can get around to modifying the original plugins, but I’m not an expert coder, and I wouldn’t complain if someone beat me to it.

Platform Minus is a simple step, but an important one, towards even better platforming with Construct 2. We’re that much closer to perfectly framerate-independent game design.

Edit: Introducing "8 Direction Minus!" This slight change to the 8 Direction behavior makes top-down movement a little smoother and a bit less-sensitive to framerate changes:

8 Direction Minus(Once you get to Google Drive, right-click the name of the whole folder and click "download" to download the whole folder)

[NOTE: If you downloaded 8 direction minus before 13 August on 5:26 PM, please download it again, as the first version actually made a worse approximation of physics than the built-in behavior.]

An additional. known error: When a sprite with 8 Direction Minus is moving in only one direction at max speed, speed in the other direction becomes a very, very small number close to zero. However, this doesn't actually move the sprite in the second direction at all.

I saw something Sol posted about the layertocanvas or canvastolayer expressions. I haven't been able to use it yet myself, but I think that's what you want.

I always just set the animation speed to 0 for something I need to stay the same frame.

—: Your idea would work similarly to mine, but I think it would also encounter the same problem.

I think the problem is that the weapon wheel is probably on its own layer with a (0,0) parallax, right? So unless you're in the very top-left of the map, the mouse is actually really far away from the wheel's center, and any movement only means a tiny change in angle.

Meanwhile, looking at absolute x and y, it seems like that refers to the mouse position for the entire screen, not just your game's window. Possibly not a problem once you port to mobile?

So a potential workaround: you could use (mouse.x, mouse.y), set the weapon wheel's layer to a (100,100) parallax, then set the wheel's position to (scrollx,scrolly) every tick. It does make the rotation work correctly. However, you would have to put your onscreen buttons in a separate layer or move them every tick as well. This method also makes the weapon wheel look a bit jumpy when it repositions, but it'll only be visible when the timescale is very low, so it might not be noticeable.

Hm…

If you add a timer and two private Booleans (I’ll use “stunned” and “LeroyJenkins”) to the enemy, you could say

1. (Inverted) ENEMY is stunned

ENEMY has LOS to PLAYER

Trigger once

-> ENEMY set LeroyJenkins true

-> ENEMY stop

2. PLAYERROCK on collision with ENEMY

-> ENEMY stop timer “OhNose”

->ENEMY start timer “OhNose” for 1 second

-> ENEMY stop

-> ENEMY set stunned true

-> ENEMY set LeroyJenkins false

3. ENEMY on timer “OhNose”

-> ENEMY set stunned false

4. ENEMY is LeroyJenkins

-> (the logic you use for shooting the player)

5. Else

-> ENEMY move along path

Where "ENEMY stop" is the pathfinding "stop" action.

You could turn the cursor invisible during selection and turn a different cursor visible. Put its origin way below the actual image, so the cursor appears over the weapon options and its origin is at the center of the wheel. Then use the "set angle to position" action:

key SHIFT is down -> cursor set angle to (mouse.x, mouse.y)

I'm not sure what to do to get the original cursor back to the right position, though.

Hi, g3nki!

I clicked on the link for Project Catnip, and it’s breathtaking! I thought it would be great to be a part of this in some small way (If I could be so bold), so I ran some tests.

As far as the jump-through problem, that happens when the player hits the edge of a link part-way up the player sprite or when the link is very steep (For a flat fall-through object, a platformer object won’t fall through for gravity angles between 40 and 140 degrees. I don’t know whether there’s a way to fix that.

Next, I tested solids. A 7x8 pixel rectangle traveling towards a surface at 1000 pixels per second, running at 60 fps, required a bar only 2 pixels thick to consistently sense collisions. However, when I positioned the bullet at a worst-case position, flush with the bar at the start of the first tick, the required thickness jumped up to 10 pixels for consistent collision! And with rectangles so wide, the corners could really get in the way of good collision.

Depending on how your game will work, especially in terms of objects’ movement speed and whether you can get a consistent framerate (How’d I get it in my head you were developing for the Wii U?), my events for solids still might work for you. But if you need high move speeds or the corners start giving you trouble, I guess codename: Bounding Box is scrap.

I'm having trouble figuring out source atop, too. Whatever object you mark "source atop" is invisible anywhere it overlaps transparency on its layer. What's giving me trouble is having 2 objects on the same layer be source atop, which might not be allowed.

Aaaannnddd..... I just saw this post is a year old...

Eh, Steve!