Ashley's Forum Posts

  • It looks like this issue which has already been fixed. (As ever it's best to post bugs to the bug tracker, they're not dealt with on the forum)

  • We made some changes and it should be working better again now - sorry for the trouble folks.

  • We made some changes and it should be working better again now - sorry for the trouble folks.

  • Windows has a hard-coded limit of a maximum of 10,000 images. If you add in an icon per image it could be hitting that limit. Try changing the icon caching setting. Also note Construct 3 was rearchitected to avoid this limit completely so can better handle such large projects.

  • I just rebooted both web servers, hopefully that will help in the short term.

  • I think this comes down to the sequence of how collisions are checked in the engine. If you check for all solids colliding with a sprite it goes along these lines:

    1. Collect all nearby objects using the Solid behavior (using collision cells)
    2. Run through list of nearby objects, skipping any disabled Solid behaviors (or with mismatched collision filtering tags)
    3. If solid collision enabled, test for overlap (which goes through its own process of bounding box, bounding quad, then collision poly, to try to use quicker checks to avoid a full poly check)

    If you have 1000 sprites all checking for collision against themselves, then that requires 1 million collision checks per tick. Obviously this is extremely demanding and even the tiniest variations in how the engine handles this will produce measurable performance differences.

    If the objects don't use the Solid behavior at all, then the process stops at step 1 (it gets an empty list). If the objects use the Solid behavior but they are all disabled, the process stops at step 2 (it collects a list of solid behaviors, then skips them all because they're all disabled). If the objects use the Solid behavior and they are all enabled, then it proceeds all the way to step 3.

    It kind of has to work like this, since the collision cells optimisation works by grouping object types in to regions of the layout for handling any type of collision (not just solids), which necessarily does not take in to account any enabled/disabled state for behaviors. So yes, in this case you can measure a performance difference between no solid behavior, and a disabled solid behavior. In practice though I don't think this will affect most games, unless they do something similar involving millions of collision checks per second (which is already an obvious thing to optimise in your game).

    While profiling the project I found an easy way to optimise the checks for disabled solids, which on my system boosted one test with 1000 objects from ~18 FPS to ~30 FPS, so that should help a bit. But checking for collisions between all combination of hundreds, or thousands, of instances is always going to be incredibly CPU intensive and is something that generally ought to be avoided. Also if these objects were spread across a large layout, collision cells would be more effective at eliminating collision checks for far-away instances.

  • Performance could well depend entirely on the specific events you're using, but unless you share an actual project file nobody can see that.

  • Actually I think it's also worth mentioning the "use worker" mode is pretty new and may have different jank characteristics. So it might be worth trying with that both on and off.

  • People have been bringing up jank from time to time over the past few years. Ultimately for flawless jank, a frame needs to be rendered every ~16.6ms without fail. Rendering a frame means running all the logic for a frame, issuing draw calls, which then go through a highly complex graphics driver and compositing stack, all the way to the physical display. This is a long and complicated process that all computer graphics go through, and the regular 16.6ms deadline is a demanding one. All it takes is something happening in the background, such as a backup, virus-scan, or other resource-intensive activity like launching an app or performing background work in the OS, which steals a few milliseconds of work and the frame deadline is missed, causing jank. Fullscreen games usually bump their priority up and pause background work to ensure rendering is smooth, but windowed content has to contend with everything else happening on the system. So I think jank is likely to always be possible in a windowed game, and the behavior tends to be non-deterministic since it depends on system-wide activity working towards millisecond deadlines.

  • Filed this NW.js bug for the crash issue.

  • All changes are listed in the release notes. The ones that apply to ads are:

    Mobile Advert: Deprecated 'Configure' action, as using the plugin properties for configuration is now a requirement

    Mobile Advert: remove any whitespace surrounding app IDs, pub IDs and unit IDs to fix typos

  • The C3 runtime is only fully supported for iOS 12+, which is covered in the manual.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It's not clear from your posts which version you are using. Is this an issue in the 0.40.1 version? Which steps are you following exactly? In general we need all the information required by a bug report to be able to help, otherwise the information is too vague to be of any use.

  • What about object's conditions and actions? For example, "Sprite Is overlapping another object" or "Dictionary set key" - how do I call these from the script?

    There isn't any way to call arbitrary conditions/actions/expressions, and probably won't be, because as I mentioned these fundamentally rely on picking which isn't a concept in scripting. There are alternatives though, such as the method to test for an overlap between two instances, or script interfaces to access specific features like dictionary keys. These are the kinds of building blocks that the Construct engine itself is built from, and these are the same things you can use in scripting to build your game out of as well.

  • When object instances are picked by event, how to pick same instances in the script. For example, I have an event "Player has LOS to Enemy", inside it a JS function "MarkEnemies()" is called, will it automatically pick the same enemy instances as the parent event?

    Scripting has no concept of picking. That whole concept is unique to Construct's event system. However you can access the picked instances from script using the IObjectClass methods, e.g. the pickedInstances() iterator.

    Different ways to pass information from the script back to events - set global/local variables, call C3 functions etc.

    That's already covered by the Integrating events with script example.

    How to use object's triggers, conditions and run actions from the script? For example, if I need to change Bullet angle, I should call something like Player.Bullet.SetAngleOfMotion(n) - what is the correct syntax and where can I find this action/method name?

    All available calls are documented in the scripting reference section of the manual. However behavior calls aren't yet supported - it's on the todo list.