oosyrag's Forum Posts

  • Doesn't look blurry to me. I think its just a combination of how fast you go and how small the enemies are. Not to mention there are so many similar looking non-enemies.

  • Problem 1 - Your target is on Layer 0, your background layer, which has parallax. Turn off parallax or move target to another layer to fix.

    Problem 2 - Point sampling with fullscreen scaling (downscaling in this case). Some pixel stars are too small to be displayed, but when you move certain pixels will be displayed and others won't be, which causes the jumpy stars. Change to linear sampling, or use a better background image.

  • Behaves consistently for me, no matter the order of the events.

    When player is "dead" you are setting his vector to upwards every tick, so he never gets around to falling back down.

    The only way he falls is if you hit space twice to toggle the dead state again. In your video you were probably getting inconsistent results because your condition was "space is down", so that would toggle on and off every other tick. Basically if you didn't let go of the space key within one frame, the dead state would toggle off again. In the example file you uploaded it looks like you corrected this already.

  • Use a container, so each enemy has a text/sprite associated with it. When the enemy is picked by conditions, the objects in its container will also be picked.

  • Your conditions don't go in the array (or dictionary would probably be more appropriate). The array/dictionary only serves as a replacement for instance variables to store if an achievement was completed or not.

    Your condition and event to trigger an achievement should be one time only, and when it triggers it will set the corresponding array/dictionary value and that value can be saved forever. You'll still have an event for each accident, which specifies all the conditions to reach the achievement. The state/animation frame of your achievement​ sprites should be based off of your stored value, and you can loop through all of those in a single event to set them.

  • Generally speaking if you want truly infinite, you generate pieces of your background around the edges of your visible viewport as you approach them.

  • Actually never mind, collisions only care about the bounding box. Have an example capx to look at?

  • Sounds like a browser issue. If it only happens the first time, try playing the sound once (muted) on start of layout?

  • Your player is probably not moving 1 pixel per frame, so if hes moving 9 pixels per frame at the point right before impact, he might be 49 pixels above the origin of worm (not overlapping), then the next frame he would be at 41 (overlapping).

    Otherwise, it might just have to do with the origin point of the worm not being all the way at the bottom of the sprite.

  • You can make a loader layout of sorts, I haven't tried it yet myself though.

    Sprites are kept in memory if they are in use on both the previous layout and next layout.

    You can take advantage of this by using the load from url action to preload assets gradually in an intermediate loader layout.

    This is mostly useful to prevent the "freezing" that occurs between layout when loading large amounts of sprites into memory. I'm not sure if this would help you regarding cpu use on start of layout if you're dynamically placing your terrain on start of layout.

    Are you generating the entire map in a single loop/frame? Maybe you can break it up into multiple frames by using a counter. Start by generating what can immediately be seen, and let the rest of the map generate over time.

  • This is actually a good idea, especially as you can stretch out the invisible helper sprite to prevent high speed projectiles from clipping through walls. You can also create interesting effects on your sprite without affecting the hitbox/colissions.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • FYI - You might get quicker answers if you post to the "How Do I" section of the forums.

    When you use the platform set vector action, that is limited by the platform behavior's maximum speed and affected by deceleration. So however high you set the vector, it is capped and based on the deceleration he will end up stopping at around the same place. Try using a bullet behavior instead.

    As for the blocks... I have no idea at the moment. It works fine when I create a new project with just blocks and a player sprite. Your collision boxes look fine, and its not because of scaling (still happens even when the blocks are 100%).

  • lerp(a,b,x)

    a - Starting number

    b - Ending number

    x - The percentage amount between the start and end number you want to get (between 0 and 1, or 0% and 100%)

    So lerp(10,20,0.5) gives you 15, or halfway between 10 and 20.

    Allan gave a pretty good explanation of why it slows down above - basically when you use the current position as a start point, the lerp amount gets updated every tick to be smaller and smaller.

    Just going to give you a heads up though - lerp is generally used for more advanced gradual motion/inertia. If you're looking for simple straightforward movement, you would best be served by getting familiar with the Bullet behavior. The Bullet behavior is generally the go to solution for almost all linear movement needs.

    Alternatively, http://c2rexplugins.weebly.com/rex_moveto.html is a fantastic plugin that you might find useful.

  • All programming techniques come from math. Math lets you take numbers and transform them into whatever form you need, following rules that a computer can understand.

    But generally speaking, experience and practice will let you recognize what you can do in any given situation.