R0J0hound's Recent Forum Activity

  • The equation is correct. Using impulse to launch the projectile is where the variance is.

    Impulse = Force*time

    and from best I can tell dt is used for time and that varies.

    Try setting the velocity instead with:

    velocityX=speed*cos(angle)

    velocityY=speed*sin(angle)

  • R192 is also free, it's just a beta version. You can find a link at the bottom of the page.

  • Here's a capx. I used "pick top instance" to pick only the last box created

  • Why not use the polygon object? It makes it very easy to draw a polygon. For example:

    on mouse left click
    --- polygon: clear polygon
    
    left mouse button is down
    --- polygon: add vertex at (Mouse.x, Mouse.y) -world-space
    
    on left mouse button released
    --- polygon: draw polygon ...
    [/code:2x63fnpc]
    It doesn't play well with the physics behavior but at least the collision polygon will match the drawn polygon.
    
    You could also draw the polygon using the canvas plugin but it has no collision polygon.
    
    So drawing it isn't what's hard.
    
    For just a box no third party plugin is needed.  Only the mouse and a sprite with the origin centered.
    [code:2x63fnpc]global number startx=0
    global number starty=0
    
    on left mouse click
    --- set startx to mouse.x
    --- set starty to mouse.y
    --- create Sprite at 0,0
    
    left mouse button is down
    -or-
    on left mouse released
    --- Sprite: set position to ((startx+mouse.x)/2, (starty+mouse.y)/2)
    --- Sprite: set size to (abs(startx-mouse.x), abs(starty-mouse.y))
    [/code:2x63fnpc]
    If you want it to fall afterwards you could use the physics behavior, only be sure to disable it until the mouse button is released.
    
    If you want a box then no plugin is needed
  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • r191 is a beta. You can get it here:

    https://www.scirra.com/construct2/releases/r192

    Minor's approach is to loop over the array twice. The first time it saves the neighbors for each cell, and the second time it apply's the cgol rules. With yours it appears you're just finding the neighbors and applying the rules as you go, which will cause issues as you go since you're modifying the array as you go.

    I tried a slightly different approach which also works. I basically used two arrays and each step I alternate which one I read cells from and which ones I write to.

    https://dl.dropboxusercontent.com/u/542 ... /cgol.capx

    That is one of about six different capx's I've been playing with.

    There are many other ca's that look interesting to implement as well. Here's just a few:

    http://www.mirekw.com/ca/ca_rules.html

    And the latest capx of a different set of cool looking ca's

    https://dl.dropboxusercontent.com/u/542 ... yclic.capx

  • If you want to be clever you could do this too:

    find(",32,37,38,39,40,", ","&a&",") >=0

    Or you could make a function if you plan on doing something like that more than once:

    on function "one of em"

    for "" from 1 to Function.ParamCount-1

    function: parameter 0 = Function.Param(loopindex)

    --- set return to 1

    Then you can use it with:

    System: compare Function.call("one of em", a, 32, 37, 38, 39, 40) = 1

  • It's a simple enough capx, change it to one object and see what happens.

    The control object acts as a shield so you can run up against the sides of the crushers with out dying. As one object It's just: if player overlaps crusher then die.

  • The front edge has a z of 1 and the back edge has a z of 2. The values were a bit arbitrary, you could pick a different value fro the back edge but then you'd need to rework the formulas. I did some fiddling with the example and stretched the perspective shapes around and actually found cases where the old method works better.

    There may be a math error somewhere in my equation since it seems to need that correction for large values.

  • I don't know of the image you're referring to. If it helps the origin is the top left of the layout and x increases to the right and y increases down. Basically it's vertically flipped from what's used in math books.

  • Like codah said there are many different ways and they really depend on the type of game. One way would be to use some sprites as detectors.

    Attached is a way to make thwomps like in mario.

  • Here's kind of a way to do that, but all collision is done manually.

    The idea is to fill an array with random heights for the terrain, and have a number of sprites across thee screen. Then the height of those sprites can be set from interpolating between array values.

    It's kind of complicated because everything is done manually but perhaps you can pull a few ideas from it.

  • You can do the motion with vars for velocityX, velocityY and gravity. Then the kinetic motion can be calculated with:

    x = x + velocityX*dt

    velocityY = velocityY + gravity*dt

    y = y + velocityY*dt

    To make it bounce there are a few approaches. One simple one it to move horizontally first, then vertically. For either motion the idea is to:

    1. move

    2. if ball is overlapping wall then unto the move and reverse the velocity.

    To make the ball always bounce back up to the same height is a bit trickier. In an idea world we would bounce at the exact point of collision, which can be calculated but even then there will be rounding errors over time.

    A simpler idea would be to conserve total energy. AKA total_energy=potential_energy+kinetic_energy

    Potential energy (PE) is the height of the object off the ground times gravity, and kinetic energy (KE) is the speed squared divided by two.

    PE = -y*gravity

    KE = 0.5*speed^2

    As the ball moves energy is transferred back and forth between PE and KE, and if energy is conserved then the total energy (E) will always be the same.

    E = KE + PE

    This is useful because with that we can calculate what the speed is for any y. You can work out the algebra yourself but it comes out to:

    speed = sqrt(2*gravity*(y - start_y))

    So with that we can correct the speed so the ball always bounces to the same height.

R0J0hound's avatar

R0J0hound

Member since 15 Jun, 2009

Twitter
R0J0hound has 157 followers

Connect with R0J0hound