R0J0hound's Recent Forum Activity

  • A second delay is a bug in your event code. The pin behavior runs once per frame and typically there is no lag at all. A one frame lag can be possible when using multiple behaviors are used. It’s basically due to the order of behaviors being run. A multiframe lag can be possible in cases of pinning to objects pinned already.

    Anyways you can always just position objects with events. With that you can control when you do it, or even do it multiple times in events if you move object around a lot.

  • Not really. Debug is always going to be slower.

  • If you move the html elements with css instead of the set position actions things won't resize. It does draw outside the canvas area, but you can use the "clip" css property to address that.

    Anyways here's an example. It basically get's the position and size of everything in windows coordinates and does the above.

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

    The example was for c2, but the only change for c3 is probably replacing c2canvas with c3canvas.

    The size of the button is smaller than it actually should be. A fix for that is giving each button an id and using javascript to get the size. I thought it wasn't needed though.

  • If you think of the layer property as binary you have 8 separate layers. The objects can be in all the layers or even a few of them. For example “11111111” would be all the layers, “00000001” would only be the first one, and “01010101” would be every other layer. Anyways any two objects will collide only if they share a layer. For example an object in layers “00001111” will collide with an object in layers “00000001” because they are both in the first layer. Whereas an object in layers “11110000” won’t collide with an object in layers “00001111” because they have no layers in common.

    You can also look at the chipmunk documentation linked in the first page for another explanation. You actually have 32 layers if you treat layers as hexadecimal.

    “Bit wise and” is a way to check if two numbers have bits in common.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Here’s the math to rotate around an imagePoint. It can be any x,y point really. Here I’m only rotating by 5 degrees, you can change 5 to anything.

    Global number cx=0

    Global number cy=0

    Every tick

    —- set cx to sprite.imagePointX(1)

    —- set cy to sprite.imagePointY(1)

    —- sprite: rotate 5 degrees clockwise

    —- sprite: set position to ( (self.x-cx)*cos(5)-(self.y-cy)*sin(5)+cx, (self.x-cx)*sin(5)+(self.y-cy)*cos(5)+cy )

    Another way could be this:

    Global number d=0

    Global number a=0

    Every tick

    —- set d to distance(sprite.x,sprite.y, sprite.imagepointX(1), sprite.imagepointY(1))

    —- set a to angle(sprite.x,sprite.y, sprite.imagepointX(1), sprite.imagepointY(1))

    —- sprite: move -d pixels at a degrees

    —- sprite: rotate 5 degrees clockwise

    —- sprite: move d pixels at a+5 degrees

  • It’s done in two steps: subtract 90 from the angle to rotate it, and normalizing the angle.

    ang = any_angle-90

    ang = angle(0,0,cos(ang),sin(ang))

    A longer way to normalize an angle would be these two whiles:

    While

    ang > 180

    —- subtract 360 from ang

    While

    ang < -180

    —- add 360 to ang

  • I’m fairly certain “on destroyed” is is triggered for each instance indavidually. So the pickedcount expression will always just be 1.

  • You can save the mouse position to some variables at the end of every frame. Then you could compare the previous frame’s mouse position with the current one. If they’re different, the mouse moved. You can get the velocity of the mouse by subtracting the previous position from the current, getting the magnitude of that and dividing but the length of a frame.

    Having it work when the cursor is already in the corner of the screen isn’t possible with the mouse api exposed by browsers.

  • mOOnpunk

    The objects are just moving in a circle. Instead of the circle being on xy it's on xz and the z is used to scale the sprites for perspective.

    Anywho the example is old. Here is one that just rotates the points around with more trig.

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

    And here's one where you can more artistically by just arranging the corners of a quad the circle will be on.

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

    There are likely many other ways. For example you could avoid trig directly and use "move at angle" instead. Add two instance variables z and r2

    global rotZ=45

    global rotY=0

    global radius = 100

    every tick

    --- add 100*dt to rotY

    --- sprite: set position to (0, 0)

    --- sprite: move radius pixels at self.iid*360/sprite.count+rotY degrees

    --- sprite: set r2 to self.x

    --- sprite: set z to self.y/radius - 3

    --- sprite: set position to (320, 240)

    --- sprite: move self.r2/self.z pixels at rotZ degrees

    --- sprite: set scale to -1/self.z

    There are probably others

  • I think it’s a bug. Or the very least I think the push out actions can be improved. As is, I don’t find the custom movement behavior useful at all with the current push out actions. The push out nearest action is mainly buggy in that if you move perpendicular to a wall the object will move along the wall when all it should do is stop.

  • Performance is easy. Events a run from the top of the event sheet down every tick. Globals and triggers are exempt, those are only run at certain times, although if you have multiple of the same trigger they are run top down.

    Still the amount of events doesn’t mean worse performance. By using conditions and sub-events it will stop any event tree once tang condition isn’t true.

    The speed of picking in events is directly related to the amount of instances of the object being picked. This is why families are thought to be slow, they just have many more instances. There are events that are exceptions to this such as “pick by uid” which is the same speed no matter what.

    Microptimizations like this one event is faster than enother are less interesting. It’s better to make events that are simple and understandable. Better performance can be gained by only doing stuff when you need to. A more advanced vein of that is to do things over multiple frames if something causes a pause when doing it all at once.

    There are probably other recommendations, but bear in mind the events are only a part of the performance of a game. The amount of things being drawin to the screen, the amount of effects, layers, etc also affect performance.

    So in a nutshell my recommendation is:

    Use everything and do everything. For performance do nothing at all. Aceptable is in the middle somewhere.

  • i see nothing wrong with things being there for internal use. They added it for a special case optimization and likely could remove it or change it on a whim if they wanted. It gives them lots of freedom to be able to freely change everything but exposed sdk functions. It really can bog down development if everything in the runtime needed to always be supported in all plugins.

    I know I’ve used runtime specific stuff in many of my plugins and I fully expect it to break if those things change in the runtime.

    Anyways I’ve always found Ashley to be pretty good balance at keeping backwards compatibility. It’s his porogative to keep stuff undocumented so it can be changed or even eventually depreciated if the normal trigger gets made faster or the way functions work get changed entirely.

    As to breaking comparability, I have nothing against it. If the new version is surpirior then it’s worth it.

R0J0hound's avatar

R0J0hound

Member since 15 Jun, 2009

Twitter
R0J0hound has 157 followers

Connect with R0J0hound

buymeacoffee.com

Trophy Case

  • 15-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

28/44
How to earn trophies