Всем привет!
Давно хотел собрать INSTEAD для Windows Phone, и, наконец, что-то начало получаться.
http://nlbproject.com/dist/instead-win.zip
Проект открывать через Visual Studio 2015, может, можно и более поздней версией.
Солюшен в папке instead/VisualC-WinRT/WinPhone81_VS2015/instead/instead.sln
В папке instead свежесклонированная версия instead, которую я слегка пропатчил.
В данный момент сборка базируется на _WIN32_WCE, но надо будет переделать с новым ключом. Есть также некоторые недоделки.
Самая существенная недоделка в том, что игры пока не запускаются :) INSTEAD запускается, можно лазить в меню настроек, менять язык. Но игры из папки games не считываются.
По поводу папок INSTEAD (games, lang, themes, ...): они лежат в instead/VisualC-WinRT/WinPhone81_VS2015/instead/Debug/instead.Windows/AppX
argv почему-то передаётся как NULL, поэтому я подменяю argv[0] на ".". Кстати, в WinRT какая-то проблема с правами доступа, при открытии произвольного пути типа "C:\\Downloads\\" возникает ошибка.
Для сборки понадобились кое-какие файлы, скачанные где-то в Интернете. Они лежат в instead/VisualC-WinRT/WinPhone81_VS2015/instead/instead/instead.Shared
dirent.h слегка подправлен, другие, кажется, не менял, или почти не менял :)
В солюшене два проекта: instead.Windows и instead.WindowsPhone. Этот тип проекта рассчитан на создание универсального приложения для Win 8.1, но я пока мучал только десктопную версию.
В проекте instead.Windows только один cpp файл, winrt_main.cpp, запускалка. В проект для instead.WindowsPhone надо будет добавить какой-то аналогичный.
Файлы для libiconv в папке есть, но в проекте его поддержку пока не включал.
Запускать из Visual Studio по CTRL+F5, т.к. при запуске с дебаггером окно приложения через какое-то время отваливается. Не знаю точно, баг это или фича.
При попытке запустить собранный exe-шник возникает сообщение "Это приложение может работать только в контексте контейнера приложения". Наверно, для WinRT это норма.
Если есть опытные Windows-разработчики, то их помощь будет очень кстати. Если получится осилить сборку таких приложений, то можно будет размещать Инстед-игры в Windows Store. Ну и вообще, это круто :)

Проверь в отладчике, что находится в game_cwd, после инициализации?
Это когда из argv[0] получаем текущий путь. Это в instead_main непосредственно перед setdir() вызовом...

Обновил http://nlbproject.com/dist/instead-win.zip
См. патч внутри: instead/instead-win.patch
Объяснение некоторых моментов патча:

-static inline int game_cycle(void)
+static __inline int game_cycle(void)
компилятор ругался на слово inline. Погуглив, узнал, что для C-кода нужно использовать __inline
см. https://msdn.microsoft.com/ru-ru/library/bw1hbe6y.aspx
Ключевое слово inline доступно только в C++. Ключевые слова __inline и __forceinline доступны как в C, так и в C++.
Если другими компиляторами соберётся так, наверно, можно оставить так. Если нет, можно сделать #define. Причём, это дефайн не только на WinRT, а на компиляцию с помощью Visual Studio в целом.

-<-----><------>pixels += pitch * queue_y1 + queue_x1 * psize;
+<-----><------>pixels = ((char*) pixels) + pitch * queue_y1 + queue_x1 * psize;
Компилятор ругался на то, что к указателю типа void* неприменима операция +=

- #define errno 0
- #define strerror(a) ""
+ ///#define errno 0
+ ///#define strerror(a) ""
#define putenv(a) ;
- #define setlocale(a, b) ;
+ ///#define setlocale(a, b) ;
errno, strerror, setlocale оказались определены и эти дефайны вызывали ошибку компиляции

-#include <dir.h>
+///#include <dir.h>
компилятор не смог найти этот инклюд

char *dirpath(const char *path)
{
<----->static char fp[PATH_MAX * 4];
-<----->if (path[0] == '/')
+<----->if (path[0] == '/' || path[1] == ':')

Абсолютный путь начинался с C:, добавил проверку на символ :, чтобы отследить эту ситуацию.

/// Antokolos: dirname & basename copied from S60 above
Линкер сказал о ненайденных символах dirname и basename, скопировал их реализацию из S60, вроде сработало

-<----->libwince_init(argv[0], 1);
-<----->wince_init(argv[0]);
+<----->///libwince_init(argv[0], 1);
+<----->//setdir("./");
+<----->//strcpy(game_cwd, "./");
+<----->//wince_init(argv[0]);
+<----->unix_path(argv[0]);
+<----->strcpy(game_cwd, argv[0]);
тут надо ещё посмотреть, возможно, можно использовать wince_init и в исходном виде. libwince_init вроде не нужна

-<-----><------><------>FREE(opt_lang); opt_lang = strdup(langs[i].file);
+<-----><------><------>/// Antokolos: for some strange reason, this FREE call triggers a breakpoint in MSVCPP :(
+<-----><------><------>///FREE(opt_lang);
+<-----><------><------>opt_lang = strdup(langs[i].file);
тут вот действительно странно, но на этом вызове FREE происходит вылет, отладчик страшно ругается про Exception Thrown.
Проблема в том, что этот FREE ещё много где встречается, просто пока повезло на него не напороться

-#include <dir.h>
+///#include <dir.h>
+#include "unistd.h"
dir.h компилятор не нашёл, в unistd.h были какие-то из неопределённых символов

-<----->if (!GetLocaleInfoA(LOCALE_USER_DEFAULT, LOCALE_SISO639LANGNAME,
+<----->/// Antokolos: Note LOCALE_NAME_USER_DEFAULT instead of LOCALE_USER_DEFAULT
+<----->if (!GetLocaleInfoEx(LOCALE_NAME_USER_DEFAULT, LOCALE_SISO639LANGNAME,
GetLocalInfoA не нашёл линкер. Загуглил, что нужно использовать GetLocaleInfoEx. Оказалось, что правда. Однако, результат выполнения функции "r" вместо "ru". Поэтому пока захардкодил в "en", а по хорошему надо разобраться...

char *game_tmp_path(void)
{
+<----->return "/tmp";
пока так, ибо текущий код не проходит линковку. Было бы здорово, если бы можно было передавать темп. папку через командную строку INSTEAD, я смогу это сделать из winrt_main.cpp.

Про то, что ещё есть в проекте:

instead/VisualC-WinRT/WinPhone81_VS2015/instead/instead/instead.Shared
тут дополнительные h и c файлы, без которых не собиралось, немного пропатченные. Кроме того, тут есть папки games, lang, stead, themes из INSTEAD, но это я, думаю, уберу, включив их в проект непосредственно из кода INSTEAD. Они копируются в папку собранного приложения как ресурсы.

instead/VisualC-WinRT/WinPhone81_VS2015/instead/instead/instead.Windows
instead/VisualC-WinRT/WinPhone81_VS2015/instead/instead/instead.WindowsPhone

папки подпроектов для Windows и WindowsPhone. Пока рабочий только Windows. Тут же winrt_main.cpp для запуска. На всякий случай, включил свою копию в каждый из проектов.

instead/VisualC-WinRT/WinPhone81_VS2015
Тут подпроекты для lua52 и libiconv. Возможно, их нужно вынести на уровень выше. И возможно, сделав нормальный Visual Studio проект для libiconv. Для lua52 такой уже есть, правда, для Windows 8.1, а не для WindowsPhone 8.1

Что ещё добавим:
в папку instead/VisualC-WinRT добавлю подпапку с проектом UWP_VS2015. Это та самая Universal Windows Platform, которая Windows 10. Можно посмотреть в исходниках SDL, как у них сделано.

ещё можно добавить instead/VisualC, чтобы собирать обычный INSTEAD компилятором Visual Studio. В SDL соответствующий проект есть.

Сейчас главная проблема в баге с мышью, про который я говорил. После запуска мышь в окне не двигается. Сворачиваем окно, разворачиваем мышью, после этого она скачком переходит в центр и опять не двигается. Если повторить сворачивание-разворачивание окна, то всё налаживается. Туториал пока что играется нормально, других проблем не нашёл.
Ну и общая неопрятность кода, что я сотворил, конечно.

Кое что пушнул:
inline заменил на __inline
void * -> char * тоже
FREE(opt_lang) -- вероятно какой то баг в первичном присвоении opt_lang, там определяется язык по локали, и делается strdup.

Про tmp -- просто давай выберем какой должен быть путь для winrt и его введем в winrt.c

Насчет локали, дело в том, что Ex функция насколько я понимаю возвращает wchar строку, а не char.
То-есть эту строку надо потом сконвертить в обычную строку char. А wchar это и есть 'r', 0, 0, 0, 'u', 0, 0, 0 -- вот ты и увидел 'r'

Обновил http://nlbproject.com/dist/instead-win.zip
Теперь Инстед запускается на Windows Phone мобиле, т.е. второй проект тоже рабочий! Кроме того, выделил все доп. библиотеки типа lua, iconv в отдельные подпроекты. В будущем их можно будет использовать в других проектах Visual Studio.
Но все эти проекты в основной репозиторий коммитить пока ещё не стоит, работа пока не закончена...
Кроме того, вытянул из git те изменения, которые ты пушнул и снова пропатчил в необходимых местах, патч instead-win.patch в архиве.

Peter> Насчет локали, дело в том, что Ex функция насколько я понимаю возвращает wchar строку, а не char.
Peter> То-есть эту строку надо потом сконвертить в обычную строку char. А wchar это и есть 'r', 0, 0, 0, 'u', 0, 0, 0 -- вот ты и увидел 'r'
Так и есть, исправил это место, теперь корректно возвращает "ru"

Peter> inline заменил на __inline
В одном файлике забыл :) См. в патче

Peter> Про tmp -- просто давай выберем какой должен быть путь для winrt и его введем в winrt.c
Гуглил по запросу "общая temp папка в WinRT", но что-то ничего не нашёл... Возможно её и нет, там что-то было про права доступа WinRT приложений, и они ограничены.
Я таки сделал параметр tmppath, погляди, пожалуйста. Если одобришь, то так проще всего. Там есть код для получения темповой папки, доступной приложению, но он на C++, и я не знаю, как его вкорячить в C.
См. в VisualC-WinRT/WinPhone81_VS2015/instead/instead/instead.Windows/winrt_main.cpp, что я передаю в этот tmppath.

Вообще по коду: я могу попробовать начать менять сам, вводить дефайны итд. Просто как тебе потом проще будет, разбираться в моём коде или написать самому :)
Если что, это всё не горит, конечно, я могу пока попробовать UWP скомпилить или ещё что-нибудь. Например, сделать сборку Windows-версии Инстеда через Visual Studio.

> В одном файлике забыл :) См. в патче
Ага, еще раз пушнул.
> См. в VisualC-WinRT/WinPhone81_VS2015/instead/instead/instead.Windows/winrt_main.cpp, что я передаю в этот tmppath.
Ты можешь оформить эту свою функцию как extern "C" { и вызывать из самого инстеда в принципе....

>Гуглил по запросу "общая temp папка в WinRT", но что-то ничего не нашёл... Возможно её и нет

https://stackoverflow.com/questions/32099821/equivalent-of-the-gettemppath-on-windows-phone

Второе сообщение по ссылке, вроде оно...

Просто делаем winrt.cpp наряду с winrt.c и в нем все что надо на cpp, а из C вызываем это все как extern "C"...
Примерно как сделано с symbian.cpp

> Вообще по коду: я могу попробовать начать менять сам, вводить дефайны итд. Просто как тебе потом проще будет, разбираться в моём коде или написать самому :)

Имхо на данном этапе нужно посмотреть что там с ротацией. Включить код для поворотов экрана и посмотреть на люмии -- все ли ок.
А так -- любой вариант норм. Мне в слепую сложновато делать патч, но думаю по твоим наработкам это будет не сложно.

Начал коммитить вот в эту ветку: https://github.com/Antokolos/instead/tree/winrt
Надеюсь, так будет легче делать патчи.
добавил winrt.c, winrt.h, попытался сделать дефайн _WINRT
Как будто бы пока всё запускается, но баги с мышью и ориентацией пока не фиксил

> Начал коммитить вот в эту ветку: https://github.com/Antokolos/instead/tree/winrt
> Надеюсь, так будет легче делать патчи.

Ага! Здорово! Только, наверное, стоит себя в заголовки winrt.c вписать. Ну и быть не против, что код, написанный тобой, будет под MIT. =)

>> Начал коммитить вот в эту ветку: https://github.com/Antokolos/instead/tree/winrt
>> Надеюсь, так будет легче делать патчи.

Peter> Ага! Здорово! Только, наверное, стоит себя в заголовки winrt.c вписать. Ну и быть не против, что код, написанный тобой, будет под MIT. =)
Не против, конечно! Сделаю.

По поводу кода для поворотов. Искать по #if defined(IOS) || defined(ANDROID) ?
Он в каком-то конкретном месте или надо во все такие места засунуть дополнительный дефайн?

Последние новости с полей: код для поворотов почти работает. По крайней мере, удалось увидеть нормальную картинку в Landscape-режиме.
Напомни-ка, пожалста, что мы передаём в параметр modes?
-modes w1xh1,w2xh2

где w1,h1 -- w, h для портретного режима,
w2,h2 -- w, h для landscape

так, или как-то по другому?
пока что, если включён -hires, то всё круто. Если -nohires, то при повороте в лэндскейп получается маленький участок в центре. Что-то такое точно было на Андроиде.
Код в свою ветку пушнул.

Вроде бы в modes мы просто передаем допустимые разрешения. Если sdl работает корректно, то это не обязательно. А так мы типа сами говорим что за режимы мы умеем.
По идее растягивание в nohires тоже аппаратная штука. И это тоже под теми же ифдефами. Мы делаем масштабируемое окно. Это не работает в software режиме. При загрузке инстеда он не пишет что включил software? А так оно само должно просто оастянуться.

Если НЕ передаю -modes, то показывает строчку
fprintf(stderr, "Fallback to software renderer.\n");
Если передаю -modes, то в это место не приходит
При этом, если -modes и -hires переданы, то всё выглядит корректно, но не поворачивается (что нормально)
Наверно, действительно software-режим...

> При этом, если -modes и -hires переданы, то всё выглядит корректно, но не поворачивается (что нормально)
Да, поворачивается оно только если ширина == высоте. В противном случае ротация блокируется.
По идее, нужно реализовать функции: rotate_landscape(), rotate_portrait() и unlock_rotation() и посмотреть когда они вызываются...

В ANDROID и IOS при повороте (если он не залочен) срабатывает :

    case SDL_WINDOWEVENT_SIZE_CHANGED:

в input.c
И вот в эту ветку тоже можно смотреть.

По новостям работы над портом:
1) Победил, наконец, баг с неподвижной мышью. Всё оказалось проще, чем я думал: я просто забыл подложить два файлика из исходников SDL в проект (курсор и *.rc-файл)

2) В попытках победить баг с неподвижной мышью сделал UWP-версию, так что Инстед для XBOX стал ближе :) UWP-версия закоммичена.

3) Ещё есть экспериментальная XAML-версия для Windows 8.1, основанная на коде SDL из вот этой ветки: https://bitbucket.org/DavidLudwig/sdl/branch/xaml
Соответствующие изменения в коде под дефайном _WINRT_XAML
Ещё не определился, стоит ли её оставлять. С одной стороны, она вроде бы работает, с другой стороны, та ветка SDL не обновлялась с 2015 года, возможно, автор решил не доделывать или сделать как-то по другому.

4) Повороты так и не победил, так что пока успокоился на том, что всегда передаю -hires и -modes , к примеру, в виде 480x800,800x480
При дебаге выяснил, что SDL_ListModes выдаёт только один режим, к примеру, 480x800, поэтому без передачи -modes и не работает

5) При дебаге видно, что SDL_VideoWindow = SDL_CreateWindow(...) даёт NULL => Fallback to software window.
ОДНАКО, далее по коду Renderer = SDL_CreateRenderer(SDL_VideoWindow, -1, SDL_RENDERER_ACCELERATED) НЕ даёт NULL, так что даже не знаю, с ускорением получается графика или нет :)
Есть вот такой проект: https://github.com/Microsoft/angle
Если собрать в нём DLL-ки libEGL.dll, libGLESv2.dll и подложить в проект, то SDL_CreateWindow(...) уже успешно создаёт окно. Однако, непонятно, нужны ли реально такие заморочки. Может быть, сейчас просто всё работает через DirectX, поэтому и не создаётся окно с флагом OPENGL. Рендерер-то, похоже, всё же ускоренный получается...

6) И при сборке для Win 8.1, и при сборке для UWP выставляется дефайн __WINRT__. Его вообще выставляет SDL, можно даже не прописывать в дефайнах проекта.
Есть ещё дефайны _MSVCC;_UWP; -- сборка Visual C компилятором и сборка для UWP, соответственно.

В общем, теперь есть:
1) Рабочий порт на Windows 8.1
2) Рабочий порт на Windows Phone 8.1
3) Рабочий порт для UWP (т.е. всех устройств под управлением Windows 10)
4) Код здесь: https://github.com/Antokolos/instead/tree/winrt

Ещё можно покопаться с флагом _USE_UNPACK, пока что он отключен. Плюс, не знаю, как там с трекерной музыкой, нужно тестировать. На туториале ошибок нет :)

Теоретически, на этом можно собирать standalone-игры и выкладывать в Windows Store, если заменить в исходниках Инстеда tutorial своей игрой.
Ланчера, разумеется, нет, надеюсь, что у Каспера получится справиться с luasocket для Навигатора, тогда можно попытаться его прикрутить сюда.
Ну и аккаунт разработчика мой для Windows Store, оказывается, протух, ибо он покупается сроком на год. Надо будет обновить...

Круто! Отличные новости!
Я обязательно попробую позже смержить!

Я начал переносить те изменения, что касаются кода INSTEAD, и у меня появляются вопросы.
1) почему void _game_cycle(void *userdata) не вызывает просто game_void_cycle? Есть какие то основания так не делать?
Я иногда немного меняю код, так что потом придется еще раз все проверить...

2) что такое nativewindow?

3) откуда берутся дефайны и что значат:
_UWP
__WINRT__
_WINRT_XAML
_MSVCC
_WIN_EXT

Не может быть так, что, скажем, _WIN_EXT лишняя, а по сути это _UWP?

Я почти сделал патч но в него не попало:
create_dir_if_needed (это по идее внешняя штука, находящаяся в обвзязке)
nativeWindow - я не понимаю пока что это и насколько оно нужно? 1в1 перенести пока не могу поэтому
все что зависит от _WIN_EXT

Расскажи plz об этом?

Конкретно этот код делался по образцу вот этого:
https://bitbucket.org/DavidLudwig/sdlskeletonxaml81/src/5c4b3d98d57bad82190e8d6d0a48532cbc0421db/SDLSkeletonXAML81/SDLSkeletonXAML81.Shared/main.cpp?at=default&fileviewer=file-view-default
Т.е. нужно передать указатель на некий коллбэк одного игрового такта, принимающий опциональный void* параметр. Именно не while, а один такт
Может быть, можно попробовать и по другому, проверим, конечно.
Ещё я попробовал вчера использовать _USE_UNPACK, и вроде бы даже оно собралось. Но при проверке оказалось, что код-таки не работает. Поэтому я _USE_UNPACK пока убрал, и соответствующие коммиты в коде Инстеда можно, наверно, не мёржить (дефайны _WIN_EXT)... Ну или разобраться до конца :)

while() == EAGAIN это и есть 1 такт. Просто за этот такт делается несколько вещей. такой ход позволил заметно ускорить emscripten сборку.
Я короче попробую через этот же. тогда....

Peter> 2) что такое nativewindow?
Это закодированный в строку указатель на нативное окно. См. опять же тот пример от DavidLudwig
Мы можем не делать XAML, тогда не нужно то, что под дефайнами _WINRT_XAML, nativeWindow и работа с ним и метод с циклом тоже

Peter> 3) откуда берутся дефайны и что значат:
все дефайны берутся из моего проекта, кроме __WINRT__ -- он делается прям в SDL
Peter> _UWP
Если билдим UWP-приложение, для Win8.1 и WinPhone8.1 эти части не нужны
Peter> __WINRT__
Если билдим UWP или Win8.1 или WinPhone8.1, проставляется в SDL
Peter> _WINRT_XAML
Для поддержки XAML. Можем исключить как её, так и код, связанный с этими дефайнами, как писал ранее
Peter> _WIN_EXT
Это я пытался сделать _USE_UNPACK. Пока не вышло, можно не мёржить всё, что с этими дефайнами связано
Peter> _MSVCC
Билд с помощью Visual Studio. Может, есть какой-то стандартный дефайн для этого, не знаю. Вроде бы он только в паре мест, там какие-то хедеры не нашлись или что-то типа того

(22:15:56) Antokolos: https://msdn.microsoft.com/en-us/library/b0084kay.aspx
(22:16:26) Antokolos: _MSC_VER -- вот этим можно заменить _MSVCC, думаю
(22:16:46) Antokolos: если есть _MSC_VER, то компилится Visual Studio

XAML -- это вот: https://ru.wikipedia.org/wiki/XAML
Насколько я понял, его поддержка в SDL экспериментальна, и мы можем её не включать. В принципе, и так работает же. Это я пытался победить кривой ресайз при повороте, но так и не вышло.
посмотри Commit a293e9d0 insteadxaml done, _WINRT => __WINRT__
Можно исключить из него всё, не связанное с переименованием _WINRT => __WINRT__

_UWP можно заменить на такое:
https://social.msdn.microsoft.com/Forums/en-US/51f29cfe-d07f-4898-9962-945ed7b66d7f/predefined-macro-to-identify-uwp?forum=wpdevelop
#if _WIN32_WINNT >= 0x0A00
// Windows 10 and/or Universal Windows Platform
#endif

У меня вопрос, не означает ли UWP просто комбинацию:
собираем для windows, собираем MSVC (а не mingw?)

Дошел до такой проблемы.
Есть функция getAppTempDir()
Но определена она совсем в другом участке кода.
Можно ли этот .cpp код как то оформить как часть src?
Примерно как symbian.cpp или ios.m.
То есть сейчас есть некая хаотичная архитектура сборки, которую я пытаюсь причесать.

Еще пример: файл uwp.h, который не инклюдится из src/

не. Можем же собирать для Windows 7 с помощью MSVC
Можно попробовать определять UWP как if _WIN32_WINNT >= 0x0A00 , как предлагали

Можно попытаться. Тогда попробую и отпишу.

Сделал, закоммитил
файлы:

SDL2-WinRTResource_BlankCursor.cur
SDL2-WinRTResources.rc
SDL2_winrt.cpp
SDL_main.c

Ещё в этом коммите чуточку зааффектились файлы из самого Инстеда

Да, сложно идет. :( В патчах оч тяжело разбираться, так как туда постоянно попадают изменения из vs. Ну и переводы строк у многих файлов сбиты,
Я попробовал сделать первый вариант патча: http://instead.syscall.ru/downloads/winrt.patch

Я использовал WINRT вместо __WINRT__, дело в том, что в библиотеки инстед вообще нет зависимости от SDL2, так что придется -DWINRT выставлять при сборке.

Это патч на мое git дерево instead. Покрути пожалуйста, расскажи если что не так?

Спасибо, постараюсь попробовать вечером.
Кстати, сделал ещё один коммит, чтобы поддержать -gamespath, -themespath, если соответствующие папки созданы.
Попутно выяснил, что трекерная музыка, похоже, не поддерживается...

1) Надо добавить SDL2-WinRTResource_BlankCursor.cur и SDL2-WinRTResources.rc файлы

2) В system.h изменить дефайны немного:

#if defined (_WIN32_WCE) || defined(WINRT)
#define PATH_MAX 255
#define errno 0
#define putenv(a) ;
#ifndef WINRT
#define strerror(a) ""
#define setlocale(a, b) ;
#endif
#endif

т.к. strerror и setlocale определены

3) Не вставил реализацию int create_dir_if_needed(char *path). Лучше куда-нибудь в utils, т.к. она используется и в UWP (где я использую windows.c) т.к. и не в UWP (где я использую winrt.c). Если посмотришь мой последний коммит, то там ещё будет функция dir_exists(), её тоже надо.

4) В windows.c
#if !defined(_UWP && defined(_WIN32_WINNT) && _WIN32_WINNT >= 0x0A00
Не закрыл скобку после _UWP

5) SDL2_winrt.cpp не может найти uwp.h, впрочем, если его удалить, то работает.

Когда поправил эти 5 пунктов, то всё запустилось

Ещё надо добавить файлик SDL_main.c, либо сделать это дефайном.
Там, по сути, та же main, которая названа SDL_main.
Это надо для сборки обычной десктопной версии через Visual C.

> 3) Не вставил реализацию int create_dir_if_needed(char *path). Лучше куда-нибудь в utils, т.к. она используется и в UWP (где я использую windows.c) т.к. и не в UWP (где я использую winrt.c). Если посмотришь мой последний коммит, то там ещё будет функция dir_exists(), её тоже надо.

Я нашел вызов create_dir_if_needed() только из SDL2_winrt.cpp, откуда второй вызов?

Да, только там вызывается, извиняюсь, запутал.
Я имел в виду, что в моём коде копипаст этой функции содержится в windows.c и winrt.c, и лучше было бы сделать имплементацию где-то в utils.c, без копипаста.
Ещё кое что. Я таки починил использование _USE_UNPACK в своём коде, теперь архивы открываются нормально. Поэтому просьба попробовать замёржить ещё и это. Сегодня запушил немного нового кода на эту тему в свою ветку, но там были и ранее коммиты на эту тему.
Смотри дефайны _WIN_EXT. Вообще, многие из тех мест, возможно, можно и без дефайнов сделать, там я просто использую немного другие функции Windows (CreateFile2 вместо CreateFile, SetFilePointerEx вместо SetFilePointer), но это, конечно, надо тестить.
Ещё, есть дефайн _WIDE_CHARS. Это потому, что TCHAR оказался widechar и пришлось применять mbstowcs
Надеюсь, понятно объяснил. Будет круто, если получится это тоже сделать.

При попытке засунуть реализацию create_dir_if_needed в SDL2_winrt.cpp получаю такие ошибки:

2>c:\work\instead-win\instead\visualc\instead_compat\instead_compat.shared\unistd.h(50): error C2371: 'int8_t': redefinition; different basic types
2> c:\program files (x86)\microsoft visual studio 14.0\vc\include\stdint.h(17): note: see declaration of 'int8_t'
2>c:\work\instead-win\instead\visualc\instead_compat\instead_compat.shared\dirent.h(924): error C2440: '=': cannot convert from 'void *' to 'dirent **'
2> c:\work\instead-win\instead\visualc\instead_compat\instead_compat.shared\dirent.h(924): note: Conversion from 'void*' to pointer to non-'void' requires an explicit cast
2>c:\work\instead-win\instead\visualc\instead_compat\instead_compat.shared\dirent.h(975): error C2664: 'void qsort(void *,std::size_t,std::size_t,int (__cdecl *)(const void *,const void *))': cannot convert argument 4 from 'void *' to 'int (__cdecl *)(const void *,const void *)'
2> c:\work\instead-win\instead\visualc\instead_compat\instead_compat.shared\dirent.h(975): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

> При попытке засунуть реализацию create_dir_if_needed в SDL2_winrt.cpp получаю такие ошибки:
А как ты ее засовываешь? Можно показать конечный cpp?

Вот так: https://www.dropbox.com/s/gbhadb4gri3j0zg/SDL2_winrt.cpp?dl=0

Небольшое вдохновляющее видео:
https://youtu.be/wBirQPnbA3c
Прикрутил ассоциацию приложения с zip-архивом, теперь можно просто скачать игры на SD-карту и запускать. Таким образом, можно и без ланчера обойтись, но с ланчером всё же было бы чуть получше.

В общем, крутил и так и этак, не могу я в таком виде патчи внести в дерево полностью.

Но могу частично, как это было сделано с андроид. В принципе, это не так уж и плохо. :) А winrt изменения можно выкладывать на instead-hub рядом.

Тут столько всего смешано, а я не могу это развести нормально, ибо не владею платформой. Я сделал патч, на том уровне, на котором у меня он не вызывает вопросов, но там не все. Проверишь?

http://instead.syscall.ru/downloads/winrt.patch

Да, конечно, попробую.
Ещё вчера допилил немного, чтобы архивы поддерживались и на Windows Phone 8.1 (который у меня в виде физ. устройства)
Благодаря поддержке архивов, появилась возможность потестировать не только на туториале. Есть как радости, так и печали.
Карантин работает
Miner Bold работает, мультитач в наличии
Поддержка jpg отвалилась
Поддержка mp3 отвалилась
Поддержка трекерной музыки отвалилась
В штурмане какая-то ошибка со спрайтами
В Варваре ошибка при использовании io.open в lua
В общем, надо смотреть и тестировать...

Текущую ветку winrt переименовал у себя на github в winrt-initial
Когда у нас устаканится полностью с патчем, видимо, придётся создать новую ветку winrt, основанную уже на патче, но с моими доп. изменениями, которые в патч не вошли.

В целом, оно собралось и заработало
только вот в winrt.h пришлось поправить

#ifdef __cplusplus_winrt
extern "C"
{
#else
extern
#endif
	void getAppTempDir(char *lpPathBuffer);
#ifdef __cplusplus_winrt
}
#endif

вместо просто extern void

Я предполагал что winrt.h используется только в winrt.c просто.

Есть смысл хотя бы такой патч мержить?