I can't notice any difference at all for the low-latency canvas. I've created this JSFiddle for testing based on the demo provided by the Chromium developers.
How to use:
1. Run and draw on the bottom-right canvas
2. Change "desynchronized:..." to "false" (line 4)
3. Run and draw again
Thanks a lot!
I've got a question regarding async actions.
What happens if an async action fails? Will the event enter an infinite loop and retry over and over again or will it stop automatically after an X amount of retries?
An example could be setting up a saving system for your game and save to localstorage but it fails (e.g. no disk space error).
Amazing! I always wanted to be able to comment in actions. That's another 3rd party plugin that I no longer have to use.
Thanks for the preview feature. Should make multiplayer game testing easier.
C3 runtime: now uses a new storage library - should not change anything but be on the lookout for anything broken
Is it using the upcoming KV Storage system?
Cool! Thanks for giving NWjs some new features.
You mentioned it's a GPU driver issue. I assume it's up to the creators of those buggy GPU drivers to fix the issues and it's not possible to work around the issues, without falling back to WebGL1.
Sounds like an issue that can't be worked around at all. I guess this approach is fine in this case, since you guys seem to do these changes based on community feedback.
I'm personally always more about making things optional, regardless of the potential risks of unsuspecting users.
The screen recorder feature is great! Going to try it out and see how it performs.
WebGL 2 had been disabled on Android due to reports of what appeared to be GPU driver bugs. We're experimentally re-enabling it to see if the issues have been resolved.
Wouldn't it be better to implement a runtime property to switch between WebGL1 and WebGL2 instead?
In my opinion it's almost always better to let the developers test and decide to use potentially "buggy" features instead of forcing it upon them.
It wouldn't be the first time having such a feature either, Construct 2 still offers not using WebGL as an example.
Really liked the "Procedural terrain generation" example. Good performance with smooth chunk generation. There are some minor errors with grass chunks sometimes, could easily fix it with a manual check in the generation events.
Is there a limit for dictionary keys or is disk space (chunk save-file size) the only "true" limitation?
I've used all the included performance tests and some of my own. Using a mid-range PC, there is no noticeable difference in performance.
Since I'm mainly developing for desktops, I'd consider this feature to be a nice-to-have in the future. I'm not sure how low-end mobile systems would perform but I guess the performance gains would be minimal at best.
Thanks for the responses!
Alright, makes sense. Although I see implementing such a system in a modular way, as a benefit for future suggestions (e.g. layout-to-layout loading customization).
I'm not sure how that benchmark would look like. I'd have to measure the rendering performance somehow, do any of the existing performance examples cover this? I don't want to provide something, that's going to be dismissed because it measures things unrelated to this feature.
I think the 2nd option I mentioned could be applied to both and you'd just need to check if WebGL is supported at all. Even if WebGl2 doesn't technically require it, it could be used there too, keeping the code base the same.
I'm not familiar with the differences between WebGL 1 and 2, so this is pretty much just speculation on my part.
For me personally it's a nice-to-have but I don't know how important it would be for others. I assume mobile dev's could make something out of this feature?
Let the action check if the device is running WebGL 2. If not, don't do any changes to the sampling mode and return an error message in the browser console?
Another option could be applying the setting on a layout change and forcing a complete reload I guess?
I'm not sure if that's something you'd like to implement though.
Amazing update!
Would be nice if we could modify the sampling mode using a system action in the future as well.
This would make it possible to include ingame settings for "graphics quality" as an example of use.
Member since 30 Sep, 2014
Tips & tricks for desktop game development and distribution with Construct.