R0J0hound's Recent Forum Activity

  • 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.

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • Having an array as a primitive variable type instead of a separate object would be nice. It would make things more readable. As is picking and functions can make it look complicated and/or make things more complicated. Don’t get me wrong, picking is pretty nifty for many things but is an awkward replacement for some logic.

  • Buttons are added to the webpage with JavaScript, they aren’t added to the exported html file.

    It looks like those snippets of html just runs some JavaScript when a button is clicked. Perhaps you can utilize the browser execjs action to run the Javascript in those snippets. At least that’s my impression. I don’t use social media so I haven’t concerned myself with how it works.

  • My guess is it would be random. Dictionaries in most languages are.

    You can confirm this by reading about JavaScript dictionaries. Depending on the implementation they could be ordered by when they were added.

    If you want it ordered you could add add the keys to an array, sort that, and loop over that.