R0J0hound's Forum Posts

  • That’s trickier. One quick way could be to use the line of sight behavior to see if a wall can be seen by the player and if it is move the wall to a layer above the shadows.

    Otherwise I’d give it more thought and do the shadows another way. Probably drawing them with the canvas plug-in.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Chat gpt created the question? That’s a new one. I thought people used it to get answers. Any particular reason you don’t just ask the question directly? I may just be confused though.

    Anyways, since construct is a 2d engine you can use the shadow caster behavior to do shadows. But since you write walls maybe you mean on a 3d shape? In which case it’s a pain to do since the engine isn’t built for it. But search the forum and you can find some complicated solutions of sorts.

  • Example:

    dropbox.com/s/wmra64o0xervngk/rotateAroundCenter.capx

    You can do it in the editor as well. Select the objects, press enter and then you can rotate them together.

  • Yes, I thought that’s what you were after and that’s why I posted it.

  • Here’s the documentation for accessing MIDI devices:

    developer.mozilla.org/en-US/docs/Web/API/Web_MIDI_API

    It shows how to do it and where it’s supported. However you’ll probably want to have a MIDI device first to test it or even attempt utilizing it.

    Playing MIDI files is different. You can already play audio in construct and change the pitch. Look at any example that has a piano.

  • It’s events. Make three variables names centerX, centerY and a. Set them to whatever you want. Then make an every tick event and add a set position and rotate action for those objects and use those expressions.

  • You can do this to rotate around any center. 

    Var a, centerX, centerY

Set position to (self.x-centerX)*cos(a)-(self.y-centerY)*sin(a)+centerX, (self.x-centerX)*sin(a)+(self.y-centerY)*cos(a)+centerY
Rotate clockwise by a degrees

  • You probably could get pretty close with the physics behavior. Make a joint between the player and apply a torque to the sword. The only downside is you’ll want to do all the motion with the physics behavior since it doesn’t work with other behaviors.

  • In general most behaviors the motion is good enough, but seldom 100% precise. I think what happens is the moveto behavior discards the overshoot.

    Anyways, here's a way to do near perfect path motion so the object's stay spaced the same. They are transparent and next to each other so if it would show desync if it happens. Additionally you can toggle that disabled action to avoid even more numeric drift.

    The gist is it moves in direction of a waypoint, and when the waypoint is passed it carries over the extra motion when it moves toward the next node.

    dropbox.com/s/5bg83cgrpv9k8tn/node_path_follow2.capx

    Edit:

    And the idea can be taken further. This one supports any speed.

    dropbox.com/s/vow1i2x2rcteee6/node_path_follow3.capx

  • There are a lot of ways to do that. I've seen the timeline used to make the paths, or the pathfinder behavior to move through waypoints. Here's a way that just moves the objects toward node sprites. Once it hits a node it moves to the next one and so on. I use the group instance variable to have multiple paths.

    dropbox.com/s/ig67mil486eh9ou/node_path_follow.capx

  • Hmm, well I'm sure it's probably similar to any other js library. But you can do it with events. One number for the significant digits and one for the exponent. Then just some functions to do math between them.

    Possible example.

    dropbox.com/s/n7vzo5y4q9mdhzz/bigNum.capx

    Something like:

    bigSet("2e1000")

    bigAdd("9e1000")

    will result in "1.1e1001"

  • Probably some edge case as you say. Behaviors can run before or after the event sheet, or both. That is done per behavior.

    If you are really curious about what the platform behavior is doing you can look at the source of it in c2 as it’s similar. Or you can find it in c3 when you preview. Open the browser debug console, sources tab and it’s one of the files.

  • I mean the gist of method 3 is it updates the position first with gravity, then the velocity. What you’re doing seems to be undoing a velocity update and it would be 100% accurate if the next frame has the same dt.

    Can’t say why that’s needed.

  • I think your first post is mainly due to how the time of collision will vary according to the framerate. With a low framerate the objects can be overlapping a fair bit when a collision is triggered. With a high framerate the collision will be triggered closer to when the object just come into contact.

    Framerate independence mainly just ensures the motion is consistent between collisions for any framerate.

    Here's a test of different ways to do the integration for projectile motion, aka jumping. It also tests what they do at some different timesteps. The first method undershoots at lower fps, the second overshoots, the third is perfect at all fps, and the last is wrong.

    I also compared it with the platform behavior, and it is using the perfect method when jumping off the ground, and actually is improved over how it was in C2.

    The difference between jumping in the air, and jumping on the ground could have something to do with the logic to handle moving platforms but that's just a guess.

    Actually looks like it's using method 3 when on the ground and method 4 when in the air.

    dropbox.com/s/a5qzfvv7y18c3hy/plat_dt_test.capx

  • The blocks are in contact with each other so they count as overlapping.

    The triple loop isn’t bad since the amount of iteration get lower rather fast.