Godot: Does UWP export works?

[AlexBSoft]

Godot version:
3.1.1

OS/device including version:
Windows 10

Issue description:

Seems UWP export does not work. It is generates damaged file, that I can't run.

And signtool can't sign file.
`C:Program Files (x86)Windows Kits10App Certification Kit>SignTool sign /fd SHA256 /a /f c:key.pfx /p x D:SystemDocuments_GODOTExportUWPgreen_pixel.appx
Done Adding Additional Store
SignTool Error: This file format cannot be signed because it is not recognized.
SignTool Error: An error occurred while attempting to sign: D:SystemDocuments_GODOTExportUWPgreen_pixel.appx

Number of errors: 1`

Steps to reproduce:
Try to export to UWP and run.

Minimal reproduction project:

[Anutrix]

Just a guess. Might be a signtool issue. Try the signtool from C:Program Files (x86)Windows Kits10bin\signtool.exe and C:Program Files (x86)Microsoft SDKsClickOnceSignToolsigntool.exe .

[AlexBSoft]

Just a guess. Might be a signtool issue. Try the signtool from C:Program Files (x86)Windows Kits10binsigntool.exe and C:Program Files (x86)Microsoft SDKsClickOnceSignToolsigntool.exe .

It is not a signtool problem. .appx file seems to be damaged, I can't open it with a double click:

An error occurred while parsing the application package.

Screenshot in Russian

[ZodmanPerth]

I am also unable to run a UWP Exported appx. I tried removing all versions of my custom certificate then recreating it using the SDK of my current version of Windows (10.0.18362.0).

I get the same error with the signtool:

"C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\SignTool" sign /fd SHA256 /a /f godotCapabilitiesTest.pfx /p "###actual content removed###" godotCapabilitiesTest.appx
Done Adding Additional Store
SignTool Error: This file format cannot be signed because it is not recognized.
SignTool Error: An error occurred while attempting to sign: godotCapabilitiesTest.appx

Number of errors: 1

It does appear that the appx generated by is invalid:

[pixelriot]

Unfortunately I can confirm the bug. Tried with several versions of the signtool.

[pixelriot]

It seems to be a bug in the way Godot packages the UWP-file. I was able to get it signed after unpacking the appx-file and then repacking it:

.\makeappx.exe pack /d C:\path\to\folder\ /p C:\path\to\folder\mygame.appx

The following appx can be installed without a problem. However the game crashes instantly upon start, so there still seem to be generall problems with the UWP exporter.

[GeorgeS2019]

@AlexBSoft this issue will be addressed in version 4.0 milestone

[ZodmanPerth]

Fantastic news. Thanks @GeorgeS2019 .
I'll be keeping an eye out for it to do confirmation testing.

[GeorgeS2019]

can someone assign this to milestone 4.0 just like this and this?

[GeorgeS2019]

There may be need to update godot doc related to this issue in 4.0

[NVriezen]

I am closely following UWP for Godot. I had the same issue exporting to UWP. But looking into several issues and reports, I am starting to think that all versions of Godot can not export to UWP at the moment. Is this true? I would love to work with the engine for a school project on the Xbox One.
Also I would love to help investigate or test UWP builds on the Xbox One.

[Calinou]

@NVriezen Godot 2.1 had mostly working UWP support, but newer versions have had broken exporting for a while. Someone from Pineapple Works is planning to open a pull request to fix some of the current UWP bugs.

[NVriezen]

@NVriezen Godot 2.1 had mostly working UWP support, but newer versions have had broken exporting for a while. Someone from Pineapple Works is planning to open a pull request to fix some of the current UWP bugs.

Thank you for letting me know
As I think Godot 4.0 is still a long way from release, this would be a great

[ndarilek]

I think I got UWP export mostly working. Here's what I've figured out, and should probably be included in any 4.0 fixes if they aren't already:

• identity/product_guid and identity/publisher_guid are required and I don't know why.
  
  
  
  • I just opened a Partner Center account, and they don't correspond to any of the settings Microsoft gives me. I.e. I'm given what I assume is my publisher name, as well as a unique name for my app. But there is nothing on these screens corresponding to either of these GUIDs, nor can I find anything anywhere while poking around my account.
  
  
  • When the appx is generated, those elements populate mp:PhoneIdentity, appear to exist to offer an upgrade path for Windows Phone apps, and don't appear to be required. As such, I don't think the export should fail if they aren't provided, but it does.
  
  
• In contrast, package/description is required in the appxmanifest but the export process exports without it. Seems to populate uap:VisualElements where it very much is required. Adding that made the export work, but again, Godot exported without a required parameter while requiring what seem to be optional parameters.
• As with many things Microsoft, processes seem to have churned a bit around UWP. In particular, I used this method to create my certificate. I didn't get a .cer file, so this got a .cer file from my .pfx. From that point, Godot's own docs got the .cer file into my trusted store, and the export installed and ran...mostly.

My final stumbling point is GDNative. This PR seems to suggest that it should work, though DLLs aren't automatically packed in the export. It looks to me like that code just strikes "res://" off the front of GDNative DLLs and expects them in the game/ folder of your appx, so res://addons/godot-tts/target/release/godot_tts.dll should be in game/addons/godot-tts/target/release/godot_tts.dll in my appx. I used these instructions to unpack and repack the appx with the DLLs in a variety of places. I've confirmed that the DLLs are listed in AppxBlockMap.xml. But nothing I do gets my GDNative functionality working in a UWP app, despite it working fine in Win32 exports.

I'm going to keep debugging this from the WinRT end--it's possible that my issues are due to writing a GDNative extension in Rust, using a dependent library that itself depends on Microsoft's WinRT preview crate and also tries loading other DLLs. In other words, there may be dragons. :) But if anyone has any thoughts on how to further debug this, I'm all ears. I don't know how to see debugging info from a running .appx, for instance, so I don't even know if my GDNative DLLs are loading, if they're loading but silently failing, if they're loading and failing loudly but I don't know where to look.

But if you aren't using GDNative, I hope this is enough to get you started, because my game seems playable without the GDNative functionality. If you do find any other issues, and especially if you find a fix, please do let me know. I've been banging my head against this one for hours and am surprised I'm not concussed yet.

[ndarilek]

OK, breakthrough on the GDNative issue. After making Godot log to files, and after finding where the appx stashes this, I get:

**ERROR**:  does not have a library for the current platform.
   At: modules\gdnative\nativescript\nativescript.cpp:1483:NativeScriptLanguage::init_library() - Condition "lib_path.length() == 0" is true.

So what do I need in my gdnlib file to indicate that a DLL is for UWP? I tried UWP.64=... but clearly that's not right.

Thanks.

[NVriezen]

I think I got UWP export mostly working. Here's what I've figured out, and should probably be included in any 4.0 fixes if they aren't already:
......

I tried to follow the process you had taken to get the exporting to work again. But in the end it still gave me the parsing error. Did you unpack and repack the game first? @ndarilek

[bruvzg]

I tried UWP.64=... but clearly that's not right.

It should be right if sizeof(void *) == 8 on UWP, try just UWP or UWP.x86_64. Library is selected if all the . separated feature tags in the config satisfies OS.has_feature(x) test.

See os.cpp#L371-L439, OS name, which is "UWP", should be enough.

[GeorgeS2019]

I hope people here can persist to get the UWP export finally works

[ndarilek]

OK, so adding to the specific issues broken in UWP:

UWP.64= and UWP.x86_64= don't appear to work when specifying library dependencies. For everything other than UWP= I get the previous error. With UWP= I get:

**ERROR**: Can't open dynamic library: game/addons/godot-tts/target/debug/godot_tts.dll, error: Error 193: %1 is not a valid Win32 application.
.
   At: platform\uwp\os_uwp.cpp:833:OS_UWP::open_dynamic_library() - Condition "!p_library_handle" is true. Returned: ERR_CANT_OPEN
**ERROR**: No valid library handle, can't get symbol from GDNative object
   At: modules\gdnative\gdnative.cpp:483:GDNative::get_symbol() - No valid library handle, can't get symbol from GDNative object
**ERROR**: No nativescript_init in "res://addons/godot-tts/target/debug/godot_tts.dll" found
   At: modules\gdnative\nativescript\nativescript.cpp:1506:NativeScriptLanguage::init_library() - No nativescript_init in "res://addons/godot-tts/target/debug/godot_tts.dll" found

That is very likely due to me compiling with the wrong Rust target, so IOW, UWP= seems to work, but nothing else does.

I'm going to specify UWP= in my GDNative module and hope no one tries using this on 32-bit or non-X86 systems, because it just won't work there. Maybe Godot doesn't officially support non-x86_64 UWP systems?

In any case, I'll try fixing the Rust targets tomorrow and will report back about whether or not that gets me further. Thanks for the help.

[ndarilek]

Actually, my mistake, I now see that I needed to select a target. I'll switch back to UWP.64 now that I'm doing a 64-bit export and see if that works.

[ndarilek]

FWIW, I've gotten this working. No need to retarget the Rust DLL after
all. So, with the above caveats, UWP export does seem to work in so far
as letting me install and play a self-signed game on my Windows 10 VM.

Now to try putting my Xbox into dev mode and running it there, but
that's a project for another day. Thanks for explaining how gdnlib
resolution works.

[GeorgeS2019]

@ndarilek pls try write it down what u do to make it works. Otherwise, the next guy will spent equally lot of time to figure out how to get it works. As far as I know, there is no github repos for e.g. simple demo that one can download to show Godot UWP works in Windows 10. If you could provide one, it will help others to proceed to the next challenge of Godot UWP, how to optimize the performance.

[ndarilek]

I think everything is pretty much captured in this issue. See
this as an example of a
module that uses it, including GitHub actions for building and creating
releases.

Note that apparently this still won't work in apps submitted to the
store because their DLLs need an additional bit set, Rust does this via
the various UWP targets, and they're tier 3 so no pre-built toolchains
are available. I'm trying to figure out what this bit is and if it can
be set manually so I don't need the target.

If someone wants to open new issues related to each of the above points,
feel free, and link them here. I feel like I've provided enough details
for someone else to do so. Otherwise, and not to put too fine a point on
it, but I spent days figuring this out, so perhaps opening issues is a
great opportunity for someone else to contribute. :) If no one gets to
it then I'll do it in a couple weeks, but between this plus
godot-accessibility plus actually building a game, my hands are pretty
full, and not exactly with easy tasks either. :)

[GeorgeS2019]

@ndarilek If you check the Godot history, I started putting the different pieces together on Godot UWP since last year May 2019. Even until last month, I still learn different versions of the truth from different people.

If you can do it in few weeks or few Months. It is already a major contribution.

There is no recent Godot UWP in youtube either. If you can share a running Godot UWP demo, it will also help.

[GeorgeS2019]

Summary of UWP export for milestones 4.0

[ZodmanPerth]

Inspired by @ndarilek I went back and tried (again) to get my export working. This time I paid a lot more attention and managed to get my app package installed and running.

First I recreated my certificate from scratch, and re-added everything in Godot settings according to the instructions.
I exported the app and confirmed the package could not be installed (as expected).
I opened the package in 7-zip and extracted all the files to a folder.
I examined the xml files for anything obvious and found [Content_types].xml contained a duplicate entry for ttf extensions. I removed the duplicate entry.
I remade the package with MakeAppx.
I resigned the package manually with SignTool.
This time the package installed successfully.

However, not everything in my game is working. Some of the visuals are not being displayed, and there is a significant lag with touch input. It's been some time since I've had a successful run on a UWP export so the lag may be new features I've introduced not performing well and I will need to investigate further.

If the visuals aren't working I'm not sure there's much I can do but abandon the entire Windows platform for my game until the Godot developers and/or community fix the UWP export. I'm extremely disappointed by this as I am developing on Windows (moving to Linux is not an option for me). My game's interface specifically targets touch which is only available with UWP on Windows.

[GeorgeS2019]

@ZodmanPerth THIS IS the kind of feedback we need for UWP godot.

So we have a clearer community view of Godot UWP. What works and what do not work after export.

We need a demo project (simple) just to reproduce a godot UWP export that the rest of community can test.

After that, we can address what is the bottleneck in UWP godot implementation

Thanks for the feedback

@Calinou => can u please feedback this latest info from UWP godot developer to more relevant Godot UWP responsible person?

@akien-mga => a relevant latest Godot UWP feedback after the Youtube live discussion with Godot. ==> also it is unclear why a series of UWP comments and feedback have been deleted from this issue.

[Calinou]

@Calinou => can u please feedback this latest info from UWP godot developer to more relevant Godot UWP responsible person?

I'm afraid it doesn't work like that. In open source projects, people work on what they want to work on. We have very few contributors knowledgeable on UWP (and I'm not knowledgeable about it either). Pineapple Works has pledged to open pull requests to fix UWP exporting a while back, but I haven't seen a pull request from them yet.

If the visuals aren't working I'm not sure there's much I can do but abandon the entire Windows platform for my game until the Godot developers and/or community fix the UWP export.

It's not like Win32 is quite dead yet :wink: Pretty much all the popular games out there are still Win32 applications.

My game's interface specifically targets touch which is only available with UWP on Windows.

I'm pretty sure the touch support in Win32 can be improved if needed. It's not a very common use case, which tends to explain it not being well-supported.

[vnen]

So, technically I am the responsible for the UWP port. The problem is that I don't really have allocated time to look at those issues for now.

Debugging UWP is quite complicated because we do it a bit differently than what the documentation expects. Sometimes there's not enough information to help me pinpoint the issues.

Graphics should work okay on 2D (although I'm not sure if shaders are well supported). 3D is buggy because we depend on ANGLE, which is not perfect. One thing we need to do is update to the latest version, since they went back to support UWP upstream and we're still using the MS fork (I want to do this for a while but had not had the time). For Godot 4.x it should be much easier to add an actual DirectX backend, which would solve the issues with graphics.

Regarding touch input: I did the initial port using emulators since I do not own any Windows device with touch input. I'm not sure what could be causing the lag.

I examined the xml files for anything obvious and found [Content_types].xml contained a duplicate entry for ttf extensions. I removed the duplicate entry.

Also not sure what could be causing this, maybe something changed along the way, but this could be the cause why the package is considered invalid. This needs to be fixed on the export code.

My game's interface specifically targets touch which is only available with UWP on Windows.

Touch can be added for the regular Windows port, it's just that nobody did that yet.

@Calinou => can u please feedback this latest info from UWP godot developer to more relevant Godot UWP responsible person?

@akien-mga => a relevant latest Godot UWP feedback after the Youtube live discussion with Godot. ==> also it is unclear why a series of UWP comments and feedback have been deleted from this issue.

Pinging specific contributors is impolite, they do not need to be mentioned in every issue. A person responsible for UWP will check the label. If you need to ping, use @godotengine/uwp which is the appropriate team. Deleted comments were most likely unrelated to the issue.

@GeorgeS2019 I already have told you to not use that issue as a tracker for UWP because that one is specifically about C# support. If you want to create a tracker create a new issue to list all the links free to do so (see for instance https://github.com/godotengine/godot/issues/39144 for a good example of a tracker issue).

[GeorgeS2019]

@vnen my time with godot is still relatively new e.g. 1.5 years +. Within this short time, I do not see too many feedback for Godot UWP. If there is any feedback on UWP, I try to support them when it is possible. I bring @akien-mga here because I too ask him for feedback and it only becomes clear after Godot Live Q&A youtube that you are the key person. I am not sure where the community can learn by going to e.g. Godotengine.org to learn that you are the UWP person for Godot.

After a few exchanges with you. I will continue to take RISK to be kick out of this community each time I attempt to promote more awareness and interaction on Godot UWP.

Godot UWP support, as U have rightly stated, there is not much time allocated and therefore it is not clear how Up-To-Date are the feedback I and others could gathered from various users here.

Each time, someone braves enough to try, each one repeats other brave attempts of others. In the end, each one contributes slightly to the true picture of Godot UWP status.

The true Godot UWP status involves many aspects. Perhaps from your point of view, it is only the not updated ANGLE support.

For some of us, perhaps lacking the necessary technical experience as yourself, we do not comprehend why Unity can make UWP export works and Microsoft works with Unity for OpenXR (Hololens 2) and why Godot is not yet there.

However, after today your remark, I see a slightly more on the Godot UWP status.

Again, I take risk whenever each time I try to understand the status of Godot UWP.

[Zireael07]

@GeorgeS2019: You were asked to stop @-mentioning specific people, esp. Akien, and you were told that this issue is not a catch-all for UWP (although the issue title could do with mentioning C# specifically, can someone with relevant access change the issue title?)

Please open a new issue for UWP support in general.

[vnen]

@GeorgeS2019

Within this short time, I do not see too many feedback for Godot UWP

Me neither that's also why it didn't get many fixes and so it doesn't work well. Android is used a lot so it gets a lot of feedback and contribution. UWP is the least used platform, it's natural that it tends to be left behind. We depend on volunteer time to work on the code, since the payed devs are limited (so we tend to work on what affects most people first). We can't force volunteers to work on what we want, they work on what they want because its their free time.

If there is any feedback on UWP, I try to support them when it is possible.

You should support by doing what akien and I have been saying multiple times for quite a while. Yet you keep doing what we told you shouldn't do (bringing unrelated issues in the same thread) and never did what we asked you to do (open a proper tracker issue for UWP). That would help much more.

I bring akien-mga here because I too ask him for feedback and it only becomes clear after Godot Live Q&A youtube that you are the key person. I am not sure where the community can learn by going to e.g. Godotengine.org to learn that you are the UWP person for Godot.

Nobody needs to know who is responsible for what in general. You just open the issue and the person in charge (if any) will be informed. If you wanted to know that you should've just asked instead of mentioning the org members at will. This is not listed anywhere, because it's mostly based on volunteer time, but you can get a hint checking the code owners file.

There's a reason I comment on most UWP issues: I follow then since I'm the maintainer.

After a few exchanges with you. I will continue to take RISK to be kick out of this community each time I attempt to promote more awareness and interaction on Godot UWP.

It doesn't help if you don't follow the guidelines and keep posting off-topic cross-references to every UWP issue. It just adds noise instead of useful information. GitHub is not place to chat, you can use other community channels for that. Here's is a place where we track _relevant_ information about issues.

The true Godot UWP status involves many aspects. Perhaps from your point of view, it is only the not updated ANGLE support.

I never said it is _only_ ANGLE. I know very well the issues with UWP. I just don't have time to work on it and when I did I spent a long time debugging only to reach dead ends. Given it's the least used platform (only 2.6% usage according to our latest community poll) it naturally tend to be less prioritized.

For some of us, perhaps lacking the necessary technical experience as yourself, we do not comprehend why Unity can make UWP export works and Microsoft works with Unity for OpenXR (Hololens 2) and why Godot is not yet there.

Perhaps because Unity has a lot of money and can pay devs to work exclusively on that, while also paying evangelists to convince companies to use their product, therefore increasing the money (and thus incentive) to work with UWP. While Godot is non-profit and relies on community donations to pay a few devs to work full time, not nearly enough to cater the whole Godot codebase.

Again, I take risk whenever each time I try to understand the status of Godot UWP.

Yes, instead of doing what the project manager and organization members tell you to do. If you don't want to follow the rules and you refuse to follow our recommendations, you don't give us much choice. No matter how much you comment, it won't increase the time I have to work on UWP (instead it will decrease the time I have to work because I have to explain the same thing to you over and over again).

---

Seriously, @GeorgeS2019, what's stopping you from opening a UWP tracker issue like I recommended multiple times? No need to answer me. Just do it (or don't). I will stop replying to off-topic comments and just hide them instead, as I feel I already wrote much more than I should have. I'm available in other community channels if anyone wants a discussion in the appropriate place.

[ZodmanPerth]

@Calinou said:

I'm pretty sure the touch support in Win32 can be improved if needed. It's not a very common use case, which tends to explain it not being well-supported.

If "improved" means "implemented" then that would satisfy my requirements and I wouldn't need UWP specifically. My aim is to target Surface line on Windows, as well as all the non-MS touch screens now available.

@vnen said:

Debugging UWP is quite complicated because we do it a bit differently than what the documentation expects. Sometimes there's not enough information to help me pinpoint the issues.

I totally agree (and sympathise). My day job is the lead developer for a UWP app, and I've recently gone through a lot of pain trying to refresh certificates. It seems everytime you need to touch the packaging process things have changed and the documentation doesn't quite help enough.

Reading between the lines (as one must do with Microsoft) I believe the packaging process is still a little in flux as Microsoft move toward the MSIX model. I believe in that model; it's fantastic for everyone. Fortunately it's an extension of the UWP packaging process. Unfortunately I think it means you (and anyone else who can help) up for more work in this complicated space.

@GeorgeS2019 I love your passion and enthusiasm for UWP. Please don't treat the feedback you're receiving as negative; we all need to engage by the rules. When the engagement rules aren't followed it disrupts _all_ development on Godot, and none of us want that. If you want the biggest and most positive impact, create a new issue as recommended.

The idea of having a sample project that allows everyone to test UWP works is a great one. I hope someone can follow that up.

[ZodmanPerth]

I was very happy to see the burst of responses following my recent posting. As someone who works with UWP every day, I am a strong believer in the platform and I do love it. However given some of the responses I'm now wondering if there is a need for UWP export at all. If Win32 support can be brought up to speed with UWP support (touch, accelerometer, etc) that seems to support the needs of all Godot games.

Win32 apps can now be packaged up and deployed to the Windows Store. If it's easier to add the missing capabilities to Win32 and support that route I can't see any advantage that a UWP implementation has over that. I know that's a little off topic, but I am interested to hear thoughts on that approach, particularly by core Godot developers.

I love all the hard work everyone is putting into Godot. You're all doing an amazing job. ♥

[Calinou]

If "improved" means "implemented" then that would satisfy my requirements and I wouldn't need UWP specifically.

Windows should already support touch events. There are multiple pull requests about it that have been merged in the past: https://github.com/godotengine/godot/pull/14346, https://github.com/godotengine/godot/pull/19708

If there are bugs, please report them :slightly_smiling_face:

[GeorgeS2019]

I will be a team/community player and follow the rules. :-)

I was very happy to see the burst of responses following my recent posting. (from ZodmanPerth)

That is all I want to see! Lots of responses and discussions on Godot UWP.
Sorry sometimes I trigger the discussions the wrong way.

[ndarilek]

@ZodmanPerth Apologies for contributing more to this thread, but as someone working on a UWP app, I'm interested in whether Win32 apps would work for my use case. Do you know if MSIX-packaged Win32 apps are installable on the Xbox One? As with so many things Microsoft, I never seem to find the right keywords that lead me to an answer. But I'm trying to support the Xbox, and if I can abandon UWP to do so, then that'd be helpful. No offense to those of you working on the UWP support, but it has been a pain to work with for a variety of reasons not Godot-related.

Thanks.

[ZodmanPerth]

Sorry @ndarilek I don't know anything about the Xbox. MSIX is most likely supported there, but the question is whether Win32 is. I've done a quick search and it looks like there will be support; the right keywords are "project reunion xbox".

[ndarilek]

Thanks for that. Knowing Microsoft's names for things is like learning
magical incantations. :)

[ZodmanPerth]

No problem. Marketing remains an insidious blight for Microsoft. Most of the FUD and misinformation around their technology stems from their inability to communicate clearly. It drives developers away from their tech, and makes supporting their tech in places (like Godot) difficult, because takup is minimal. I find it incredible that they haven't appropriately addressed this issue.

[NVriezen]

What should be included in an example project for UWP?
I myself am targeting Xbox One and I would benefit from UWP working well with Godot.
Unfortunately I don't have the knowledge yet, but I am planning to dig into the engine a bit more.
So I wouldn't mind to cook up a little example project for people to reference for their UWP projects.
And also for anyone working on the engine code fixing certain stuff for UWP.

[Calinou]

@NVriezen The demo projects are usually a good reference for porting Godot to a new platform.

[akien-mga]

My game's interface specifically targets touch which is only available with UWP on Windows.

I can confirm that touch support works fine on Win32, I've tried it myself on my convertible laptop. You can check @HEAVYPOLY's HeavyPaint application which uses touch and pen input: http://www.heavypoly.com/heavypaint

[ZodmanPerth]

Thanks @akien-mga. I confirm touch does work on Win32 as well.

Unfortunately, my game also relies on the accelerometer. Neither Input.get_accelerometer() or Input.get_gravity() work on Win32, despite my device having an accelerometer.

This is why I was targeting UWP originally where both touch and accelerometer (using Input.get_accelerometer()) work on Windows devices. I've done a quick test of the accelerometer in UWP and while it's still "working" it's not the same as it was in September 2018 when the UWP export was working perfectly for me:

• YouTube Video
• Full blog post

(I'm now using a Surface Pro 7, so perhaps it reports differently. Perhaps it's related to the rendering issues with the current UWP export).

Looks like my avenue to Windows support for my game is to raise issues against Win32, which just needs accelerometer support.

[GeorgeS2019]

@ZodmanPerth, thx for the youtube link! Because we have so few up-to-date UWP feedback, this is why it will help the community, to have JUST one godot UWP demo project (@NVriezen ) that will provide functional testing of the UWP ONLY features like e.g. accelerometer, touch so users can always get the latest feedback from others if the latest Godot commits do not break or cause regression to these UWP ONLY features.

[NVriezen]

Okay, makes sense!
I can not promise anything yet. But maybe I can put together such demo project in the upcoming month. So we can have a clear view of what works and what does not regarding UWP. As I said earlier. I am planning to dive in deeper into the engine, but this won't happen in the upcoming 4 to 4.5 months probably.

[GeorgeS2019]

So we can have a clear view of **what works and what does not** regarding UWP.
It took me many months speaking to many different users here TO FINALLY get here.

Godot 4.x should be much easier to add an actual DirectX backend, which would solve the issues with graphics.
Before we address the graphic performance issue. The demo project (@NVriezen ) will help to address non graphics issue before needing to wait for the DirectX backend in coming months.

[NVriezen]

I noticed that I could install my game and get it to run by following the instructions @ZodmanPerth provided.
To make my life easier I made a batch file to do the work for me.

So if you have trouble getting your UWP export to work, follow the newest instructions to create a certificate from scratch
Then follow the godot instructions as @ZodmanPerth noted.
After exporting, drop your .appx file on the batch file and voila!
You should now be able to install and run the game if you have trusted your certificate correctly (just double-click and install for local machine).

Make sure you fill in the Description field and also that the publisher name is something like CN=PublisherName in the Godot UWP Export window.
While creating your certificate you should also type CN=PublisherName as the publisher name.

Do notice that gpacker is a .txt file.
First open the file and set all the variables under the "setup" label.
Instructions should be clear enough what is asked for.
After that, rename the file to gpacker.bat and you are ready to use it.

Regarding the UWP Features Demo project. I did start on it, but I was a bit too busy with finishing another project.
This weekend I would like to take a look at the basic stuff like mouse, keyboard, touch and gamepad.

[NVriezen]

While working on the UWP Features Example Project I noticed something odd.
I got a working .appx package from my UWP export.
I thought it was because I changed the export mode to "Export Selected scenes" instead of "Export all resources in the project".
But after using both export modes to see if I was right I was amazed to learn that both export modes now seem to work...
Though, when using another project I am actively working on. I found that exporting with export mode "Export Selected Scenes" made that project export correctly. While using the all resources option still was broken.
So it was actually changing the export mode to "Export Selected Scenes" that made the export work!

Unfortunately there seems something weird is going on with my certificates as well.
I have added the certificates I use for both projects to my Trusted People store.
Before today I could easily install that other project, but with this working godot export I can't install it as the package is untrusted...
The example project worked with another certificate, but I needed to add the certificate to multiple stores or it just took some minutes before the system actually registered it or something.

So yeah, please try this for yourself and maybe we can sketch a better picture of what is going wrong.
Hopefully the untrusted certificate issue is only on my machine.

[GeorgeS2019]

Exactly this kind of ground investigation will help the community to make UWP export works in a reliable way by exposing the inconsistent observations. Thank you...

[NVriezen]

Did a bit more research.

Certificate

First, the certificate issue was caused by the signtool not being able to sign the package.
After export the package was not build correctly (on all resources export mode) or the block map was incorrect (on only selected scenes export mode).
So I dug a little further.

Signing

It seems that the uwp features project I mentioned exports with a correct block map and content types file.
Therefore signtool can sign the package and then I am able to install it.
It seems Godot always picks the debug certificate from the Editor Settings.
I could be wrong, but making sure the editor settings and the export project settings reference the same certificate made the signtool pick the correct certificate (because they are the same in that case).

Broken Files

Unfortunately my other project seem to no export with correct files.
I used the broken export package and ran it through my earlier mentioned gpacker tool to get a "working" package.
I have looked at both packages (before signing) and the block map and content types file were both different.
It seems the block map just places the appxmanifest entry in the wrong place.
The broken package places it as the first entry, while my working package placed it at the end.
Sort of the same can be said about the content types file. In the broken package there are more entries.
And it labels json files incorrectly.
To help anyone who wants to look into this, I have zipped the diff reports and can be downloaded by clicking HERE

Conclusion

My conclusion is that Godot may be using incorrect commands/options to build the package.
As the files who are incorrect are generated by MakeAppX.exe and not by Godot (right?)
Signtool can therefore not do it's job and the result is a non-signed package which can't be installed.
And if you use the all resources export mode, you even end up with a completely broken package

[NVriezen]

I assume u program in mono c#.

I am not. Currently I use GDscript and GDNative C++

I looked at the source code. I saw that the broken files (block map and content types) actually get generated by Godot.
I think they do this so that you can make packages on all operating systems instead of only on Windows.
Though you would still need a Windows machine to sign the package.

To keep this functionality, the source code should just simply be fixed and I think the file Diffs I attached in my previous post help with that.
Though for a temporary fix for windows only, we could simply run our files through MakeAppX like my gpacker does.
There is already a directive which checks if the code runs on Windows. And I guess it won't be much of a hassle to add a field in the UWP Editor Settings for a path to MakeAppX just like there already is for SignTool.
So running MakeAppX just before signing would fix it for a lot of UWP users I think and makes it easier to debug the broken code.

[GeorgeS2019]

@NVriezen Perhaps you may also need to track Godot proposals ref 1, ref 2 related to UWP. If possible, you could also create a new Godot Proposal on how to proceed with a PLAN to make Godot UWP export robust and reliable to work with future commit of Godot.

[Calinou]

@GeorgeS2019 Fixing UWP support is considered a bug fix, not a feature request. You don't need to open a proposal for that.

[GeorgeS2019]

@Calinou

One reason why we are having this long conversation is that over years, once a while, someone will try to export UWP and perhaps in the many commits, regression happens that fail the UWP export and then have a bad experience with Godot UWP export

This is partly there are not so many Godot UWP export developers.

However, the next generation Windows is based on UWP API.

Perhaps, there will be more developers

I think, if @NVriezen can figure out a way TO MAKE UWP EXPORT ROBUST once and for all => by recommending MEASURES and NOT BUG FIX ( as have been done according to the list above OVER MANY MONTHS to YEARS), then GODOT UWP export will be more ROBUST => perhaps @NVriezen figure out a way to check for each future Godot Commits.

That requires a different way of thinking to ensure future Godot UWP export is bug free. That requires discussion among community. That proposal in my view is a valid GODOT Proposal. => Not a bug fix that may address the issue here.

But a Godot proposal that ask community how to best prepare the test project that properly test the DIFFERNT STEPS leading to a reliable Godot UWP export.

[akien-mga]

Talking in CAPS doesn't solve much, and nobody can future proof the UWP port to prevent bugs in the future.

What's needed is simple: bug reports.
There should be ONE bug report for EACH bug that affect the UWP exporting process / running UWP applications.

Then there can be bug fixes to solve these bugs. Then UWP will work out of the box.

[GeorgeS2019]

@akien-mga thx for your suggestion. You have the experience. I agree with you

[ZodmanPerth]

As for UWP developer numbers, I do get the occasional question about Godot UWP export via my blog and youtube videos. I only have a _tiny_ pool of followers, so to get multiple questions tells me there are many out there.

[ndarilek]

Sorry, I don't know if I should be posting here anymore or opening up new issues.

After making all sorts of progress getting this working, I'm back to square one. In particular, running SignTool manually gives:

SignTool Error: SignedCode::Sign returned error: 0x800700C1                                                             
        For more information, please see https://aka.ms/badexeformat                                                    
SignTool Error: An error occurred while attempting to sign: onslaught.appx                                              

Number of files successfully Signed: 0                                                                                  
Number of warnings: 0                                                                                                   
Number of errors: 1                                                                                                     

Everything I've read suggests matching the publisher with the cert. I'm pretty sure I've done that. In particular, the CN=... values passed to makecert /n are cut-and-pasted directly from the manifest. I'm also pretty sure I'm using the X64 toolchain.

There are two differences between what I did in June and now. First, I'm now natively on Windows. Next, I'm using the publisher ID issued to me by the Microsoft store to create a self-signed cert for on-device testing. But I don't know what's going on with this cert.

Thanks for any help.

[ndarilek]

OK, apologies for the spam. Figured it out by looking at the packer. Initially I was using makeappx unpack, but that breaks on the invalid appx and doesn't provide enough for makeappx pack to create a valid file. I just switched to unzip, and now the signature works.

Thanks to everyone for doing all this work. I'll grant that this issue is a bit messy, but it's a great resource for figuring this stuff out.

[ZodmanPerth]

I had the same issue with makeappx unpack which is why I just unzipped it as you've done.

You can the full steps I took in my comment from 3 Aug, 2020 (which is now inconveniently hidden behind a fold in this conversation).

[Anutrix]

@ZodmanPerth Can you post the contents of your [Content_types].xml file for reference?

[GeorgeS2019]

Is it important to include information such as e.g. [Content_types].xml and other best practices discussed here in the official instructions for UWP export?

[ZodmanPerth]

@Anutrix here's the contents of my [Content_types].xml for reference.

<?xml version="1.0" encoding="UTF-8"?><Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types"><Default Extension="xml" ContentType="application/xml" /><Default Extension="png" ContentType="image/png" /><Default Extension="exe" ContentType="application/x-msdownload" /><Default Extension="dll" ContentType="application/x-msdownload" /><Default Extension="cl" ContentType="application/octet-stream" /><Default Extension="stex" ContentType="application/octet-stream" /><Default Extension="import" ContentType="application/octet-stream" /><Default Extension="shader" ContentType="application/octet-stream" /><Default Extension="gdc" ContentType="application/octet-stream" /><Default Extension="tscn" ContentType="application/octet-stream" /><Default Extension="ttf" ContentType="application/octet-stream" /><Default Extension="tres" ContentType="application/octet-stream" /><Default Extension="remap" ContentType="application/octet-stream" /><Default Extension="binary" ContentType="application/octet-stream" /><Default Extension="p7x" ContentType="application/octet-stream" /><Override PartName="/AppxManifest.xml" ContentType="application/vnd.ms-appx.manifest+xml" /><Override PartName="/AppxBlockMap.xml" ContentType="application/vnd.ms-appx.blockmap+xml" /><Override PartName="/AppxSignature.p7x" ContentType="application/vnd.ms-appx.signature" /><Override PartName="/AppxMetadata/CodeIntegrity.cat" ContentType="application/vnd.ms-pkiseccat" /></Types>

Note that when I tried formatting to be more readable by humans the repackaging failed.

Here's the contents in a more readable format for the sake of this conversation:

<?xml version="1.0" encoding="UTF-8"?>
<Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types">
    <Default Extension="xml" ContentType="application/xml" />
    <Default Extension="png" ContentType="image/png" />
    <Default Extension="exe" ContentType="application/x-msdownload" />
    <Default Extension="dll" ContentType="application/x-msdownload" />
    <Default Extension="cl" ContentType="application/octet-stream" />
    <Default Extension="stex" ContentType="application/octet-stream" />
    <Default Extension="import" ContentType="application/octet-stream" />
    <Default Extension="shader" ContentType="application/octet-stream" />
    <Default Extension="gdc" ContentType="application/octet-stream" />
    <Default Extension="tscn" ContentType="application/octet-stream" />
    <Default Extension="ttf" ContentType="application/octet-stream" />
    <Default Extension="tres" ContentType="application/octet-stream" />
    <Default Extension="remap" ContentType="application/octet-stream" />
    <Default Extension="binary" ContentType="application/octet-stream" />
    <Default Extension="p7x" ContentType="application/octet-stream" />
    <Override PartName="/AppxManifest.xml" ContentType="application/vnd.ms-appx.manifest+xml" />
    <Override PartName="/AppxBlockMap.xml" ContentType="application/vnd.ms-appx.blockmap+xml" />
    <Override PartName="/AppxSignature.p7x" ContentType="application/vnd.ms-appx.signature" />
    <Override PartName="/AppxMetadata/CodeIntegrity.cat" ContentType="application/vnd.ms-pkiseccat" />
</Types>

In my experience with UWP packaging the content of this file changes. I presume Godot is only adding the extensions it needs, so this is not a definitive list.

@GeorgeS2019 I follow the official instructions, then do the manual processing in my comment from 3 Aug, 2020. In this way I guarantee Godot does what it needs, then I fix the resulting file. For my game at the moment this fix is easy, but I expect people will have different experiences depending on what their game is doing.

[Anutrix]

@ZodmanPerth Thx a lot. But I wanted the original unfixed file with multiple/duplicate lines like you had for ttf extension in https://github.com/godotengine/godot/issues/30558#issuecomment-667926124.
And you are right, Godot only adds extensions it needs.
Also, as you can see here, it only adds unique extensions.
https://github.com/godotengine/godot/blob/e93af13959e2840e6fed58fb79ec4f7b9fdfec6a/platform/uwp/export/export.cpp#L251-L261
Do provide unmodified version of [Content_types].xml if you can. I was asking for it so that I can confirm if the duplicate entries are exactly same. Were they next to each other? Does it happen to other extensions or just ttf?, etc.
Thx again.

[ZodmanPerth]

@Anutrix : here's a freshly generated copy of the [Content_Types].xml from when I export:

<?xml version="1.0" encoding="UTF-8"?><Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types"><Default Extension="xml" ContentType="application/xml" /><Default Extension="png" ContentType="image/png" /><Default Extension="exe" ContentType="application/x-msdownload" /><Default Extension="dll" ContentType="application/x-msdownload" /><Default Extension="cl" ContentType="application/octet-stream" /><Default Extension="stex" ContentType="application/octet-stream" /><Default Extension="import" ContentType="application/octet-stream" /><Default Extension="shader" ContentType="application/octet-stream" /><Default Extension="gdc" ContentType="application/octet-stream" /><Default Extension="tscn" ContentType="application/octet-stream" /><Default Extension="TTF" ContentType="application/octet-stream" /><Default Extension="ttf" ContentType="application/octet-stream" /><Default Extension="tres" ContentType="application/octet-stream" /><Default Extension="remap" ContentType="application/octet-stream" /><Default Extension="binary" ContentType="application/octet-stream" /><Default Extension="p7x" ContentType="application/octet-stream" /><Override PartName="/AppxManifest.xml" ContentType="application/vnd.ms-appx.manifest+xml" /><Override PartName="/AppxBlockMap.xml" ContentType="application/vnd.ms-appx.blockmap+xml" /><Override PartName="/AppxSignature.p7x" ContentType="application/vnd.ms-appx.signature" /><Override PartName="/AppxMetadata/CodeIntegrity.cat" ContentType="application/vnd.ms-pkiseccat" /></Types>

... and in human readable format:

<?xml version="1.0" encoding="UTF-8"?>
<Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types">
    <Default Extension="xml" ContentType="application/xml" />
    <Default Extension="png" ContentType="image/png" />
    <Default Extension="exe" ContentType="application/x-msdownload" />
    <Default Extension="dll" ContentType="application/x-msdownload" />
    <Default Extension="cl" ContentType="application/octet-stream" />
    <Default Extension="stex" ContentType="application/octet-stream" />
    <Default Extension="import" ContentType="application/octet-stream" />
    <Default Extension="shader" ContentType="application/octet-stream" />
    <Default Extension="gdc" ContentType="application/octet-stream" />
    <Default Extension="tscn" ContentType="application/octet-stream" />
    <Default Extension="TTF" ContentType="application/octet-stream" />
    <Default Extension="ttf" ContentType="application/octet-stream" />
    <Default Extension="tres" ContentType="application/octet-stream" />
    <Default Extension="remap" ContentType="application/octet-stream" />
    <Default Extension="binary" ContentType="application/octet-stream" />
    <Default Extension="p7x" ContentType="application/octet-stream" />
    <Override PartName="/AppxManifest.xml" ContentType="application/vnd.ms-appx.manifest+xml" />
    <Override PartName="/AppxBlockMap.xml" ContentType="application/vnd.ms-appx.blockmap+xml" />
    <Override PartName="/AppxSignature.p7x" ContentType="application/vnd.ms-appx.signature" />
    <Override PartName="/AppxMetadata/CodeIntegrity.cat" ContentType="application/vnd.ms-pkiseccat" />
</Types>

As you can see comparing with my previous post, I am removing the TTF extension and leaving the ttf extension.

I'm a complete noob a C++, and unaware if export.cpp is used for multiple platforms, but I believe updating the expression types.has(ext) to be case insensitive for Windows exports (UWP and Win32) will fix the issue in my circumstances (because on Windows the content types are case insensitive).

[Anutrix]

@ZodmanPerth Thx for the data again. Just changing the first line to String ext = file_metadata[i].name.get_extension().to_lower(); should work. You can make PR with this change. Otherwise I'll make short PR soon when I have time.

I'm a complete noob a C++, and unaware if export.cpp is used for multiple platforms, but I believe updating the expression types.has(ext) to be case insensitive for Windows exports (UWP and Win32) will fix the issue in my circumstances (because on Windows the content types are case insensitive).

This export.cpp is UWP specific (since it's located at godot/platform/uwp/export/) so it won't affect other platforms.

One UWP problem down. Few more to go.

[GeorgeS2019]

@Anutrix @ZodmanPerth I sincerely thank both of you and others who contributed to this Godot UWP thread. I have followed Microsoft c# 3D initiatives for many years, e.g. ManagedDirectX, SlimDX, SharpDX, and other 3D game engine initiatives. I see 3D as key to the next digital transformation. Godot as 3D c# option is key to this next step for me and others.

When time come, I also hope to get inputs from you all on how to transition what we have achieved here in alignment with the next waves of .NET technologies such as moving to WinUI 3.0 and MAUI. Thank you all for persistent support of Godot UWP.