Wouldn't it be better to implement a runtime property to switch between WebGL1 and WebGL2 instead?
I think it's best to avoid this wherever possible. The ideal situation is that everything just works and you don't have to fiddle with obscure (to a new user at least) settings to get things to work correctly. That's also why we didn't add a setting in the first place: if something can't be guaranteed to work, if possible the engine should work around it automatically. So the burden of "find the right settings that make sure it works" is handled by the engine, and not dumped on unsuspecting users to have to figure out for themselves.
These comments are unacceptable and you have been banned for one week. If your conduct does not improve, next time you will be permanently banned. We are willing to co-operate on any issues but you are required to follow the Forum & Community guidelines.
It just means people using beta releases.
Please file a bug following all the guidelines or this won't be investigated.
There was never meant to be a feature for that, especially not one that doesn't make it clear it applies to layouts other than the one you're looking at. I guess if you think it's important file a suggestion for it.
This change doesn't affect editing object properties across a whole layout.
It's not really meant for that - it only did that as an accidental side effect of being implemented at a time when C3 didn't have a way to edit object type properties only with no instances.
It also applies, but in the case of Drawing Canvas it stretches the max texture size to the size of the object rather than failing to load.
You can already view spritesheets in the editor (Project -> Tools -> View spritesheets), and adjust how they're generated using the max spritesheet size setting.
TBH some of the Playable Ads restrictions are pretty bizarre! e.g. I'm not sure why everything has to be in one file, when that makes it bloated and less efficient - if you want efficient transmission, HTTP/2 can send everything down one connection... and why would the size limit be uncompressed? Do they not compress the file before sending it...? If they cared about efficiency they should say "use HTTP/2 and use compression"...
This is actually very complicated for the same reason described here: construct3.ideas.aha.io/ideas/C3-I-683
Please report any issues to the bug tracker following all the guidelines otherwise we cannot help.
It would mostly affect GPU texture read performance. I'm not sure we have a performance test that directly covers that, but the fillrate test is probably closest.
Please file any issues to GitHub following all the guidelines. Last time I tested it, it worked.
Issues only mentioned in comments won't be investigated - please use the bug tracker.
It's still complicated to do that - there are no other features that require a layout restart to apply a change at runtime, and currently restarting a layout does not reload any textures because it knows it's using the same set of textures. So there's a new codepath to write for 'reload layout and also reload all textures as if it's a different layout', which will need separate implementation and testing to a normal 'restart layout'. I'd be more persuaded this was worthwhile if you actually had benchmark numbers showing this made a significant difference for a particular game.
Member since 21 May, 2007
The official blog for all things Construct and Scirra run by our employees!
Wider technology issues from Ashley's perspective.