R0J0hound's Forum Posts

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

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You’re doing something like

    Land.x<-200

    —- destroy land

    —- create land at (200, 400)

    The gap will vary as dot varies.

    A more robust way would be to pick the rightmost land and create the new one to the right of it.

  • To get around the layout limit of 1 million you could make the objects smaller and increase the layout scale or zoom ( i forget what it's called). The image sizes would be the same as if they weren't scaled down so it will look visually identical.

    As far as if a level that big is possible. I'd say so, but you'd have to actually try it and see how it goes.

  • Effects let you change the paremeters on the fly, and turned on or off on the fly, whereas an image is fixed. Also it’s simple to see that just drawing a sprite is faster than drawing a sprite with an effect since less is being done. The actual performance difference could be negligible. You’d have to test and see.

  • The bounding box is the area c2 uses for the effect. It does that as an optimization. The reason the outline of the box could be it’s sampling pixels outside that, which this effect does. Maybe it’s undefined behavior or maybe it’s something that can be handled. If it is it would be in the c2 renderer and not in shader.

    The reason it draws darker or only happens when transparent could be multiple reasons. One, perhaps doing an outline only works when no transparent and the opacity should be applied later? This is something that maybe can be addressed at the runtime level? I could be wrong there since I have minimal understanding how effects and the c2 renderer work together.

    You could perhaps work around the issues in this shader by utilizing the paster plugin to get more control of the rendering pipeline. This may not be feasible if the effect doesn’t draw right, since there are issues drawing effects with it. I haven’t tested it, but I digress.

    Basically you make the objects not transparent and paste them to a paster object with the outline effect. Then you make the paster object semitransparent and paste that to another main paster... it sounds more complicated than it is.

    The object is to have everything invisible and instead just draw to the paster.

    So the solution is to either:

    1. Fix the shader. No idea what a fix would be.

    2. Use the paster object to do the rendering in a more manual controlled way. It may be tedious.

    3. Modify the renderer? Least feasible of all. No idea what you’d change here if anything. Probably doing some investigations with straight webgl and shaders in straight JavaScript would be enlightening. Maybe a solution would be clearer after that.

    Anyways cheers

    Edit:

    It occurred to me that you could try increasing the bounding box size (there’s a setting in the shader xml), then in the shader itself skip when processing pixels around the edge. It should be doable I think by dealing with the uv cords. I feel like I have to re-figure out how they work in shaders every time I use them so I’ll pass.

  • You're talking about a layout in an exported game? It is in an obscure form so that it both takes up less space and isn't readable by anything but the runtime. It would open a can of worms if we reverse engineered the export to make that possible. There are probably better solutions than doing that

    Anyways, if you created both games you could make your own level loader. Basically take a level and output all the object locations and any other stuff relevant to your game to a text file. Then make a parser that reads that said text file and recreates all the objects again.