R0J0hound's Forum Posts

  • Probably can do it with a maze generating algorithm. Or something like that.

    en.m.wikipedia.org/wiki/Maze_generation_algorithm

    Edit:

    One possible way using prim's algo.

    dropbox.com/s/58l1kqgcdlse96x/primsAlgo.capx

  • It’s a special thing. There are many ways to do it.

    Here’s one possible way.

    construct.net/en/forum/construct-2/how-do-i-18/resize-handles-example-48892

  • Oops. I’ll need to fix that and reupload. You’d add it to the velocity update event.

    Set vx to (self.x-self.px)/step*damping

    Set vy to (self.y-self.py)/step*damping

    Let me know if there are any other features needed.

  • Ah, I see what you mean. You want damping. Re-download from my post.

    There are two ways you can introduce damping. One is to change damping from 1 to say 0.995. Another is to make the timestep bigger, so change step from 0.0005 to 0.005 or something. I had used a small step initially so that the balls would end up about the same height.

  • I agree with dop, seeing a project or at least a picture of your events would be helpful. Best I can guess it's likely some small logic or picking aspect you're overlooking with your events.

  • It’s no waste of time. It’s something I’m interested in and it was fun to try it.

    The gravity is handled by the “add 400*mdt” action. You can change the 400 to adjust the strength of it.

    I didn’t include mass, which would allow you to make things heavier. But that would only change things if you applied a force, impulse or deal with collisions or a joint between objects. As is, the joint with the layout and gravity would be the same regardless of how heavy the objects are.

    Anyways, if you wanted to apply an impulse and take mass into consideration you’d do:

    Add impulseX/mass to vx

    Add impulseY/mass to vy

    It’s best to not touch pTime. That would just advance the simulation forward in time more. It wouldn’t conserve energy.

  • Here's a simple test of event based physics that will update at the same rate regardless of the screen refresh rate. So motion of objects will be consistent.

    dropbox.com/s/c8ynrpg5ribps1p/smooth_fixedstep_physics.capx

    The physics is done with verlet integration, and uses a small step so it's more accurate and loses less energy over time. The position is interpolated between simulation steps to give smooth motion with different fps. I followed your example video and made it connect with a distance joint when below a certain point, and then remove the joint when above.

    Anyways, the physics is pretty bare bones. Objects falling with gravity with optional joints to the layout per object. More deluxe physics can be made depending on what's needed.

    For something simple like this we can go a step further by finding equations of motion so we get the exact path without energy loss, but that may be a bit of a overkill.

  • With a varying time step what the y is when you add or remove the joint will vary, which is why the height differs.

    One way to have it repeatable is to use a fixed time step so the y position will be consistent. Of course the sim will run twice as fast at 120fps.

    I’m don’t think there’s much you can do with the builtin physics behavior to make it more repeatable.

    If you did the physics manually you’d have more control. Such as updating at a fixed rate and lerping in between steps. Or calculating the exact time to add the joint and use equations for the exact motion of a kinematic body and a pendulum.

  • The transparent part should be pretty straightforward. Make the bottom layer transparent and make the html div element the canvas is on transparent as well. You should be able to the have that div overlay the rest of the website. Anyways, that’s the rough idea and can give some points to google.

    Having input events pass through the canvas to the website below is another matter. Be default input is absorbed but there may be a way to let it pass through with JavaScript. Worst case you’ll have to manually remove event handlers the construct has by default.

  • Poor guy always seems to look like a smashed can after he falls.

  • It certainly is a sore point as projects get bigger. Would be nice if the editor could point us to those things but I guess having some dummy layouts to store global layouts and default instances is what we’ll settle with for now.

  • Sorry, this isn't on my radar for things I'm interested in doing currently.

    If anyone else is interested in attempting this it basically amounts to taking the official canvas plugin and changing the paste function to draw immediately instead of deferring to when the frame is rendered. Likely C3's renderer is designed to setup most of it's state when the frame is rendered. Also that is likely the point where any culling occurs. Both those things mean there will be some set up that will need to be done with care to not break what the render later expects.

    Overall I imagine it may be fiddly to setup, and probably has a high chance of breaking with construct updates. I'm more into one-off projects that only need to be updated for fun as of late. I'm less interested in something that requires a lot of maintenance and requires compatibility with most other construct features.

    Anyways, looks like a cool project. There's probably a way to utilize a canvas to do split screen, but not having it draw immediately is inconvenient (it basically complicates it). I haven't really used it but you could use two canvases to display the second screen. Basically any given frame one of the canvases would be on screen where you can see, and one is offscreen being drawn to. The only drawback is what you see will be one frame behind, which may be ok?

    Decided to test the idea:

    dropbox.com/s/pkjhiiaumiebo4t/split_screen.c3p

    Seems to work well, but like in C2 the tilemap won't draw tiles that are offscreen. In C2 the solution was to temporarily move the tilemap onscreen but I don't have a solution for C3. Likely particles have a similar issue.

    Anyways, cheers.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You're not doing anything wrong, most behaviors just aren't very robust when dealing with collisions.

    One solution is to use the physics behavior to handle the collisions. Just set the velocity of the player.

    Another way is to just handle collisions and collision response with events:

    dropbox.com/s/msb4cz5sqle5one/better_collisions_sdf.capx

    The above treats the player as a circle and works with boxes and circle walls.