Ashley's Forum Posts

  • It's unusual to disable hardware acceleration in Windows, and it could be the cause of the problem in the first place. Have you tried using the system defaults?

  • Closing as this is not a bug report following the guidelines.

  • If you are only managing small numbers of objects, this blog post applies: https://www.scirra.com/blog/83/optimisation-dont-waste-your-time

    For large numbers of objects, creating and destroying objects is actually relatively CPU-intensive: the engine has a lot of internal data structures relating to created instances which all need to be updated when objects are created and destroyed. It's not slow per-instance, but adds up to a lot of work if you are handling hundreds of objects. In this case setting invisible (or repositioning far away) can be faster, but then you have to balance that with the fact they still exist and events will therefore still test against them. Repositioning far away is good with collision cells since it removes them as candidates for collision tests. Overall I'd say if you have a very large number of objects that are constantly appearing and disappearing very quickly, implement it by repositioning them far away instead of destroying. Otherwise normal create/destroy should be fine.

  • Moved to website issues. Tom runs the website/Arcade stuff, not me, but I don't see a problem with this.

  • Running a server requires some technical knowledge. You should not purchase the server if you do not understand the information in the description relating to NAT, SSL certificates and TURN servers, since these are essential aspects of running a signalling server. You can always simply connect to wss://multiplayer.scirra.com which runs on a dedicated server with a gigabit connection, so has more than enough capacity to run a great deal of games.

  • We deal with all license-related issues by email, please continue to take this up there if you still have trouble.

  • There isn't a new tutorial, because it's not a new feature. See: https://www.scirra.com/tutorials/71/how-to-make-native-phone-apps-with-construct-2-and-phonegap

  • I don't think it's a big waste of space, it's only a small size increase. It guarantees that no colors bleed through from adjacent images. For example if you had a red square and a green square exactly side-by-side on a sprite sheet with no padding, sometimes the red sprite could have a green tinge bleeding through down the side after scaling or rotating, and it's important to avoid such artefacts in all kinds of games.

  • Closing as won't fix: by design, changing the animation inside an animation trigger (in this case, "On animation finished") causes the animation change to be postponed to the next tick. Unfortunately I can't remember why this was originally done, but it was in response to other bug reports. This means for one tick it renders the last animation frame at the offset position. This is not normally a problem, and only seems to be because you're unusually using the animation system as a way to move objects. You don't need to use animations for that: you could just have a cropped single frame for the "move" animation and change its position with events only instead of wastefully using an animation to simulate movement (see remember not to waste your memory). Alternatively as a workaround add "Wait 0 seconds" as the first action in "On animation finished", which postpones both the positioning and animation change to the next tick, where they occur simultaneously.

  • I spent a while testing in Chrome, Firefox and Edge and I could never reproduce what the gif shows. Is there any way you can find to reproduce the issue more reliably?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Your linked .capx has 138 events. This is far too many to consider for a bug report. Did you upload the wrong file?

  • 600x600 is a poor size because it is just over a power-of-two size (512x512) so will be awkward to assemble on to a power-of-two size spritesheet.

    As the export-time optimisations tutorial says, the ideal size is two less than a power of two, because C2 adds a 1px border around images when spritesheeting. So on a 1024 wide sheet, 512x512 is padded to 514x514 and it can only fit one image on with nearly half the width wasted (unless something else smaller fits in there). However 510x510 pads to 512x512 and fits two across exactly with zero wasted space.

    However those are some slightly weird numbers - it might be best to just aim for 2000, 1000, 500, 250, 100, 50.

  • Can't reproduce. I published Space Blaster with the Intel XDK building for Android with Crosswalk, and the music (which is in the music folder) plays as expected on a Moto X (2nd gen) with Android 5.1. The original report does not include a .capx so I can't investigate this any further. This is why we ask that you always follow the bug report guidelines. Closing. Please file a new report following all the guidelines if you still have trouble.

  • Closing as not a bug. Following your instructions, I add the effect to the initial layer, which is opaque therefore turns all red. If I add a sprite, that turns all red too, so it can't be seen. This is working correctly. Please also always follow the bug report guidelines in full; you did not attach a .capx so I cannot guarantee I am seeing/doing the same things as you.

  • Closing, please follow the bug report guidelines, and note we will not investigate if the source of the problem is from your server or database.