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


  • replied
    Originally posted by manoelneto View Post
    Are you sure it's connecting? AFAIK UWP apps cannot access localhost by default, you need to setup an exception for specific apps: https://msdn.microsoft.com/en-us/lib.../dn640582.aspx
    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.

    Originally posted by Zelex View Post
    I made a whole new blank project, set it up, works 100% when launching from the editor, I run the cook server, Press F5 from the debugger, game connects to the cook server and streams some stuff, then a totally black screen.
    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.

    Leave a comment:


  • replied
    yup logs show it connecting and transferring stuff.

    Leave a comment:

Working...
X