Ashley's Forum Posts

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

  • No. It's only greyed out if you use script anywhere in the project. If you use only events, it's still enabled.

  • It tells you in the export dialog why:

    NOTE: this is not yet supported for projects that use JavaScript code.

    It's on the todo list to add support for that.

  • It should be possible if you use the Game Recorder object to record User Media.

  • That doesn't make any sense... reducing the spritesheet size increases memory management granularity ensuring it can avoid loading content it doesn't need. But yes, it can decrease performance as many more texture swaps are necessary. If this is what you get from reducing the spritesheet size, then the logical conclusion of that is that if spritesheets were disabled completely (effectively a spritesheet size of 0), then memory use will increase further (although this makes no sense...) and performance will reduce further. So that doesn't seem to solve the stated problem.