Ashley's Forum Posts

  • Closing as not a bug. 'Layer 1 is visible' is true every tick, so you keep resetting the flash every tick. Add 'trigger once' and it works correctly.

  • Please re-test with r156 - we already fixed an issue that sounds the same.

  • Can't see any issue here. By putting in a text object to display fullscreen_scale_toggle, it's actually mode 1 that sometimes displays smaller. That makes sense, since you're setting a larger canvas size, so integer scaling that up has fewer options.

  • Arima - your example could double the peak texture memory usage. Take your example but going from level 1 to level 2 instead, which use different image sets (e.g. level 1 is "desert" world, level 2 is "ice" world).

    Currently the C2 engine efficiently manages the peak memory usage like this. When switching layout:

    • the engine stops running
    • any images used on level 1 but not used on level 2 are released
    • then any images used on level 2 but not used on level 1 are loaded
    • then level 2 begins running

    Therefore the peak memory usage is never higher than what level 1 or level 2 would use by themselves. This pretty much can only happen because the engine stops running while this happens, so it doesn't suddenly need an image after releasing it.

    If you can load the next layout's images before the current layout finishes, you end up with a pattern like this:

    • level 1's images are in memory
    • you request to load level 2's images while level 1 keeps running
    • briefly, both level 1 and level 2's images are in memory - this could be up to double the memory usage
    • when switching to level 2, level 1's images are released and memory usage goes back down

    For any games close to the memory limit of the system, this would probably crash the game when it changes layout.

    For previewing, it's a different matter really. Maybe we could do something to speed it up, but it's a little complicated: you can't create objects from other layouts or go to a different layout until the rest of the game finishes loading. That could result in some weird preview issues. An advantage of loading the entire game in preview mode is you can jump to any layout at any time.

  • This is exactly what happens when the graphics card drivers are broken. Are you sure the drivers are up to date? A fresh install would suggest you got the default out-of-the-box drivers which can be pretty old.

  • Try the node-webkit plugin. (It will only work when exported to node-webkit though.)

  • NaN is the correct answer if you do something like divide by zero, which would happen if q is 100.

  • buse - just post a bug report with the http and www part removed for links.

  • Well, did you test it on other platforms? You should always do that to identify platform specific issues. That's why the bug field has that information to fill in by default. If you can't reproduce it on any platform other than Firefox OS, it's probably a Firefox OS bug.

  • Report a reproducing .capx to the bugs forum or we won't be able to investigate.

  • I think the browser keeps the compressed image data in memory, but can flush it out if it runs out of memory and load it from disk again later if things get tight. However if it does not even keep the compressed image data in memory, the pauses between layouts will get even longer, since it not only has to decode the compressed image but also go all the way to disk to load it. Are you sure that's what you want?

    I'm not sure adding actions to manage texture creation is such a good idea - what could you do that's better than layout-by-layout loading without either using even more memory or having janky games which keep loading textures mid-game?

  • We already support a new physics engine, the asm.js compiled version of box2d, available in the latest beta. I doubt any non-asm.js library could beat it performance-wise, it's close to native engines in speed.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • jayderyu - I think you're talking about something else - the suggestion in this topic is not to download assets until they're needed. If you switch between layouts, right now that means everything is already downloaded but it still needs to load stuff in to memory. If there is 250mb of images to load in to memory in the next layout, that's just plain and simple a lot of work, and even a native engine is going to take a few seconds to get through that (indeed, that all happens in the browser engine which is actually native code). So that's simply a very large amount of work given the current capabilities of computers.

    Arima - if your game is already offline (e.g. node-webkit), then there is nothing to download. As above, there may still be pauses between switching layouts not because anything is being downloaded, but simply because loading all the images in to memory can take a moment. And to clarify, layout-by-layout memory management means it does not load the entire game to memory on startup, only the first layout, and when you switch layout it only loads the next layout's images, and so on.

  • 1) This is on the todo list. We can't give an ETA, sorry!

    2) This is probably already doable via events. The Pin behavior might be especially useful here. We generally avoid implementing high-level features in the engine in favour of general-purpose building blocks, to avoid becoming a "cookie-cutter engine".

    And yes, we don't maintain the CocoonJS plugin any more, Ludei do.