Thanks!

At least one of my players is getting the error now, even though it doesn't do it for me anymore, do you know if I have to get them to delete the NWjs folder as well? I wonder if I have to rename the game so it has a different folder name, and doesn't use save files from the newer NWJS (.../appdata/local/gamename).

It'll still write to the nwjs folder I think, so yes, they'd have to delete/rename the directory as well. Honestly, because of the improvements that have been made in more recent versions of NW, you're better off picking up Steam4C2 instead of trying to use the buggy Greenworks plugin from Scirra. Steam4C2 has a lot more features, and is actually supported by its developer.

Thank you very much digitalsoapbox, can you message me your paypal address?

I appreciate the offer, but no need .

I installed the latest NWjs but then installed the older NW.js: 0.19.4 so that I could use Greenworks plugin. When I open the game this error pops up then the game runs, with this error message present in the background. What does it mean?

The issue is the latest nwjs install left behind some files when you installed/copied the older version over it:

https://github.com/nwjs/nw.js/issues/5761

To fix the issue, trying deleting or renaming the nwjs folder in Users/username/AppData/Local and see if that helps. If you just copied the older version over the newer version, try uninstalling both and reinstalling only 19.4.

Edge is a great browser engine and is really high performance now. It's comparable to Chrome in the latest releases.

If XB1 is slow because of deliberate limitations by Microsoft - e.g. capping CPU usage - then there's nothing much we can do about that. It's not Construct's fault, and no other framework can get around that either, it's the XB1 OS that is capping apps that run on it. In that sense UWP apps will run exactly as well as Microsoft let them. This isn't anything to do with the performance of C2 or HTML5. It's the same thing if an app can only use 128mb RAM (which IIRC I've not seen any official reference for, would appreciate a link on that) - no other framework or technology is going to let you get around that, it's an XB1 issue, not a Construct issue. So the best people to go to about this would be Microsoft. FWIW you should already be able to detect backgrounded games (Browser plugin 'On suspended', 'On resumed', same as all other platforms), and you can try using the savegame system to do full state saves and restores to work around that too.

System resource details direct from Microsoft below. This info has been around for quite some time, though I believe the increase in overall memory usage when not running in the background happened around the end of last year if I remember correctly (from 500MB to 1GB):

https://docs.microsoft.com/en-us/window ... allocation

As for knowing when the game is running in the BG: Yeah, the browser plugin works on XB1, but we still have no way to release the memory and reload needed assets when the game returns to the FG.

> Just LAUNCHING Sombrero takes about 300MB, and that's with loading most of the assets manually after start and nothing on the layout - just playing a video takes 300MB.

>

I could have sworn you had a video of Sombrero running on Xbox One and it was actually running quite smoothly....or was i mistaken and it was actually running on the PC?

Not really, no. I use XB1 or XB360 usually when showing the game at places like PAX or GDC, but running on actual XB1 hardware is a different story. You really, really don't want to know what the performance is like right now.

Yea. Technically it is still beta so "features may be missing" and Im sure ive seen Ashley say somewhere the live plug in is pretty much done so I think it is coming together.

To be honest I was surprised the UWP performance wasn't better but it wasn't atrocious I'm sure there are a lot of construct games that could work with it. I would very interested to see the performance boost enabled by signing up for the ID program. And This 128mb issue something that could probably be easily sorted. I'm so far away from anything like releasing on Xbox that I'm not to bothered though it is just interesting to tinker. (Wow I'm feeling positive today must be good coffee !) It sure would be nice to see Sombrero on live though. digitalsoapbox you'll have to be the trailblazer on this one... Trailblazer , now that's a blast from the past... I was pro skills at that back in the day....

There are currently no trails to blaze. It just isn't possible at this time. The 128MB issue - a requirement to deploy on the platform - is bigger than you think. That's really just a few sound files and sprites stored uncompressed in memory. Just LAUNCHING Sombrero takes about 300MB, and that's with loading most of the assets manually after start and nothing on the layout - just playing a video takes 300MB. If we had a way to reliably flush memory it may be less of an issue on startup, but memory issues aside that's still not taking into features that are required for XB1 games.

If Scirra hasn't addressed that in the their code, then that would be a bug that needs to be reported.

Complaining, and making accusations of false advertising doesn't do anything.

If they're saying the plugin is ready, that doesn't seem to be the case. If they're saying games can be deployed commercially, that's untrue. Missing features is not a "bug" - it's missing features. This is not a complicated statement.

thanks for the insight digitalsoapbox

i dont get the 128 mb you are talking about,

MS says that UWP has access to 1 gig when real world deployed in forground mode (450MB when in dev mode)

Are you saying that we cant use more than 128 MB because construct games have to be able to handle a background mode and they cant?

cant the games just quit if not running in foreground?

[quote:12zl9hhc]The maximum memory available to an app running in the foreground is 1 GB.

The maximum memory available to an app running in the background is 128 MB.

Share of 2-4 CPU cores depending on the number of apps and games running on the system.

Share of 45% of the GPU depending on the number of apps and games running on the system.

https://docs.microsoft.com/en-us/windows/uwp/xbox-apps/system-resource-allocation

what I dont get is that with access to even these restricted specs and running through edge in UWP then most construct 2 / 3 games should kill it...

but it seems they dont....... hmmmmm....

Scirra

Ashley

dont you think it would be prudent to remove the "export to xbox one" claim in Construct 3 advertising until plugins and everything else is in place and xbox UWP performance is validated and any limitations can be stated in a caveat against an export to xbox claim?

The 128MB limit on apps running in the background is a big issue and, really, the biggest game stopper with the stated limitations (performance is another issue and is Construct-specific, not platform or technology-specific), based on Construct's available functionality. Saying Construct 2 OR Construct 3 can export a functional, commercially-viable game to XB1 that would be allowed on the platform by Microsoft isn't true (again, at this time). Performance issues and current UWP limitations aside, neither support the feature set required to launch a game on XB1. I hadn't even realized that claim was being made about C3 but if it is, it's false advertising. It's simply not possible at this time.

I could be wrong....but if i recall correctly, digitalsoapbox who is the developer of Sombero, actually has some experience of getting it to run on the Xbox One's UWP platform also.

Sombrero* but close enough .

C2 games with any level of complexity don't run very well on XB1, period. This includes with the limits placed on Dev mode not being in place, which you need to be accepted into IDzvb@XBox to get access to, and the limits are still somewhat lower than what's available to non-UWP tech, though even those limitations don't really explain the performance issues.

Why this is the case isn't especially relevant (so any apologists can save their typing fingers), but until things are a bit tighter engine-side - in addition to the features required by XBox games still needing to be added to Construct - so I wouldn't get your hopes up just yet, considering C2's performance track record on consoles or lack thereof. Interestingly, Unity UWP deployments, while they can also have performance issues, tend to be more related to export options than what their HTML5 tech is capable of, and it's just a matter of editing the right files after export to get the kind of performance you'd expect, considering the hardware in the console.

There is also the extreme memory limitations of a game running in the background when using Construct w/ UWP, which is very low, and considering Construct has no direct way to clear memory to get under the limit (around 128MB*), you'd be pretty limited on what you can do anyway. As in, less than you could do in a typical mobile game (where C2 performance can also be...questionable). While the memory limit is obviously not just an issue with C2, providing ways to sneak in under it certainly is.

This could obviously all change in the future, but I can't say I recommend waiting for something that *might* happen when there are tools available that can make it happen now.

*EDIT: The 128MB limit refers to what's available when a UWP app is running in the background

Considering that C3 uses the same runtime as C2, there's little to no benefit in porting to C3 at this time.

>

>

> This about sums up my experience. But if you say it out loud, and they're using your game as a showcase piece for C3, expect them to pull it.

> ¯\_(?)_/¯

>

Is that surprising?

Why would they support you if you keep voicing negative opinions?

Is there some process in your mind where saying things like that magically makes things better?

You don't like something, then don't use it.

Seems like the same logic they used.

Right?