Announcement

Collapse
No announcement yet.

Unreal Engine 4 is available for Win10 UWP app dev now

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    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://github.com/M3d10n/UnrealEngi...ab60871a9765b8

    Initialization now got as far as removing the splash. The next challenge is PhysX, which is crashing during initialization.
    Last edited by manoelneto; 11-10-2016, 09:56 PM.

    Leave a comment:


  • replied
    Originally posted by jsyarrow View Post
    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:
    Code:
    _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...

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    Originally posted by jsyarrow View Post
    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:
    Code:
    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).
    Last edited by manoelneto; 11-07-2016, 11:10 PM.

    Leave a comment:


  • replied
    Originally posted by manoelneto View Post
    I didn't think about using WACK, that's a good idea. I'm using SDK 10.568.
    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.

    Leave a comment:


  • replied
    Originally posted by jsyarrow View Post
    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.

    Leave a comment:


  • replied
    Originally posted by manoelneto View Post
    -- 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

    LayoutDirString += " <PropertyPageSchema Include=\"$(VCTargetsPath)$(LangID)\\WindowsAppEmulatorDebugger.xml\" />" + ProjectFileGenerator.NewLine;

    Leave a comment:


  • replied
    Originally posted by jsyarrow View Post
    Ooh, nice work on the ARM build! Do let us know how it runs.
    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.
    Last edited by manoelneto; 11-04-2016, 11:51 AM.

    Leave a comment:


  • replied
    Does anyone tried out to make a build of a uwp game in ue4 for windows 10 mobile or only for xbox one?

    Leave a comment:


  • replied
    Ooh, nice work on the ARM build! Do let us know how it runs.

    Leave a comment:


  • replied
    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!

    Click image for larger version

Name:	2016-11-01.png
Views:	1
Size:	182.3 KB
ID:	1117764

    Leave a comment:


  • replied
    I was able to work around by adding

    RuntimeDependencies.Add("$(ProjectDir)/Content/Movies/...", StagedFileType.UFS);

    to my Build.cs

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    nevermind I think the answer is yes, it does work!

    Leave a comment:


  • replied
    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?

    Leave a comment:

Working...
X