Problem Description

The system expression "renderer" doesn't return "webgl2" even when it's supported by the browser.

(This is a minor inconvenience and can be included in the next C2 release.)

Attach a Capx

Download the example

Description of Capx

Fetches the renderer at the start of the layout and displays it using the text object.

Steps to Reproduce Bug

• Run example inside a browser with WebGL2 support (e.g. NW.js v0.20.0)
• Notice that it returns "webgl" instead of "webgl2"
• Be concerned about your browser and question if it actually supports webgl2

Observed Result

Returns "webgl" instead of the expected "webgl2"

Expected Result

It should return "webgl2" if the browser supports it.

Affected Browsers

• All browsers with webgl2 support

Operating System and Service Pack

Windows 7 everything up to date.

Construct 2 Version ID

r242

Can confirm, this is a visual glitch since the early days of C2. I honestly never really bothered to report it.

It does only seem to happen with certain types of themes. (Dialog reset doesn't fix it for me.)

TheRealDannyyy Any idea what could be causing youtube videos not to play via NW.JS anymore?

Thanks for the heads up, waiting for a response now.

This will either be included in future NW.js installer releases or I will add a simple tutorial to the roundup.

EDIT: Burvey and all the others with codec problems, please take a look at THIS topic.

Sorry but I don't think that I will add this to the roundup, I might reconsider it if a lot of people demand it.

The builtin ffmpeg only contains royalty free codecs. See http://docs.nwjs.io/en/latest/For%20Dev ... %20Codecs/ for the list of supported codecs in builtin ffmpeg. We couldn't ship ffmpeg with proprietary codecs due to legal issues. So you have to get ffmpeg libraries from community or build yourself if you are eligible to use them in your app.

This is a known issue, feel free to take a look HERE.

To make things short, you will have to manually DOWNLOAD the ffmpeg.dll file by the community and replace it with the existing file inside your gamefolder.

(Download the correct version of the ffmpeg.dll!)

Depending on Ashley's response to the following question, I will make my decision to either include this in the roundup as a "workaround" or not.

Ashley I know it's a tricky thing with the legal issues and all that but would you consider replacing the ffmpeg.dll by the community in future NW.js installer releases?

Last I wrote that it was true (quite a while ago now), but if you can rename the .exe and everything still works... I guess they fixed it!

Sounds good, the more personalized our games get the better.

I guess before spreading false information all around here, I'll head over to their git and ask them about this.

Thanks again for the quick response!

[quote:2gcxd6eu]on Windows the engine's executable file must have the name nw.exe for addons to work

source nw.js-wiki

Needed for modules containing C/C++ addons because they use parts of the engine to sustain their execution. (greenworks/setam4c2/robotjs....)

quote]

I've noticed that Ashley mentions in the greenwork plugin post that the game's exe must be named nw.exe for it to work, I also notice you didn't write anything about it, my game and steam overlay seems to work fine for me with a different exe name, but I'm not sure what was the original problem that required this action, can you shade some light on the subject?

---

I see, but it also says at the top that some of these issues only apply to version 0.12 and lower, we're on version 0.19.4 already, so that might not be an issue anymore. My point is that my game runs, steam overlay is accessible, achievements are being registered and pop is shown, so unless I'm missing something, I don't see any problem.

I think that Lof is onto something here, could it really be that more recent versions don't have this requirement anymore?

So far I've always been assuming the same because of the given information from the (outdated?) documentation about the use of addons.

Either MadSpy and/or Ashley, I would like to request a statement about this.

Is it still required to use "nw.exe" as the application name or are you guys perhaps "outdated" about the latest requirements of NW.js + Addons?

References:

New Docs | Old Docs | Native Modules

The users who want a native export are getting more restless.

quote]

I'm much more interested in some of the hinted-at workflow/organization improvements than native export, even if it were a possibility.

I have a feeling the natives will be throwing spears at me pretty soon for that one.

TRIGGERED *throws spear*

In all seriousness though, native tech isn't the best of the best either and people that worked with DX9 can relate.

I will personally always go with arguments for native over web and continue to criticize the other side for known

reasons because I got used to the flaws that come with the used tech. I guess it's the same case with Ashley and the web.

For me currently the most annoying thing is the fact that we have next to no control over un/loading certain things

but judging by the latest changes, it seems to be possible to workaround those limitations.

With that said I hope that C3 won't just end up being C2 with a different number in the name

meme

and bring the required changes that will make "advanced" game development less of a pain than it currently is.

Great.

...overlay will flicker when it appears (shift+tab).

The flicker is because the redrawing interval is set to every 3rd frame (50ms) and on your screen it must be noticeable. Madspy will most-likely set it to every frame so it won't be noticeable anymore.

For the temporally workaround you could try to reduce the time to 2 seconds, we just used 5 seconds to make sure that even the "potatoest" of PCs will get a redraw call in.

So now we know that it just requires a community made plugin in order to get Ashley to add highly requested features.

Just kidding, thanks a lot Ashley!

(Closing this one for now, please update to r242+ in order to get the "more official" unloading features!)

TheRealDannyyy Yes! This helped me.

...

Now it looks good.

Thank you both TheRealDannyyy and BackendFreak!

Cool, good to know that it works as expected.

If you are a Steam4C2 user (judging by the screenshot you are), you'll just have to do this temporally until Madspy is back on track and updates the plugin with that workaround.

... I know we have HTML form inputs now, but they are not very skinnable or flexible, and certainly don't look native on any platform..

I think to be useful, at minimum something like: ...

I won't say that, I think CSS styling is a great thing and gives you tons of options to make your forms look less like well, forms.

Sure C2's one action per CSS styling isn't great and the language itself might require some research but I think it's better compared to the native alternative, which is using "sprite-forms" for the most part. (We also still have the option to use the great 3rd party CSS import plugin. )

Maybe, just maybe C3 could provide us with an easier way to customize forms.

In the old days of C2 there was actually something like that planned. I think it was going to use the sprite-form method as mentioned before but see for yourself.

I guess Ashley decided to drop that feature for the better alternative, which is in my (and probably his) opinion, the use of CSS.

tecbug I didn't hear anything from you yet, is it working fine on your end?

Some feedback about it would be nice!