WebGL supports antialiasing, but it has a big performance overhead and isn't necessary for smooth edges, so we have it permanently disabled in C2 and C3. The reason the crop tool leaves a 1px transparent border is to get the smooth-edges appearance using linear sampling only, since it smoothly blends with an extra pixel of transparency at the edges, rather than having a hard edge. This is much more efficient than running a full antialiasing engine and looks pretty much the same. So enabling antialiasing will only cause a major slow down with no real visual quality improvement.

Every videogame developer and player is well aware about the performance overhead of antialiasing (that's why you can usually disable it in the ingame settings) but I don't think that it "looks pretty much the same" in my opinion. I mean you can test this by yourself, use a simple box sprite and rotate it. Without antialiasing it just looks terrible, even with the more efficient 1px transparent border workaround.

Is this somehow implemented into WebGL so that I can easily enable it using JS?

I'd really like to do some performance tests of my own if that's possible, just out of curiosity.

I had this question in the back of my mind for quite a while now so I hope and appreciate if someone with knowledge about the web, specifically WebGL & Canvas could give me an answer to the questions found below. (Perhaps the creator Ashley himself, if there is some free-time in between working on Construct 2 and Construct 3.)

Please note that this isn't meant to be a topic about: pro vs anti-aliasing.

bad pun, I know...

Does the web support multisampling/antialiasing?

Almost every game engine supports multisampling, including Construct Classic. So far neither Construct 2 nor Construct 3 seem to support this. Everything I could find regarding this was the "sampling" project setting, which doesn't really seem to smooth out edges at all (or at least not as effectively as you'd expect from multisampling).

If the web supports multisampling, will we see support for this anytime soon?

It would be amazing if we could toggle multisampling (MSAA) inside the project properties like you could using Construct Classic. System actions to set the sampling level ingame would also be appreciated, even if they require a restart of the application like the most native games supporting this feature do.

People that still have no clue about what "multisampling" is, here is an example of it in action:

*AA = Anti-Aliasing aka smooth object edges

1. in next update as beta

2. in next update as beta, the JS dependencies was reduced to less than 200ko (instead of the initial 15Mb)

4. Added an auto body redraw while overlay is displayed and testing the same workaround when an achievement popup is displayed (available as beta in next update)

Sorry if this is being perceived as me being impolite but I'm getting a bit impatient with these features, especially Steam Lobby. I won't ask for another release date (since that didn't work out so far and always resulted in delays) but I would like to see this getting done before 2018. Please keep me posted about further progress.

3. the plugin doesn't manage the steam overlay; it's the steam process GameOverlayUI.exe .

Btw, I have less isssue if I use the single process arg... and I still use older nw.js version (0.18.7) for my purpose

I have no clue what you're addressing here, what specific issue are you talking about? My question was if we still need to use that chromium-arg at all in more recent versions of NW.js, I remember that you wanted to check that out a couple of weeks ago.

I would always like to use the most recent version of NW.js, meaning that downgrading isn't something I'd like to put into consideration for now.

It's October and I'd like to ask for progress regarding the following things:

• When is Steam Lobby going to be released?
• When is the Profile Picture fetching going to be released?
• Does the plugin still require in-process-gpu to be enabled in the recent NW.js releases?
• Is the Letterbox-scaling fix for the Steam Overlay already implemented?

Cheers!

Possible addendum re changing the icon of the window frame (when exporting windowed mode), unless already covered somewhere that I might have missed:

In short: modify the "icon-128.png" found in the current project's /icon folder as it is used for the window icon.

Just checked it out real quick and you are correct, seems like more recent versions of NW.js use the "icon-128.png" file and apply it automatically as the application icon when starting the application. This wasn't the case in older versions so it would be great to find out when this feature got implemented into NW.js.

By the way, it's not necessary to manually edit any icon files found inside C2's directory, editing the "icon-128.png" inside your project works fine.

Just in case for people that didn't get the "current project's /icon folder" part from your post.

Here are the steps:

• Click on the Project bar
• Click on the Files folder
• Click on the Icons folder
• Double-click to edit the "icon-128.png" file

I think I will add a <!> mentioning this, thanks for the heads up!

dimitriosfl ; Danwood

Could one of you guys please provide me an example to do tests on? I'll report it to the NW.js team if their software is at fault.

Another user has reported performance issues in NW.js recently. Feel free to subscribe to my NW.js topic for further updates about this.

()

I've noticed a huge performance decrease from v0.24 (affecting 0.25 too)

Anyone noticing it? Can someone confirm?

UPDATE: basically, versions 0.23.6 and previous ones, and also 0.24.0 beta1, are NOT affected by this problem. 0.23.7 and 0.24.0 onwards are. Seems like the problem is not related to chromium, but is caused by an update (maybe to Node.js?) made around 20 july...

Could you please provide the reliable example(s) that you've used for these tests?

I'd also like to request a list of chromium-args that you've used in your tests. Anything useful you got for debugging this issue is helpful and could make things easier.

Before reporting this to the NW.js Team, we'll have to make sure that this isn't a chromium issue in general and a problem with NW.js's implementation of it, assuming that chromium is at fault at all. There is also a quite impactful issue caused by --in-process-gpu in the recent versions of NW.js. It might be worth testing out if you have better performance without that chromium-arg in use.

Thanks for the reply,

I have removed many "for each" and "every tick" events and excluded audio from save along with some other minor tweaks.

I also used --single-process.

So far it looks fine. Ive played from start to finish with no problems and also someone who had the issue did not have it now.

I hope it got fixed.

If single processing works you must be using a fairly outdated version of NWjs.

Anyway, I'd still recommended debugging your project and letting it run for a while.

I see now that the 2 processes using 90MB RAM, after i left the game open (just open a lvl and stay idle) for about 30min it went up to 600MB RAM!

So i guess that is my problem..

I will try --single-process arg but i dont think it will make any change.

Any other arg or some setting in NWjs or C2 to solve this problem?

Single processing is broken (again) in the recent releases.

This sounds more like an eventing problem to me as well and the increasing amount of memory usage is probably related to audio files being loaded into memory (if you don't load everything into memory on start). You should debug your project and closely watch for suspicious and unusual behavior.

Very old versions of NW.js had a problem like this as well, so testing this out using a more recent version might help.

You could take the case of a Dreamcast and put a Raspberry Pi inside to run C2/C3 games.

Updated the Roundup with the following changes:

• <Added> How To: Force GC To Instantly Unload Audio From Memory
• <Added> How To: Add Chromium-Args & Js-flags
• <Added> NW.js Bugreports (Github) section
• <Changed> Moved some "how to's" to Custom Features & Debugging
• <Changed> Minor design updates here and there, nothing interesting

Construct 3 is out and things seem to be a lot easier there, will update this topic as soon as I have a C3 license.

From what I've seen so far, you can't preview in NW.js (yet) and the most of the chromium args can be added during export.

That's everything, cheers!