R0J0hound's Forum Posts

  • You can get a good speedup by utilizing an array to make the cell lookup faster.

    See here for an example:

    The slowdown you're encountering has to do with picking. Event 23 in your capx is the bottleneck.

    If you're using 40x40 then you have 1600 cells, and event 23 does this:

    cell: coordX = checkX //this filters the 1600 cells down to 40

    cell: coordY = checkY //this filters the 40 cells down to 1

    1600 times.

    The idea in my capx is to just do everything in the array, so I can lookup if a cell is on or off with a direct check. Then to update it visually I just loop over the sprites and set their visibility depending on the value in the array.

  • Make that part transparent so you can see the bricks behind it?

  • The difference between lerp and anglelerp is anglelerp lerps in the closest direction.

    Also I'd like to point out that while something like:

    lerp(a, b, 0.5) will give an easing out effect, so will cosp(a,b,0.5), qarp(a,b,c,0.5) ... etc.

    As long as a constant value is used for any of the interpolation functions it will only give an easing out effect.

  • Set some text to Canvas.RgbaAt(350,120) and see what the color is at that spot.

  • Looking here:

    https://www.scirra.com/manual/29/object-type

    Couldn't you save a copy of sol.instances and sol.select_all to variables and then set the sol later?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If the comparison doesn't work, what is the value of rgbaAt()? What are the x and y values you're using? They do need to be integers as I recall.

  • While lerp() can be used for easing out, there's no way to do easing that way.

    The main way to use easing like that is this:

    about-the-new-interpolations_p787879?#p787879

    Although that's not really suitable for a moving target like yours.

    You could treat it a bit different by using angular speed. Basically just accelerate toward the target and decelerate to stop at the angle exactly.

    For that you could use this older example:

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

  • The two equations you need to calculate collision impulse are:

    Total momentum before = total momentum after

    m1*v1i + m2*v2i = m1*v1f + m2*v2f

    "i" means initial and "f" means final.

    We also need another equation so we can solve for the two unknowns (v1f and v2f). Since we want perfectly elastic collisions we can use:

    total kinetic energy before = total kinetic energy after

    0.5*m1*v1i^2 + 0.5*m2*v2i^2 = 0.5*m1*v1f^2 + 0.5*m2*v2f^2

    So with some algebra I was able to calculate it as:

    v1f = (v1i*(m1-m2) + 2*v2i*m2)/(m1+m2)

    v2f = (-v2i*(m1-m2) + 2*v1i*m1)/(m1+m2)

    Now those velocities are in only one dimension. For 2d collisions if we only need to consider the speeds along the normal between the two objects, which is still is one dimensional.

    So the steps would be:

    1. calculate the normal between the two objects.

    --- normalx=cos(angle from object1 to object2)

    --- normaly=sin(angle from object1 to object2)

    2. calculate v1i and v2i only in direction of the normal.

    --- v1i = normalx*object1.velocityx+normaly*object1.velocityy

    3. use the equations above to calculate v1f and v2f.

    4. apply v1f and v2f back onto the object's velocties.

    --- add normalx*(v1f-v1i) to object1 velocityx

    --- add normaly*(v1f-v1i) to object1 velocityy

    Working example:

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

    You can also incorporate a coefficient of restitution into the impulse equation so you can anything from a "perfectly elastic collision" to an "inelastic collision".

  • gogobotz

    When physics is concerned (this or the official physics behavior) it doesn't mix well with other movement behaviors. So to to have 8 direction with physics you'd need to do it all with physics.

  • Here's a simplified version. The units go around the wall when they collide with it. "Overlaps at offset" could be used to get the units to start avoiding prior to overlap. In the capx above i was checking for an overlap in the range from where the unit is to where it will be later.

    Sprites:

    "Wall"

    "Unit" with variables i, targety

    Events:

    Global number starty=240

    Start of layout

    --- unit: destroy

    Start of layout

    Repeat 10 times

    --- create unit at (0, starty)

    --- unit: set i to loopindex

    Every tick

    --- unit: set x to self.x + 100*dt

    --- unit: set targety to starty+(self.i-5)*16

    Wall: is overlapping unit

    Pick all unit

    ===unit: targety<wall.y

    --------unit: add -wall.height/2 to targety

    ===unit: targety>=wall.y

    --------unit: add wall.height/2 to targety

    Unit: y < self.targety

    --- unit: set y to self.y+100*dt

    Unit: y > self.targety

    --- unit: set y to self.y-100*dt

  • Try the bullet behavior with gravity instead. It would look the same only without collisions.

  • Here's one possible idea. When you create the objects calculate their spread out position, that will be the target position. Next see if the path from the current position to the target hits any walls. If it does shift all the targets up or down depending on if they're above or below the line. Finally move toward that target and repeat next frame.

    Here's a basic example that spreads units up and down around walls.

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

    Another idea would be to looking into boids or flocking behaviors.

  • I don't think you can, but I'm curious, why you need it? If it doesn't have the solid behavior and if you aren't checking for collisions with it in events then no collisions are checked with it.

  • This example here is applicable, although I forget if varying costs is implemented in it.

  • AllanR

    TELLES0808

    I'm glad it was useful and amusing to tinker with. I had fun making it.

    Concave terrain like that would cause the algorithm to run longer, but it's only an issue if pathfinding for all your ships ends up being too slow. A simple thing you could do is avoid concave terrain in your levels.

    Or if you're feeling ambitious you could reference this fun site for other pathfinding ideas.

    http://theory.stanford.edu/~amitp/GameProgramming/

    One thing I've done in the past is calculate the path over multiple frames instead of all at once. It helped spread out the pause when a large amount of nodes were used.