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
    Originally posted by gfoot View Post
    Does anybody have any pointers for integrating the Xbox Live libraries here? It feels like the regular way (using nuget packages, or project references in the solution) is not going to work with Unreal's build system, so we'll need to explicitly link in the static libraries and reference the headers.

    It looks like the project code is built with C++/CX enabled when targeting UWP, but obviously this doesn't work in the editor, so it feels like some ifdefs will be needed too. Alternatively I'm considering separating the C++/CX code into a separate library, and keeping it quite separate from the Unreal interfacing code. I'd be interested to hear how others have got on with this.
    For Xbox Live support see the note at the bottom of the GitHub readme.  You'll need to be in the ID@XBOX program to access Live.

    As for C++/CX in the editor you ought to be able to hide this in pre-built binaries easily enough. Another approach, requiring some additional modifications to UBT, would be to just allow its use in Win32/Win64 builds. The work to do this in UWP builds should port across fairly easily.

    Leave a comment:


  • replied
    Does anybody have any pointers for integrating the Xbox Live libraries here? It feels like the regular way (using nuget packages, or project references in the solution) is not going to work with Unreal's build system, so we'll need to explicitly link in the static libraries and reference the headers.

    It looks like the project code is built with C++/CX enabled when targeting UWP, but obviously this doesn't work in the editor, so it feels like some ifdefs will be needed too. Alternatively I'm considering separating the C++/CX code into a separate library, and keeping it quite separate from the Unreal interfacing code. I'd be interested to hear how others have got on with this.

    Leave a comment:


  • replied
    Originally posted by manoelneto View Post
    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+).
    Could you tell me what I must do to add ARM support (theoretically) or give link to your working copy. I want try work with ARM in my free time. But I don't understand what I must add to unreal building tool to start building for ARM.

    Leave a comment:


  • replied
    Hello everyone !

    Since several hours I'm trying to build an empty UWP app on Xbox One but now I have an error when I tried to deploy it on the xbox by the Xbox Device Manager.

    The error : Failure reason: Failed to start deployment. Failure text: Package could not be registered. (0x80073cf6)

    Do you know how to fix it ?

    Thank you in advance !

    Leave a comment:


  • replied
    Originally posted by gfoot View Post
    I can't find any option in the editor to keep the cook server running all the time - the only reference I can find in the UI is that it starts up the cook-on-the-fly server when launching on device. Do you know a better way to get the cook server running?
    I'm not aware of editor UI that just starts the cook server and does nothing else. But there's a great deal I don't know about the editor . I typically just kick it off from a command line (ue4editor <project> -run=cook -cookonthefly).

    Is it practical to get this content deployed automatically, or perhaps hard-link it in, as part of the regular build process?
    I'm not very happy with this either. The trouble is that the content may be very large indeed, and it would need copying (UWP won't follow any kind of link to a location outside its package).  I think the best would be to expose it as an option to the user, but then there isn't a very good home for it - the project launcher UI doesn't seem to support platform-specific customizations, so it would probably end up in the project settings.

    Indeed! It's tempting to start something, at least with key information from this thread, for later refinement.
    Please do!  We'd love to see more community involvement in the project.

    Leave a comment:


  • replied
    Hi Adasi and jsyarrow

    I have just ordered a Hololense and am very interested in what you guys are working on. I am a big UE4 user for both Oculus Rift and HTC Vive and was disappointed to hear that UE4 does not officially support Hololense. Your work here gives me hope. Will you be making a plugin that will expose all the relevant functionality to blueprints? If so get ready to take my money

    Leave a comment:


  • replied
    Originally posted by jsyarrow View Post
    To run from VS you need to get content files into a location where the temporary deployment can read them. This can't be the standard UE directories since the UWP sandbox prevents access. Typically this means running an editor build to do cook-on-the-fly, and then pointing the UWP app at it to stream the content. To do so, you need to set some 'command line' parameters, which for UWP means dropping a UE4CommandLine.txt in your Binaries/UWPxx folder (this should automatically get copied into Binaries/UWPxx/AppX during deployment).
    Thanks for this, it was very helpful.

    You can also borrow the instance of the cook server that the editor spins up in order to provide the content.
    I can't find any option in the editor to keep the cook server running all the time - the only reference I can find in the UI is that it starts up the cook-on-the-fly server when launching on device. Do you know a better way to get the cook server running?

    Alternatively you can pre-cook everything offline and then manually copy your cooked content into the Binaries/UWPxx/AppX location.
    Is it practical to get this content deployed automatically, or perhaps hard-link it in, as part of the regular build process?

    All this is a good reminder that we still need a FAQ posted to GitHub.
    Indeed! It's tempting to start something, at least with key information from this thread, for later refinement.

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:

Working...
X