calebbennetts's Forum Posts

  • 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!

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I think I figured it out. The platform behavior uses imperfect approximations of the physics equations for projectile motion to save processing time (which is done pretty often in computer games). The approximation is usually good enough, but as dt gets bigger, so does the error. Thus, machines with different speeds have different frame rates, have different dt's, have different amounts of error. I made a sample capx with the exact calculations for Y movement. X Movement still depends on your machine until you reach max speed, when it should always be the same. The minimum frame rate at the top is just to adjust for testing purposes. Unfortunately, the new method was incompatible with behaviors, so everything is events, down to the collisions. I doubt anyone is actually going to want to use this in the long run, but if you do, be advised you can only use rectangular collision boxes.

    So-called "Perfect Jump"

    Eh, Steve!

  • I made an all-event-based version of what you're getting at.

    I'm actually surprised how easy that was to make (I thought it was going to be super-difficult).

    Important notes:

    -Numbering is zero-based.

    -Object number, node number, and last node are all really important to get right. If you don't remember "last node," subsequent shapes won't draw.

    -Steep jump-through objects don't seem to detect collision in the x direction.

    boundingboxes.capx

    (And Google Drive will show a bunch of files, but just click the download button at the top and it'll turn back into a .capx)

    Eh, Steve!

  • The url isn't loading. It might have gotten accidentally changed by Scirra's wierd (but as far as I know, effective) rules for URL posting. You might be better off putting in the changes yourself. It's actually pretty easy to do once you get your head wrapped around it. Sorry I couldn't help more.

  • You save the game as a single file, then upload it to something like Google Drive and post a link in the forums. Don't cut the red wire, and remember, the space mutants fear fire.

  • Woah, how long was I asleep?!

    Just kidding. My laptop charger died, and I had to wait a couple of days for the new one. If you have paid version, all my worries are placated. I'd still be happy help.

  • I'd be happy to, but I have the paid version, so I'm not sure if you would be able to edit what I sent back to you. At the very least, you could look at what I do and duplicate it on your original capx.