R0J0hound's Forum Posts

  • mattb

    One idea that may work is use a force on the object toward the base of the rope and just set the length as it gets closer. That may be more true to life where a force would be used to pull the rope in. You could also instead set the velocity of the object parallel to the rope as well, which would make the rope retract at a constant rate. For the latter you'll need this formula to get velocity along an angle:

    velocity at angle = vx*cos(ang) + vy*sin(ang)

    So given:

    ang= angle of rope

    and

    rope_vel

    We can set the velocity so the perpendicular velocity stays the same and the velocity along the rope is whatever value we want.

    perp_vel= vx*cos(ang+90) + vy*sin(ang+90)

    vx=rope_vel*cos(ang) + perp_vel*cos(ang+90)

    vy=rope_vel*sin(ang) + perp_vel*sin(ang+90)

    Then as with the first idea only set the rope length as the object moves closer.

    Edit:

    A third idea would be to set the maximum force of the joint so that the collision isn't as radical.

  • You can check if the xVelocity is between -1 and 1 with two conditions.

    Basically this:

    Sprite.Physics.velocityX > -1

    Sprite.Physics.velocityX < 1

    Now there are a lot of conditions that can be used to do this. A basic one is the system->compare condition. And if you want it to work with more than one instance of sprite add a "for each sprite" condition above the two conditions.

  • The pin behavior is run after the event sheet, so you either would have to wait till the next tick or position B with events before pasting.

  • That's by design. The size of the texture can't be changed as easily as c2's drawing surface. One reason is the texture is cleared whenever it is resized, another is it isn't always desirable to have the paster's resolution match screen pixels.

    Using digitalsoapbox's suggestion to use the "set resolution" action to the window size is the way to go to make resolution the same as screen pixels.

  • In the image editor the frog needs to be facing to the right. From your image it looks like it's facing up.

  • In my experience object sealing hasn't affected my code at all. Not sure if it's because it's not being done or something, but I'd say just go forward with your plugin and if you get to the point of it not working because of sealing then look for workarounds.

  • If you can re-work it so the walls don't move and you just change the scroll position then you won't need to update the obstacle map.

  • With the built-in physics behavior you can approximate the egg shape with an up to a 16 point collision polygon. The Center of mass defaults to the center of the object, but you can use torque with an imagepoint to make it seem like the center is in a different location. Not mathematically correct but it looks good.

  • It's by design. To make group variables like globals make then static.

  • One idea is to change the collision polygons to have a bevel to round them out.

    So instead of the corners being this:

    ----*
    |
    |
    |[/code:1pixj20c]
They'd be this:
[code:1pixj20c]---*    *
    |
    |[/code:1pixj20c]

Another idea is to use the "overlapping at offset" condition to see if a wall is just a step and then move the player up.

right key down
player: wall to right
player: [NOT] overlapping SolidTile at offset (32, -1)
--- player: set y to self.y-1

Instead of -1 you could use a lower value to go up larger steps.  The approach will need some tweaking.

  • 1.

    You could either just nudge vx and vy around when bouncing. For example for a horizontal bounce:

    set vx to -self.vx

    add random(-1,1) to vy

    A vertical bounce can be done similarly.

    Or you can actually nedge the angle. To do that takes two steps. First calculate speed and angle from vx and vy, then convert it back to vx and vy from that after nudging the angle.

    ang = angle(0,0,ball.vx,ball,vy)

    speed = distance(0,0,ball.vx,ball,vy)

    vx = speed * cos(ang+random(-2,2))

    vx = speed * sin(ang+random(-2,2))

    2.

    For changing the angle depending on where on the paddle was hit you could just add the horizontal distance between the ball and paddle when hitting the top of the paddle (event 16). So basically:

    add (ball.x-paddle.x) to vx

    You could multiply it by 0.5 or something to make it more subtle.

    For actual round objects you'd need something better for contact normal detection.

    This may work, you may want to add 1 or so to the radius check.

    local number NormalAngle=0

For each roundWall
system compare: distance(roundWall.x,roundWall.y,ball.x,ball.y) <= ball.radius+roundWall.radius
--- set normalAngle to angle(roundWall.x,roundWall.y,ball.x,ball.y)[/code:1dvz1wet]

Basically to bounce you need to know the normal of the surface hit and then you can bounce using either the math event 19 in your capx or with the normal angle using that formula from granpa:
set angleOfMotion to 2*normalAngle-ball.AngleOfMotion+180

  • 1. It's for organization purposes and probably has no impact on performance at all.

    2. Less things to draw would speed up rendering.

    3. Whether the music is one minute long or on hour has no impact on performance, only loading time of the webpage.

    4. Basically. The pin behavior has more features than just that, such as setting angle. And there are cases where doing it with events is more useful.

    5. Any value below 0.0166 (1/60) with every n seconds will be the same as "every tick". Other than that just use the one that makes sense for what you're doing.

    6. As I understand it CocoonJS takes some shortcuts to make rendering faster at the expense of unsupported edge cases, whereas IntelXdk supports everything C2 supports. Making it faster is unknown to me, I do not use it.

    7. Don't know. I'm guessing it's where you're placing them. Else can't be used after a trigger is one reason that comes to mind.

    8. Why not just increase the layout size? Margins are just extra space around the layout for editing purposes.

  • —

    Just an idea. You could spread out the processor load further by doing something like this: instead of updating all the enemies every time interval just update half one interval and the other half the next. Or you could spread it further if needed. That would reduce the amount of stalling when looping over a large number of enemies.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The way to join two objects together like that is to give them the same collision group and add two joints, a pivot joint and a gear joint with a ration of 1.

  • Here's the topic where go faster's approach was devised.

    In the linked post there's a capx. Events 6-9 move the tiles. The recalc variable is just a flag to tell the tile to re-lookup if it's a wall or not in it's new position. The most complicated bit is how the level is generated. It uses a array of random values and then does some interpolation with those values so that any position can be checked on the layout and always be able to get the same value. There's a perlin noise plugin that would greatly simply this.