[WIP] WinRT port

[MoeMod]

Related PRs

FWGS/hlsdk-portable#114
FWGS/mainui_cpp#29
FWGS/gl-wes-v2#2

Build

FWGS/hlsdk-xash3d => hlsdk/
extras.pak => msvc/extras.pak
SDL2-2.0.10 => SDL2/
Build msvc/xash3d-winrt.sln with Visual Studio 2019 v142

[mittorn]

sln project missing (maybe it in .gitignore?)
If it possible to use waf/msvc (it currently only supports desktop and phone apps), use it because nobody will update project on every file list change

[a1batross]

Instead of just defining XASH_WINRT everywhere, define it as 1 in build.h, so macro checking will be a lot eaiser:
#if XASH_WINRT // instead of long defined( XASH_WINRT )

As well as checking XASH_WIN32:
#if XASH_WIN32 // instead of defined( _WIN32 )

[MoeMod]

sln project missing (maybe it in .gitignore?)
If it possible to use waf/msvc (it currently only supports desktop and phone apps), use it because nobody will update project on every file list change

I don't know whether the waf or even cmake supports winrt builds for msvc. In every project there should be a .cpp compiled with /ZW to force creating .winmd files. And the linker only deploys DLLs referenced with .winmd files.

Instead of just defining XASH_WINRT everywhere, define it as 1 in build.h, so macro checking will be a lot eaiser:
#if XASH_WINRT // instead of long defined( XASH_WINRT )

As well as checking XASH_WIN32:
#if XASH_WIN32 // instead of defined( _WIN32 )

I checked and found build.h is only referenced by engine, but not hlsdk/mainui. Adding #include "build.h" may destroy builds on other platforms.

[MoeMod]

In winrt builds, _WIN32 and _WIN64 are always defined. Checking winrt requires winapifamily.h which may not be included in legacy Windows SDKs.
Maybe we should make a new marco XASH_WIN32_DESKTOP = (XASH_WIN32 && !XASH_WINRT) ?

[mittorn]

waf adds /ZW for winphone and winapp targets:
https://gitlab.com/ita1024/waf/blob/master/waflib/Tools/msvc.py

[MoeMod]

Some extra problems:

1. Should we treat UWP as a mobile platform? It restricts background running anyway.
2. UWP apps runs on both x86 and arm, both 32bit and 64bit. I have only tested amd64 build.
3. where and how to store game resources.

[mittorn]

1. It is impossible to run dedicated server (it will be unuseful without background execution), and uwm is similar to android
2. maybe need test uwp x86 because it may use stdcall or have some sse-related bugs, but do we really need uwp/x86 targets if we have win32/x86 and all mods use it?
3. Does UWP allow loading zip file or package? Or just some single external file? Engine supports zips, it may be used

[mittorn]

And biggest trouble: how to specify command line? On ios i used dialog box with input field and text fike for earlier ios (because it crashed on dialog creation). On android there is java launcher., but engine still does not have cross-platform launcher

[a1batross]

1. Yes, UWP mainly used for mobile phones(though they are dead now) and less on PCs. I think we can think of it as a mobile platform.

2. Yeah, they should be built for any possible combinations, except uwp-x86, it's kinda useless as mittorn said.

3. Is UWP actually supports access to external filesystems? If yes, then we can use it.

I checked and found build.h is only referenced by engine, but not hlsdk/mainui. Adding #include "build.h" may destroy builds on other platforms.

I suppose you're doing something wrong then. Both mainui_cpp and hlsdk-xash3d are meant to be crossplatform by minimizing the platform-specific code. I've seen your PR to both mainui_cpp and hlsdk and... it's not something that user DLLs should solve. I've accepted that one change for mainui_cpp, but HLSDK is something that we gonna discuss.

If SDL2 fails to handle the input for WinRT, then you can add a WinRT specific input in engine instead and use our input extension

Also, if you're gonna to maintain the WinRT port, once it will be shaped, I require that every port we have is built through Waf and Travis CI is set up to always build latest version. It may sound as additional work for you, but in fact it minimizes your and everyone's else headache. We will knew which commit has broken the winrt support and if engine will be refactored or new files will be added, no standalone MSVS project will be required to update. We dropped Android.mk, CMakeLists, Makefiles because of this. It's physically hard to maintain multiple buildsystems.

[MoeMod]

And biggest trouble: how to specify command line? On ios i used dialog box with input field and text fike for earlier ios (because it crashed on dialog creation). On android there is java launcher., but engine still does not have cross-platform launcher

We cannot draw SDL window in an XAML control. I found that SDL uses SwapChainBackgroundPanel, but SwapChainBackgroundPanel must be the root and no more controls can be added.
Maybe we can create another XAML-based UWP app and uses URI to launch engine app?

Is UWP actually supports access to external filesystems? If yes, then we can use it.

Actually it can because there are some UWP file explorers in the Windows Store. However it looks like that this capability is only available in newer Windows 10 versions (maybe 17134 or later?).
I think that our app should at lease run on 14393, or even 10210.
Right now the resource path is printed on the error message box like this:

[mittorn]

I think, it must be possible to "send" zip archive to UWP app

[a1batross]

Maybe don't use SDL for UWP port then?

We don't use SDL for Android port already because it just suck.

[MoeMod]

I think that only pro users may change command line, while others just leave it default.
Why not place it into a file for those who wants to change it?

[mittorn]

It is unuseful without public filesystem. I used file with cmdline on ios6 because running on ios6 without jailbreak is impossible

[mittorn]

About idea with URI: is it secure? If this allows ay web page open this URI, it maybe dangerous (for example, Android has flag that forbids launching from browser)

[MoeMod]

It seems that the app can have full access to a folder selected by Windows.Storage.Pickers.FolderPicker.
https://docs.microsoft.com/en-us/windows/uwp/files/quickstart-using-file-and-folder-pickers
Another approach is to access user's Document/xash3d folder by Windows.Storage.KnownFolders which requires Documents Library capability.
https://docs.microsoft.com/en-us/uwp/api/windows.storage.knownfolders.documentslibrary

[MoeMod]

It seems that the app can have full access to a folder selected by Windows.Storage.Pickers.FolderPicker.

Tested but the FolderPicker shows and doesn't respond to any input. Maybe some random SDL2 take over it and await sucks.

Another approach is to access user's Document/xash3d folder by Windows.Storage.KnownFolders which requires Documents Library capability.

Always ACCESS DENIED

My current solution is to open the app local path with explorer.exe . It should be user-friendly enough.

[mittorn]

Will it work on windows 10 mobile?

[a1batross]

Also, I suppose WinRT doesn't support loading libraries from filesystem at all, so there absolutely shouldn't be an extension on library naming?

[a1batross]

While doing #88, I thought that instead of this "_WIN32 && !_WINRT" we can NOT define XASH_WIN32 for WinRT targets(although WinRT supports limited Win32 API) and add instead XASH_WINRT macro.

[MoeMod]

Sorry for my late reply.

Will it work on windows 10 mobile?

I don't have windows 10 phones for testing, so... IDK

Also, I suppose WinRT doesn't support loading libraries from filesystem at all, so there absolutely shouldn't be an extension on library naming?

Maybe we can build all mods into the app just like the previous iOS port.

While doing #88, I thought that instead of this "_WIN32 && !_WINRT" we can NOT define XASH_WIN32 for WinRT targets(although WinRT supports limited Win32 API) and add instead XASH_WINRT macro.

How about #define XASH_WINDOWS (XASH_WIN32 || XASH_WINRT) ?
Further more, there should be XASH_WINRT_DESKTOP and XASH_WINRT_MOBILE for windows 10 mobile if supported.

[a1batross]

How about #define XASH_WINDOWS (XASH_WIN32 || XASH_WINRT) ?

Yep. Good idea.

Further more, there should be XASH_WINRT_DESKTOP and XASH_WINRT_MOBILE for windows 10 mobile if supported.

If you want to support them, then ok.

[ghost]

If this PR is completed someday, Xash3D should also run just fine on Xbox One/Series consoles (when deployed via dev mode), as well as natively on Windows 10X (without the use of VAIL or RAIL).

[MoeMod]

csmoe will drop supporting for UWP due to lack of users, so I am closing this.

[a1batross]

Sad. UWP port would be useful for XBox One/Series but I don't have such hardware (and I don't know who does).

…

On Sat, Apr 17, 2021, 3:02 PM Moemod Hymei⭐ ***@***.***> wrote: Closed #86 <#86>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#86 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYQTANBB4Y2FM23MX3OHODTJF2FVANCNFSM4JOQOI7Q> .