Ashley's Forum Posts

  • I do not agree that plugins should re-use other plugins. They should generally be standalone and not depend on anything else, and the user should set up dependencies with events. For example if you go ahead and rely on calling the Sprite object 'Set animation frame' routine directly, you now:

    • have a hard dependency on the Sprite object: if it's not in your project, that feature of the plugin will not work,
    • lose control over the Sprite animation frame from events: either the plugin overrides it continually, or will change it based on its own logic which may conflict with normal animation playback or the user's events,
    • breaks interoperability with other features, e.g. what if you wanted to use a Spriter animation instead? Or another third-party plugin?

    Compare to simply providing an expression for the animation frame the plugin wants to set. This solves all the above problems, and the user can achieve what you wanted in the first place by simply setting the animation frame to that expression every tick, but with way more flexibility to implement their own custom logic around that.

    Note very few official Construct 2 features depend specifically on other plugins or behaviors. For example you can set text to either Text objects or Sprite Fonts; you can use the Pathfinding behavior on any object, not just Sprites; data is provided through expressions instead of forcing you in to using WebStorage; etc.

    So no, I see it as always a bad idea to do this, unless you somehow persuade me that your particular use case cannot reasonably work any other way.

  • Does the problem still occur when publishing with Crosswalk? Android's browser or web view has many bugs that the Chromium-based Crosswalk doesn't have.

  • Are you using the techniques described in Remember not to waste your memory? You must have either an extraordinarily large number of animation frames, or many extremely large images (2048x2048 or larger), to use such an incredible amount of memory. You will simply have to use fewer frames and lower-resolution images. 2.7 GB is so insanely high that many 32-bit devices simply won't have the address space to allocate that much memory. To reach a reasonable range of devices you're looking at needing to cut at least 80% of the memory use of your project.

  • You should describe all this by email and we'll take it up there.

  • We don't do license support on the forum, please contact the support email.

  • Memory usage describes how to calculate the memory use for an individual image, but remember spritesheeting and power-of-two padding will make it vary on export.

    [quote:3flus19s]i heard that one way to optimize is to always try and keep the images to 16x16, 32x32, 64x64 in those kind of intervals so they will fit better in the spritsheet on export.

    That's actually the worst size for sprites, since sprite animation frames go on a power-of-two sprite sheet with an extra 1px border added around every frame. So the ideal size is two pixels less than a power-of-two size, e.g. 14x14, 30x30, 62x62 etc. In fact I'd recommend just totally ignoring the power of two sizes and using whatever size you like and letting C2 spritesheet it on export. More info in Construct 2's export-time optimisations.

  • ajonk - please do not double post - you already made the same post here: https://www.scirra.com/forum/viewtopic.php?f=151&t=120775

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Render cells only benefit when you have thousands of static objects. Read the blog post on how render cells work. 100 objects is probably too few to show any benefit, and if they are moving (since they have the bullet behavior), using render cells could actually make it a bit slower.

    As the blog post recommends, the time to use it is when you can actually measure an improvement.

  • There's no easy way to do that, since the dimensions and offsets of the rectangles in the spritesheet are buried within the JSON data, which as mentioned previously is deliberately designed to be difficult to use. You may as well just cut them out manually in an image editor.

  • Apple do not support this in Safari 8. They did in Safari 7.1 with the "minimal-ui" viewport mode, which C2 uses, but they removed support for this in Safari 8, and have not added support for the Fullscreen API or orientation lock, so there is simply no alternative. I'm not aware of any HTML5 engine or framework that can do this, since as far as I can tell Safari simply does not support this at all. The only workarounds are try to stick to portrait mode (since landscape mode has big invisible areas that bring back the browser UI and generally get in the way of the game), or rely on 'Add to home screen' or publishing a native app. Hopefully a future version of Safari will add support for this.

    It's not a problem with all mobile browsers though: Chrome for Android supports both 'Request fullscreen' and orientation locking. See fullscreen and orientation lock in browsers for more information.

  • In the past a crash when the layout view first appears (when using File - New or File - Open) has always been a graphics driver issue.

    Do you have a dual-GPU laptop? For example if you have Intel HD graphics integrated and a separate nVidia card, it may ignore your settings or otherwise default to the Intel chip. You should make sure you have the latest drivers for the Intel graphics as well, to rule out that being the cause of the problem.

  • If you're that close you might be able to get it under the limit by:

    • use JPEG anywhere you can (think you said you were doing this already) - remember to set this in the Image Format options dialog from the C2 image editor, C2 ignores the imported format
    • use PNG-8 anywhere you can without causing a significantly noticable reduction in image quality (as above set this in the Image Format dialog in the image editor)
    • delete any .m4a files that are exported - Android can play the .ogg files. Mobile speakers are often not great so you may be able to get away with pretty low quality (unless headphones audio is especially important)
    • use an external tool to re-encode any large .ogg files to an even lower quality
    • any images which are blurry/same color/low contrast, resize the image smaller in the image editor, then stretch the image up again in the layout view. This makes the image smaller while producing a similar looking result
    • simply cut any artwork, music or sound effects that aren't strictly necessary

    Expansion APK support is in the works for Crosswalk, so hopefully that will be able to split off at least the images from the main APK file.

    Maybe I should write up a blog post on minimising the download size?

  • The easiest option is to use "letterbox scale" fullscreen mode and it will work on any size screen at all. If the aspect ratio is different, it'll show black bars down the sides (like 16:9 movies on a 4:3 TV).

  • [quote:ti7keqfg]Make that file in use (open it in a program that will lock the file)

    How exactly are you doing this step? You need to provide exact steps to follow so we can do exactly what you are doing.