As far as I know Fusion doesn't export as a single .exe file either. Am I wrong?

I hope that this gets stabilized by the next stable release of construct2!

The 20-25% faster performance is a huge huge improvement!

do you guys think that construct2 should ship with nw.js as part of the installer? I dont understand why it is separate at the moment

Because Construct 2 updates much more often than NW it would be redundant to have to download the same version of NW with every new C2 update.

This issue has been gone over extensively, and in short Ashley has said that adding native exporting would be a whole lot of work for much less benefit than people tend to assume. It wouldn't necessarily fix the performance problems you're talking about.

I think the more pixelized style of example 2, though not the same as true pixel art, still works better for your art style. It adds a coherence and consistency that the first image lacks. The effect in the third image does too, to some extent, but in an off-putting way IMO.

Have the event that starts the music track first check if that track is already playing.

Fisholith made an example here:

Thanks to you and them, then.

You just have to calculate the size of the border and subtract it. Set 2 global vars to the native resolution, then subtract that from the retrieved window size.

Could you reword or dumb this down for me please? Or make a project file of it, if that's not too much to ask.

Why even call it C3... Stupid move, if its just an editor remake. I don't get it

That's not so different from how a lot of software works. It would make less sense to make such a time-consuming project into just another iteration, like Construct 2 v230.

As per the following blog post it will mainly be a remake of the editor itself, not of the engine. So the engine will not be radically different, and will still be using HTML5 (not Flash or native Windows exporting).

https://www.scirra.com/blog/155/the-future-of-construct

Someone responded to Chromium's Issue 422000. Their response:

Assigning to self since Brandon already did his part on this bug.

+simonhong since the "unified BeginFrame for Aura" patch (https://codereview.chromium.org/1016033006) definitely added noise to the graph.

Depending on how bad the jitter is, maybe we should have the unified BeginFrame work land behind a flag while we work on making it more responsive and integrating it with the rest of the system.

After the patch above, the rAF start can be blocked by work on the Browser's UI thread which is where the jitter is coming from. This isn't necessarily bad though since going through the Browser's UI thread also allows us to avoid races with user input, which can actually improve perceived smoothness; but we haven't yet integrated with jdduke's work to get that benefit.

Unified BeginFrame should also become more responsive as we move work off the Browser's UI thread with efforts like impl-side-painting in the Browser. We should probably see if there's anything else monopolizing the UI thread and what we can do about it (blink scheduler on the UI thread?).

To follow up what I was talking about before. I finally figured out why our game was breaking on NW.js export.

It seems that upon export, all animated sprites with overlay effect break. However, all non-animated sprites with overlay effect still work perfectly.

I tried creating a new project confirming my suspicions and I was able to re-create the bug 100%.

To clarify, animated sprites with overlay effect seem to work in preview but as soon as the project is exported to NW.js it all goes south.

When you say they work in preview are you previewing using NW.js?

> Here is my attempt at a fix, is this working how you wanted?

>

> https://copy.com/0ZeQHizXjlbc8JDG

>

Yes, that's perfect!

I see what you did, both objects has 8 direction bur only the movement one has colision.

Great stuff, thank you so much

Glad I could help <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink">