Ashley's Forum Posts

  • It doesn't matter. This is the wrong approach for performance. Do whatever suits you best, and then optimise later based on actual performance measurements. Anything else is basically a waste of time.

  • iOS 12 removed the feature for security reasons. It's back in iOS 13 behind a permission prompt.

    • Post link icon

    I don't think so, it probably also redraws the OpenGL view on a click as well. This isn't really a useful direction to take the conversation though. The things I outlined in my first reply are the key things to make progress on this.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Projects use the same runtime code regardless of how you imported the project. So there is no technical reason for there to be any difference with imported C2 projects vs. other projects. If you encounter bugs as usual please report them following all the guidelines and we can investigate.

    • Post link icon

    Well, you can't really rule it out - driver bugs can be non-deterministic, and could involve memory corruption that depend on random unrelated details of the app. And nothing else significant other than redrawing an OpenGL view happens when you zoom the layout view.

    • Post link icon

    I've been thinking for the past few minutes but I can't think of any reason zooming in would cause C2 to close.

    Well, zooming will redraw the Layout View, which is rendered with OpenGL. That suggests it might be a GPU driver bug...

  • I tested your project on a Pixel 3 and got the following results:

    C2: first switch ~232ms, later switches ~100ms

    C3: first switch ~170ms, later switches ~100ms

    So according to this, the C3 runtime is faster in this case. I don't know why other devices would be different, maybe specific hardware is better or worse in different cases.

    Besides, C3 has a new feature that helps you hide this from the user - there's a built in memory management action "Load layout images", so you can load the next layout's images in the background while the current layout continues to run, and then switching layout will be instant. This feature is not available in C2. If I use "Load Layout 2 images in to memory" on start of layout in Layout 1, then it can switch layouts in around 5ms, which is far faster than you can ever achieve in C2.

    So as far as I can tell C3 is both faster at loading layouts and it has a feature to help guarantee that layout switching will be instant, which works here.

  • So it dosent matter how many family members there are?

    If by "family member" you mean "object type added to the family", then no. Families work in terms of instances, not object type members.

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