R0J0hound's Forum Posts

  • Ok, fiddled with it more and got it to work. The link is updated

    Found that fixed resolution canvas' scale the image when loading pixel data, so left it at automatic. Also changed the line detection to use a tolerance.

    Found that pasting repeatedly blurs the lines so I combined the pixel data directly with some javascript.

    The only issue now is that the delay from making the mask is noticeable.

  • In javascript if you can access the canvas element you can center it with some css:

    canvas.style.position="fixed";
    canvas.style.left = Math.max(0,(window.innerWidth -canvas.width )/2)+"px";
    canvas.style.top = Math.max(0,(window.innerHeight-canvas.height)/2)+"px";
  • Example is done:

    dropbox.com/s/339te0solmn4yws/marchingSquares.c3p

    Should work as long as the image isn't touching the edge of the canvas. I didn't add the polygon simplifying step. Also it just uses the first polygon it finds if there are multiple.

    For debugging the outline used is drawn onto the canvas, and the collision shape is visible.

    I haven't gotten to figuring out how to deal with how any fullscreen scaling changes the resolution of the canvas.

  • I guess it depends on how the sine behavior does the math internally.

    But instead of finding a way to look at the workings of the behavior, and maybe finding a correction you could just do the sine motion directly with math instead.

    It’s fairly simple to do it in a way that I’d frame rate independent. Here it does horizontal motion:

    X = startX + magnitude*sin(time*360/period + offset)

    I suspect the sine behavior moves objects in a more relative way since you can use it with other motions.

    This would do it in a relative way but still be frame rate independent.

    Previous = current
    t = t + 360/period* dt
    Current = mag*sin(t)
    X = x + current-previous

    As I said, the behavior must do something different.

  • Im not sure either. By default the resolution of the canvas will change when the view size changes, although there is a setting to make the canvas have a fixed resolution.

    When I tested it it didn’t seem to work either way. Mainly the fill seemed to pass the lines due to things being blurred a bit from resizing, so the lines were no longer fully black.

    My thought was to have the canvas use a fixed resolution and maybe at most have to adjust the mouse location, but trying it didn’t seem to work but I’m not sure.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Here's one way to do it. The 3d features in construct aren't always up to par but you can utilize some math to do it.

    dropbox.com/s/xre95xeumgsmw8l/orbit_camera.c3p

  • One promising approach is to use the marching squares algorithm on the image to get the edges. It would allow you to get a nice approximation without looking at all the pixels.

    You could get multiple polygons from that when multiple shapes are drawn or there are holes inside the shapes. Since you want only one shape you could calculate the area of each and keep the biggest, or maybe find the convex hull of all of them perhaps, but the former would be better. Handling holes could be possible too but that would need more work. Essentially we’d make a cut from the hole to the outside of the polygon.

    Next step could be to simplify the polygon a bit so there are less points. One simple way would be to look at every three points and remove the middle one if the angle between the three is a threshold from 180 degrees.

    The final step would be to use distort mesh to make the shape. Size would be count/2 x 2. And set each on the mesh in a clockwise way. I’ve done it for a convex shape but since we are just concerned with the collision shape it should work with any polygon, but it just won’t draw correctly.

    Seems like something I’d want to attempt sometime this week if I get time.

  • Sure, but I see construct getting in the way depending on the kind of game engine you’re making.

  • Strange, I use Chrome and it doesn't crash for me. Wonder what is causing the crash.

  • Here's one possible solution of the flood filling and masking.

    dropbox.com/s/z7afhehma5py976/draw_within_lines.c3p

    The flood fill basically just makes a hole that you then can draw into on the mask canvas. Didn't get it working with any full screen scaling though.

  • There isn’t a way to do that in the image editor. You’ll have to copy/paste it into another image editor that can.

  • Hmm. The for loop serves no purpose, you're just creating 10 objects at a time that are the same. You probably should set the width to the distance from the mouse. Also changing the image x offset could be useful, probably it would relate to the total distance so far.

    Anyways here's a different way to do it. I'm sure there are many other ideas.

    dropbox.com/s/wh1hf0ji0sueive/draw_dashed.capx

  • I couldn't find anything about some drivers doing that, but I suppose drivers could do anything behind the scenes. Even if it was slow it's not something that would need to be done per frame, or in the case of what that initial post only some specific objects would need to be changed.

    Realistically all that would be needed is an option for a canvas to be drawn without filtering if wanted. The pixelate effect can be used to do the nearest filtering instead but it's not 100% perfect and isn't simple to do.

    Jase00

    You can utilize the pixelate effect to simulate nearest filtering of a scaled up canvas. If the canvas and sprite are unscaled the sprite will paste 1:1 perfect as long as you offset the canvas by (-0.5,-0.5).

    dropbox.com/s/88hlbstc1gjol2e/simulated_nearest_filtering.c3p

  • It seems possible in webgl 1 since the sampling is set per texture, but maybe the worry is how slow looping over all the textures and changing each one would be? Webgl 2 adds the sampler object which would let the filter change be done in one spot.

    Anyways, I can appreciate the issue of having to do it multiple ways depending on the webgl version, not to mention any renderer redesign to support such a feature.

  • Your code wasn't correct. The total length is zero because you set it to zero when loopindex=p.count-1 aka at the last instance. It should be loopindex=0 like in the pseudo code. Also you don't need to use abs() with distance because distance is already always positive, but that has no effect.

    The verlet rope physics doesn't work too well when wrapping around small obstacles as you noted in the layout. It can be improved by decreasing the distance between links and/or running the physics with multiple smaller timesteps, but it still can fail. I think it could be improved by doing collision detection/response between the obstacles and the lines between links, but that's not a simple to solve with the circle vs sdf collision detection used.