oosyrag's Recent Forum Activity

  • Use a fixed angle of your choosing and it will be the same every time.

  • Add an event- on start of layout set camera rotation to default rotation.

  • They will be archived in the previous suggestion platform, and yes you will have to copy and paste your suggestions to the new page, if they still matter to you, every few years or so.

  • That looks like a construct 2 screen shot. But that action still exists in construct 3 afaik. construct.net/make-games/manuals/construct-3/system-reference/system-actions

  • On created is a trigger condition. It can't be used with other trigger conditions unless the event is converted to an "or" block, or in a subevent.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • > ie: int(13.5451) gives you 13

    thanks for explonation of all system expressions

    i need receive: "13.5451"

    not 13

    Take out the int() part. If you know what an expression is you should be able to figure this out.

  • I wouldn't say always use only tilemaps or not, but tilemaps have specific advantages that you should take advantage of if it's suitable for your use. As always, there are multiple ways to go about implementing software, and the "best" way will always depend on your situation and goal.

    Ashley is vsync triple frame buffering something we have access to, or already built in? Ref: intel.com/content/www/us/en/support/articles/000006930/graphics.html

    Edit: Read some more and looks like double buffering is implemented by default in webgl, but doesn't resolve the drop to 30 fps on a missed frame.

  • Check your collision boxes in the animations editor. They can be different per animation frame as well if your sprite is animated.

    Make sure you don't have other conflicting behaviors active.

  • There's nothing wrong with using the CPU. The CPU is there to be used. Are you running into slowdowns? 7000 objects still seems within the realm of reason, although the line of sight checks could be causing you issues, as those have collision checks. With so many objects moving, some fps fluctuations would probably be reasonable and hardly noticable.

    The first thing that comes to mind is to add a condition filter out only the objects in range first to check line of sight on, then you're only checking on a few hundred at a time. Actually I'm not sure if collision/los checks can be optimized this way, so it would be nice if someone else could confirm.

    Why are you trying to make this work on low end platforms? If you want to target low end platforms, you don't do something that would push any limits in the first place. If you want to make a game about being able to collect thousands of dust particles, your idea by nature is not targeting low end platforms. Also, how do you define low-end? The computer you're working on? The cheapest phone you can buy today? A tablet from 10 years ago?

    Here's a quick example that runs fine on my machine at 10000 objects. I'm sure you don't need to cover the entire screen so you should be able to do with significantly less. Another simple option is to lower your target resolution, so you just don't need as many objects to fill the screen in the first place.

    dropbox.com/s/4rrawizdr9404nb/vacuumexample.c3p

  • There is a limitation of memory. You're unlikely to be anywhere near of it being a concern.

  • pcgamer.com/what-is-microstutter-and-how-do-i-fix-it

    Basically, on a 60 fps sync, even though your system is capable of 60+ fps, if for whatever reason it fails to render any given frame on time for 60 fps (this can be a memory issue sometimes, or simply high load, background processes or overhead, there are many possible reasons that can cause this), it will skip that frame resulting in an effective 30 fps (half) for that instant, which is very noticable as stutter. Over the course of a second, it might only skip one or two, resulting in the 59, 58 fps you sometimes see. This is an oversimplified explanation, and there is a lot more you can read about if you want.

    For one thing, frame buffering is a type of vsync that should minimize these issues, but I'm not familiar if that's implemented on the software side or hardware side as far as Construct is concerned, so check your graphics card settings.

    nvidia.com/en-us/geforce/technologies/adaptive-vsync/technology

    Also see if you can enable adaptive vsync on the hardware side, that could be another possible simple fix.

  • Vsync is a limit to only render as many frames as your hardware can display per second, because additional frames won't be shown anyway. In Construct, a frame, or tick, is basically a run through all your events before repeating. If you turn it off, then your device will try to do that as fast as it can, regardless of what can actually be displayed. So of course it will use up all the processing power it can.

oosyrag's avatar

oosyrag

Member since 20 Feb, 2013

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