R0J0hound's Forum Posts

  • Cool

  • I think I’ve answered better many times in the past. To read pixels of an image you need a plugin like canvas. To read the collision polygon of a sprite per pixel you could use a bunch of overlapping point checks.

  • irina

    Maybe switch the mouse events with touch events?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Open the sprite in the image editor. Rotate the image so it’s facing right.

  • That’s unrelated. You can use the audio plugin to affect the volume of your game.

  • I don’t think there will be a measurable difference.

  • I’d assume so but I have no idea.

  • Ah I understand now I think. You could do a three layer setup. Objects on the bottom layer and light in the middle. Then if any object has a line of sight to the light you can move it to the top layer.

    Another idea is to just do shadows yourself, either with the “paster” or “custom draw” plugins. Basically it’s just a quad from each edge with two points projected with a ray from the light to the edge corners. The trick to show objects in the light and hide those in shadow would be to only use edges facing away from the light. Anyways there was an old example of this done with the canvas or paster plugin I think.

    Edit:

    Example using "custom draw"

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

    plugin:

    plugin-custom-draw_t190098

  • Thanks. I was pretty pleased how that guy came out.

  • Then maybe putting the light object in a layer below?

  • Would it help to have another approach entirely?

    https://www.dropbox.com/s/96purzfhhs4j7 ... .capx?dl=1

    It's rough in almost every way, but it's at least similar to what you're after?

    I can be made faster by using an array instead of the node sprites for the pathfinding grid, although it may be a bit more complicated. The net gain is the units would be able to see what direction to move with a array lookup instead of a collision check.

    If you want to use behaviors then the physics behavior can do a lot of it. It looks pretty good.

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

    To vary the path a bit more you maybe could use a perlin noise function to alter the forces on the units. Or maybe have a random force that you change periodically to each unit.

  • Found the video. Looks way more complicated than it needs to be.

    If you have sprites: head, base an multiple body

    Then a event like the following should do it. You can use the sine behavior instead for moving the head if you like.

    every tick:

    --- head: set x to 320 + 100*sin(200*time)

    --- head: set y to 100 + 50*sin(500*time)

    --- body: set x to lerp(base.x, head.x, (self.iid+1)/(body.count+2)

    --- body: set y to lerp(base.y, head.y, (self.iid+1)/(body.count+2)

    You could use a instance variable instead of iid if you want to have multiple heads but for one this is fine. For a more interesting effect you could use qarp instead of lerp to give a curve. The middle parameter could be the position of an invisible sprite that's moving around with sine much like the head.

  • NetOne

    Lol. Probably not. I do enjoy Many aspects of construct 2 though, so I’ll be around to use that I think.

  • 1.

    Probably a valid worry, but what can you do? Maybe try getting the average fps several different times and only look at the best or median case to decide to lower the quality?

    2.

    Probably not, but I have no idea.

  • When i was last poking around C2's renderer i noted that particles have two ways they can be rendered. Typically they are rendered as points, but when they are bigger they are rendered as quads. I'm guessing the quads will rotate.

    Why the two different ways? Webgl, or graphics cards for that matter, have a limit on how big they can draw points, so when C2 wants to draw points bigger then it has to use quads. Also the limit varies from graphics card to graphics card. On my machine both scaling factors are rotated.

    You can see this done in the particles drawgl function. And here are the stats of the supported point sizes:

    https://webglstats.com/webgl/parameter/ ... SIZE_RANGE