R0J0hound's Recent Forum Activity

  • Here is the sorting with the perspective you're using.

    dropbox.com/s/m1p2f090xmqa230/alt_iso_sort.capx

  • I like how simple alextro's formula is. Unfortunately that will only work with isometric blocks with the same size.

    For different sized blocks you need to figure out which objects are in front of the other. Consider the simplest case of two blocks. This site does a nice job at explaining a way to do that:

    bannalia.blogspot.com/2008/02/filmation-math.html

    Once you have a way to decide which of any two blocks should be in front of the other you can use that to progressively sort the scene. You only need to sort objects visually overlapping each other. For making everything sort more instantly, you can use a topo sort if needed.

    In my latest tests I've found the step of figuring out which of two blocks should be in front of the other is closely related to pushing one object out of the other for Collison detection. Basically find the normal of the collision/overlap of each pair. Even if the objects aren't overlapping in 3d it's possible to find this normal. If you're not familiar with normals, they are just the 3d direction from one contact face to the other object.

    Anyways with that you dot product the normal vector with the direction of the screen. If <0 then one object is in front, otherwise the the other is in front.

    Here's a test of that.

    dropbox.com/s/9veb43lyxd7bja0/iso_sort3simplified.capx

    Anyways, for the perspective you're using it will be simpler than sorting for a isometric view, but the idea is similar. I was attempting to adapt my example to your perspective but not much luck yet. Hopefully it gives some ideas, or you stumble on a simpler solution.

  • Link now fixed. Guess I need to verify the links I’m copying from Dropbox. That’s been happening a lot lately.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • alextro

    Ah, thanks man. That's at least the second time i've done that this week. Link fixed now.

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

  • 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