Ashley's Recent Forum Activity

  • Is the Crosswalk Player still maintained by Intel? I thought they had dropped it. What version of Crosswalk is it using? Does it work if you build a Crosswalk app with the XDK?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Modern graphics cards don't have any of these restrictions anymore. They deal with non-power-of-two textures natively, and graphic languages like OpenGL (which WebGL is based on) also support NPOT textures.

    I'm not actually sure to what extent this is really true, when it comes to memory use. OpenGL specifies non-power-of-two support in terms of rendering behavior, and AFAIK it's perfectly spec-compliant for a GPU to actually allocate a power-of-two texture, paste in a non-power-of-two image, remember the size of the image, then act as if the texture was really that size (such as by calculating texture co-ordinates relative to the image size instead of the surface size). So I don't know if "NPOT support" actually always translates in to "memory efficient NPOT textures". On top of that mobile GPUs tend to be simpler/more limited so do have NPOT limitations, and I think the square power-of-two limitation does still apply on some hardware as well. Even if non-square power of two-edges is supported, it's still hard to tell that's not using an in-memory power-of-two surface without knowing what the driver is doing.

    I don't know all the answers here, so Construct 2 errs on the side of caution and spritesheets on to square power-of-two surfaces to ensure no matter what the driver pretends to support, there is minimal wasted GPU memory.

    WebGL 2 (based on OpenGL ES 3) also in theory gets non-power-of-two texture support, but again it's still not obvious this also means "memory efficient". It means we get mipmaps for any size image which is nice, but that's all I would count on.

    Compressed textures are a tricky area for a different reason: they are usually far less efficient at compression than PNG and JPEG, which means the compressed format has to be encoded from Javascript or the browser. No browsers support this yet, and doing it in Javascript means running in to patent issues on encoding some non-free formats, is probably slow, and there's still not one format that works everywhere. Also they are often lossy, meaning it can garble nice 2D artwork (they're designed for 3D engines where distance helps hide artefacts). So it's unlikely to be supported any time soon.

  • 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

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

Ashley's avatar

Ashley

Online Now
Early Adopter

Member since 21 May, 2007
Last online 27 Oct, 2026

Twitter
Ashley has 1,834,734 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x6
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x44
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs