Ashley's Forum Posts

  • You can choose what you want. It is good example to show you we don't have any control on spritesheeting with C3.

    I'm totally confused because these two sentences directly contradict each other.

    If we have animated sprites in project this time it is exporting that frames using max spritesheet size (1024 for C2)

    C2's max spritesheet size is hard-coded at 2048 and there is no option to change it. C3 has an option to change it, and smaller sizes tend to use less memory, so C3's 1024 setting can help.

    You can say use 1024 option. It is not really help on mobile.

    I made actual measurements and demonstrated it got pretty close to C2's memory use.

    FYI C2 loads images one after the other, but the C3 runtime loads images in parallel, which is faster. At the time I wrote it I took some measurements that showed C3 could indeed switch layouts faster than C2. But as noted it depends on the memory use, since using more memory also requires loading more memory. Given similar memory usage though, the C3 runtime should be significantly faster at loading.

  • So does that mean, in theory, if I do a for each enemies, I should create a Boolean that says “Exists” and check that first before the for each?

    Do you mean comparing a boolean instance variable? That doesn't seem to make sense, because the object still exists even if you set that to false...

    Anyway, normal conditions do an internal for-each loop along the lines of "for each instance, if it matches the condition, pick it". So if you have 1000 instances, starting with a "compare boolean" condition for example would still iterate 1000 instances, so it doesn't avoid the problem of checking lots of instances. Only "is overlapping" has the special quality of being able to entirely skip far-away instances via collision cells.

    Checking a boolean instance variable first might help if later conditions are particularly slow, and it's much faster to first filter by a boolean, but I think such cases are rare.

    I remember seeing a tutorial on the subject (that I would have to do some digging for) that stated that checks with families checked for every sprite in the family even if they didn’t exist in the layout.

    That's incorrect, because objects that don't exist, don't exist. Events can't pick nonexistent objects and run actions on them. So I guess the tutorial you read was wrong.

    • Post link icon

    With issues that are so difficult to pin down it would be helpful to have:

    1. Full system details of anyone who is affected by this
    2. Full system details of anyone who is not affected by this - if there are people out there who are working away just fine in r269. This could help start to correlate the issue with certain system configurations. It may for example actually be caused by something like a buggy GPU driver update for certain nVidia GPUs - we've certainly had serious and equally difficult issues in the past along those lines.
    3. Use all of r265, r266, r267, r268 and r269 for long sessions and identify where the stability issue first showed up (if it is newer than r265). This will help narrow down the set of possible changes that could have started causing a problem.
    4. Try working with Preferences -> Misc -> Other -> Icon mode set to "Don't show unique icons". If this is anything like previous leaks involving Windows GDI and the "10000 graphics objects is enough for anyone" limit in Windows, that setting may work around it.

    Hopefully that provides some leads and some ways others can contribute helpfully to figuring out what's going on here.

  • Why don't you give us a choice?

    And don't change any option in my example

    You first asked for an option, then insisted that any options must not be changed in your project. So I don't know what I can do to help you any more.

  • Spritesheeting had a number of upgrades in C3. However it's extremely complicated and involves endless tradeoffs. It's pretty much the case that any change we make at all to spritesheeting, half of games get better in some way, and the other half get worse. We've played this game of whack-a-mole for some time and I don't think there's much more we can do to improve things for everyone.

    The key changes in C3 are preview mode also uses spritesheets - C2 does not in preview mode so you have to export to get a fair comparison; and C3 can combine more kinds of objects on to single spritesheets, whereas C2 never does. This means in C2 you often have far more separate image files, which in some cases can slow down downloads and loading, and reduce rendering performance at runtime, however it offers more granularity in memory management. In C3 the objects combined on to the same spritesheets are the ones most commonly used together on layouts across the project, the idea being that when it loads a spritesheet it's most likely all those objects are being used at the same time, thereby minimising the likelihood that a spritesheet is loaded with some content that won't be used. From what I've seen this does tend to scale pretty well to large real-world projects. (This doesn't tend to work so well with dummy projects, because they're not realistic examples of objects being re-used across multiple levels.)

    Also, C3 does already provide options to control this. The max spritesheet size setting lets you alter the performance vs. memory use tradeoff. According to my tests with the provided .capx I get:

    Exported C2 project: ~26mb image memory

    C3 project with max spritesheet size 1024: ~29mb image memory

    That's near enough to the C2 memory usage, so it seems that option is already there and working for your case.

  • Look at the memory management system actions. They're only available in the C3 runtime. There are also new spritesheeting project settings to help control memory use.

    • Post link icon

    Ah, I see. (This is the kind of detail that gets lost in long threads...)

    I've added a new beta branch on Steam that is fixed to r265 so you can use that to roll back if you want. But that doesn't itself do anything to solve the problem.

  • Conditions only check the instances picked by previous conditions. So you can use a condition to filter down the picked instances to just a few, and then the next conditions will only run on those instances.

    Testing overlaps is actually a good way to filter down instances, because it uses the collision cells optimisation to avoid even checking far-away instances. So it can even scale to enormous layouts with thousands of instances and stay efficient.

  • Construct 3 can directly import C2 .capx files.

  • And how can I call their library inside the runtime.js inside the c2runtime folder?

    I don't understand why you're asking - it's all still JavaScript. So, the same way you already are.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • FYI Construct 3 may well be better suited for this. Firstly the C3 runtime handles image memory much more efficiently. IIRC the C2 runtime always holds all compressed images in memory at all times, so you pay a memory cost for images even if they're not loaded. The C3 runtime avoids storing them in memory at all until they're really loaded, which can save tons of memory for large projects. Secondly the C3 runtime has built-in features to load and unload images for objects which helps manage the memory usage within a layout.

  • My plugin does not have a c2_runtime folder

    You'll need a c2runtime folder with a script named runtime.js in there with the C2 runtime implementation.

    I'd hope sooner or later KaiOS will update the browser engine and then C3 runtime games will work fine on it too!

  • Create an event sheet function with a string return value. Inside the event sheet function, add a script action with: 

    runtime.setReturnValue(testing());

    Now you can call the event sheet function as an expression, and it returns a value from JS.

    The general approach is to "wrap" JS functions with event functions.

    • Post link icon

    Then what about making a beta branch with r265?

    What does that actually solve? You can already roll back to r265 if you want. Just download and install it. It won't open projects saved in newer releases, but if you're willing to modify the project file to allow that, then you can already go ahead and do it.

  • Which platform is that? All major browsers have supported WebGL and WebAssembly for some time now.