R0J0hound's Recent Forum Activity

  • I don't have all the plugins required to open your capx. If you want to attach objects together like that then yeah, joints would work. There are probably some examples in the forum that do that.

    If the original cell is the same object type as the other cells then you'll need to do a forum search on how to pick two different instances of the same type so you can attach one to the other.

    Once you can do that then the pivot joint combined with a gear joint is a useful way to attach two objects together (there's an example of this in the chipmunk topic). If the attached objects overlap at all they will jitter around so it's also to put connected objects in a collision group so the ignore collisions with each other.

  • It is faster but I'd go with what was more readable.

  • dellong

    If you look at the source of the example, paperJS only does the drawing part. Everything else is done with code.

  • Joints won't help in this case, and in your image you're creating a joint with itself which does nothing. what you want is to apply a force to all the objects to an average center. Here's one way:

    global number centerx=0
global number centery=0

every tick
--- set centerx to 0
--- set centery to 0

for each sprite
--- add sprite.x to centerx
--- add sprite.y to centery

every tick
--- set centerx to centerx/sprite.count
--- set centery to centery/sprite.count
--- sprite: apply force polar(angle(self.x,self.y,centerx,centery), 100)[/code:1187k6ok]

I used a force of 100 but that could be changed.  You could even make it proportionate with the distance from the center.  
Further ideas include applying the force to the average center of only the particles in a radius around each particle.  You could also do a repelling force between the sprites to keep them away from each other.  It would give more of a fluid motion.  You'd have to tweak it in such a way so the attracting and repelling forces balance.

Here's some fluid experiments i'be done before:
[url=https://www.scirra.com/forum/viewtopic.php?f=147&t=116854&p=842125&hilit=fluid#p842125]viewtopic.php?f=147&t=116854&p=842125&hilit=fluid#p842125[/url]

And here's one from today:
[url=https://dl.dropboxusercontent.com/u/5426011/examples31/chipmunk_blob.capx]https://dl.dropboxusercontent.com/u/542 ... _blob.capx[/url]
To make it more fluid like I made the sprites be in a collision group to disable collisions between each other.  Then I compared the distances between each pair and repel or attract depending on the distance.  The forces are proportionate to the distances using a spring equation: Force=-k*displacement.  To add to the stability I gave the sprites a max speed.  Also I readjusted their positions when they get to close since the force when the objects are almost on top of each other will send the sprites flying.

One thing I haven't tried that's used in fluid simulations is velocity smoothing.  Basically you average out the velocity of the particles around another particle, where the weight they have in the average depends on the distance.

  • vsync works on my machine on firefox/chrome. If it's not disabled in your graphics card properties then i'm not sure where the issue lies.

  • It was just an idea. No need to switch, and using a guid would be better if you run multiple games.

  • Actually the object's uids will be the same on any computer you run the exported project on. You can easily test this. The only fuzzy part I guess would be if you create any objects at runtime, but even then if you ensure you create the objects in the same order then they would be the same.

    The values for the uid are very predicable too. The first object has a uid of 0, the second: 1, and so on.

    My point is a guid sounds unnecessary.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You could do it like this. The first event moves the objects and the second corrects overshoot. Another option could be to use the MoveTo behavior.

    global number toMove=20

    global number speed=100

    toMove>0

    --- sprite: set y to self.y + speed*dt

    --- subtract speed*dt from toMove

    toMove<0

    --- sprite: set yo to self.y +toMove

    --- set toMove to 0

  • There have been simulation games, and I guess using the physics behavior is a simulation. I have no idea what a pure simulation game is though.

  • If you add the "pin" behavior to the particles and position the particles object on top of the sprite in the editor, you can then add a "start of layout" event to your event sheet and add a action to pin the particles to the sprite. Then from that point on the particles will go wherever the sprite goes.

    https://www.scirra.com/manual/99/pin

  • The examples look impressive and all, but that's due to clever coders. The library itself is just a cleaner interface to draw stuff rather than using the html5 canvas interface. It would be a nice alternative to C2 to make a html project if you like scripting, but putting it inside C2 would be clunky to use imo.

    You can already draw curves with the canvas plugin if that's what you're after. I don't see anything in this library that makes that any easier.

    To make it work with C2's collision and physics system the curves would need to be converted to polygons. Doable but probably not the fastest considering C2 prefers you to use collision polygons with 8 or less points.

  • Yes.