R0J0hound's Forum Posts

  • I agree it would be tedious to make the collision shape manually and it would be hard to get it to be smooth.

    But you can use mesh distort to make any shape you want. For example this takes a square sprite and makes it into a circle. Even with just 20 points it's decently smooth. Typically you'd make that invisible and put the sprite you want for a visual on top.

    dropbox.com/s/rxruw0ke7ox9uo5/collision_shape.c3p

    The second part of that example loads the outline of a mario sprite.

    You can use this tool to create the point list.

    dropbox.com/s/ldpsgtgzxwuajfc/marchingSquares2.c3p

  • Guess it’s better than nothing. My main complaint is its solution didn’t give something working. You had to modify it a lot.

    At least the formula was probably useful. It basically is a way to move by an angle and it is one of the main uses of trigonometry for games. But then again construct has the move at angle action which could be used instead of the math.

    The problem I see with more complex problems is having to see if the solution is correct. If you have to modify it heavily like removing the angleToRadians expression and such then it’s not helpful.

    But I can see the value of it giving some ideas of where to maybe start.

  • It won’t affect performance one way or another. Using something else is just to organize things.

  • By default the color components go from 0-100 not 0-255.

    Use (0, 100, 102/255*100)

    Or use one of the other rgb expressions that take values 0 to 255.

  • In construct 3 if you make the function return a value it won’t show up in actions but it will show up in expressions.

  • Functions are simply a way to re-use chunks of events. They are only run when you call the function.

    Triggers can be thought of as functions. If it helps some things like input are probably checked regularly like non triggers but that check is done at some lower level point in the system. Like mouse clicks are checked in the mouse driver, which is taken by the operating system, sent to the browser, which loops over the events and sends them to the js event listeners, which in turn is handled by construct’s engine.

    Other triggers come from checks in other places. For example on frame changed comes from the sprite objects tick function which updates the frames. There it calls the trigger when the frame changes.

    Some things are so called fake triggers, but that’s mainly a term in the sdk. There aren’t too many examples of them, off the top of my head on collision, gamepad triggers, timer triggers, and I want to say in the Los behavior. It’s more of an exemption to the rule, and they act like a normal event with a trigger once.

    In collision is interesting since it’s both a fake trigger and a real one. It’s kind of like an is overlapping and a trigger once but it’s done per instance It’s also a normal trigger because the physics behavior calls it when the physics engine has a collision.

    Anyways, functions are just a way to organize and reuse code.

    In general you can think of triggers as functions that don’t run every tick, and instead are called by other parts of the runtime. But like many parts of the engine there are exemptions where things may work differently.

  • Sprites are not dom elements so they can't have js events such as mouseenter added to them. But either way to logic is the same: all the sprites would need to be checked to see if the mouse is overlapping them every frame, unless there is some spatial partitioning done behind the scenes.

    Anyways, simpler is often better (and faster) with events. Like others have stated you can do this which will will access all the sprites twice per frame. You'll run into other performance issues with a high number of instances in other ways before this is an issue. 

    every tick -> sprite: set highlight to false
mouse over sprite -> sprite: set highlight to true

    You can reduce it to accessing all the instances only once per frame with logic like this: 

    var prevUid=-1

sprite: pick by uid prevUID
-- set highlight to false
-- set prevUid to -1

mouse over sprite
-- sprite: set highlight to true
-- set prevUid to sprite.uid

    The final idea is to use some kind of spatial partitioning which could in theory reduce the number of instances to check to one per frame. For example here is a grid hash idea.

    dropbox.com/s/n21w4qwgp1k9tkt/spacial_hash2.capx

  • Reuploaded again in case I didn't remember to do it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Testing more you'll need to add 0.5 if the origin is centered:

    (x-self.x)/self.width+0.5

    (y-self.y)/self.height+0.5

    If the origin is top left it would be 0,0

    Also here's an example if you want to work with rotation: dropbox.com/s/qpriwtyej3ngylb/layoutXYtoDistort.c3p

  • Yea, It assumes the sprite angle is 0. If it's not zero we'd need to unrotate the xy first but that may be more trouble than it's worth.

  • Here's another example as well.

    dropbox.com/s/an2pbq49au6rkxd/thumb_sticks_2.capx

  • With absolute mode you can do this to distort to an xy position.

    (x-self.x)/self.width

    (y-self.y)/self.height

  • Is level=9 when the timer finishes?

  • Updated link to handle fullscreen scaling.