godot
godot copied to clipboard
godotengine
Does UWP export works?
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 Kits\10\App Certification Kit>SignTool sign /fd SHA256 /a /f c:\key.pfx /p x D:\System\Documents_GODOT\Export\UWP\green_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:\System\Documents_GODOT\Export\UWP\green_pixel.appx
Number of errors: 1`
Steps to reproduce: Try to export to UWP and run.
Minimal reproduction project:
Just a guess. Might be a signtool issue. Try the signtool from C:\Program Files (x86)\Windows Kits\10\bin\<Windows version><Your architecture>\signtool.exe and C:\Program Files (x86)\Microsoft SDKs\ClickOnce\SignTool\signtool.exe .
Just a guess. Might be a signtool issue. Try the signtool from C:\Program Files (x86)\Windows Kits\10\bin<Your architecture>\signtool.exe and C:\Program Files (x86)\Microsoft SDKs\ClickOnce\SignTool\signtool.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
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:
Unfortunately I can confirm the bug. Tried with several versions of the signtool.
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.
Fantastic news. Thanks @GeorgeS2019 . I'll be keeping an eye out for it to do confirmation testing.
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.
@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 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
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_guidandidentity/publisher_guidare 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/descriptionis 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.
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.
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
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.
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.
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.
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.
@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.
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. :)
@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.
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.
@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 => 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.
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].xmlcontained a duplicate entry forttfextensions. 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).
@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.
@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.
