bjadams that may be true, if you want an export for windows

without as much overhead/functionalities or good performance you are alway free to try to use alternatives like this one:

https://code.google.com/p/phpdesktop/

I wouldn't say it's a curse, of course, the SDL for example is really minimal in it's size compared to NW,

but the more functionalities/freedom with the easiest difficulty you want, you have to pay the price in it' size.

Not everything can be perfect, but in general, it's still a long way to go for HTML5,

you can expect some awesome things i think in the coming years looking at the speed of development of new things for it now and then.

Especially considerating the big companies are beginning to use it more and more.

• Conti

If you exported with Node-Webkit that is easy to explain:

Node-Webkit is basically the whole Webkit engine + Node.JS in modified form.

Therefor, it also almost has the same size as Webkit + Node.JS.

So short explanation: it isn't your app/game that is 40mb, but it is the .EXE from node-webkit (+DLL's) that are/is that big.

If you talk about another export option im sorry.

• Conti

Now that i think about it, the Steam SDK is written in C++, and that is the problem.

What if, we use Emscripten to port the SDK to JS so we from there on could make a plugin.

Wouldn't that work? Or do i missed something out?

• Conti

No, it does not sync the size of objects.

Since the host handles the collisions and positions of objects, it also handles the collision polygon size,

so it may seem like the collision polygon is synced, but it is not

You have to set the object size on both sites, yes.

• Conti

Exactly, while the rendering is done by the GPU and it only renders what is on screen, even if there is a object partial on screen it only renders what is visible.

But still the CPU continues to execute it's calculations.

Everything else would be near Madness

To answer your question: Ashley said that

• Conti

Bl4ckSh33p thanks

Ashley it did, especially in my game i worked on, it tended to happen alot when i tested the multiplayer in chrome.

But since i now updated my chrome to 36, the issue seems to be gone.

So as it stands it's probably a bug introduced in 34 and resolved in 36.

Weird, im sorry if im responsible for any confusions

So it 'happened' in chrome, but since i hadn't checked since 35, i may have missed that it has been resolved.

I think you can close this. I hope they rebase NW soon to 36

• Conti

Ashley , since this problem also persists in Chrome itself, i dont think it would be good to rely on only Roger/GnorTech to fix it,

since the problem then still would exist in Chrome, but may be gone in Node-Webkit.

So if already the problem doesn't is a problem of C2 itself, then i should follow it tracks back to Chromium and file a bug report to the Chromium development team itself.

Right?

Problem Description

I know NW 10 is only an RC yet, but still, it seems the text object in general needs an overhaul.

Since not only this problem, seems to be one (Performance problem on mobiles).

But now to the problem, the problem persists since Chromium 35+ that means Node-Webkit 10 (RC1) too.

When the text in the text object changes, it either disappears/get invisible or get's "Blocky"

Example further down.

Note: The problem only exists when using WebGL renderer

As — already noted, the problems only exists when using WebGL.

When using Canvas2D the problems are non-existent.

[quote:tzh4ao5i]it seems the problem only occurs with webgl, not with canvas2d

Description of Capx

Launch it with either chrome or the most recent NW (10 RC1) with WebGL renderer, see the text being "Blocky" or maybe disappearing.

Launch it then with Canvas2D and see that there is no problem whatsoever.

A random btw note: The freezing problem in Node-Webkit can be resolved by adding the chromium argument: "--disable-threaded-compositing" as fluffrabbit noted.

So yes, it really fixes it. Already added it to my json file in the exporter folder in C2 Please make that change for r174 (If not Roger fixes this in general).

Steps to Reproduce Bug and use the Capx

• Launch it with either Chrome 35+ or NW 10 Using WebGL
• Watch the text being buggy.

Observed Result

This happens:

Or it get's invisible, sadly i couldn't reproduce that.

Expected Result

It should appear like this:

Affected Browsers

• Chrome: (YES)
• FireFox: (NO)
• Internet Explorer: (NO IDEA)

Operating System and Service Pack

Windows 8.1 64bit

Construct 2 Version ID

R173

1. You download an Updated version of Node-Webkit. (Win32)

2. You extract the files from the ZIP.

3. Then you copy the 6 files (You don't need Credits.html) into this location: %WhereC2IsInstalled%/Construct2/exporters/html5/node-webkit/win32/

Could be that i got the Construct 2 installation folder name wrong, since i have the Steam version it's a bit different (Not from /exporters)

4. You may notice there is 1 file that did not get overwritten, that is icudtl.dll

Since Node-Webkit has a change in it's file structure and the file now is named icudtl instead of icudtl.dll

you have to copy the file icudtl from the downloaded Node-Webkit folder, to your export location.

You have to do this since i believe C2 does not copy this file too to the export location, since as i suppose it is hardcoded which files it copies.

5. Now you can export your project, copy the icudtl file and then enjoy NW10 (Currently RC1), together with Chromium 35.

//Note: There are some weird Text issues, where the text get's invisible/unreadable when changed, maybe Ashley could take a look at it ahead of time?

//And yes im confident that this needs to be fixed within C2 itself, since i already met these issues in Chrome itself (34+)

//But of course, as always, i could be wrong

I hope this helps and is described clearly

• Conti

joelbelo , are you testing it with Node-Webkit?

If yes, it is not working yet, since NW doesn't work with the Multiplayer plugin as of yet.

Anyway, a bit more information would be appreciated

• Conti

Totally agree on this one, but i took it more of a "It's a feature, not a bug" approach.

But while we are at it, a few additions to the Button object could be great:

Condition - If disabled

Condition - If hovered

Condition - On Right Clicked

Expression - Button State (Disabled, Enabled, Hovered)

These additions might could come in handy, at least for me

Especially the On Right Clicked and If Disabled is important for me.

• Conti