R0J0hound's Forum Posts

  • You can avoid a loop by setting an boolean instance variable that can be used to pick the objects in a function. A caveat is you have to set the boolean to false for everything first. 

    every tick
--- sprite: set picked to false

some conditions to pick a certain group of sprites
--- sprite: set picked to true
--- function call "foo"

on function "foo"
sprite: is picked
--- do something

  • One is made in that range because it’s easier to think in 0 to 360, and the other is because the angle calculation from linear velocity using atan2 gives that range.

    Typically it doesn’t matter what you set the angle to. If you want to know when an angle is close to a certain angle don’t compare it’s value directly. There are angle compare conditions that handle the cyclic nature of angles for you.

    If you need to rely on a certain numeric value for an angle then you can clamp the value in some way first.

    0-360

    ((A%360)+360)%360

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • This topic seems close to what you’re after. There are a few examples and ideas.

    construct.net/en/forum/construct-2/how-do-i-18/moving-character-leftright-144643

    A Bézier curve would be done by converting it to a bunch of lines.

  • You can make it stop by making t stop increasing. Here’s one way to do it.

    Every tick

    — set t to min(t+dt, 1)

    — set x to lerp(50, 500, t)

  • AllanR thanks, there are probably pros and cons of either way. I see in that other topic you did a redo too, which is pretty slick.

    Alon

    The example was mainly to try out various ideas. On one hand it’s a control scheme that I did for fun and the other part is a way to do undo. It was mainly to maybe give ideas, the bulk of it would be much different with different setups.

    The main contribution was to use a id variable instead of uid.

    Anyways the undo system is simply this in a nutshell. Right before modifying stuff save it to a list somewhere. Then when you want to undo, you take that list to restore how things were.

    My events do tend to be pretty dense and admittedly I use lots of tricks to make things more compact or make some things simpler. Tricks are mainly:

    Using text as a list and using tokenat to get values.

    Using pick by uid to get around picking a newly created instance.

    Using groups to scope away some variables to keep things a bit more organized.

    I also don’t use c3 but the way to call functions is just different but can be used in the same way.

    Probably the simplest way to do save as a beginner is to just save/load state I guess.

  • I did a test of an undo system with some editor I came up with.

    dropbox.com/s/y0yt072j0nyfbst/undo_test.capx

    Here are some thoughts.

    * For doing undo with creating/deleting sprites it works fairly well to do your own id system instead of using uid's. Basically a global variable nextID that you assign to an instance variable id, and increment every time you create an object.

    * Here I saved the id,x,y and angle of all the selected objects for every undo point. You could go more compact by just saving a list of ids and a change in position or angle for things like moving and rotating.

    * you could also merge consecutive move or rotate undo points as a way to make stuff more compact. It would depend on how you want editing done though.

  • Instead of the repeat you could use an infinite while with a condition at the end to stop the loop. Isn’t that the same as a do..while?

    While

    — do stuff

    — system:compare found=1

    ——stop loop

  • That’s the one. Not sure the extent of how much it stops the antialiasing. If the c2 project setting uses linear filtering then the canvas will get blurry if it’s scaled or if the window is scaled. Basically a pixel on the canvas needs to be the same size as a pixel on the view.

    Worst case you could draw the shapes directly a pixel at a time to get crisp edges. Again that would depend on scaling to some extent.

  • dop2000

    There is a property in html5 canvases to disable/enable that smoothing. Its not exposed to the plugin though and when I looked last it’s something that wasn’t universally supported across browsers.

  • It’s probably a throwback to how arrays were separate objects in Clickteam products.

    Also it does help keep things tidy to have the array actions and conditions grouped together. At least with how types are handled currently.

    Construct classic actually had a way to assign arrays to variables, although they were pretty much constant. You couldn’t change the size or elements of it, and it wasn’t supported in all places. The feature didn’t make the jump to C2.

    I think it would nice be have as a variable type though. If it made the array object obsolete I wouldn’t mind, as soon as you do something moderately complex that involves picking you realize containers don’t really help a lot.

  • If the player is moved with the physics behavior too, then no, not with the bundled physics behavior since there is no collision filtering.

    There are other physics plugins such as chipmunk physics you can download and use instead. It for instance has a setting called collision mask for any object using the behavior.

    Set the player to 01

    The enemies to 10

    Any walls both hit to 11

    And walls only the player can walk through to 10

  • It should just bounce. You shouldn’t need to apply an impulse at all.

  • It probably can be simplified to:

    rotate clockwise by (mouse.x-self.x)*k

    Where k is to tune the rotation amount

  • The terrain is just a graph. For any x position you just need a way to calculate a y.

    A simple start would be y=sin(x)

    Or to center it vertically and make the hills bigger you can do y=240+100*sin(x)

    There are many ways to make the terrain more interesting than just a sine wave. You can use a noise plugin, or maybe add multiple sine waves together. Another idea is to just fill an array with random numbers and use cosp() to interpolate smoothly between the numbers.

    So basically a function like this:

    Function terrain(x)

    — i = int( x/100)

    — t = x/100 -i

    — return cosp(array.at(i),array.at(i+1),t)

    Then you can move the player around in any way you like, and you can know if it hit the ground if player.y > function.call(“terrain”, player.x)

    I don’t really want to fight with constructs collision system to somehow make it work with this, so instead you can do it manually. It’s also simple enough to do your own motion with a vx and vy variable.

    Every tick

    — add 200*dt to player.vy

    — add player.vx*dt to player.y

    — add player.vy*dt to player.y

    Set y0 to function.call(“terrain”, player.x)

    Set y1 to function call(“terrain”, player.x + 0.001)

    Set ang to angle(0,y0,0.001,y1)

    Player.y > terrain(player.x)

    — set player.y to y0

    — set dot to player.vx*cos(ang)+player.vy*sin(ang)

    — set player.vx to dot*cos(ang)

    — set player.vy to dot*sin(ang)

    So far so good. I guess I forgot to cover a way to draw the terrain. You could get away with only drawing what’s on screen.

    Destroy circle

    Repeat 100 times

    — create circle at (0,0)

    — set x to lerp(leftScreen, rightscreen, loopindex/99)

    — set y to function.call(“terrain”, self.x)

    You could also stretch rectangle sprites between the circles to give a continuous line.

    To fill the area below you could use all the circle locations along with the bottom two corners of the screen with a canvas fill function.

    The gradients would require reasoning about how you’d want it to look and maybe drawing an offset polygon or placing blurred scaled sprites at key spots.

    EDIT:

    working example.

    dropbox.com/s/q9vpfm2psqr4qfe/terrain_physics.capx

  • dop2000

    Ah, I hadn’t tested it, good to know. I guess in that case it would be a false positive if the imagepoint was actually the same as the origin.