Ashley's Forum Posts

  • Note the previous tutorial link is for Construct 2 and is out of date. For Construct 3 see the tutorial Offline games in Construct 3.

  • No, and it would be extremely difficult to add - a suggestion for this has already been filed and read the official response there for some of the details about why it is so difficult to do.

    There are other options for teamwork though, for example collaborating using source control tools like SVN.

  • I'm afraid it's impossible to tell what happened from that picture alone. We need reliable steps to reproduce the problem to be able to investigate.

  • Sure, just call the browser APIs directly. See getUserMedia.

  • Yeah, texture uploads are slow. Text does not do anything specific to handle this, but often text objects do not change every frame, so they just render like sprites and largely get away with it. Large text objects that change text every tick have been reported to be slow before, but there's not much to be done about it, so we just advise to avoid that case if possible, or use SpriteFonts which render directly without any texture uploads.

    Since a Spine animation presumably can be expected to always change contents every frame, then it will hit you harder. There's very little that can be done to optimise it, other than not using texture uploads at all. That is why my very first suggestion was to find a way to render it directly, so this problem would be bypassed. The main advantage of using texture uploads is that it's probably much quicker to get it working, since you mentioned it looked difficult to set up the library to render directly... so to completely solve this, you're probably just going to have to bite the bullet and do all that work.

  • Yes, we need steps to reproduce the issue to be able to investigate it. Please provide these otherwise there is nothing we can do. Unfortunately videos generally do not help - we cannot debug a video.

    There have been no significant changes to the save system since the last stable release r269 so it seems unlikely this was a recent change in Construct. There are several other reasons saves could fail, including driver bugs, hardware failure, software conflicts and so on - it may be one of those reasons instead.

  • Yes, but normally that would do nothing, since usually you'd have to actually make some calls to the plugin for it to do anything.

  • I think the best approach is to use the addon SDK to write a plugin that uses the Cordova plugin. You can also set the Construct addon to automatically add the Cordova plugin as a dependency.

  • All I need is to CLEAR it or REMOVE or UNLOAD from that specific frame and not just the option to replace with another, it is very important in my project that it can get back to empty frame

    This doesn't make sense. You first say that you don't want to replace it, but then you say you want to go back to an empty frame, which means replacing it with a transparent image.

    I think you are confusing "unloading" with "replacing with a smaller image to save memory". They're not exactly the same thing. The System object can unload object images. If instead you want to replace a sprite frame with a different image, another way of doing that without having to use obscure data URL strings, is just to create a small Drawing Canvas object, clear it, and save the image. Then you can load the SavedImageURL in to the Sprite object. This also has the benefit that you could draw any content at all in the Drawing Canvas object (e.g. clearing to a fixed color, adding a border, etc).

    So I think there are already a few good options to do exactly what you want. In general it's better to ask "what other options are there?" before "can a new feature be added to do this?"

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I'm not convinced it was a good idea to include in C3, really, since it doesn't really fix the problem and means you get inconsistent results across devices... but if you really want to... it just compares window.innerWidth/window.innerHeight to the size it really wanted, and calls window.resizeBy() with the difference to compensate. But resizeBy() doesn't correctly take in to account devicePixelRatio, so sometimes you still end up with the wrong size.

  • There already is a built-in way to unload an image, which I just described. I don't see why you can't just use that. If you want to revert to some default image, just destroy the sprite, unload it, then put some stock image in its place with a different sprite object. If it's already easily doable, why does there need to be any new feature to cover it? As a small team with limited resources, thousands of bug reports and hundreds of other feature requests, suggestions would have to need a really good reason to motivate them, and I don't see why the existing feature doesn't cover what you want here. Don't jump straight to a feature request before properly considering the alternatives... or if the engine actually fully supports that already!

  • Why? Does this affect a separate web page that you maintain yourself or something? The hack is ugly and doesn't actually completely solve the problem anyway, so it's not something I'd recommend anyone using - just live with the quirk if you can.

  • Please note that simply copying and pasting a crash report is rarely sufficient for us to be able to fix the problem. See the bug report guidelines for information on how to report problems so we can actually help with them.

  • I still don't know how to unload the image, I didn't found any unload option while exploring it,

    Can anyone please show me how to do that via screenshot so I can follow ?

    Normally unloading a single object has negligible impact on memory use. Do you have measurements showing this is necessary? If not, it's probably a waste of time worrying about minor cases like this.

    If you find that the memory difference really does matter, the built-in way to unload images is to destroy all instances of the object, then use the Unload object images system action.

  • Loading an image in to a Sprite unloads and replaces the existing image. There's nothing you need to do to manage memory if you keep loading in different images, the old ones are already being released.