Ashley's Forum Posts

  • The Google Play plugin is not compatible with CocoonJS or Crosswalk right now, it will only work from the web.

  • Unfortunately this is not currently supported, so yes you'll have to check at runtime.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The time scale will probably have no effect on performance.

    IIRC, 30 FPS mode was dropped simply because I couldn't get it working properly. Accurate timing in Javascript appears to be very tricky unless you just go with every vsync. With the same code some devices kept running at 60 FPS, others would get a really horrible choppy 40-45 FPS, some would get 30 FPS but still look horrible (it wouldn't hit every other vsync, it would have some ugly irregular frame pattern), still others would dip below 30 FPS and get close to unplayable framerates. It could vary between those even on different browsers on the same system. So it didn't appear to be useful, so I got rid of it. Modern budget phones are surprisingly good and can get close to 60 FPS on simple games, and it will only improve in future, so I don't think there's any need to bring it back (even if I could get it working).

  • You do not have permission to view this post

  • It's not supported. The engine caches collision poly data in various places, so if you change it the caches won't update and things will be broken.

  • It steps down by fractions, the same as when it scales up. Scaling up goes 2x, 3x, 4x etc, and scaling down goes 1/2, 1/3, 1/4, 1/5 etc.

  • Some old computers still have graphics cards with 256 or 512mb VRAM on them. This is separate to system memory so having 4 GB RAM does not mean you have 4GB of image memory available. If Construct 2 estimates your memory as being over that, your game will likely fail on those machines. 500mb+ is an extraordinary amount of memory and probably means your game is appallingly inefficiently designed; see remember not to waste your memory.

  • The stock 'pathfinding demo' example shows how to do this.

  • Share a .capx demonstrating the problem. It would be helpful to also reduce the problem to either something wrong with the AJAX requests, or something wrong with the array.

  • That looks like a Javascript library to read WebP. Actual browser support looks like this: http://caniuse.com/#feat=webp

  • but will be in theory a smaller filesize at the end

    PNG/JPEG compression will compress away empty space to effectively nothing, so in practice extra space in the image does not affect file size, only memory use.

    [quote:3gnhec7u]have spritesheets shared between animations

    They already are - a spritesheet can have images from all the animations of one object type on it. Two different object types won't share a single spritesheet, but then that probably helps keep the colour counts down (since animation frames of the same object type are likely to use a similar palette), making it more likely the whole spritesheet can go to PNG-8 and significantly save on the file size. Also as mentioned in the blog post, if everything ended up on one giant spritesheet, there would be no progress feedback while loading, so it's useful to break things up across a few spritesheets for that too.

  • It would be difficult to add. Don't hold your breath. You can work around it by putting tilemaps on rotated layers, but that won't work well for small objects. It's fine to use sprites or tiled backgrounds as small, dynamic parts of tilemaps anyway, so long as the large static parts are in a tilemap.

  • Images are decompressed in memory so the file size has no impact on memory use.

    The spritesheeter engine will already use 1024x1024 textures if the given images can fit on that. You are probably just using too many images. See Remember not to waste your memory

  • Make the looping portion a separate sound effect that is played as looping, and play the intro part separately.

  • I do not clearly understand why a rectangular sheet wouldn't be possible?

    Low-end GPUs only support square power-of-two texture sizes. Also, I don't think even having non-power-of-two texture size support actually guarantees that in memory they are a non-power-of-two size - it could still put it on a power-of-two size and just emulate non-power-of-two support (e.g. by reporting a different texture size to what's really allocated). Square power-of-two guarantees that the GPU texture will also be exactly the size of the spritesheet.