R0J0hound's Forum Posts

  • You can't change the refresh rate of the game with C2. I believe a half framerate (30fps) was attempted before but it didn't perform well with html5, the result wasn't smooth. A search could probably give more info.

    That said C2 only redraws if something has changed position. So you possibly could force lower redraw rate by only moving the objects every other tick or something. It wouldn't work if you used any behaviors since they update every tick but with just events it could work. Probably more trouble than it's worth though.

  • You could do it like this. First you pick the object and save it's x, y and uid to some variables. Next you use an inverted "pick by uid" to pick all the instances except the original instance. The you can use the "pick closest" condition as usual.

    global number x=0

    global number y=0

    global number obj=-1

    pick sprite at random

    set x to sprite.x

    set y to sprite.y

    set obj to sprite.uid

    [inverted] pick sprite instance by uid obj

    sprite: pick closest to (x,y)

    do something

  • It looks like you'll need to call this function:

    CollisionPoly_.prototype.cache_poly = function(w, h, a)[/code:1bjeiulg]
The only catch is it won't update if the width, height or angle haven't changed. So you'll probably need to change one of those first.

I only took a quick look so I didn't investigate where that function is usually called.  You may even be able to change the size or angle of the object to force a update without calling the function if it's called every tick anyways.  Or instead you could change the .cache_width value from the polygon.

  • Waltuo

    It was mainly as an exercise to see how physics is implemented, so I didn't get it to a perfect state. I'm sure the collision detection could be better, maybe using SAT instead of what's currently in place would help.

    As far as adding sleeping I'm sure it could be added but I haven't looked into it. Basically there is a whole lot missing with it so it is mainly for amusement right now.

  • Here's one way

    Every tick

    Sprite: move forward 100*dt pixels

    Sprite: rotate 10*dt degrees clockwise

    Sprite: set X to self.x+50*dt

  • You need to adjust where the origin is on your Sprite. You can do this in the image editor.

  • It's likely a graphics driver bug, try updating your graphics card driver.

  • For the other example you'd have to tweak it to use the 8dir movement instead of what it uses now.

    With just horizontal and vertical walls you could use the overlaps at offset condition to see if there's a wall next to it and just invert the X or y vector depending on which side a wall is. You could do it like the following. The first step would be to get the Sprite out of the wall, that is where custom movement is useful. On another note you could also compare the X and y velocity in addition to the wall detection, since you only need to bounce against walls you're moving toward.

    Sprite overlaps wall

    Sprite: customMovement: push out of solid

    Sprite: overlaps wall at offset (-1,0)

    Or

    Sprite: overlaps wall at offset (1,0)

    Sprite: set xvelocity to -self.xvelocity

    Sprite: overlaps wall at offset (0,-1)

    Or

    Sprite: overlaps wall at offset (0,1)

    Sprite: set yvelocity to -self.yvelocity

  • Oos

    You could also use the bullet behavior to handle the bounce:

    https://dl.dropboxusercontent.com/u/542 ... _8dir.capx

    For more precise bouncing you'll need to find the angle of the object hit.

    Maybe something like this:

    viewtopic.php?f=147&t=152906&p=964827&hilit=normal#p964827

  • —

    The joints just need to be created a tick after the objects are created. You could save the tickcount to a global variable when you create the objects and compare when the tickcount equals that global plus one to add the joints.

  • Yeah the compare all will do that. It's probably a bit flawed now that I think about it since it's comparing per component instead of per pixel.

    So a transparent pixel rgba(0,0,0,0) will be 75% similar to a black pixel rgba(0,0,0,255) instead of not at all.

    Fix that and a blank image should give a lower percentage.

    "rms" is a term used in your last link. It's basically the distance between the two pictures.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • socialpilgrim

    As rex said you could use the asjson expression to load the image into a array for faster comparison than using rgbAt().

    Here's an example with three examples:

    https://www.dropbox.com/s/5c5ei994g3fjt ... .capx?dl=1

    /examples30/imageCompare.capx

    Since it's for a drawing competition I find that just comparing the alpha gives a more meaningful percentage. Just checking all the pixels like with your links gives a 90% similarity to a blank canvas.

    Anyways I implemented three methods in the capx.

    The first follows the examples in your links and gives a percentage and rms number. I guess rms could be used as a way to compare.

    The second only looks at the colored areas of both images and gives a pretty good measurement.

    The last one finds the bounds of both drawings and compares both as if they were the same size. This allows a small box to match a big one.

  • neverk

    There's a fix for that here:

    I haven't put the fix in the plugin link yet.

  • JoaoCesar

    If you want to distort the paster's texture itself you'll need a second paster object to draw to.

  • I've found a spring works better than a pivot joint in situations where you want to drag the object around. I think I had a example in the first few pages of the plugin.

    Other things you could try:

    *set a max force for the joint. By default a force up to infinity can be exerted on the objects to make the joints match. By setting it lower it would make the joint more relaxed and keep it from pulling into another object.

    *increase the iterations of the simulation. This is a performance trade off. The higher the iterations the simulation will get closer to converging on a perfect solution. Personally I never mess with it, instead I do other things like above.