К вопросу о машинном творчестве, кстати. Были статьи про написание музыки компьютером. А ещё нейросеть имитирует стиль художников.
Там тоже есть функция красоты, в музыке гармонии, для картин примеры работ. Хотя все согласны, что что-то тут всё равно не так :)
https://geektimes.ru/post/272430/
https://habrahabr.ru/post/185154/

Возник такой вопрос.
К примеру, у нас есть таймер, установленный по timer:set(5)
и вот такой код:

game.timer = stead.hook(game.timer, function(f, s, cmd, ...)
if vn.processing then
return;
end
if not vn.on then
return f(s, cmd, ...);
end
vn.processing = true;
local result = code_that_can_take_more_than_5ms_to_complete();
vn.processing = false;
return result;
end)

Собственно, вопрос: нужно ли вообще это извращение с vn.processing? Или в таймере всё синхронно и новый вызов гарантированно не произойдёт, пока старый не завершён?
А если там реально всё асинхронно, и таймер стреляет с той частотой, что ему указали, будет ли такой код потокобезопасным (в Java я бы точно сказал, что нет, vn.processing нельзя модифицировать без синхронизации, мьютекса итп.)
Ну и вообще, как разрулить такую ситуацию? В идеале хочется, чтобы новый вызов кода по таймеру НЕ происходил, пока старый не отработал.

Antokolos> Возник такой вопрос.
P.S.: Вопрос по STEAD2, но, думаю, в STEAD3 всё примерно так же.

Peter> Таймер всегда синхронный -- он не прерывает команду инстеда, он обрабатывается между командами и сам может генерировать команду. Насколько я помню -- game.timer это уже производное событие -- которое обрабатывается как обычная команда своим чередом.
Ясно, спасибо! Ну, тогда код упростится :)

Kerbal> В таймере новый вызов происходит, емнип, через timer:set(n) после отработки старого вызова. Т.е. отработал вызов, ждёт n, новый вызов. Во время n происходят другие события.
Вообще, изначально у меня было так:
в самом начале длительного метода timer:stop(), чтобы точно уже не пришёл новый тик.
в самом конце длительного метода timer:set(n), чтобы вновь запустить таймер.
Однако, это по каким-то причинам иногда стало приводить к тормозам (сейчас делаю Варвара под Андроид, и на слабом планшете это очень чувствуется).
Была даже гипотеза, что какие-то проблемы с освобождением памяти, но нет, это не подтвердилось.
Сейчас у меня timer:set(n) только в функции init(), timer:stop() вообще не используется, т.е. таймер бесконечно молотит.
В результате становится возможным реализовать, к примеру, onmouseover для спрайта.
Единственно вот беспокоил вопрос, не может ли так выйти, что таймер запустится снова, не дождавшись отработки предыдущего вызова.

kerber> onmouseover для спрайта хотеть! Покажешь потом как сделал? Я, когда делал панорамы и дёргал функцию отрисовки в таймере, обрамлял рассчёт каждой линии рендера вызовом stead.busy() чтобы не залипал курсор. Этот же трюк использовал в шахматах. Там тоже на планшете медленно ходы обдумывает. Посмотри, может пригодится где-нить.
kerber> https://yadi.sk/d/pmvrIvW5xiXbZ
kerber> http://instead-games.ru/game.php?ID=225

Спасибо, погляжу!
Ну, а по поводу onmouseover идея простая. Постоянный таймер + stead.mouse_pos() даёт координаты, и есть два спрайта, обычный и при наведённой мыши. С помощью модуля vn в нужный момент показывается нужный спрайт.
Более подробно можно в Варваре посмотреть, только там страшный код, конечно :)
Ну или вот есть более простой пример:
https://yadi.sk/d/bj-eEC403DszoC
Только модуль там староват, я его постоянно обрабатываю напильником.
Последние версии смотреть здесь:
https://github.com/Antokolos/NLB/blob/master/NLBL/src/main/resources/vnstead/modules/vn.lua

Peter> Очень мне хочется, чтоб вы пощупали новые спрайты. В stead3. Ибо там они автоматом освобождаются. И мало кто их тестил. ;) У самого пока руки никак не дойдут до творчества...
Пощупаем-пощупаем :) В планах перевод конструктора на stead3, заодно и генерируемый код надо причесать.
А кстати, sprite.free() осталась, но теперь ничего не делает?

Отличные новости!
Интересно, в чём была проблема прошлой Emscripten-версии, которая подтормаживала?
А сборочный скрипт для Emscripten будет прямо в основном репозитории Инстеда?

Собрал INSTEAD-EM ещё раз после нашего вчерашнего разговора в чате.
Демо Варвара без музыки (~40MB)
http://nlbproject.com/instead-em/instead-em.html?barbarian_caves_demo_nosound.zip
Демо Варвара с музыкой (~60MB)
http://nlbproject.com/instead-em/instead-em.html?barbarian_caves_demo.zip

Версия с форума в конечном итоге упала с ООМ, поэтому в своём варианте я заменил
-s ALLOW_MEMORY_GROWTH=0
на
-s NO_EXIT_RUNTIME=1 -s ALLOW_MEMORY_GROWTH=1

Падение произошло во время игры в кубики. Попробуйте её найти, это хороший стресс-тест для INSTEAD-EM :)

С моей скоростью интернета версия игры без музыки качается минуты полторы-две, уже более или менее

Интересно:
1) Куда реально попадают сохранения? Это же где-то в браузере должно храниться?
2) Какие именно изменения сделаны в "пропатченном Emscripten"? Критично ли это для конечного результата?

>Если нужно, могу подробно описать что я сделал.
Да, было бы здорово.

Всем привет!
Давно хотел собрать 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. Ну и вообще, это круто :)

Peter> casper_nn высказал идею, продлить инстедоз и написать об этом прямо в сборнике, в каком-то смысле сделав призыва писать новым людям.

Peter> Как вы к этому относитесь? Нормальная идея?

Очень хорошая идея!

Обновил 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 соответствующий проект есть.

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

Обновил 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.

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

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

>> Очень хорошая идея!
Peter> На сколько напишем в призыве? Неограниченный срок? ;)

Можно, конечно, и так :) Будет бесконечно пополняющийся сборник

По новостям работы над портом:
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, оказывается, протух, ибо он покупается сроком на год. Надо будет обновить...

Конкретно этот код делался по образцу вот этого:
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)... Ну или разобраться до конца :)

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

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

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

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

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

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

Спасибо, постараюсь попробовать вечером.
Кстати, сделал ещё один коммит, чтобы поддержать -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.

Да, только там вызывается, извиняюсь, запутал.
Я имел в виду, что в моём коде копипаст этой функции содержится в 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

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

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

Да, конечно, попробую.
Ещё вчера допилил немного, чтобы архивы поддерживались и на 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, основанная на этом патче
https://github.com/Antokolos/instead/tree/winrt
Самый последний коммит там (_USE_UNPACK support) посвящён дополнениям для того, чтобы можно было собрать с флагом _USE_UNPACK

Да, конечно, тут. Буду пробовать, спасибо!

Итак:
1) Сделал git clone https://github.com/instead-hub/instead в пустую папку
2) Скопировал туда папки VisualC и VisualC-WinRT из https://github.com/Antokolos/instead/tree/winrt
3) Открыл свой проект
4) В файле windows.c пришлось сделать изменение
#ifndef _MSC_VER
#include <dir.h>
#endif
ибо файл dir.h он не находит
5) В файле https://github.com/Antokolos/instead/blob/winrt/VisualC-WinRT/src/uwp.h пришлось сделать изменение -- убрал #ifdef _UWP в третьей строчке, т.к. теперь я использую его вместо удалённого winrt.h.
6) Соответственно, в файле https://github.com/Antokolos/instead/blob/winrt/VisualC-WinRT/src/SDL2_winrt.cpp убрал использование winrt.h и всегда использую winrt.h
7) Убрал использование _USE_UNPACK у себя в проекте, т.к. этот код ещё не смёржен.
8) Приложение как для WinRT, так и для UWP собралось, туториал запустился.

P.S. извиняюсь, не перечитал то, что написал :(
6) Соответственно, в файле https://github.com/Antokolos/instead/blob/winrt /VisualC-WinRT/src/SDL2_winrt.cpp убрал использование winrt.h и всегда использую uwp.h

Здорово, да можно сильно не торопиться :)
Больше всего меня тревожит, что не все игры работают.
Скорее всего, дело в относительных путях, ибо мне даже при распаковке пришлось в одном месте хачить, чтобы всегда абсолютные пути передавались.
Это т.к. https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps
_chdir _wchdir _getcwd _getdcwd _wgetcwd _wgetdcwd The concept of a working directory doesn't apply to Windows 8.x Store apps. Use full paths instead.

AL> ЗЫЖ Спор получается пустой. Самое очевидное тут дело такое: если не видно смысла в технологии, то зачем её использовать? Я вот не вижу смысла в социальных сетях и просто не использую их. И не чувствую необходимости сидеть там и указывать на очевидные недостатки.

AL> ЗЗЫЖ Тут, что удобно, каждый волен сам решать в каком виде ему удобней пользоваться сетью. Никто не принуждает сидеть именно в веб-интерфейсе клуба. Более того, не обязательно вообще пользоваться веб-интерфейсом.

Влезу чуточку в обсуждение, всем привет, правда у меня небольшой оффтопик.
Читаю сообщения тут через Caesium и иногда немного через сайт.
И вот в Caesium эти вот ЗЫЖ и ЗЗЫЖ появились только тогда, когда попробовал ответить на сообщение. А на экране чтения сообщения их нет, хотя получить новые сообщения (G) нажимал.
Надо ещё что-то нажать, или Caesium доработать?
Пользуясь случаем: Андрей, спасибо за Caesium, он мне нравится :) Пускаю на Маке, кстати.

AL> Да. Тебе нужен параметр comment. За одно можешь и scrollbar перекрасить. Потому как его, скорее всего, у тебя тоже не видно.
Сделал, спасибо! Теперь всё видно.

Началось всё с того, что друг кинул мне архив с книгами, среди которых была Стань Стальной Крысой Гарри Гаррисона.
Я пропёрся от идеи того, что история может пойти разными путями, и выбирать эти пути будет сам игрок.
Это уже потом я узнал, что Стальная Крыса -- пародия на книги игры, а CYOA на Инстеде вообще не жалуют. Но я всё равно люблю эту книжку :)
Скоро я захотел написать что-то такое же. Причём, я всегда хотел именно рисовать историю в виде графа, а не программировать. Сначала хотел попробовать какие-то
существующие инструменты, чуть ли не какой-то редактор UML-диаграмм, но быстро понял, что нужен спец. инструмент. Подумал над концепцией, решил,
что такое можно написать за выходные. Пишу до сих пор :)

Долгое время я вообще варился в своём соку и ничего не знал о текстовых играх в России и СНГ. Потом решил посмотреть-таки в интернете и обнаружил, что
сообществ много и все они разные.

Сначала я пошёл на quest-book.ru. Но Джуманджи меня обломал, сказав, что книга-игра и текстовый квест -- это абсолютно разные понятия, за употребление
которых в одном предложении следует кара Господня :)

Потом я пошёл на форум Инстеда. В то время как раз стартовал третий Инстедоз, где позже и состоялся наш дебют со скромным квестиком.
Сначала я его написал в духе книг-игр, и Пётр мне доказывал, что на Инстед надо писать не так. Надо сказать, я всё же проникся идеей Инстеда, и квест
переписал, чтобы он был мало-мальски похож на Инстед-игру. Даже свой редактор подкорректировал, чтобы там можно было создавать не только параграфы
(аналог room в INSTEAD), но и объекты.

К сожалению, пока ещё так и не написал крупного квеста, который был бы именно Инстед-вейным. Зато в соавторстве с женой и её братом сделали две ВН-ки,
и готовы поклясться, что Инстед для создания ВН приспособлен ничуть не хуже, чем RenPy :)

Peter> Интересно! Про андроид только не рассказал. :)
Peter> А я думал ты тру-книгоигро адепт. :) видимо, на форуме книг игр упор на pdf?
Андроид-версия родилась от отчаяния: вот есть же опенсорсный код, который должен работать и работал когда-то, наверняка доработать его должно быть несложно :)
Очень хотелось, чтобы и на планшетах заработало тоже, как раньше, желание придавало сил и уверенности в том, что всё получится.
Разумеется, среди мотиваций была и возможность выставить наши игры в Google Play для продажи, но я рад, что тут полезное для нас совместилось с полезным для всех любителей INSTEAD. Иногда люди благодарят за работу, и это очень радует. Всегда приятно, когда делал что-то не зря.

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

>> Всегда удивлялся от такого подхода. Как-то привык сызмальства считать, что литературное произведение ценно содержанием.

Peter> Думаю, любителям книг-игр важна "неинтерактивность". Книга полностью открыта, прозрачна для игры. То-есть это самое простое, что может быть... Высказал, как гипотезу. :)
Кстати да, точно, абсолютно правильная гипотеза.
Ещё обсуждали возможность легального жульничества в игре, ибо если игра на компьютере и исходники закрыты, то просто так не почитеришь, а в книге-игре можно выиграть бой и не следуя правилам, при желании. Можно вообще пропускать бои. В одной книге-игре (кажется, Легенды Всегда Врут) есть упрощённая боёвка, когда ГГ автоматом выигрывает бой ценой нескольких очков здоровья.
А ещё не так давно был конкурс, когда для уже существующей книги-игры участники придумывали новую игромеханику. Т.е. весь авторский текст остаётся тем же, но правила боёв заменяются.