R0J0hound's Forum Posts

  • Here's a test using verlet physics since I've been using that a lot lately. Looks more like a pony tail, but if using a distort mesh stretched over the points it may look better.

    dropbox.com/s/niureg675c6ae8h/scarf_verlet.capx

    Further test adding wind and air resistance. Events got a bit messy. Not super happy with the wind.

    dropbox.com/s/37fi58li47jpspc/scarf_verlet_wind.capx

    There are probably other creative ways to make more appealing scarfs.

  • Here is a test of keyboard controls. It involves two steps:

    1. find the minimum and maximum y of all the points.

    2. apply an acceleration to the points while a key is down. It uses the previous ymin,ymax to apply more acceleration to the top points than the bottom points. This causes the object to roll.

    The formula used is: 800*mdt*((self.Y-ymax)/(ymin-ymax))^10

    (self.Y-ymax)/(ymin-ymax) gives a value from 0 to 1 for each point. The top points will have a value of 1 and the bottom have a value of 0. It's changes linerarly for the points in between. I added the ^10 to give it a steeper curve. Basically with that the points at the top will still have a value of 1 but more of the points below will have a value closer to 0.

    The 800 is the force, and mdt is the timestep.

    Can be read as a force of 800 is applied to the top of the blob. The force bleeds to some of the points close to the top but most of the low points will barely have any force.

    I only did it for the plain c2 version but it should be simple enough to add the the others. Events 7-12.

    dropbox.com/s/s1m388u87wbajn0/jello_no3rdParty_keyboard.capx

  • Yes, that’s what I meant. That else will only run if none of the previous ones run.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Sorry didn’t see the other posts above my reply. Dividing by dt doesn’t sound like a great idea. Should be multiplied. Dividing by dt would make it faster at higher refresh rates.

    100*dt would be 100/60 at 60hz and 100/240 at 240hz. Which is correct.

    When you divide

    100/dt would be 6000 at 60hz and 240000 at 240hz. Which doesn’t seem right.

    Also your last post seems to be going opposite to the suggestions by going from using dt to a fixed step.

    Anyways, as to your other question, no, there isn’t a way to make the game use a fixed refresh rate. There have been attempts at ways to do it but it’s overly complicated and doesn’t really work with behaviors and such.

  • I’ve done that with a local variable. Set it to 0 those events, then set it to 1 in all three events. Finally replace the else with a comparison to see if it’s 0.

    Local number else=0

    Event 1: set else to 1

    Event 2: set else to 1

    Event 3: set else to 1

    Compare else=0: do something

  • Typically motion is done utilizing dt so it runs the same speed regardless of the framerate.

    So say you pc's screen updates at 60hz, you could make an object go 100 pixels in a second with:

    set x to self.x+100*1/60

    but if someone has a screen that runs at 120hz the object will move twice as fast with that.

    It is corrected by utilizing dt. This will move the object 100 pixels in one second no matter the framerate:

    set x to self.x+100*dt

    Now, all the motion behaviors utilize dt for you so everything should run the same speed regardless. Although there is no built in z axis motion behaviors so you'd have to look into how you're doing that and see if dt is utilized.

    As a side note, parabolic motion (like a jump or an object being thrown and falling with gravity) could be done with:

    var gravity=500

    add gravity*dt to velocityZ

    set z to self.z + self.velocityZ*dt

    However, that's just an approximation and can cause the utimate jump height to vary a bit at different refresh rates. It can be made more accurate like this.

    set z to self.z + self.velocityZ*dt + 0.5*gravity*dt*dt

    add gravity*dt to velocityZ

    Construct 3 already does that with the platform and bullet behaviors with it's gravity, but it may be useful if making the motion with events.

  • My apologies, using family1(family2.iid).z won't work. We can only utilize iid to access different instances of the same type, not family. Guess there's always something new to learn.

    Here is a test of three different ways to access and set values of two different instances.

    1. family vs family containing the same types.

    2. type vs family with just that type. (by far the simplest imo)

    3. type vs same type.

    dropbox.com/s/82wzrtp796gjbnj/twoInstances_sameTypeOrFamily.capx

    In general you can just pick one at a time and store the instance variables to some other variables, so then when you pick the other object you can have values to compare to.

    Another option is to use a function to get/set values from different objects. 

    on function "get"
-- number var uid=-1
-- text var name=""
-- set uid to function.param(0)
-- set name to function.param(1)
-- family: pick by UID: uid
-- -- name="x"
-- -- -- function: set return to family.x
-- -- name="area"
-- -- -- function: set return to family.area

  • Here's yours fixed. Sub-events were setup incorrectly, and didn't use family(i).x.

    dropbox.com/s/ux4ehxdhchi7kas/BOX_TESTrojo.c3p

    Here's the other idea, just simpler.

    dropbox.com/s/1vw46xaxwmul7su/shuffle_sprite_positions.capx

  • Sorry for the delay. May take a bit longer for me to open the example since I’m not on my computer.

    But my guess is what I wrote doesn’t make it completely clear what is a sub event and what isn’t.

    In the meantime here’s a slightly different idea. If the objects aren’t all the same type then put them in a family. The create another sprite marker, and make it invisible. 

    On click
— destroy marker

On click
For each family
— create marker at (family.x, family.y)

On click
For each family ordered by random(1)
Pick nth: marker instance loopindex
— family: set position to marker

    Anyways, just an idea. If you placed the marker sprites down over each object in the layout you wouldn’t need the first two events.

    I’ll make an example of both when I get a chance.

  • Ah, I know that issue well. Events don’t excel at dealing with two instances of the same type independently.

    Personally I like just having a single type, putting that into a family, and adding the instance variables to a family. That way you can use picking to get two separate instances and still access the variables for both.

    I’ve attempted to two family method but I ran into the same issue. Can’t access the instance variables in one of them.

    A third tool we have is sprite(2).x. That expression will give you the x of the sprite with iid=2 no matter what is picked, and it will work for any property.

    So for your example you probably could do a hybrid of iid and the second family idea. The instance variables would be added to family1, and the second family2 would have the same objects and would be used to utilize the overlapping conditions. Anyways to access the variables from a family2 instance you’d do family1(family2.iid).z.

    In theory something like this would then work. I’m going with the premise that family1.iid and family2.iid have the same value for the same object. 

    Every tick
— family1: add 300*dt to vz
— family1: add self.vz*dt to z
family1: z>0
— family1: set z to 0
— family1: set vz to 0

For each family1
Family1 is overlapping family2
For each family2
Compare family1.z<family1(family2.iid).z
Compare: family1.z > family1(family2.iid).z-family1(family2.iid).zheight
Compare: family1.z< family1(family2.iid).z+family1.zheight
— family1: set z to family1(family2.iid).z-family1(family2.iid).zheight
— family1: set vz to family1(family2.iid).vz

  • Here’s one idea. You can put all those sprites in a family to simplify the events. Basically you’d swap the positions of random pairs of the objects. 

    Var i=0
Var xtemp=0
Var ytemp=0

On button clicked
Repeat 10 times
— pick random family
— — set i to family.iid
— pick random family
— — set xtemp to family.x
— — set ytemp to family.y
— — family: set x to family(i).x
— — family: set y to family(i).y
— pick family instance number i
— — family: set x to xtemp
— — family: set y to ytemp

  • Sure, the physics is a position based dynamics simulation, so you just need to move the points.

    left is pressed

    — p: set x to self.x-100/60

    Just put that event towards the top of the event sheet. That would move it left at 100pixels per second at 60fps.

    But we can probably do better. Instead of moving all the points we could move the top ones more than the bottom ones, which would let it roll.

    Var ymin=0

    Var ymax=0

    For each p

    — set ymin to loopindex?min(ymin,p.y):p.y

    — set ymax to loopindex?max(ymax,p.y):p.y

    Left is pressed

    — p: set x to self.x-(self.y-ymax)/(ymin-ymax)*200/60

    That should move the top points more than the bottom ones. Might need to change the 200 if it doesn’t move it enough to roll.

  • I think it’s in notification settings under construct 3 updates. I have both turned off but hopefully the second unnamed one is that

  • I guess you could give the bowl more mass or the balls less.

    If the balls are still leaking through then you are running into the limits of what that particular physics engine can do. Probably need to reduce speeds and make things move more gradually like changing the 10 to a smaller value. That or make things bigger. Those things and my precious suggestions in theory should help prevent objects from passing through each other.

    I think overall the physics engine was made to be general purpose and work pretty well. It is possible to break the simulation pretty easy though. When that happens you just have to dial things back I suppose.

    Reduce speeds, enlarge objects, make the masses more similar. Might be able to make it run better by increasing the iterations of the simulation. There’s an action for that. Not sure.

    The alternative is to scrap using the physics behavior and just devise a way to keep the balls from moving through walls with raycasts or something. The con of that is the rest of the physics would need to be done too. I don’t really think a hybrid approach would be any easier than from scratch.

  • Ah. Yeah I did link the wrong file. Fixed now.

    It uses the 8-direction movement and does the z axis movement with events. It toggles the solid behavior as needed and checks what blocks are above and below the player to handle z-axis collisions.

    Camera controls are completely independent of this. So I didn’t move it at all.