R0J0hound's Forum Posts

  • I wouldn’t mind at all.

  • For a fairly straightforward way of getting the collision point you can take all the points of one object’s collision polygon, and see if they overlap the other object. Then do the same for the second object with the first. Then, for all the points that do overlap just average the positions together to get a collision point.

    There are more robust ways, but it should work in most cases. One case where it would fail is if the objects are severely overlapping and no points overlap, just edges.

    For the impact sound it basically boils down to:

    Velocity_after - velocity_before

    Maybe Every tick save the old velocity to some variables. Then on the collision, after stopping or bouncing the object, subtract the velocities to get the impulse.

  • Here’s some pseudo code to do the bounce. The only trig has to do with the collision normal. The normal is perpendicular to the angle of the platform. So if you know the angle of the surface it’s enough to subtract 90 to get a perpendicular angle. Then to make the math look cleaner we can convert that angle to a vector.

    Anyways here’s the math.

    Nx,ny is the normal vector and can be calculated with:

    nx= cos(plat.angle-90)

    ny=sin(plat.angle-90)

    Next we calculate the velocity along the normal’s direction. Here vn is that velocity, and vx, vy is the x and y velocity of the object. We are utilizing a vector dot product to get the velocity along the normal’s direction.

    vn=vx*nx+vy*ny

    So far so good. Next is to do the bounce by changing the velocity.

    You only need to do the bounce if the object is going toward the platform.

    Then the bounce is done by taking the velocity along the normal, converting it back to a vector by multiplying it by the normal, and finally subtracting that twice from the velocity. If you subtracted just once, then it would just stop motion in the direction of the normal.

    if(vn >0)

    vx = vx -2*vn*nx

    vy = vy -2*vn*ny

  • megatronx

    The hexadecimal digits each are four bits. So you can use them for four layers. See the key here, but you can find it elsewhere as hexidecimal to binary. In total you can have 32 layers or 8 hexadecimal digits. In the layout editor it's convenient to use hex to set the layers. In the event editor you can do it too, or you can take an existing mask and modify it with construct's bitset expression. 

    0 0000
1 0001
2 0010
3 0011
4 0100
5 0101
6 0110
7 0111
8 1000
9 1001
A 1010
B 1011
C 1100
D 1101
E 1110
F 1111

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I'm not sure why box2d is so jittery sometimes. Roughly, as I understand it, the way physics sims work is it moves stuff around with gravity and forces, then it loops over all the constraints (collisions and joints) to resolve them. It does that loop multiple times. The higher the iterations the closer to perfect it will be. In the case of rope with infinite iterations it should in theory be a perfectly stiff rope that doesn't stretch at all.

    Anyways, aside from iterations you should be careful with vastly different masses, that also can make things more unstable with something like a rope. As least from tests and what i've read. Your other issue of the rope being pulled through smaller pegs may be helped by links closer together, bigger pegs or even using segments instead of circles for the pieces of rope.

    I did this event based rope based physics to test some stuff out. It's probably much slower than box2d but the results are pleasing to me. The length of the rope is limited as you drag the rope around. Some things such as the pinned end and that it only works with one rope are hard wired in so far.

    dropbox.com/s/8vobbfougch0edt/verlet_rope_test.capx

    Here's also a quick modification to make it similar to you c3 project. The end is moved with the 8dir behavior and it's momentum is set to 0 so it kind of drags behind if the rope gets momentum.

    dropbox.com/s/c7ikyff1z4b7mtl/verlet_rope_test_8dir.capx

    Not sure either are useful. They are mostly just tests for fun. The first half of this post is the helpful part.

  • Hi,

    No, I don’t know why it doesn’t work anymore. Could be peerjs since as I recall it talks with their server to connect stuff together. Also I only have the vaguest idea what Cordova is. It never interested me.

    Anyways, never hurts to ask. I still pop in to read here and there. I’m not updating/fixing plugins though.

  • You can change the "steps" variable to control the strength of the light. The default is 20, which makes a 20*8 or 160 pixel radius light.

    Color light is probably done the same way you'd color lights with the shadow caster.

    Here's one way that doubles the amount of objects. Basically a layer to do the shadow, and another layer with the light color which is blended with the scene. This also animates the color and strength of the light.

    dropbox.com/s/y3m0iq02z0b3jbp/shadowtest7.capx

    Multiple lights would be done by doing each light separately and combining the shadow and color layers of each. As is the performance isn't good enough to do that. Also I'd want to reintroduce something like paster to handle the mixing instead of juggling layers.

    It's as far as I'll go with this for now. A significant speedup can be done by doing the floodfill algo with javascript, and the drawing should be simpler/faster to draw directly to textures for the shadows and colors. Less overhead at least, not my cup of tea to do that mixed with construct though.

  • WackyToaster

    Thanks

    I wasn't satisfied with the diamond shape, so here it is more rounded. Octagonal really. Also changed the falloff rate of light.

    dropbox.com/s/bw3lcf08ascchtv/shadowtest5.capx

    Another tweak to see if i could make it cast shadows instead of wrapping around as much. Ended up looking the same, but should do less checks.

    dropbox.com/s/tr4m8p6burf5uzt/shadowtest6.capx

  • Canvas is obsolete, but here is the third example done without paster at all:

    dropbox.com/s/xrukzy9cdv8p5az/shadowtest4.capx

    Paster just lets it blend more.

  • Had a go at attempting to replicate the effect, since it's not super clear how it works. I used C2 and the paster plugin for drawing and compositing. C3 may be able to do the drawing in some other way.

    My first attempt just used a shadowcaster blended with a radial gradient to do the shadows. Made lowres with a lower res paster object. The next step would be to do some kind of bloom to feather the lit area to light the surrounding walls. Maybe could be done with a shader, maybe. Anyways, I stopped there.

    dropbox.com/s/g068azvan5t3m7y/shadowtest.capx

    The next test did a kind of weighted flood fill to expand light gradually outward from a mouse click. When a wall is hit it wouldn't stop the light but make it reduce quicker. Used sprites as a test and only runs on a click.

    dropbox.com/s/0m9gm2fuqz5tdrn/shadowtest2.capx

    The third test used a weighted flood fill as well but in a different way. It referenced a tilemap for walls and used some arrays to keep track of stuff while flood filling. Paster was merely used here to draw the shadow area. The lit area is carved out with a destnation-out blend.

    dropbox.com/s/eo7iafxuoh3fsmz/shadowtest3.capx

    A hybrid between the first and third could look alright. Colored lights could be done with more blending modes with paster instances to do the multiple steps one by one. In C3 you may just need apply the ideas in a similar but different way since paster doesn't run there.

    Anyways just some ideas.

  • It’s still not 100% clear but I’ll give it a shot.

    So I’m guessing you have an object moving along the top line left to right, and you want a second object to be on the line below, so that both objects will hit the right yellow line at the same time while moving in parallel?

    If that’s the case set the second object’s speed and angle of motion to be the same as the first. Then you can either do

    Object2: set position to object1

    Object2: move 32 pixels at angle self.bullet.angleOfMotion+90

    Or you can do:

    Object2: set position to (object1.x+cos(self.bullet.angleOfMotion+90)*32, object1.y+sin(self.bullet.angleOfMotion+90)*32)

    Where the 32 is the pixel offset.

  • Guess I’m confused by what you’re describing as well. A diagram could probably make it clearer.

    Instead of an angle from one object to another, you’d like the angle from one object to the other if the other moved forward a bit?

    Or maybe you mean the two objects are both moving at the same angle. They’d be moving along parallel lines then. I’m not sure what you want to calculate though. A diagram should make it clearer though.

  • If the array is square you can set another array of the same size to be a rotated version. Here's a simplified version.

    for CW 90 degrees 

    array1: for each xy
-- array2: set at (array1.width-1-array1.curY, array1.curX) to array1.curValue

    for CCW 90 degrees 

    array1: for each xy
-- array2: set at (array1.curY, array1.width-1-array1.curX) to array1.curValue

    Long version on how that's derived

    2d rotation is defined by these formulas: 

    newX = (x-centerX)*cos(angle)-(y-centerY)*sin(angle) +centerX
newY = (x-centerX)*sin(angle)+(y-centerY)*cos(angle) +centerY

    Then we can simplify things when using say 90 degrees for the angle since cos(90)=0 and sin(90)=1. 

    newX = -(y-centerY)+centerX
newY = (x-centerX)+centerY

    Then we can simplify further since the array is square so centerX=centerY, and centerX = (array.width-1)/2. Plug that into the formulas and we get: 

    newX = -y+array.width-1
newY = x

    Using similar logic you could do rotation of non square arrays, you'd just have to flip the x and y sizes of the second array.

    I suppose you could do something clever to rotate an array in place, but I think it's much simpler to just save the rotation on something else and then copy it back to the original if needed.

  • Here's one way to do it. It basically just pushes balls out of each other by using the distance between them. Pushing the balls out of the wall is done by comparing the distances from the corners and edges of the wall's collision polygon and using the smallest distance. It defines the polygon with imagepoints as you can't access the actual collision polygon used by construct.

    Anyways, the value of doing it this way is we can then push the balls out of other balls and walls perfectly, plus we get the collision normal to then do a perfect bounce.

    dropbox.com/s/8t7mugpm6d8u5e9/ballvsConvex.capx

    A few usage notes:

    In the capx I just move the balls with two instance variables for the velocity (vx, xy) and one event to do the motion. It is equivalent to bullet motion.

    The bounce calculation is based on vx and vy, but if you wanted to do the movement with another behavior, you would disable the motion event and set vx and vy before the two events and set the behavior velocities afterwards. Here are some formulas to convert velocities: 

    vx = speed*cos(angleOfmotion)
vy = speed*sin(angleOfmotion)

speed = distance(0,0,vx,vy)
angleOfMotion = angle(0,0,vx,vy)

    Other thoughts

    It's a similar result to using the physics behavior (you can tell a physics behavior object to use a circle instead of the collision polygon). The bouncing angle has been more consistent from what I've tested. That is probably due to other things the physics behavior does to resolve collisions in a softer way in some cases.

    As with the physics behavior this solves the bounce after the objects are overlapping. Basically on overlap, push out, calculate bounce. Good enough almost always. A more perfect albeit slower solution would be to calculate the exact time of the collisions between each frame and using those points to solve for the bounces.

  • theseanmullins

    To move along the arc it is just moving along a circle. And you can do that with a bit of trig with:

    X = radius*cos(angle) +centerX

    Y = radius*sin(angle) +centerY

    So basically the code calculates the radius and center from the start and end positions.

    Angle is the angle from the center to the start point, which is then gradually changed to the angle to the end point. Basically a lerp, but I do it here with t. we make t go from 0 to 1 and stop at 1.

    Angle = startAngle +180*t