R0J0hound's Recent Forum Activity

  • 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.
  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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.

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