oosyrag's Recent Forum Activity

  • An alternative way to handle this is with the drawing canvas object to take a snapshot of the previous sprite texture. The drawing canvas can keep the name or index of the sprite in an instance variable to assist in picking.

  • The scroll to is updating the position of player2's viewport every tick. Before it updates, all objects are moved the difference between player 1 and 2's positions, saved to the canvas to take a snapshot, then moved back. This all happens within a tick, so no movement is actually displayed to the user. The viewport scroll to is then updated to player2's position for the next frame.

  • Not really understanding what you want.

    Just import the single image you want into a sprite object then.

    You can also set animation speed to 0 in the animations editor.

  • You can use the system expression tokenat(src, index, separator).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Physics is as good as you know how to handle the physics object and your understanding of how actual physics works to apply them to your game mechanics.

    Note that there are two stepping modes, dt, or framerate independent which is non-deterministic (may be bad for precision), and fixed, or framerate dependant, which is consistent but will run at different speeds at different refresh rates.

    You should not be using other behaviors such as solid or bullet with physics. They will absolutely cause problems.

    Often people end up realizing didn't need a full physics simulation to begin with for what they were trying to do, and would be better served by other behaviors and game logic/mechanics.

  • Syncing projectiles is a pretty frustrating topic for networking code. I've attempted to tackle similar problems a few different ways, each with their own issues.

    One way I've tried is to have the actual synced projectile object invisible. Each peer will create their own visible sprite for the projectile locally, that is not synced but should behave synchronously. It can be accelerated towards the actual (invisible) synced projectile over time, to fudge latency. This is in effect putting a second layer of local input prediction and interpolation net code on top of the built in one, but you get a little more control over how you want it to appear for each peer. It is a tradeoff between "looking right" when network conditions are good and desync artifacts when network connections are bad.

    Another way is to delay the destruction of the projectile. You can simulate its destruction with an animation or setting it invisible and disabling its behaviors/events, but this gives peers some time to catch up before it actually gets destroyed.

    The last way I've tried is to simply not sync the projectile at all, only the input and the result. Let each peer display what it thinks should have happened to the projectile. This works best when you can fudge the visuals and precision isn't as important, so probably not the best for a top down tank game.

    One fairly common method that doesn't work with the built multiplayer object's method of syncing is to run a lockstep simulation, where everything is deterministic and can be recreated accurately on each peer. There are pretty much always syncing issues that build up over time due to the differences in hardware though, so corrections are made periodically by peers checking in with the host. I think this works best when input lag is acceptable (no local input prediction).

  • construct.net/en/tutorials/using-3d-construct-2746

    See the section 'Using 2D Layers' towards the end.

    You probably just put it on the wrong layer.

  • Generally speaking, you would crop the image you want and save it.

    These files are often tilemaps. In that case you can load it into the tilemap object, set the right dimensions, and "paint" the specific image you want.

  • Add the behavior to every object that can move from it's original position in that layout.

    Or you can use a family to do so, with the persist behavior on the family.

  • Use the persist behavior.

  • Because it isn't fully automatic, and each port needs individual attention.

    Because they have their hands full with developing Construct as it is, and perhaps that's what they want to do.

    You could try replacing instances of Scirra with yourself in your post, and maybe you'll gain some insight on the 'why' part.

  • One more possibility to consider: does your tilemap exist on the layout in the layout editor? If it doesn't, the texture needs to be loaded into memory on creation, which may result in a visible delay.

    Why are you using a tilemap to black out/fade in instead of a layer background, sprite, or tiled background object?

oosyrag's avatar

oosyrag

Online Now

Member since 20 Feb, 2013
Last online 26 Nov, 2024

Twitter
oosyrag has 38 followers

Trophy Case

  • 11-Year Club
  • 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
  • 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
  • Email Verified

Progress

21/44
How to earn trophies