Ashley's Forum Posts

  • You do not have permission to view this post

  • Most modern displays only have one true display resolution (since they have a physical pixel grid of a fixed size) and simply stretch the screen to the native resolution to achieve a sort of fake support for different resolutions. That's the same thing 'Low quality fullscreen mode' does in C2.

  • As far as I can tell, sub-events to exactly what you describe already. Sub-events are "gated" by the truth of their parent events.

    You may also be interested in looking in to functions to improve the modularity of your events.

  • Why would you want to activate/deactivate a group instead of just putting all those events as sub-events under 'start of layout'?

    With a group you separate the events from their cause of running, and they also become delayed in time: they don't run at the same time as the 'start of layout' trigger, probably just the next tick afterwards, which can cause confusing sequencing issues. I'd definitely prefer subevents.

  • Maybe you need to re-publish with the latest version of Crosswalk?

  • It sounds like a pretty exotic question - I don't know many people who would re-write the entire game compatibly in a different engine later on, since that's double the amount of work (why not make two games?) Still, the easiest solution is to store everything on a server backend and have both versions communicate with that. In the browser you could possibly share local storage, but if you're switching from a hybrid to a native app, I don't think there's any way to preserve locally saved data.

  • akai998 - why not try Crosswalk? It is far better.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Ashley, just to clarify, there are no static frames that are larger than 1024x1024 (max size per frame 200kb), and all frame-by-frame animations are between 2 and 20 frames (max size per frame 50kb). I have looked into Spriter but it can't replicate the look of the complex animations I have hand drawn.

    I don't think I'll understand this unless you show some examples of the types of animations you are using. But surely you have must hundreds or even thousands of animation frames in total?

    Also when you are stating a size like 50kb, is that just the PNG filesize? As described by Memory usage, the correct calculation to determine the memory usage of a single image is W x H x 4, so a single 1024x1024 frame will use about 4mb of memory alone, regardless of the size of the image file.

  • So is there a simple way to import a json not formated for c2 and convert it to a tilemap?

    Is that what you are trying to do? Why would you even want to use Sprites for that instead of the Tilemap object? Your plugin should probably just convert the format in to one the Tilemap object understands.

  • optimize your pictures - 2^n x 2^n for your sprites

    That's actually the worst size: 2^n - 2 is best, since Construct 2 pads all images with a 1px border round the edge when putting them on a spritesheet.

    There must be thousands of large animation frames to use up gigabytes of memory. It's just a fundamentally inefficient approach to take with your game. You should redesign the project with a whole new approach. Maybe look in to Spriter for creating smooth animations with a very limited set of images. I imagine you are trying to use frame-by-frame animations to create smooth video-like playback, but you just can't do that with frame-by-frame animations without shooting memory use through the roof.

  • You should report this type of issue to the Bugs forum following all the guidelines so we can fix it if possible.

  • Closing as not a bug. Please follow the bug report guidelines, and note:

    [quote:2nwzyeg4]upload any sound and change the extension to .wav as long as its not on the recommended sound files

    This does not make it a supported sound file. Sticking a "cookies" label on a jar of pickles does not make it a jar of cookies.

  • What format are the .wavs that you're trying to import? Check they're 16-bit PCM at a reasonable sample rate (e.g. 44100). You can get all sorts of exotic formats in WAV files and the AAC and Ogg encoders don't support all the same ones.

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

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