R0J0hound's Forum Posts

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

  • 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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

  • Depending on how deep you want to go you can get 3d collisions with a bunch of math.

    Using oosyrag's idea you can see if two boxes also overlap on the z axis with: 

    box1 is overlapping box2
box1.z>box2.z-box1.depth
box1.z<box2.z+box2.depth
-- do something

    Or if you want to find the next box below the first box: 

    box1 is overlapping box2
box2.z<box1.z+box2.depth
pick box2 with highest z
-- do something

    Pseudo logic of utilizing that could be: 

    move on z axis
if overlapping in 3d: move up
move on xy
if overlapping in 3d: move backwards

    More finesse is needed to make it smooth. To have wall sliding or some more robust collision response you'd need SDFs(signed distance fields) or SAT(separating axis theorem) or probably some simplification of those.

    Heightmaps are also a technique to do terrain. You just need either a function that gives a height for an xy position. That can be done either with some equation or sampling an array of values with interpolation or sampling from a noise function.

    After that it can get a lot more complex. In general a good practice is trying to to do collision detection and response in 2d first with just events or js. Most of the ideas do carry over. Overall it may be more involved than most want to deal with.

    Here's a possible example of being able to jump on and go under 3d blocks. There was more nuance than I anticipated, but maybe it's useful.

    dropbox.com/s/4j93hionaa1c6qn/simple3dplatformer.c3p

  • Here's one idea:

    Attach the bowl to an immovable physics object with a revolute joint.

    Then change the angular velocity to turn toward the angle you want.

    Details with some more explanations:

    dropbox.com/s/fp0hrl9f73f10yh/physics_rotate_bowl.capx

    In general think of setting angle or position of physics objects as the same thing as teleporting. In your example you set the angle directly so if you rotated the bowl object fast enough the balls could suddenly be on the other side of the walls of the bowl. The physics engine won't think the balls went though the walls.

    However when setting velocities the physics engine can do it's magic to avoid jumping through walls. Especially if the "bullet" setting is enabled which does continuous collision detection.