R0J0hound's Forum Posts

  • There's a bunch of ways you can tweak it. The motion is done with verlet integration currently which just infers the velocity after moving objects apart. We could change that to deal with the velocity change with each collision instead. That probably would fix the explosions where crowded objects end up moving rather far and get a lot unintended velocity because of it.

    Having bigger objects, slower speeds, and simulating in sub steps (kind of like the physics behavior iterations) are also few ways to make it more stable. Even the physics behavior itself has a threshold where it breaks under pressure.

    Utilizing the velocity to do a continuous collision detection is an idea, but it would be more complex and slower to do.

    Also there's no reason this can't handle different sized objects. It just needs some reworking.

  • To my best understanding you'd add a cube and set the six texture faces to relevant images. Then you'd center the cube on the 3dcamera's position. Then just rotate the 3d camera to look around.

  • MyXpandaZ calminthenight

    The simulation is rather basic so I can lead to instability.

    I'm not sure how you're moving the sprites toward the target, but it's better to set the velocity than setting the position, and better than that is to gradually change the velocity. In general that allows everything to be more stable. Another thing you can do is limit the max speed the objects can move. Another solution is making the push out less rigid. As is it pushes each pair out of each other completely in one go, but changing it so it only moves apart 25% of the way or lower will smooth things out more. Look for the js line that sets dist. There should be a /2 at the end. Change that to /10 to make the pushout softer.

    I probably need to revisit this to clean it up.

    Here's were I tweaked the example from last week but it deviated a fair bit as I was messing around with various ideas. 

    https://www.dropbox.com/scl/fi/adgm5izhyk7indhjbqlz4/spatialGridJS2.c3p?rlkey=oafjw813djgai8x9pddbaq6ke&dl=1

  • If instead of a random area outside the screen you just want a random spot on a rectangle bigger than the screen you can do this. The var k sets how much bigger the rectangle is beyond the edge of the screen and r does a calculation to make the random more uniform. If we just set r to choose(0,1) the short sides would get more points. 

    var x=0
var k=16 //0 would be edge of screen, 16 would be 16 pixels beyond the edge of the screen

set r to random(1)<(OriginalWindowWidth+2*k)/(OriginalWindowWidth+OriginalWindowHeight+4*k)

set x to (r?random(-k,OriginalWindowWidth+k):choose(-k,OriginalWindowWidth+k))+ViewportLeft(0)
set y to (r?choose(-k,OriginalWindowHeight+k):random(-k,OriginalWindowHeight+k))+ViewportTop(0)

    Or if you wanted a point outside of the layout instead of the screen: 

    var x=0
var k=16 //0 would be edge of screen, 16 would be 16 pixels beyond the edge of the layout

set r to random(1)<(LayoutWidth+2*k)/(LayoutWidth+LayoutHeight+4*k)

set x to r?random(-k,LayoutWidth+k):choose(-k,LayoutWidth+k)
set y to r?choose(-k,LayoutHeight+k):random(-k,LayoutHeight+k)

  • Yeah, that looks pretty good. I wish I could knock out good art that quick.

    Here's the idea I was working on. It needs to be reworked to handle multiple vines and the transfer of momentum when grabbing the vine needs tweaking. 

    https://www.dropbox.com/scl/fi/selt7na61fdxs7xkw7zx2/rotate_vine.capx?rlkey=qcom7w4ienynvdjen2r68oyza&dl=1

  • Here's one way. 

    https://www.dropbox.com/scl/fi/tbsd0woz3v14csc10q8mz/array_combine.capx?rlkey=m5kqrkoo9m8g0thdttvnxg1ve&dl=1

  • Looks like he found a a nice solution. My guess it’s a nice animation and it moves along the vine segments. Not bad.

    twitter.com/PD_CGT_games/status/1708700907238539702

  • I think calculating the path in a more dynamic way could be possible too. A reason for that could be you want the spinning to start where you first grabbed the vine, or if the shape of the vine is dynamic.

    The first step would be to have a curve fit the shape of the vine, then find the point on the curve that was grabbed.

    After that it’s a matter of moving along the vine, and the spin is done by moving along an angle perpendicular to the vine with a distance of 32*sin() or something. You can use cos() for the zelevation or use it to change the zorder. Finally when the end is reached you’d enable the platform behavior and set the speed.

    The coiled path around the vine could be refined further by doing some relaxation filter or something. Maybe overkill but it seems to kink a bit otherwise.

    I’ll finish up an example tomorrow and see if I can simplify the solution further. At this point I only have twisting around an arbitrary path.

  • It just uses whatever blend mode the object is currently using. So you’d need to set the blend mode before pasting. (And probably set it back to normal after).

  • It would be nice to have access to collision cells from js, so it’s a valid request.

    Still I suspect making a spatial partition in js could be faster. I made a rudimentary grid hash and even outperformed the physics behavior which does its own spatial hash behind the scenes.

    If I attempt it again I’ll reference this. Seems fast enough. And it builds the spatial partition every frame.

    matthias-research.github.io/pages/tenMinutePhysics/11-hashing.html

    github.com/matthias-research/pages/blob/master/tenMinutePhysics/11-hashing.html

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • When picking becomes a problem I try to do things in a way that does less picking that looks cleaner if possible. One idea is to make getter/setter functions with uids. Another is to use one data structure object such as json to store all the data.

    JavaScript works too but it has its own set of annoyances so pick your poison I guess.

    I’m always trying to find ways to do stuff in simpler, cleaner ways, and some kind of system on top of events to abstract away complexities often come up.

  • Sounds like fun. But I like math and replicate behaviors with events anyways.

    There is value in working within constraints.

    Making an event based drag and drop is useful. I can think of two times at least where I had to do that since the behavior didn’t give sufficient control of when to drag and drop.

  • You can set the velocity toward the position of the other object.

    So once you get the angle toward a position you can do:

    Vx=speed*cos(angle)

    Vy=speed*sin(angle)

    But there are other ways.

  • You can access individual letters with the mid() expression. The tokenat() expression can be useful to grab individual words if there are spaces in between. To filter around punctuation you can remove them first with replace() or maybe regexreplace to remove all punctuation in one shot, but that can be tedious to do.

  • The non-behavior way is to compare the distance between each pair of objects and push them apart and update their velocities if they are too close. That doesn't scale well with such a large amount of objects, so we need to do some kind of spatial hash so we only need to check objects that are nearby. Unfortunately when doing it with events it's hard to get that much of an improvement so JavaScript is better.

    Here's one possible test of that. It handles one object type and treats them all as the same size. Disable the group to compare performance with the physics behavior.

    dropbox.com/scl/fi/ja4hfo7dv9sqq7phs1q25/spatialGridJS.c3p

    With 1400 objects:

    Custom push out: 60fps

    Physics: 10fps

    The example also does it's own physics, but you can just use the spatialGrid() function if you just want push out.