Ashley's Forum Posts

  • 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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

  • 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.

  • Nothing else in Construct uses this, so there is not currently any mechanism for it. Further it's complicated because to balance memory usage and rendering performance, the sprite image data is either in storage in compressed format (therefore requiring loading and decompressing to access the image data), or uploaded to the GPU as a WebGL texture (where it can only be rendered, or if you are willing to kill GPU performance, read back to the CPU, in which case it will have also gone through a lossy alpha premultiplication). So I have to ask what do you need to use this for, and is it really the best/only way to do that?

  • It's just an oversight. I've added it to the todo list.

  • I just updated the WebGLRenderer docs to cover new methods CreateDynamicTexture(), UpdateTexture() and DeleteTexture(). These should be enough to implement the approach I outlined above. If not let me know and I can look in to covering more of the API surface. These methods should already be supported in the runtime, but note if you want to use them in the editor they won't be supported until the next release.

  • It seems to work for me. As usual if you think there is a bug please file an issue following all the guidelines; we need all that information to be able to help.

  • Updated the original post with new downloads based on Chrome 76 (NW.js 0.40.1). This should have a fix for a crash issue involving popup windows.

  • I think the best approach would be to use the same approach as the Text plugin, which similarly renders via a canvas. The steps are roughly:

    1. Draw content to a 2D canvas (text for the Text plugin, or in your case a Spine rendering)
    2. Create a new empty texture managed by the plugin
    3. Whenever the canvas size changes, destroy the texture and create a new one to match the new size
    4. Whenever the canvas content changes, upload it to the texture
    5. Finally draw the texture normally with a quad

    The key points are the texture is owned and managed by the plugin itself, so it's not trying to overwrite existing content used by other parts of the engine; it uses a direct WebGL texture upload so there's no unnecessary compress/decompress cycle; and there is support in the engine for this approach already (as Text uses it already). I also must point out that you cannot safely mix raw WebGL calls and Construct renderer calls, as Construct's renderer queues WebGL commands using a batching system (meaning WebGL calls will happen in an unexpected order) and heavily relies on caching and ignoring redundant changes (and changing WebGL state outside of the renderer with calls like bindTexture will corrupt the internal state of the renderer and probably break the game). This is why there is no documented/supported way to get the WebGL context directly - it's for good reason! I've added to my todo list to document the necessary renderer calls to support that approach.

  • Have you got objects correctly placed in your layouts? The way memory management works is it expects all objects that will be used on a layout to be placed on that layout in the editor. Then if you don't want them to be used on startup, add an event to destroy them on start of layout. This informs both the way objects are grouped on to spritesheets, and which objects are loaded in to memory at runtime when switching layouts.

    Also if you switch the spritesheet size down to 512, then even if that same problem happens, it's only 1/4 as bad.