R0J0hound's Recent Forum Activity

  • I think it’s similar to when created objects are pickable. Destroyed objects are truly killed at the end of the nested events.

    You could set an instance variable when you destroy an object as a workaround. Then you could check the variable before picking to avoid re-picking instances that are queued up for being completely destroyed.

  • Mesh is a feature that lets you divide an object into a 2d grid of points that you can move around to distort it. You can right click on most objects in the editor to create a mesh and visually drag the points around. You can also do it with events. For example under sprite actions there's a "set mesh" and "set mesh point" actions. I refer to it as a mesh distort but maybe searching for the word "mesh" may help you find documentation or tutorials.

    I like the simplicity of just setting a face to use a sprite texture. However if you have animations with different sized frames or different origins per frame it won't look great. You could probably correct that by resizing and moving the shape per frame to compensate though.

    However I wasn't pursuing the 3dshpe method. Here is a Mesh distort method that keeps the frame origins and frame sizes.

    dropbox.com/scl/fi/8eod773bnyxw9z0wjba1k/3dRotate_sprite_mesh.c3p

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • To prop up a sprite in 3d it will require a 2x2 mesh distort and some math.

    You’d start with an unrotated sprite with a 2x2 mesh distort.

    Steps to do it for each corner is:

    1. Get corner position

    2. Subtract object center

    3. Rotate 90 on xz plane

    4. Rotate on the xy plane towards the direction you want to face

    5. Set the mesh point. But you have to divide x by sprite.width and y by sprite.height.

    The math for xy rotation of a point is:

    Rotx = x*cos(a)-y*sin(a)

    Roty = x*sin(a)+y*cos(a)

    Xy rotation is similar. Just replace y with z in the above formulas.

    In the end all those steps can reduce down to a relatively compact formula.

    But if following a math recipe isn’t your thing, you’ll have to wait till I have time to bake an example at a later date.

  • So things are just blurry when in motion but fine when not moving?

    Doesn’t sound like it’s something that has to do with pixel size or sub pixel positioning.

    Is it something you can take a screenshot of or is it just something you visually perceive when it’s moving?

    What’s your screen refresh rate? Have you tried setting the framerate mode in construct to fixed?

    If it’s a visual perception thing then running at a lower framerate could result in less smooth motion to break up the perceived blur.

    If you reproduce the game in another engine and it doesn’t have the motion blur it would be interesting to know why. It’s not something that’s deliberately added.

  • The arbitrary bone structure is rather easy. just place a bunch of joints, and stretch bones between joints, then just add revolute joints from each joint to any bones overlapping it. Muscles are done with an angular spring between pairs of bones to keep a specific angle between them.

    In this example I set it all up with overlapping sprites and some minimal events to add the joints and setup the initial state of the muscles. I also used a slider to be a runtime control of the joint angles. To control which way a muscle will turn I used the opacity to control that, but it's not the most intuitive imo.

    dropbox.com/scl/fi/fum80cv36619qgvbp407e/torque_muscle_structure.c3p

    Anyways, just an idea. You may want to do the setup in a different way. Also I just used the muscle sprites as a guide for the initial setup. You'd have to do your own thing if you wanted them to stay visually attached while it runs.

    You could also try lineal springs on anchor points (easier said than done), but I find angular springs avoid joints getting stuck inverted better than linear.

  • Connecting limbs with revolute joints (or limited revolute joints if you want to limit range of motion) and applying torques is a good way to go.

    I've found using a damped spring works well to torque a joint to a specific angle. The damping aspect is just to make it less bouncy.

    torque: -strength*signedAngleDiff(lowerArm.angle, upperArm.angle-160) -damping*lowerArm.physics.anglularVelocity

    Anyways, seems like pretty believable motion. You can even do kipping reps if it's too heavy.

    dropbox.com/scl/fi/2r00jno5uguu3epvdup7y/Physics_arm.c3p

    I'd imaging there's other ways to model an arm/muscle as well.

  • Besides being able to convert between rgb to hsv colors you also can get away with just generating the gradients once, and tinting them later with the color property.

    In this c3p the gradient generating code is commented out if you want to use it. Besides that the color conversions are just single line expressions

    dropbox.com/scl/fi/35l84rzbgh45zp467a2ts/color_picker.c3p

    Alternately I was interested in HSL and a circular color picker. Here is that.

    dropbox.com/scl/fi/wfqyelkd0rm3bzgk15h5l/color_picker_HSL.c3p

  • When you create a family instance it just randomly chooses one of the object types in the family and creates an instance from that.

    So to actually duplicate objects in a family you’d probably need to just copy the first two events multiple times and handle each object type in the family specifically. That or just use different animations of one type instead of families.

  • I’m guessing the speed difference is from the deceleration always being applied in the behavior after you set the velocity.

    So at 60fps the speed after deceleration is applied would be:

    300-5000/60 = 216.66

    And at 144fps:

    300-5000/144 = 265.28

    And at unlimited it could in theory approach much closer to 300.

    Which seems to match with what you’re seeing where 144fps makes it go faster.

    You could try setting the deceleration to 0 when you’re pressing buttons, and set it back to 5000 otherwise. Or maybe you could utilize the simulate control action, since I’m pretty sure deceleration isn’t applied when you tell the behavior a control is pressed.

    I guess we could suggest to have deceleration disabled any frame we set the velocity from the behavior itself, but I don’t think that’s a good idea and would result in many more issues so I’d do one of the other two ideas.

  • Here's one way to do it that's basically what you described:

    dropbox.com/scl/fi/lfmr9x6woehinwv3unnsf/dropshadow_idea.c3p

    The meat of it is the instances are duplicated and placed on the shadow layer. Then to position the shadow you need to access the position (xy) of the instance it was copied from and then you position the shadow with:

    set position to x+(x-light.x)*0.1, y+(y-light.y)*0.1

    The way I handled pairing the instance duplicates is by storing the uid of the shadow instance in the original instance then doing some picking juggling. There are probably other strategies with various pros and cons.

  • You may be able to get a more organic crowd by experimenting with Boids and Steering Behaviors:

    red3d.com/cwr/steer/gdc99

    In practice you have a lot of things you can tweak to get all kinds of different behaviors. Here's one possible result for a jostling crowd that moves around in groups. Left click to have it pursue the mouse.

    dropbox.com/scl/fi/a1mmcm9ty5hpjrz9hgpx9/boids_test.capx

    In some ways it resembles a crowd but it may be more like a living slime kind of thing. But there is a lot of room to tweak to make it behave differently. Anyways, just an idea that could be explored more.

  • If you're not tied to a tilemap you could do the roads with a few crafted overlapping sprites placed in a grid.

    Namely with these 5:

    You could do roads like this. Although making dedicated intersection could look cleaner.

    dropbox.com/scl/fi/eidz69wqyodpz52h2896d/road_pieces.capx