Ashley's Forum Posts

  • Construct 3 uses a different spritesheeting algorithm that is better at combining multiple objects on to the same spritesheet. However if you do things like create lots of objects dynamically at runtime without them being placed on the layout, this can cause higher memory usage as Construct doesn't know ahead of time how to group objects on spritesheets according to when they're used together. See memory usage in the manual for more information on best practices.

    If that doesn't help solve it, you can try reducing the spritesheet size in project properties. It can help increase the granularity of image loading, which can bring down the overall memory use.

  • That should definitely not use jQuery then.

  • Well, "made in C3" doesn't necessarily mean much, since C3 supports both the C2 runtime (which uses jQuery) and the C3 runtime (which does not).

    If you are using the C3 runtime it's also possible a third-party addon included jQuery. There's not much need for it these days so in that case you could ask the addon developer to remove it.

  • My question is, how powerful is Construct 3's visual scripting really? It claims that it can make just about any 2D game you can think of, but due to the nature of visual scripting I'm a little skeptical.

    Really powerful. Commercial games have been published to Steam using nothing other than the block system. Take a look at the showcase too.

  • Assume you have a sprite that want to load random image from a selection of 500 images. How can you achieve that without the need to load all images into memory?

    Use 500 separate sprite objects and put them in a family. Then it only loads the ones placed on the layout, or that you create at runtime.

  • I guess just ignore the message for the time being. The fact a library has a known security issue does not mean you definitely have a security issue. In particular Construct only uses jQuery for a few random utilities so I'd guess it's not particularly relevant. Also this is the C3 section, if you think it should be fixed in C2 then you could file an issue for it there.

  • IIRC only the C2 runtime uses jQuery. So if you switch to the C3 runtime it should remove the warning.

  • It sounds like in both cases you actually want to use the viewport, and not the window or screen size.

    The viewport is the visible area of the layout, so if you want to place things to fill the view or relative to the view, you need to position them relative to the viewport.

    The viewport sometimes happens to match up with the window or screen size, so sometimes using the wrong values will work by accident. However as soon as you scroll, scale or rotate the view, or use certain fullscreen modes, it won't line up any more and will appear broken.

    The viewport system expressions can return the viewport size. I just realised the scripting APIs don't cover the viewport yet, so I'll add something for that.

  • "Wait for previous actions to complete" when there are no asynchronous actions works the same as "Wait 0 seconds", which waits until the end of the event sheet before resuming the rest of the actions. Since that happens to also be after the next top-level event, it also happens to ensure that all created objects are fully created. So it does actually work after "create object", and the description of the action fits better than "Wait 0 seconds".

  • Which PlatformInfo sizes exactly? And are you sure you're not actually after the viewport size? If you're looking for where to position objects in a layout, you need to do that relative to the viewport, not the screen, otherwise in some cases it will look wrong. This is why it's important to explain clearly what your goal is, rather than what the exact answer to a specific question is.

  • Construct has been around for years and by now I'm pretty confident in saying it's a robust, well-tested engine that has very few obvious bugs, and that applies particularly to the event system, since it's all code we control (vs. something like platform-specific code where issues come up due to changes in the underlying platform). Of course there are still bugs - all software has bugs - but usually they're pretty specific, or involve unusual edge cases.

    Having dealt with thousands of bug reports and forum posts over many years, generally I have to say it's very common that people jump to blaming Construct before properly establishing whether their events are set up properly. As part of this, the bug report guidelines are carefully crafted to ensure we don't get inundated in bug reports that are really just mistakes in people's projects (and yet, it's still common). If you can't reproduce the problem in a new empty project, it's a strong sign that you have gotten your events wrong somehow. Making complex event sheets is a form of programming, and programming is a difficult endeavour that is really hard to get right. This is why it's important to learn to structure your events well, and learn good diagnostic/debugging techniques, such as logging, using the debugger, and so on.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Why would you want to? This will waste lots of memory, versus just showing the original object.

  • Worker mode isn't supported on Safari so will just be ignored. Most of the settings mentioned would similarly have no effect and the console messages mentioned are of no significant consequence. It's hard to help without knowing precisely what the problem is.

  • (Moved to scripting forum) In scripting, maybe you just want the browser's window.innerWidth / window.innerHeight? It's not clear what you're trying to do though, because you shouldn't need to do anything like that to make a layout fill the screen.

  • Check for errors in the browser console. It's probably returning 404 not found for some files because you forgot to upload them (or the server is misconfigured).