Ashley's Forum Posts

  • The problem (if I understood correctly) is illustrated by this image: Painter's problem

    This is from the Wikipedia article on the Painter's algorithm, which is the type of algorithm Construct uses for rendering.

    One solution in this case could be to cut the green rectangle in half (making it two objects), so the right part can be layered under the red rectangle, an the left part layered over the blue rectangle.

  • loadScripts is an async function. You need to await it, otherwise you'll try to use the things it's declared before it's loaded.

  • Take a look at Bullet stepping.

  • Please note we will soon be moving the file system implementation in NW.js to be the same as the one used in Chrome. In theory this is just an internal change and nobody will notice. However NW.js will show the same file permission prompts as Chrome, unless you use NW.js 0.45.2 or newer, which has been updated to automatically approve them. So I'd advise any users of the NW.js desktop app update to 0.45.2+ so you don't get these prompts.

  • It's not really clear what you're doing. Normally when you save a project to Cloud Save, it saves your entire project with all resources like images and sounds included in the project file. So you should never have the problem you are describing - all the images and sounds are saved in your project file on Google Drive.

    Are you saving as a folder project or something? Even that should work, assuming you save to a synced local folder (like Dropbox's local folder which is automatically uploaded).

  • This is not possible to achieve with Construct's 2D renderer. Everything is drawn one after the other on top of the previous content. This kind of result can only be achieved with a 3D renderer (using a depth buffer to determine overlap per-pixel). In 2D you'll have to work around it, maybe by cutting up objects in to different segments.

  • Physics defaults to framerate dependent, because around the time it was first introduced (and this is going back years), people had issues with making deterministic physics. The problem with framerate independent physics is because the time step has small random variations due to timer imprecision, it can result in random variations in physics simulations. This resulted in bug reports like "my tower of physics objects falls down a different way every time". People wanted their physics simulations to be predictable, which is what you get when using a fixed time step, so I (with some unease, knowing the downsides of fixed time steps) changed it to default to fixed. The downside of a fixed time step is, predictably, that it's framerate dependent, so now the physics simulation speed depends on the display refresh rate.

    Now that different display rates are more common, the default Physics setting probably needs to be changed back to framerate independent. But now we have the problem of figuring out a way to do that without breaking all existing projects which use the default and rely on deterministic physics.

  • This sounds like a bug we already fixed. Try the latest beta.

  • This is another case of the "newly created instances are not fully available until the next top-level event" quirk.

    If you create an object, you can use it in the same event and sub-events, but not in sibling events, until the next top-level event. Since those events are all in a group, the newly created object is not available in subsequent events, until the end of the group (which is the "next top-level event" point).

    The reason for this is to make the event engine fast, it assumes the internal data structures do not change while running events. Creating an instance changes the internal data structures, but this change is delayed until the next top-level event when it is safe to update the internal data structures, because it's not half-way through running events. We could remove the limitation by slowing down the entire event engine for everyone (i.e. adding regular checks for "did the internal data structures change" through the entire event engine). But that makes all Construct games slower just to solve this quirk, so it doesn't seem a reasonable thing to do. And if we break the assumption that internal data structures do not change, it ends up with crash bugs - and user reports of exactly those crashes is what led to the current "wait until next top-level event" workaround. So the quirk lives on.

  • Pinning width and height was already added in one of the recent betas.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Sorry, my code was wrong, you have to assign the whole saveData object yourself like this: 

    function OnSave(e)
{
	// Save myVariable by adding it to saveData
	e.saveData = {
		"myVariable": myVariable
	};
}

  • It's entirely up to third-party developers where they publish their addons. Ask the developer if you think they should publish it to the Addon Exchange - that's what we designed to be the one place to find addons.

  • Mirror is negative width and flip is negative height. So you should already inherit mirror/flip if you pin the width/height.

  • It should always copy in that case. If it doesn't, please file a bug. I did just check it on Safari and it seemed to be working fine.

  • Your screenshots also show you still using the older and much slower Construct 2 runtime. Switching to the C3 runtime could help a lot. It sounds like the game might be bottlenecked on the GPU hardware bandwidth though, which is typically the result of using too many images and effects.