yup 
logs show it connecting and transferring stuff.
Visual Studio automatically applies the exception when running under the debugger. There’s a similar step in the AutomationTool implementation for UWP - see the end of UWPPlatform.Deploy.
I haven’t looked at the actual project, but if you’ve got past the UWP splash screen and onto a black window then you’ve loaded something, probably the built-in Entry map. You might see whether you can open the debug console and load some other map, or take a look at the debug spew to see if it offers any clues.
I’ve punted on the previous issue for the moment.
Currently trying to have a DLL be packaged via RuntimeDependencies so I can LoadPackagedLibrary() it. Anybody tried this before? Is the build system setup to work for this currently for UWP?
nevermind I think the answer is yes, it does work!
Alright, so far so good. Debugging was broken in this test because it was the entry map like you said.
I think there is a new gotcha though. Deploying is supposed to include the full contents of “Content/Movies” folder into the final package - however the UWPDeploy does not follow this rule. As such in-game movies do not work.
I was able to work around by adding
RuntimeDependencies.Add("$(ProjectDir)/Content/Movies/...", StagedFileType.UFS);
to my Build.cs
Finally got an ARM build to link properly!
Now to package a build and see which wonderful new crash messages I’ll get on an actual Lumia 640. Ayy!
Ooh, nice work on the ARM build! Do let us know how it runs.
Does anyone tried out to make a build of a uwp game in ue4 for windows 10 mobile or only for xbox one?
I managed to install it on an actual device, and it crashes right away on launch (I fully expected this, since I know the RHI code will need a few tweaks to use D3d11 feature level 9_3), but I just hit an unexpected wall: I can’t debug an installed package on the device, no matter what. There’s no option to debug an installed package via USB in Visual Studio (only via direct deployment) and the remote debugging refuses to connect to the mobile device (after extensive googling, it doesn’t seem to be supported on mobile).
I need to be able to at least have some idea of what is crashing before I can make the necessary changes, so this will slow me down a great deal until I can come up with a way to get at the very least an output log out from this thing.
– EDIT –
I added a while(true) at the top of the main() function to halt the app before it does anything but it still closes as soon as I launch it (it should pause on the launch image). This means there’s something wrong with the app package itself that prevents launch. I’ll have to dig though the event viewer on the device to see if I can find any clues.
In my experience this kind of thing is frequently a missing dll issue. In addition to the traditional causes in UWP this can also come from using the desktop import libraries for Win32 APIs (e.g. kernel32.lib) instead of windowsapp.lib, since the desktop versions take a dependency on a specific dll (which may not be present on all devices), vs windowsapp which has an extra level of indirection. Are you able to run WACK on your package? That usually flags these problems pretty fast. Also, what version of the Win10 SDK are you using?
Getting the device emulator up and running as a debug target might help. If you look at UWPProjectGenerator.cs, GetVisualStudioLayoutDirSection, you can see where we sneak in the basic set of UWP debuggers. I think the appropriate additional property to get the emulators listed would be something like
Now that you mentioned, I remember adding Kernel32.lib as an input to one 3rd party libraries I had to recompile for ARM, can’t recall which one (probably one of the Vorbis libraries). I will double check them.
I didn’t think about using WACK, that’s a good idea. I’m using SDK 10.568.
I thought about using the emulator before, but it takes x86 packages, which I guess would mask any problems related to ARM packaging. Thinking about it now, it might actually be useful for finding out other problems related running in mobile mode.
Thanks for the tips, they’ll definitely help.
A note on 10586 specifically: you may well have spotted that the existing UWP integration code explicitly adds kernel32.lib to the link line when using this version of the SDK. As alluded to in the comment it’s a bit of a cheat to get access to TLS APIs. If you’ve been basing your ARM version on this then it could be a source of problems. I’d recommend moving to the 14393 SDK if possible - you can still target earlier OS versions at runtime if that’s an important scenario for you.
It really seems to be caused by bad dependencies. This is what I got from WACK:
A API getenv em api-ms-win-crt-environment-l1-1-0.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API InitializeSecurityDescriptor em advapi32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API RegCloseKey em advapi32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API RegOpenKeyExA em advapi32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API RegQueryValueExA em advapi32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API SetSecurityDescriptorDacl em advapi32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API CreateFileA em kernel32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API CreateFileMappingA em kernel32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API GetACP em kernel32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API GetCurrencyFormatW em kernel32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API GetDateFormatW em kernel32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API GetGeoInfoA em kernel32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API GetLocaleInfoA em kernel32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API GetLocaleInfoW em kernel32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API GetNumberFormatW em kernel32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API GetThreadLocale em kernel32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API GetTimeFormatW em kernel32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API LoadLibraryA em kernel32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
A API MapViewOfFile em kernel32.dll não é compatível com este tipo de aplicativo. UWP_test.exe chama essa API.
(Nevermind the non-English)
These are very different from the results from a x64 appx, for example (it also fails, but all the errors come from 3rd party dlls that have no business in a shipping UWA like glut32.dll and nvToolsExt64_1.dll). I tried changing the SDK in the Project Settings to 14393, rebuilt Freetype2, libogg, libvorbis and libvorbisfile as actual UWP libraries and did a full rebuild, but the results are the same. Well, it’s some progress at least.
I’ll take a look at the full linker command arguments UBT is using to produce the exe tomorrow to see what’s going on. I’ll also go back through the other 3rd party libraries I built for ARM and make sure they’re all built targeting Windows Store (oh boy, here I go recompiling PhysX again, that takes a while). But I’m in no hurry: I’m mostly doing this because it’s a good opportunity to toy around “porting” UE4 to another platform (sort of, since this is based on the UWP branch) since I cannot rely on pre-compiled 3rd party libraries.
So far it’s nice knowing that everything I need to compile UE4 for a different platform is included (all 3rd party libraries have their source available).
Based on those results I’d be inclined to focus on ICU first - I’d imagine you’ll find the ACP, Format and Locale stuff there. We definitely had to tweak the version we use for x86(-64) UWP.
I also remember cURL being the source of a getenv, but ultimately we switched to IXHR which eliminated that. That might be one to look at if you’ve gone back to cURL on ARM.
A note on the x64 failures: the Shipping configuration should be clean - it strips out those extra dlls (plus an illegal D3D debug API or two). For other configurations our approach has usually been to leave as much as we can alone so long as it builds and runs, and never mind the WACK failures. Let me know if that’s not your experience.
Ahh, fixing the ICU did it! Thanks a lot!
I added these defines to the “common” and “i18n” projects:
_tzset=int
PLATFORM_UWP=1
WINAPI_FAMILY=WINAPI_FAMILY_APP
Then had to make sure LoadLibraryA was not used if PLATFORM_UWP was defined and that did it. Got a nice, green “APPROVED” from WACK. The app now loads and I get a proper crash dump from the device (yay!).
That wraps it up for today. Next, I have to find out why FFileHandleUWP::Seek() is crashing trying to read the size of the PAK file…
Alright, I got a bit further in the ARM build. It took me a while to figure out the reason behind the crash when trying to seek files. After tons of experimenting, it seems file seeking via SetFilePointerEx will always fail on the device if the file was opened for synchronous reading. I don’t know if this is always the case on UWP on ARM or if it’s due to the app being installed on the SD card. Fixed that one by porting the FAsyncBufferedFileReaderWindows to UWP (which only needed one function call to be changed) and passing the flag to open the files in async mode (which is how UE4 does in Windows). There was another crash when writing some config files, but that one was also fixed by simply updating the UWP openWrite function to match the Windows one.
This is the commit with the fixes: https:///M3d10n/UnrealEngine/commit/86801ddd64b69529a00d1a9316ab60871a9765b8
Initialization now got as far as removing the splash. The next challenge is PhysX, which is crashing during initialization.
Got past the issue with PhysX in the ARM build. It was crashing during delayed loading DLLs caused by a few mistakes I did when configuring the PhysX visual studio projects.
Now I’m finally at the point where I knew I would have some work to do before I even started this: getting UE4 to run using D3D11 feature level 9_3. Fortunately, I don’t need to keep deploying ARM build for that, but this will still take a while.
It should be useful for non-UWP projects as well, like getting 2D games running at 60fps on bottom of the barrel Intel IGPs.
Hey guys. Cool stuff regarding UWP on ARM. Could mean a lot for mobile dev.
I’ve had some extra time lately, i’m back on the UWP UE4 train. I have a question I’m hoping somebody with more experience might be able to easily answer.
I’d like to access some Windows Runtime APIs from a project plugin. For example, I’d like to access the Windows::Graphics::Holographic namespace in a project plugin. How might I go about doing this? I’ve tried including the “UWPSDK” module in my Plugin’s Build.cs as a private dependency module, as well as public; it seems to be not doing the trick. I feel like I am missing something very simple.
Any insight/help is greatly appreciated. Thanks guys!
Anything in Windows.Foundation.UniversalApiContract (which includes Windows.Graphics.Holographic) ought to be available from anywhere in your code, including plugins, when compiling for UWP32 or UWP64 - it’s part of the global compiler setup in UWPToolChain.cs. Are you certain the error comes from not finding the types?
Windows Runtime APIs that aren’t part of the UniversalApiContract (e.g. Windows.Phone.PhoneContract) do need to be explicitly referenced via a build.cs file. The UWP fork allows you to do this via Private/PublicWinMDReferences.