R0J0hound's Forum Posts

  • With 2d sprites you'd have to draw them lit from different sides I suppose.

    It may be enough to just have a gradient sprite over the flash with the additive, screen, or lighten blend mode though. You could even give the impression of a brighter flash by darkening everything underneath first. With more layers, or the drawing canvas you can mix and mask multiple light gradients with a sprite with blend modes. It's just something you'd have to fiddle with. If you find any information about how to do such a thing in photoshop or something the ideas may transfer.

    For more advanced lighting you could look into a normal map lighting effect. There is a built in one where you place the sprite, then a sprite on top to use as a normal map, and give the effect to that and provide the light location as parameters. There is also a third party effect that has more features. Anyways, the busywork to drawing/generating the normal maps of the sprites.

  • Forget about the previous touch location. Just use the distance between the sprite and touch to know if you want to simulate a control or not. Seems smooth on my end.

  • An alternate to using css, blend modes, or the drawing canvas to do it would be to use a mesh distort.

    dropbox.com/scl/fi/tstr83o5l7mixoeayie2v/Rounded_sprite_mesh.c3p

    You could use the approach to crop to any convex shape and even some concave ones, but not all.

  • Construct doesn’t have 3d collision detection yet. So collisions are just 2d. Hence only the base getting collided with.

    At this point you’d have to roll your own 3d collision detection or find someone else’s solution to that and use that instead.

  • Yeah it’s been like that since Construct 2 first came out. It was noticed and asked about as I recall but it wasn’t changed. It would be something to find that post though.

    The difference only really matters for shapes placed perfectly on a grid at least. And mostly is just an issue with rectangle shapes. I tend to shrink the collision poly slightly, or shrink the size slightly, or do my own aabb collision check if it matters.

  • With JavaScript you’d have to save/load state manually with some api callbacks I think.

    Drawing canvas pixels and images/sounds loaded from urls aren’t saved either. You’d need some additional logic to save/load those.

    Everything else you listed should work fine. Things like hierarchies, timelines, flowcharts, etc… are just state and should save/load just fine barring any bugs.

    Event stuff like loops and variables will either not need to be saved/loaded or will save/load just fine.

    Sounds like the only thing you need to look at is async stuff. The file/network stuff makes sense to not work. Stuff running in a worker like finding a path makes sense that they wouldn’t work too.

    That said “wait for previous” should work with the “wait” and “wait for signal” actions since that is serialized.

    I don’t have a hard fast rule for all the async actions. They should be easy to identify since construct labels them all. I’d suspect a fair amount of them can save mid progress though.

    You could add some bookkeeping events around those actions to keep track of how many async things are running, and maybe when you want to save/load set a variable that prevents any new ones to start and wait till all the pending ones to complete before saving/loading. Just an idea.

    Anyways, just some thoughts.

  • To compare two separate instances of the same sprite type you could utilize a family with just that type to be able to pick two instances independently. Or you could pick one, save info about it to some variables, then pick the other.

    Personally I like a variety of the latter and pick one instance, save it's iid to a variable, then pick the other instance. As an example you could set up the events like this: 

    var i=-1

sprite: pick random instance
-- set i to sprite.iid

sprite: pick random instance
compare: sprite.animationFrame = sprite(i).animationFrame
-- sprite: set animation frame to self.animationFrame+1
-- pick all sprite
-- pick sprite instance i
-- -- sprite: destroy

    Generally I find using one sprite type for all the cards is the cleanest way to go. You'd just differentiate between to cards with different animation frames and instance variables.

    Here's a more complete example that could give you some ideas.

    dropbox.com/scl/fi/3y3ql8yvicyxklrcp0qbj/card_merging.c3p

    Besides that some like to use arrays or json to handle the logic and update sprites from that. I find it becomes rather hard to read as it looks more abstract, but it could allow you to avoid more of the picking system of the event sheet.

  • 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

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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