R0J0hound's Forum Posts

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

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

  • Try Construct 3

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

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

  • Basen

    I think you can improve it by increasing the the space iterations perhaps.

  • Doing it with just events is simple enough. Give the ball two variables vx and vy for the x and y velocity. Motion is done by appling the formula speed*time=distance. You can also set it from a speed and direction if you so please with a simple convertion from polar coordinates to rectangular: vx=speed*cos(direction) and vy=speed*sin(direction).

    Then instead of using a plugin or behavior, just check the position against the four walls and bounce. See attached capx.

    That's just for outside walls. For inside walls you'll need push the ball out of the wall before using overlaps at offset to bounce. In the following link I implemented the push out with just events and it works well enough. If you make the ball too fast so that the jump of positions completely misses the wall then this still could fail.

    To solve passing through walls you'll want to check the positions in between or do a raycast.

    For the first you could do the same as this bouncing laser example:

  • In the image editor there's a button on the toolbar where you can specify the "export file format" where png-8 is one of the options. As far as actual memory usage by your game, it doesn't matter what file format is used because when an image is loaded it's loaded as a uncompressed 32bit image in video memory.

    The best that could be done if the game designer was happy about a loss of color depth would be for c2 to use compressed textures in webgl. The issue is support of it. According to the stats here:

    http://webglstats.com/

    The most supported texture compression format is s3tc and even then it's only supported by about 75% of devices.

    s3tc gives a 4:1 compression at the loss of the amount of colors.

    http://en.wikipedia.org/wiki/S3_Texture ... Comparison