Ashley's Forum Posts

  • Yes, so long as you change the plugin ID so it's published as a separate plugin. How do you intend to achieve that if you don't simulate the complete path? You need to know its entire path before you can play it back in reverse, right?

  • Since the particle path is random and non-deterministic (in the sense that you don't know what random alterations will be made until you call random() at the time you want to make them), the only way I can think to do this is to simulate a complete forwards path, then start at the end and play it backwards. That's not exactly a trivial change. I think perhaps it could be made in to a separate plugin.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I think I could reproduce this just using Space Blaster. Should be fixed in the next build.

  • — - you could test this further in r177 by enabling/disabling 'Preload sounds' in project properties (it's a new feature) and comparing memory use. Do you really have ~600mb of sounds? Are you hoping to target mobile devices? How many sounds do you have exactly? Are any of the sounds very long (e.g. 30sec+)?

  • The same caveats about working sets that I mentioned in the other post apply here. I have reviewed most of our saving code and made some measurements with Chrome dev tools. I am pretty sure there is not a memory leak in our code. This does not rule out a memory leak in Chrome itself, but I think it is more likely to be making use of system memory for caches if it knows there's lots of system memory available. (After all if you have gigabytes of memory going empty, why not use it?) The save code does generate a pretty large JSON object, stringify it, then discard it immediately, so it may show up clearly when the collector decides to do a full GC sweep (until that happens there are likely lots of large JSON objects and their string counterparts hanging around unused in memory from previous saves).

    I can't reproduce that error on Firefox, btw. Were there any special steps to follow to get it to appear?

    I've tried disabling the IndexedDB backend for saving, making it save to WebStorage instead. It seemed to avoid using so much memory. So perhaps it is related to that. IndexedDB saving is asynchronous, and this particular example is unique in that unlike most realistic games it creates multiple save requests in parallel, since it does not wait for "On save complete" to trigger before changing layout then issuing a new save request. That may be related to the error in Firefox, and it may be related to your original game, which may accidentally make large numbers of save requests such as by trying to save in an event that is true every tick. Still, unless the game at some point actually runs out of memory and crashes or shows a JS error, I can't say this is definitely a bug in our code.

  • I don't think there is anything to be done here. Memory management in modern browser engines is complex and measurements may not give an accurate picture of what is happening. There are a lot of subtleties to making these kinds of measurements.

    I am pretty sure our memory management code works and that textures really are released by our engine when switching layouts. We have dealt with bugs in other engines like Ejecta where the engine itself failed to release textures and caused out of memory errors, then we fixed it and the out of memory errors went away. (None of this involved changes to Construct 2 - only Ejecta.) When the memory management feature was first introduced, it also enabled large games that previously would not start up to run smoothly throughout.

    Some of the complexities involved in these measurements are issues like:

    • the "working set" is not exactly the same as "amount of memory allocated by the program". MSDN defines the working set as "the set of pages in the virtual address space of the process that are currently resident in physical memory". This is subject to the OS virtual memory management and it will probably be making decisions based on caching for performance with respect to the total amount of memory in the system and its current usage.
    • modern browser engines make heavy use of caching to improve performance. While our engine may explicitly release a resource, the browser may keep it around if it sees no harm in doing so, so subsequent requests can be faster. If the system really gets close to using all its resources (which your test does not appear to come close to), the browser may start freeing its caches to prioritise memory use over performance.
    • modern javascript engines have two or more levels of garbage collection. Typically there is a small, fast and regular generational collection aimed at releasing short-lived objects, and then there is a separate large, infrequent, slow full-heap sweep aimed at releasing long-lived objects. There may be multiple stages in-between and they may be separate sweeps aimed at different sized allocations. This means identifying a drop in memory use does not mean the browser has released all unused resources - it may have only done a partial sweep.

    Minimising Chrome probably causes a full sweep since it thinks it may not be looked at for a while, and it's a good opportunity since doing it while scrolling or playing a game can cause a momentary pause (jank). Your data appears to support this, where the blue line also represents some kind of cache that isn't being freed, perhaps because Chrome or the OS has identified there are still plenty of free resources on the system so doing so would only reduce performance.

    While it's interesting to investigate such issues, it is difficult to draw firm conclusions from data like this. I think we have to limit memory use bug reports to cases where the system can be shown to fail due to exhausting available resources, which suggests a memory leak. (I haven't investigated the savegame bug report yet, but the javascript error suggests it's more likely there's a real issue there.)

    Also note it's good to check the latest betas if possible - we may have fixed or altered the issue in recent releases, either deliberately or accidentally.

  • Thanks, fixed in next build.

  • Closing as won't fix. The problem is you are categorising long music tracks as sound effects. Sound effects are designed to play with low latency and are thus held decompressed in memory at all times. Music tracks stream the compressed audio so have much lower memory usage.

    It is not easy to deallocate sound effects, because if they are not loaded and suddenly need to be played, there is a delay while it decompresses the audio file again. For big sounds on mobile this can take literally seconds. Perhaps we could add an "unload audio" action to correspond with the "preload audio" action, but I don't see a compelling case here, because it's wrong to categorise music under the "sounds" category.

  • Closing as fixed in r177.

  • Phobos002 - we are coming up to a stable release and you haven't updated this bug report. If you don't update it soon then the next stable release might still contain this issue.

  • but it could be solved by clear document.

    Assuming users read documentation

    In the past we've even had messageboxes pop up with very clear instructions on what to do, and users still come to the forum asking why it doesn't work.

  • Closing, see "Expecting math calculations to be exact" in common mis-used events and gotchas.

    In binary floating-point representation, 0.1 is a recurring decimal (like one-third in base 10 is recurring forever as 0.333333333....). Naturally with a limited precision some rounding happens. This happens at the CPU level and affects all software on your system.

  • Just set unbounded scrolling and impose your own custom limits with events. 'Scroll To' definitely works with unbounded scrolling.

  • delgado - that project makes no sense. You are trying to use "Sprite is outside layout" to detect if all sprites have been destroyed. You should check if the sprite count is 0 instead. If no instances exist, none of its conditions are ever true (it makes no sense to ask if a sprite is inside/outside the layout if none exist - the question simply does not apply).

  • I would strongly recommend you do not design plugins that operate on any part of the game that the user does not explicitly tell it. For example don't automatically find objects and work with them - require the user to add the object via an object parameter before your object works on it. This avoids surprising "magical" behavior that can't be turned off, conflicts with other plugins that take the same unwise approach, and allows the user to exercise control over precisely what your plugin does. I would give more specific advice if you had mentioned exactly what you're trying to achieve.

    For private global data, just put some variables in the file-level closure that wraps everything. It will be global to all instances and types, and it does not pollute the global namespace or attach any junk to "window".