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 jsyarrow View Post
    I think the trouble with using ProjectDisplayedTitle is that it's an FText, not FString, which the build tools don't properly understand so you may still get an incorrect value.
    Yes, that may be an issue. I believe though that the values are pulled from the INI file, which the change above uses. I'm not stating that as fact, just surmising.

    [EDIT 2017.05.16 @ 3:26PM MST]
    That was funny, I saw the effects of using the FName field in the manifest. It had the namespace localization macro as part of it:

    Code:
    NSLOCTEXT("[/Script/EngineSettings]", "0E530AFC44260274FBA09C8EC0BDCCA1", "Longshot Hero")
    Well, at least there is a workaround


    [EDIT 2017.05.16 @ 7:52PM MST]
    After I reverted my changes and used the original source from GitHub, my build and upload to the Windows Store worked. Again, for anyone else that may stumble on this problem:

    Add XXXXX.GameName to the reserved names under App Management :: Manage App Names
    Last edited by Jerry.Richards; 05-16-2017, 09:57 PM.

    Comment


      I'm still waiting on approval for the XboxLive Creators Program. I'm a little confused though because under my Account Settings I have an Xbox One Developer console. It seems odd to have access to development on the Xbox but not the Live Services. Is that for local testing only then? Shoot (pun intended), XNA Creators Club had access to some form of the Live Services, if I remember correctly.

      Comment


        Alright, new batch of changes just went in. Relevant to active issues in this thread:
        - The package DisplayName, PublisherDisplayName and Description are now bound to localized strings. These can be authored in resw files located in [Game]\Build\UWP\[culture]\resources.resw. Building and deploying will automatically generate stubs for you if these files don't already exist. You can then open them up and adjust the string values to match your Store display name etc. in your various territories. It's a little clunky that you can't just use UE's localization system and formats, but it should help for now.
        - There are a couple of new settings in the UWP platform settings menu. One in particular flags the title as using Xbox Live via the Creators Program, per my proposal earlier in the thread. Another allows you to set the compiler version used for your project independently of the IDE (and is the only way to control the compiler used when building via the Editor) - it's the same as the compiler version setting on the Windows platform page.

        A reminder on the Xbox Live Creators Program: you still need to be accepted into the program for the new setting to have any effect. Again, the need for acceptance is temporary to the early stages of program rollout. And if you have access to Live already through a different program (e.g. ID@Xbox) you should not enable this setting.

        Comment


          For debugging, what build configuration do you use for UWP?

          Normally I use DebugGame Editor for the Win64 Platform, and it works well. I noticed that twenty-five projects are skipped for Debug Editor, and DebugGame Editor for UWP64. Also, the actual game project isn't included in the build or deploy. What is the correct choice?

          [EDIT]
          Debug appears to be working. . .

          Now I understand the issue of COOKED and UNCOOKED. I have to resolve it though.

          Are we still able to modify our game in the Editor while debugging with Visual Studio?
          Last edited by Jerry.Richards; 05-17-2017, 05:52 PM.

          Comment


            For the Cook on the Fly issue I setup a shortcut to the UWP UE Editor, then modified the Target to load my project with the needed switch:

            Click image for larger version

Name:	CookOnTheFlyShortcut.jpg
Views:	1
Size:	65.5 KB
ID:	1128191

            Code:
            E:\UEUWP\MICROSOFT_UWP_UNREAL\Engine\Binaries\Win64\UE4Editor.exe \MyDir\UWPSource\MyProject.uproject -run=cook -cookonthefly
            A few log messages later the console output stops at:

            Click image for larger version

Name:	CookOnTheFlyServer.jpg
Views:	1
Size:	93.5 KB
ID:	1128190

            And from Visual Studio, with Debug UWP64 built, pressed F5 and my game executed properly.
            Last edited by Jerry.Richards; 05-17-2017, 05:57 PM.

            Comment


              Visual Studio isn't honoring my breakpoints for: Debug, DebugGame, . . .

              Comment


                Originally posted by Jerry.Richards View Post
                Visual Studio isn't honoring my breakpoints for: Debug, DebugGame, . . .
                You probably need to manually point VS at the pdb file. It doesn't get copied into the temporary layout used for running under the debugger (we skip it because tends to be a large file), so it's not automatically located adjacent to the exe. This is a one-time thing - after you've done it VS will remember the association.

                Open up debug->windows->modules, locate your exe (probably at the top), right-click and hit load symbols, then locate your pdb (in [Game]\Binaries\UWP64).

                Comment


                  Originally posted by jsyarrow View Post
                  Alright, new batch of changes just went in. Relevant to active issues in this thread:
                  - The package DisplayName, PublisherDisplayName and Description are now bound to localized strings.

                  - There are a couple of new settings in the UWP platform settings menu. One in particular flags the title as using Xbox Live via the Creators Program, per my proposal earlier in the thread. Another allows you to set the compiler version used for your project independently of the IDE (and is the only way to control the compiler used when building via the Editor) - it's the same as the compiler version setting on the Windows platform page.

                  A reminder on the Xbox Live Creators Program: you still need to be accepted into the program for the new setting to have any effect. Again, the need for acceptance is temporary to the early stages of program rollout. And if you have access to Live already through a different program (e.g. ID@Xbox) you should not enable this setting.

                  Thank you James.

                  Comment


                    I just got approval of Xbox Live Services

                    I'm doing some cleanup on my UI now and should finish no later than tomorrow. Afterwards, I'll start the XboxLive integration and can provide updates to anyone that may be interested.

                    Should I stay in this thread or start another one?

                    Comment


                      This may be a dumb question: can we access other UWP API's, particularly the UI:

                      https://docs.microsoft.com/en-us/win...rial-resources
                      https://developer.microsoft.com/en-u...ws/apps/design
                      https://docs.microsoft.com/en-us/win...user-interface

                      Comment


                        Originally posted by Jerry.Richards View Post
                        The build system is set up so that you have access to APIs for which the 'API Contract' is listed as 'Windows.Foundation.UniversalApiContract' anywhere in C++ code. APIs under Windows.UI.XAML, however, will mostly not work, even though they're in the universal contract, because we don't create the UE game window as a XAML window. While there are docs out there that discuss overlaying XAML UI on a DirectX panel, that's not the approach I'd typically recommend to games - instead I'd encourage you to draw your UI as you always have, to your game's swap chain. That way you don't have to go relearn how to get the perf and look you're after, and it's much easier to ship multiplatform.

                        UI APIs that pop external windows are typically not part of the XAML space and, per above, will work. The ones games are most likely to need (notably message box, and Xbox Live UI) should be wrapped with UE interfaces (e.g. FPlatformMisc::MessageBoxExt, methods of IOnlineExternalUI) again to facilitate multiplatform dev. But if you do need to add something more, say a FilePicker for some reason, you can. Be careful to only interact with Windows UI from the main game thread though, otherwise you'll hit exceptions from violating the UWP threading model.

                        If you need to use a WinRT API outside the universal contract you can do that too! But you'll need to add a reference to the contract from the build.cs file of the module where you wish to use it.

                        Code:
                        		string StorageApiMetadata = VCEnvironment.GetLatestMetadataPathForApiContract("Windows.Gaming.XboxLive.StorageApiContract");
                        		if (!string.IsNullOrEmpty(StorageApiMetadata))
                        		{
                        			PrivateWinMDReferences.Add(StorageApiMetadata);
                        		}

                        Comment


                          Originally posted by jsyarrow View Post
                          Alright, new batch of changes just went in. Relevant to active issues in this thread:
                          - The package DisplayName, PublisherDisplayName and Description are now bound to localized strings. These can be authored in resw files located in [Game]\Build\UWP\[culture]\resources.resw. Building and deploying will automatically generate stubs for you if these files don't already exist. You can then open them up and adjust the string values to match your Store display name etc. in your various territories. It's a little clunky that you can't just use UE's localization system and formats, but it should help for now.
                          - There are a couple of new settings in the UWP platform settings menu. One in particular flags the title as using Xbox Live via the Creators Program, per my proposal earlier in the thread. Another allows you to set the compiler version used for your project independently of the IDE (and is the only way to control the compiler used when building via the Editor) - it's the same as the compiler version setting on the Windows platform page.
                          Okay, I can see everything that you mentioned, and it makes sense. But I am running into a problem with the manifest in that ms-resource:ProjectName, ms-resource:CompanyName, and ms-resource.Description are the final results in the fields:

                          Click image for larger version

Name:	NewManifest.jpg
Views:	1
Size:	153.3 KB
ID:	1128307


                          Am I doing something wrong?

                          A note: I can confirm that the resource.resw was created for each supported language.

                          Comment


                            That looks right to me!

                            The ms-resource:<resource key> syntax indicates to the system that the value needs to be looked up at runtime from the compiled package resources (this is the resources.pri file, generated by the makepri.exe step in the build process). If you run the packaging step now to create an appx, and then double-click that to install, you should see the strings you entered into your resw files, selected based on the current OS language/locale settings.

                            Comment


                              Originally posted by jsyarrow View Post
                              If you run the packaging step now to create an appx, and then double-click that to install, you should see the strings you entered into your resw files, selected based on the current OS language/locale settings.
                              The APPX, and its manifest, were generated from the UE4 Editor package command (File->Package). Both contain what I provided above.

                              If I understand you correctly I should delete the existing APPX file, and regenerate it again with the makeappx command. Is that correct?

                              Comment


                                Originally posted by Jerry.Richards View Post
                                The APPX, and its manifest, were generated from the UE4 Editor package command (File->Package). Both contain what I provided above.

                                If I understand you correctly I should delete the existing APPX file, and regenerate it again with the makeappx command. Is that correct?
                                The final manifest should look just like what you provided. What do you see in the appx installer UI when you double-click the appx that the Editor package command generated for you?

                                Comment

                                Working...
                                X