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

    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;

    Comment


      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.

      Comment


        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.

        Comment


          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.

          Comment


            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.

            Comment


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

              Comment


                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.

                Comment


                  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.

                  Comment


                    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!

                    Comment


                      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.

                      Comment


                        Thanks [MENTION=494622]jsyarrow[/MENTION] for the reply. That's what I figured; it makes sense that they should be accessible.

                        I can use the Holographic namespace in an engine .cpp file without any issues. Unfortunately, as soon as I add the line "using namespace Windows::Graphics::Holographic;" in any .cpp file in my plugin, I run into the following errors:

                        ~~~~Snippet from UE4 packaging log:
                        MainFrameActions: Packaging (UWP (x86-32bit)): UnrealBuildTool: C:\Users\Adasi\Documents\Unreal Projects\HoloTest\Plugins\AdasiEmptyPlugin\Source\AdasiEmptyPlugin\Private\AdasiEmptyPluginRender.cpp(19): error C3083: 'Graphics': the symbol to the left of a '::' must be a type
                        MainFrameActions: Packaging (UWP (x86-32bit)): UnrealBuildTool: C:\Users\Adasi\Documents\Unreal Projects\HoloTest\Plugins\AdasiEmptyPlugin\Source\AdasiEmptyPlugin\Private\AdasiEmptyPluginRender.cpp(19): error C2039: 'Holographic': is not a member of 'Windows'
                        MainFrameActions: Packaging (UWP (x86-32bit)): UnrealBuildTool: c:\program files (x86)\windows kits\10\include\10.0.10586.0\um\WindowsNumerics.inl(136): note: see declaration of 'Windows'
                        MainFrameActions: Packaging (UWP (x86-32bit)): UnrealBuildTool: C:\Users\Adasi\Documents\Unreal Projects\HoloTest\Plugins\AdasiEmptyPlugin\Source\AdasiEmptyPlugin\Private\AdasiEmptyPluginRender.cpp(19): error C2871: 'Holographic': a namespace with this name does not exist
                        MainFrameActions: Packaging (UWP (x86-32bit)): UnrealBuildTool: ERROR: UBT ERROR: Failed to produce item: C:\Users\Adasi\Documents\Unreal Projects\HoloTest\Binaries\UWP32\HoloTest.pdb

                        ~~~~ Snippet from VS2015 build log:
                        2>C:\Users\Adasi\Documents\Unreal Projects\HoloTest\Plugins\AdasiEmptyPlugin\Source\AdasiEmptyPlugin\Private\AdasiEmptyPluginRender.cpp(19): error C3083: 'Graphics': the symbol to the left of a '::' must be a type
                        2>C:\Users\Adasi\Documents\Unreal Projects\HoloTest\Plugins\AdasiEmptyPlugin\Source\AdasiEmptyPlugin\Private\AdasiEmptyPluginRender.cpp(19): error C2039: 'Holographic': is not a member of 'Windows'
                        2> c:\program files (x86)\windows kits\10\include\10.0.10586.0\um\WindowsNumerics.inl(136): note: see declaration of 'Windows'
                        2>C:\Users\Adasi\Documents\Unreal Projects\HoloTest\Plugins\AdasiEmptyPlugin\Source\AdasiEmptyPlugin\Private\AdasiEmptyPluginRender.cpp(19): error C2871: 'Holographic': a namespace with this name does not exist
                        2>ERROR : UBT error : Failed to produce item: C:\Users\Adasi\Documents\Unreal Projects\HoloTest\Plugins\AdasiEmptyPlugin\Binaries\Win64\UE4Editor-AdasiEmptyPlugin-2033.dll
                        2> Total build time: 25.19 seconds
                        2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.MakeFile.Targets(41,5): error MSB3075: The command "C:\HOLO_UNREAL_1\Engine\Build\BatchFiles\Build.bat HoloTestEditor Win64 Development "C:\Users\Adasi\Documents\Unreal Projects\HoloTest\HoloTest.uproject" -waitmutex" exited with code 5. Please verify that you have sufficient rights to run this command.
                        ========== Build: 1 succeeded, 1 failed, 3 up-to-date, 0 skipped ==========


                        Any Ideas why this might be? Thanks again!

                        Edit: Also, how might I include a winmd reference manually in the build.cs? I'm imagining a line like "PublicWinMDReferences.AddRange(new string[] { "Windows.Foundation.UniversalApiContract" });", but I'm not sure about the syntax and I'm having trouble finding documentation on it. Thanks!!!
                        Last edited by Adasi; 12-08-2016, 04:30 PM.

                        Comment


                          Originally posted by Adasi View Post
                          2>ERROR : UBT error : Failed to produce item: C:\Users\Adasi\Documents\Unreal Projects\HoloTest\Plugins\AdasiEmptyPlugin\Binaries\Win64\UE4Editor-AdasiEmptyPlugin-2033.dll
                          2> Total build time: 25.19 seconds
                          2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.MakeFile.Targets(41,5): error MSB3075: The command "C:\HOLO_UNREAL_1\Engine\Build\BatchFiles\Build.bat HoloTestEditor Win64 Development "C:\Users\Adasi\Documents\Unreal Projects\HoloTest\HoloTest.uproject" -waitmutex" exited with code 5. Please verify that you have sufficient rights to run this command.
                          These lines suggest that your plugin is being built for the Win64 platform, not UWP32 or UWP64. That would explain why the reference to the required winmd isn't automatically present. Do you have a 'WhitelistPlatforms' entry for your plugin module that restricts it to UWP32/UWP64 only?

                          Comment


                            I have added a WhitelistPlatforms entry to whitelist "UWP32" and "UWP64" in my plugin's .uplugin file and rebuilt the module, but I'm still running into the error.

                            If I enclose the 'using namespace ...' line in a "#if PLATFORM_UWP ... #endif" block, it will build in VS2015, however I run into the same error(s) when packaging.

                            I'm currently rebuilding everything (mainly because of superstition), I'll let you know if the issue resolves itself.

                            How might I go about adding the winmd reference manually in the meantime? Thanks again! You're my hero [MENTION=494622]jsyarrow[/MENTION]

                            Update: my superstition didn't pay off. It is behaving the same. With the Whitelist entry added, we see that the plugin is now being built for UWP:


                            MainFrameActions: Packaging (UWP (x86-32bit)): UnrealBuildTool: C:\Users\Adasi\Documents\Unreal Projects\HoloTest\Plugins\AdasiEmptyPlugin\Source\AdasiEmptyPlugin\Private\AdasiEmptyPluginRender.cpp(21): error C2871: 'Holographic': a namespace with this name does not exist
                            MainFrameActions: Packaging (UWP (x86-32bit)): UnrealBuildTool: ERROR: UBT ERROR: Failed to produce item: C:\Users\Adasi\Documents\Unreal Projects\HoloTest\Binaries\UWP32\HoloTest.pdb
                            Last edited by Adasi; 12-08-2016, 05:28 PM.

                            Comment


                              PublicWinMDReferences wants the path to the winmd file. For APIs that are part of the Windows 10 SDK there's a helper function that'll get you the path to the latest version based on the contract name. So something like:

                              Code:
                              PublicWinMDReferences.Add(VCEnvironment.GetLatestMetadataPathForApiContract("Windows.Foundation.UniversalApiContract"));
                              It's only relevant for UWP targets though, so you'll still need to make sure that nothing's trying to build your plugin for Windows desktop.

                              Comment


                                I'm a bit busy with a project at work, so I haven't been able to work on the ARM build for the past weeks, but I'd like to give an update on how it's going.

                                I got past all the problems involving 3rd party libraries and the engine now initializes to the point where it's writing logs and config files on the devices (and proper crash dumps, which is a godsend).

                                As expected, it crashes when trying to initialize the D3D11 device, since most (all?) UWP ARM devices only support feature level 9.3 and UE4 requires 10.0 minimum. I cleared up a bunch of incompatibilities (thanks to the D3D debug device and looking at what is/isn't enabled in the GL ES 2.0 renderer), but there are a bunch of shaders that still fail to compile under FL_9_3 even when targeting PCD3D_ES2.

                                However, I'm trying to run the editor under FL9_3 so I suspect some shaders that would never be in a mobile build are being compiled and they don't respect the instruction limits of ES2, even under mobile preview (since mobile preview uses either D3D10+ or OpenGL3+).

                                Comment

                                Working...
                                X