Недавно @technix подсунул мне статью https://if50.substack.com/p/1981-his-majestys-ship-impetuous в которой рассказывается о Роберте Лафоре (Robert Lafore) создателе интерактивной литературы и его играх. В играх применён довольно простой и забытый сегодня приём. История разворачивается как в CYOA играх, в ключевых моментах предлагая игроку вводить текст в свободной форме. Движок реагирует на:

* присутствие ключевых слов в фразе (например: да, нет, имя NPC и т.д.);
* отсутствие ключевых слов в фразе (попрошу обращаться ко мне как "сэр");
* объём текста и так далее...

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

Сам факт свободной формы вводимого текста тоже может работать на погружение. Интересно, что похожий приём я использовал в своей игре "Вахта" при написании электронного письма.

В общем, статья хорошая, интересно было прочитать. Но после её прочтения я снова задумался о форматах интерактивной литературы.

Мне всегда нравилось писать истории, которые напоминают книги или кино (или театр). Загадки в такой истории воспринимаются как часть происходящих событий и естественно вплетаются в повествование. Поэтому и INSTEAD был написал с упором на такой вид игр. Условно, назовём их играми с моделью мира или просто квестами. Не смотря на ощущение свободы, на самом деле, именно свободы как правило в подобных играх нет. Мы просто "проживаем" разворачивающиеся события. Это "проживание" помогает погружению и не является средством реализации вариативности.

Модель мира позволяет реализовать линейную историю, потому что само разворачивание сюжета составлено из действий игрока. Это уже само по себе "актёрская игра". Возникает элемент вовлечённости. Сюжет один и тот же, но остаётся ощущение, что ты был в центре описываемых событий.

Зачем эти рассуждения? Дело в том, что меня давно интересует вопрос применения элементов CYOA для написания _линейных_ историй. И прочитанная статья вроде бы в очередной раз намекает на возможность этого пути. Мне казалось, что должен бысть способ скрестить парсер и CYOA и получить нечто новое.

Что мне нужно от CYOA? Литературный текст. Лёгкость работы с текстом (как в книге). Что мне нужно от парсера? Чувство свободы (хотя бы и мнимое) и вовлечённости. Однако, как только мы убираем модель мира, мы приходим к неизбежной нелинейности! Этот парадокс я долгое время не замечал.

Подумайте, если вместо моделирования действий игрока мы начинаем работать с голым текстом, то мы обязаны работать с нелинейностью! Потому что в CYOA процесс разворачивания сюжета, это не моделирование действий игрока, а чтение текста! CYOA это не способ управления игрой, CYOA -- это подход к написанию историй! И этому подходу совершенно чужда идея "линейной истории". CYOA всегда предполагает литературное описание альтернативных вариантов сюжета.

Я уже слышу возмущённый гул голосов, в котором я угадываю примеры игр доказывающих ошибочность моих наблюдений.

Предполагаю, что речь идёт о (назову их так) "стратегических" играх. Я имею в виду игры с явно выраженной игровой механикой. Сюжет в таком случае будет "побочным" продуктом. Он будет развиваться не средствами CYOA подхода. Например, в случае игры про детектива, работающего с документами при помощью меню, сюжет, скорее всего, будет развиваться за счёт чтения игроком содержимого документов. А сам игровой процесс при этом не будет иметь прямого отношения к CYOA подходу.

То-есть, при проектировании игры мы можем выделить некую игровую механику и уже вокруг этой механики развернуть сюжет. В качестве примера: SMS игры, работа с документами, игры в виде диалогов, кликеры, текстовые-roguelike, расшифровка текстов и так далее. Да, мы всегда можем придумать новую уникальную (или не очень) механику и навесить на неё сюжет. Но, в таком случае, нельзя говорить об универсальности подхода. И, строго говоря, мы не можем назвать это CYOA. Потому что игровая механика таких игр не влияет на сюжет. Напомню, я говорю сейчас об играх с линейным сюжетом.

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

Игры с моделью мира -- настоящая интерактивная литература. ;)
P.S. Edited: 2021-03-22 18:58:47

Пытаюсь понять эту классификацию, но путаюсь в неоднозначной терминологии. Такие термины, как "квест", "линейность", "модель" или "механика" можно понимать по-разному.

Я могу только попробовать предположить, что речь тут идет об отличиях игр с открытым миром (симулятора) от предопределенного сюжета (истории). Такими (крайними) примерами могут быть Minecraft с одной стороны и визуальная новелла - с другой. Тут, вроде бы, все ясно.

В книгах-играх уже явно есть и игровой мир и дерево сюжета. Игрок может взаимодействовать с объектами этого мира, выбирая нужную ветку.

Куда тут отнести Zork или, например, Maniac Mansion? Есть игровой мир и есть набор (частично связанных) задач для достижения (одной из) целей игры. Сюжет присутствует, но на ход игры не влияет.

Это то, что тут имеется в виду?

Я говорил об играх в рамках интерактивной литературы или классических point&click квестах. Под "квестом" или игрой с моделью мира я понимал игры в которых моделируются действия игрока. Ходить по локациям, брать предметы и т.д. Тогда и Zork и Maniac Mansion относятся условно к "квестам". Сюжет в таких играх обычно линеен. Чувство свободы возникает от свободы перемещений и действий, но на сам сюжет это не влияет.

В CYOA подходе обычно речь идёт не о моделировании локаций/действий, а о развитии сюжета непосредственно. Текст (художественный, а не сгенерированный движком) выводится порциями и в идеале не повторяется, не заставляет игрока ходит по тем же местам снова и снова, а ведёт игрока от начала истории и до конца, ветвясь в зависимости от замысла автора.

Конечно и в CYOA можно применить элементы "моделирования", но это довольно дорогое удовольствие по сравнению с "квестом". Потому что требует от автора написания художественного текста для всех развилок.

hugeping> Ходить по локациям, брать предметы и т.д.

Это условность. В любой книге-игре такие элементы тоже присутствуют, например: "если вы хотите пойти туда-то, то идите на параграф такой-то" или "если вы решили взять этот предмет, то впишите его в лист персонажа и идите на соответствующий параграф".

hugeping> В CYOA подходе обычно речь идёт не о моделировании локаций/действий, а о развитии сюжета непосредственно. Текст (художественный, а не сгенерированный движком) выводится порциями и в идеале не повторяется, не заставляет игрока ходит по тем же местам снова и снова, а ведёт игрока от начала истории и до конца, ветвясь в зависимости от замысла автора.

hugeping> Конечно и в CYOA можно применить элементы "моделирования", но это довольно дорогое удовольствие по сравнению с "квестом". Потому что требует от автора написания художественного текста для всех развилок.

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

Но идею я понял.

Кстати, чтобы увидеть возникающую путаницу достаточно посмотреть на "Земли сказаний" (http://instead-games.ru/forum/index.php?p=/discussion/412 ). Это типичная книга-игра, но которую трудно отличить от "квеста".
P.S. Edited: 2021-03-23 15:24:46

Последнее время я внёс множество изменений в репозитории, которые относятся к проекту INSTEAD. Изменений накопилось масса. И я подумал, что неплохо держать гипотетических энтузиастов в курсе того, что именно происходит. Ведь нет ничего интересней, чем наблюдать за чьей-то работой, правда? :)

Изменения к 14 мая 2021.

# Метапарсер

Метапарсер изменился очень заметно. Толчком послужило мероприятие по написанию коллективного парсера "17 комнат". Сложно уже перечислить всё, что с происходило с кодом МЕТАПАРСЕРа. Назову только самые заметные вещи:

* Значительно улучшены подсказки. Смешных и абсурдных ситуаций должно стать меньше!
* Решение проблемы одушевлённости слов, которые имеют несколько смыслов;
* Улучшено качество распознавания при использовании сокращений;
* Исправлено множество внутренних недоработок (сообщения, ввод, и так далее);
* Улучшена документация;
* Служебные глаголы: счёт, парсер глаголы, парсер версия;
* Безопасный формат записи if "объект" ^ w (по сравнению с if w ^ "объект", w может быть nil);
* Новая тема по умолчанию;
* Экспериментальный модуль приказов.

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

# instead-cli

Долгое время я пользовался для разработки своих игр tiny instead. Эти минималистичный интерпретатор в 100 строк, который можно собрать в дереве исходного кода INSTEAD (src/tiny) и запускать его из терминала.

Для работы в Plan9 я сделал другой вариант tiny, который назвал 9instead. Очень удобная штука! Игра Луна-9 почти полностью написана с его помощью. Можно запустить редактор (acme или emacs), набирать текст и тут же прогонять заготовленный автоскрипт а другом фрейме редактора. Ничего лишнего!

Долгое время меня просили собрать такой интерпретатор, но в виде "продукта". Для Windows в том числе. И в этот раз у меня, наконец, нашлось время это сделать! Теперь на instead-hub появился проект https://github.com/instead-hub/instead-cli Он постоянно развивается. Сейчас готовится новая версия. Все наработки из Plan9 интерпретатора перешли в этот новый проект и я удалил 9instead. Присутствуют статические сборки для Windows и Linux. Особенно instead-cli удобно использовать при разработке парсерных игр, в том числе для перегенерации словаря и прогона тестов. Да и играть в нём тоже неплохо. К тому же, этот интерпретатор можно использовать как референсную реализацию при создании своих версий INSTEAD.

Ну и, конечно, instead-cli собирается в 9front. Так что теперь это официальная версия INSTEAD для Plan9 вместо 9instead.

# Модуль protect

Иногда хочется сделать так, чтобы исходники вашей игры не были доступны для изучения. Для этого есть "штатный" метод в виде doencfile в INSTEAD, но он довольно неудобен в использовании (требуется модификация кода) и легко вскрывается. Поэтому в stead3-modules появился protect! Как он работает?

Для его запуска вам нужен lua или instead с опцией -lua для запуска скрипта. Ну и instead-cli теперь умеет запускать скрипты Lua.

```
instead-cli -xprotect.lua main3.lua main3.lua
```

Осторожно! Файл main3.lua будет закодирован! Вы можете повторить эту процедуру для всех lua файлов вашего проекта.

Конечно, "защиту" можно взломать. Но сделать это сложнее, чем стандартный encoder в INSTEAD. Если вам удалось сделать расшифровщик, расскажите, насколько это было легко. Это правда любопытно. Сам я не сторонник закрытия исходников, но иногда художественный замысел требует этого. Например, если речь идёт о хардкорной головоломке.

# Перевод игры "Архив"

Я перевёл игру Архив на английский. Но нужна вычитка. Если у вас есть скиллы и возможность помочь, прошу на https://github.com/gl00my/instead-game-archive Игра полностью проходима на русском и на английском.

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

# INSTEAD, вперёд!

В общем, я доволен прогрессом. INSTEAD превращается в инструмент мечты. Много интересных задач. И радость творчества присутствует! Готовлю обновление: метапарсер + metaparser-js + instead-cli + перевыпуск всех своих парсерных игр. Потом в очередной раз подумаю, что делать дальше. Надеюсь, работа над INSTEAD доставляет радость не только мне. :) А пластмассовый мир пусть идёт лесом.

Сегодня обновлены:

- МЕТАПАРСЕР3 до версии 2.0;
- metaparser-js до версии 2.0;
- instead-cli до версии 1.2;
- Обновлён metaparser-js на сайте https://parser.hugeping.ru

Ссылки на проекты:

МЕТАПАРСЕР https://instead.hugeping.ru/page/metaparser
instead-cli https://github.com/instead-hub/instead-cli
P.S. Edited: 2021-05-15 11:32:07

Все эти споры о парсере подвигнули меня покопаться в исторических парсерных играх. Сравнение классических игр Sierra On Line и образцов типичной интерактивной литературы показывает интересные отличия. В частности очевидно, что игры Sierra имели немалый элемент аркадности.

Здесь исходный код Leisure Suit Larry (без интерпретатора AGI): https://github.com/historicalsource/leisuresuitlarry
А здесь исходный код нескольких парсерных игр для IBM PC (можно найти и тот же код для TRS-80 Color Computer, кому интересно): https://archive.org/details/mark-data-products-games-1984-85-source-code.-7z

Кстати, удивляет сегодня, что такое было возможно на компьютерах с 32 _килобайтами_ памяти и 8-битным процессором (в графике!). И да, разумеется, там же рядом можно полюбоваться исходным кодом Zork и Dungeon на ZIL или FORTRAN.

vvs> Все эти споры о парсере подвигнули меня покопаться в исторических парсерных играх.

Вот что интересно, я почти не играл в "оригинальные" парсеры старой школы. И вообще, любил квесты попроще. Например, предпочитал графические адвенчуры от Lucas Arts (там подписывались объекты при наведнии, в отличие от игр Sierra).

Так что мои игры реконструкцией сложно назвать. Более того, я терпеть не мог эффект "угадай глагол". Почему сейчас всё поменялось, сам не понимаю. Ну, угадай глагол мне и сейчас не нравится, конечно. :) Просто я теперь знаю какие глаголы работают :)

vvs> Кстати, удивляет сегодня, что такое было возможно на компьютерах с 32 _килобайтами_ памяти и 8-битным процессором (в графике!). И да, разумеется, там же рядом можно полюбоваться исходным кодом Zork и Dungeon на ZIL или FORTRAN.

Вообще, старые технологии часто недооценивают. Например, в troff можно верстать не хуже, чем в Latex, но только при этом ресурсов нужно на порядок меньше.

hugeping> Более того, я терпеть не мог эффект "угадай глагол". Почему сейчас всё поменялось, сам не понимаю. Ну, угадай глагол мне и сейчас не нравится, конечно. :) Просто я теперь знаю какие глаголы работают :)

А в point'n'click есть свой аналог: охота за пикселями.

Чат https://t.me/insteadtalk, а также все связанные с ним чаты (irc, discord и jabber) целиком переходят под управление нового владельца -- spline. Теперь, неофициальный INSTEAD чат больше не контролируется мной (автором движка INSTEAD). Начиная с этого момента, будущее и политика чата зависят от spline и сообщества любителей INSTEAD.

Судьба официального (модерируемого) телеграм-чата https://t.me/insteadchat пока не решена.

#news

Модерируемый телеграм чат https://t.me/insteadchat передан новому владельцу @canwolf.
Чат переименован в "INSTEAD разработка" и теперь его политика и будущее будут определяться новым владельцем и сообществом INSTEAD.

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

Мне нравится проект INSTEAD, я трачу много своего свободного времени на его кодовую базу и на написание своих игр. (Сейчас, например, готовится новая версия INSTEAD с долгожданной поддержкой hidpi и масштабируемых тем.) Я занимаюсь проектом с 2009 года. При этом, мои социальные роли в проекте вызывали и вызывают эффект выгорания. У меня нет никаких амбиций по продвижению INSTEAD, поэтому я постепенно отчуждаю все ресурсы, которые не относятся непосредственно к разработке движка: группа VK, репозиторий игр, форум... Теперь настало время чатов.

Моей единственной территорией социального взаимодействия остаётся https://hugeping.ru
Присутствие меня в чатах INSTEAD вероятно, но не гарантируется.

Cпасибо @spline и @canwolf за свободу!

P.S. Фактическая передача чатов новым владельцам займёт около 6 дней.

#news

Выпустил новую версию метапарсера.

* transcript больше не включается автоматически по команде autoscript;
* mp.detailed_attr;
* mp.msg.INCOMPLETE_NOUN/SECOND_NOUN/UNKNOWN_VERB переписаны;
* mp:content переписан;
* mp:footer();
* mp:verb_filter() (ru: лучшее детектирование глаголов);
* ru: исправлен глагол #Insert;
* исправления в автодополнении;
* исправления в английской библиотеке.

Рекомендую обновиться, если вы пишете свои игры с использованием МЕТАПАРСЕРА.

Выпущены: metaparser, metaparser-js, instead-cli

https://instead.hugeping.ru/page/metaparser/
https://parser.hugeping.ru

#news
P.S. Edited: 2021-07-31 18:43:00

Выпустил новую версию метапарсера. Исправление содержит исправления ошибок, поэтому рекомендуется для всех авторов.

* исправлено падение при вызове mp:myself();
* исправлено поведение Meta команд;
* исправлен std.busy();
* бекпорт исправлений из проекта re:instead.

С новым модулем выпущены: metaparser, metaparser-js, instead-cli

https://instead.hugeping.ru/page/metaparser/
https://parser.hugeping.ru

#news

Сегодня вышла в свет первая версия нового проекта RE:INSTEAD!

Что это: https://github.com/instead-hub/reinstead/blob/master/MANIFEST.md
Скриншоты: https://github.com/instead-hub/reinstead/blob/master/README.md

Вы можете скачать готовую сборку, которая должна работать на Linux (64 бита) и Windows. Также, проект собирается в 9front (Plan9).

https://github.com/instead-hub/reinstead/

RE:INSTEAD распространяется с играми проекта "ПАРСЕРНОЕ СОПРОТИВЛЕНИЕ", которые лицензированы под лицензией CC SA 4.0.

http://parser.hugeping.ru/

#plan9
#news

Обновлёна js версия метапарсера до версии 2.2.1.

Изменения:
- исправлена работа старой js версии, которая активизируется если браузер не поддерживает wasm;
- исправлена доступность для незрячих (спасибо Даниилу Гусеву за помощь в отладке).

#news

На исходе последнего дня лета вышел INSTEAD 3.4.0! Версия с поддержкой hi-dpi экранов и возможностью создавать игры с адаптивными темами. Список изменений:

- исправление в pxl:fill_triangle (сортировка вершин);
- исправлена сборка с новым SDL_image;
- корректная работа с масштабированием в Windows (dpi awarness);
- поддержка высоких dpi (если включена опция HQ);
- новый параметр -dpi;
- новая функция instead.screen_dpi();
- новый параметр theme scr.gfx.scale;
- новый параметр theme scr.dpi;
- новый параметр theme scr.scale_aware (1|2) - поддержка адаптивных тем;
- возможность запуска игры через командную строку по пути к main?.lua файлу;
- более качественное масштабирование картинки сцены;
- обновлён SDL для windows сборки;
- улучшение: используется GetModuleName для нахождения полного пути к .exe (Windows);
- новая функция pxl:tosprite (конвертация pxl в sprite с масштабированием);
- ускорение pxl:fill;
- экспериментальная поддержка сборки с gtk4.0 (пока отключено).

Бинарные сборки будут появляться по мере готовности.

#news

Обновлён метапарсер.

- Исправлено формирование с/со в русской библиотеке;
- Исправлены сохранения в metaparser.js.

Обновлениы: metaparser, metaparser-js(до 2.2.2). Заменена сборка instead-cli(1.5).

#news

Сегодня, тихо и незаметно, выпущено обновление re:instead 0.2!

RE:INSTEAD это приложение проекта "ПАРСЕРНОЕ СОПРОТИВЛЕНИЕ"

https://parser.hugeping.ru

которое предлагает вашему вниманию сборник парсерных игр в минималистичном формате. Сборки подготовлены для: Windows, Linux и Android. Для других ОС (включая Plan9, MacOS X, BSD*) предлагается тривиальная самостоятельная сборка из исходных кодов.

Изменений масса:

- изменение размера шрифта клавишами ctrl-+/-/0;
- поддержка автоскриптов через параметр -i <autoscript>;
- значительное ускорение работы;
- исправления в играх;
- поддержка сохранения настроек;
- порт на Android;
- исправление ошибок и прочие улучшения.

Сборку для android пока можно скачать прямо в виде .apk файла. А потом, я надеюсь, приложение примут в F-Droid. Соответствующий merge request уже создан.

Проект на github: https://github.com/instead-hub/reinstead

Руководство для игроков: https://github.com/instead-hub/reinstead/releases/download/0.2/manual.pdf

Бинарные сборки: https://github.com/instead-hub/reinstead/releases

#news

Сегодня выпустил re:instead. Сделал также merge реквест в f-droid. Настроение выполненной работы держалось до самого вечера, когда пришли тревожные новости...

# INSTEAD от btimofeev заблокирован в Google Play #

Что они там нашли, не знаю... Вероятно, не нравится установка Lua кода из сторонних источников. Что же, закономерный оскал капитализма.

На самом деле, неуместность INSTEAD на коммерческой площадке чувствовалась и раньше. И вот, сейчас мы получили логическую развязку. INSTEAD не место на площадке Apple. Не место на площадке Google.

Не знаю, что будет дальше, но лично моё мнение, что лучше просто послать Google подальше и продолжать заниматься творчеством. Пока ещё есть возможность запускать открытый код на наших (пока?) компьютерах.

Напомню, что скачать приложение вы можете из репозитория открытых проектов на F-Droid: https://f-droid.org/en/packages/org.emunix.insteadlauncher/

Я обновил ссылку на https://instead.hugeping.ru на приложение для Android.

#news

Выпущен Re:instead 0.3. В новой версии:

- Настройка conf.width: максимальное число символов в строке;
- Обновлён Метапарсер;
- Исправлены ошибки;
- Улучшена Android версия.

Также, Re:instead уже можно поставить из F-Droid! Правда, пока только прошлую версию (0.2).

https://github.com/instead-hub/reinstead/releases/tag/0.3

#news

P.S. Edited: 2021-09-19 13:24:33

Выпустил RE:INSTEAD 0.4

Новое:

* возможность сборки с одной из трёх библиотек рендеринга шрифтов (stb_truetype/libschrift/freetype);
* статические сборки Linux/Windows теперь собираются с freetype;
* исправление ошибок;
* системные команды теперь начинаются с ! (например, !save);
* команды !saves и !rm для просмотра и удаления сейвов.

Готовы бинарные сборки для Linux/Windows (reinstead-0.4.zip) и .apk для Android.
Обновление в F-Droid должно тоже скоро подоспеть.

https://github.com/instead-hub/reinstead/releases

tts в re:instead

Со второй попытки, всё-таки, поддержку tts решил оставить. (Пока, только для Android). Спасибо Никите за помощь! Поддержка неидеальна, конечно, но пользоваться можно.

Будет в следующей версии (0.5).

Приложение снова доступно :) Ура!

Выпустил Re:instead 0.5 с поддержкой голосового вывода и улучшениями в Android сборке.

* поддержка голосового вывода на: Linux, Windows и Android.
* !tts команда;
* функции доступности в Android версии;
* лучшая поддержка виртуальных клавиатур Android;
* исправления ошибок.

Этот релиз не состоялся бы без помощи Nikita Tseykovets. Спасибо!

Как обычно, скачать версии для Windows/Linux и Android можно с github: https://github.com/instead-hub/reinstead

Версия в F-Droid будет через несколько дней.

#news

Вышло большое обновление для всех проектов, связанных с метапарсером.

# МЕТАПАРСЕР 2.3

* исправление TakeAll (для частей объекта);
* экспериментальный режим mp.strict_mode;
* mp.inp_delim;
* исправление в mp:match;
* исправление в mp:post_action во время abort_cmd (snapshots);
* исправления в стандартной библиотеке.

# RE:INSTEAD 0.6

* перевод Urzi на английский (спасибо, canwolf!);
* новая игра "Краски октября:;
* Android: совместимость с настройкой rotate lock;
* исправление ошибок.

// Версия для F-Droid в пути!

# Сайт парсерного сопротивления https://parser.hugeping.ru

* обновлён МП;
* добавлены новые игры: Краски октября и перевод Urzi.

# instead-cli 1.6

* обновлён до новой версии МП.

# metaparser-js 2.3

* обновлён до новой версии МП.

#news

Встречайте большое обновление ПАРСЕРНОГО СОПРОТИВЛЕНИЯ!

Вышли новые версии проектов: МЕТАПАРСЕР, Re:instead и metaparser-js.

https://parser.hugeping.ru
https://instead.hugeping.ru/page/metaparser/

# МЕТАПАРСЕР 2.4

Парсерный движок для создания игр с текстовым вводом. Для использования требуется INSTEAD или Re:instead.

https://instead.hugeping.ru/page/metaparser/

Изменения:

* комната gameover теперь имеет атрибут 'gameover';
* функция getDaemons() -- получить список фоновых процессов;
* комната gameover останавливает все фоновые процессы;
* атрибут 'concealed' удаляется, когда предмет перемещается в инвентарь;
* новый метод obj.is_once() для проверки факта срабатывания obj.once();
* обновление документации;
* исправлены/улучшены некоторые сообщения.

# Re:instead 0.7

Минималистичный парсерный движок для Unix, Windows, Plan-9 и Android. В комплект включён набор игр.

* значительное улучшение кернинга при работе с freetype и libschrift;
* параметры -noautoload/-noautosave;
* новый метапарсер 2.4;
* исправления в игре "Краски октября";
* поддержка клавиши del;
* исправление при изменении размера шрифта;
* исправление смены иконки приложения в Windows;
* возможность делать синонимы команд (conf.cmd_aliases);
* Windows: перенаправлять stdout/stderr в errors.txt только если stdout не доступен;
* команды !script и !debug;
* !stop команда в autoscript.

# metaparser-js 2.4

Реализация парсера на js.

* обновление метапарсера до 2.4;
* команды !ls, !rm, !restart;
* возможность загружать и выгружать сохранения;
* возможность выгружать транскрипт (пока только в пределах одной игровой сессии);
* локализация на английский (язык выбирается по основному языку браузера).

Борис Тимофеев выложил Re:instead в Google Play. Так что библиотечка парсерного сопротивления стала ещё доступнее. Не забывайте оценивать приложение, если оно вам нравится. ;)

https://play.google.com/store/apps/details?id=ru.hugeping.reinstead

#news

hugeping> Русский Inform был отложен.

Не знаю, заметил ли это здесь кто-нибудь ещё, но вчера свершилось то, что Грэм Нельсон обещал уже несколько лет подряд: Inform сменил лицензию на OSS. Кроме того там много нового, например возможность компиляции в C. И, конечно, вопрос перевода Inform7 на русский язык остаётся открытым :)

Inform 10.1.0-beta: https://github.com/ganelson/inform

vvs> Не знаю, заметил ли это здесь кто-нибудь ещё...
vvs> Inform 10.1.0-beta: https://github.com/ganelson/inform

Да, тоже заметил. Правда, теперь я уже вряд-ли буду заниматься ещё одним проектом. Тут и на МП то времени нет... Русификация Информ7 интересная задача. Но лично для меня, не очень актуальная. Мне (как программисту) кажется, что логику проще описывать с помощью обычного ЯП.

hugeping> Мне (как программисту) кажется, что логику проще описывать с помощью обычного ЯП.

Хе-хе. За эту ересь тебе с удовольствием устроили бы аутодафе любители функционального и логического программирования. Ну разве не проще логику описывать с помощью исчисления высказываний или функций? :))

Inform 7 - вполне обычный язык программирования, только не императивный, а реляционный/логический, наподобие Пролога. Единственная его особенность - это синтаксис, напоминающий естественный язык, например английский. Что особенно нравится гуманитариям.

Некоторое время назад у проекта INSTEAD на github отвалился travis-CI. В чём там дело я не помню сейчас, но несколько месяцев CI не работала. Вообще, мне не очень нравится идея завязываться на инфраструктуру которую предоставляют компании. Поэтому сначала я думал просто радикально отказаться от всё этой "блажи". Но как-то постепенно я начал переводить все проекты на рельсы github workflow...

Я понял, что сами по себе сценарии могут быть полезны в плане изучения. Например, теперь можно увидеть как собирается версия emscripten: https://github.com/instead-hub/instead/blob/master/.github/workflows/emscripten.yml

Можно изучить сценарий и повторить уже на реальной машине.

На данный момент автоматизирована сборка проектов: instead, instead-cli, metaparser, metaparser-js.

P.S. С instead есть нюанс, собранная версия под Windows -- нерабочая (битая таблица импорта). Похоже, причина в mingw в Ubuntu. Имейте в виду. Интересно, что в wine, при всём этом, она работает. :)

Записал и выложил новый видеоподкаст. INSTEAD и парсерные игры.

https://www.youtube.com/watch?v=5fflaYGf9cY

hugeping> Записал и выложил новый видеоподкаст. INSTEAD и парсерные игры.

Браво! Мне понравилось.

Особенно произвели впечатление усилия по хорошей подборке истории парсерных игр: основательно, последовательно и много ностальгических фотографий :)

Небольшие замечания на будущее. Элизы в моем emacs вообще-то нет, требуется специально её устанавливать, зато везде есть dunnet, который почему-то не упоминается вовсе. Так же не мешало бы упомянуть и SHRDLU, которая являлась настоящей реализацией ИИ для своего времени, тоже в MIT. Музыка в игре временами заглушала речь, да и голос, бодрый и выразительный в начале, несколько увял к концу :(

В целом же всё было изложено весьма познавательно. Спасибо большое!

hugeping>> Записал и выложил новый видеоподкаст. INSTEAD и парсерные игры.

vvs> Браво! Мне понравилось.

Спасибо!

vvs> Небольшие замечания на будущее. Элизы в моем emacs вообще-то нет, требуется специально её устанавливать, зато везде есть dunnet, который почему-то не упоминается вовсе.

Потому что не знал! Почитал, прикольно.

> Так же не мешало бы упомянуть и SHRDLU, которая являлась настоящей реализацией ИИ для своего времени, тоже в MIT.

Спасибо, не знал!

> Музыка в игре временами заглушала речь, да и голос, бодрый и выразительный в начале, несколько увял к концу :(

Там много проблем было со звуком. Я даже выложил 2й ролик https://www.youtube.com/watch?v=el2Dh2HwB3s где пытался исправить звук, но возможно сделал ещё хуже. Не так просто без опыта это делать.

vvs>> Небольшие замечания на будущее. Элизы в моем emacs вообще-то нет, требуется специально её устанавливать

Нашёл-таки у себя doctor - это, похоже, клон Элизы, но только безымянный.

hugeping> Там много проблем было со звуком. Я даже выложил 2й ролик https://www.youtube.com/watch?v=el2Dh2HwB3s где пытался исправить звук, но возможно сделал ещё хуже. Не так просто без опыта это делать.

Я и не думал, что это легко, просто сообщил для сведения. И я и не заметил, что опыта не хватает - мне наоборот показалось, что весьма профессионально снято :)

OK, перебрался в эту тему :)

По поводу DPI. Возможно я написал слишком сумбурно и не очень понятно. На самом деле проблема там не одна и не все связаны с DPI напрямую, но влияют косвенно.

Одна проблема связана с тем, что на полном экране у меня заметно тормозит курсор и поэтому я предпочитаю запускать инстед в окне. Другая - это неправильное переключение видеорежима, когда изображения вообще нет или мусор. Но это далеко не всегда воспроизводимо даже у меня.

А основной вопрос был там такой: при запуске инстеда в окне шрифт по умолчанию слишком мелкий. В настройках стоят: тема и HQ. Версия инстеда 3.5.1, откомпилированная с исходников, ОС Linux (NixOS), видеорежим 1920x1080. Инстед выбирает коэффициент масштабирования 1.058333, поскольку у моего монитора DPI 101.6. Это ещё одна косметическая проблема: я не могу указать дробный DPI, но если инстед берет его от SDL, то реально использует именно это дробное значение.

Но основная проблема, как я уже сказал в мелком шрифте. Коэффициента 1.058333 просто недостаточно на таком мониторе.

P.S. Edited: 2024-01-27 17:59:54

hugeping> Вот обсуждение на форуме на эту тему:
hugeping> https://instead-games.ru/forum/discussion/766/podderzhka-dpi-v-instead-chto-delat

hugeping> Возможно, проблема существует, но мне нужно её увидеть. А так, вроде бы я вижу что масштабируется всё нормально. Странно в общем.

В Windows XP таки масштабируется нормально :)

С моей точки зрения проблема здесь в том, что основная единица измерения, от которой выполняется масштабирование, выбрана произвольно. Согласно википедии, для первоначального значения DPI Apple выбрала 72 типографских пункта, что было вызвано размером экрана, соответствовавшего тогда размеру листа бумаги. Microsoft увеличила это значение ещё на треть и получилось 96. В настоящий момент оно не соответствует никакому физическому явлению и является историческим артефактом.

Если просто вычислить размер экрана, соответствующего разрешению 800x600 и DPI 96, то получается 10" по диагонали - это очень маленький экран. У меня нормальный размер шрифта получается только если исходить из размера экрана 15", что соответствует 67-68 DPI или коэффициет масштабирования 150% (что, кстати, и было реально задано мной в DPI у Windows XP).

Вообще, в современных версиях Windows и Linux DPI вообще нигде не используется, а есть другие API для определения масштаба изображения. Особенно мешает тот факт, что реальный DPI монитора не имеет ничего общего с 96 DPI. Тем не менее я понимаю, чем было вызвано такое решение в INSTEAD - это кажется простым и независимым от платформы способом определения масштаба, но на практике это вовсе не так. Например, в последних версиях Gnome этот параметр всегда принудительно устанавливается 96 DPI для любых мониторов. Ожидать, что среднестатистический пользователь будет знать, как рассчитывается DPI изображения - достаточно нереалистично, особенно если учитывать, что этот параметр даже недокументирован в INSTEAD.

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

Просто мысли вслух :)

> А основной вопрос был там такой: при запуске инстеда в окне шрифт по умолчанию слишком мелкий. В настройках стоят: тема и HQ. Версия инстеда 3.5.1, откомпилированная с исходников, ОС Linux (NixOS), видеорежим 1920x1080. Инстед выбирает коэффициент масштабирования 1.058333, поскольку у моего монитора DPI 101.6. Это ещё одна косметическая проблема: я не могу указать дробный DPI, но если инстед берет его от SDL, то реально использует именно это дробное значение.

Кроме видеорежима хорошо бы сказать размеры монитора, тогда бы мы проверили действительно ли dpi равен 101 :)

А вообще, в таком случае можно указать параметр -dpi число -- чтобы инстед брал именно его, а не тот, что стоит в системе. То-есть, например -dpi 150 -- коэффициент масштабирования станет 150/96

Эту настройку можно записать в профиле инстед. Я сейчас точно не скажу где он лежит (это зависит от ОС и от сборки) но в Linux думаю проще опцию добавить (командной строки).

P.S. Edited: 2024-01-28 22:07:21

vvs> С моей точки зрения проблема здесь в том, что основная единица измерения, от которой выполняется масштабирование, выбрана произвольно. Согласно википедии, для первоначального значения DPI Apple выбрала 72 типографских пункта, что было вызвано размером экрана, соответствовавшего тогда размеру листа бумаги. Microsoft увеличила это значение ещё на треть и получилось 96. В настоящий момент оно не соответствует никакому физическому явлению и является историческим артефактом.

Мы исходим из того, что сегодня DPI всё-таки указывается верно. Ну по кр мере, я вижу на своих Linux системах что действительно в зависимости от размера экрана картинка масштабируется корректно (в оконном режиме!).

vvs> Если просто вычислить размер экрана, соответствующего разрешению 800x600 и DPI 96, то получается 10" по диагонали - это очень маленький экран.

Это если ты меряешь dpi по диагонали. В инстеде используется "горзонтальный" dpi.

vvs> Вообще, в современных версиях Windows и Linux DPI вообще нигде не используется, а есть другие API для определения масштаба изображения.

В SDL2 API предоставляет именно горизонтальный и вертикальный dpi. Я использую горизонтальный.

vvs> Особенно мешает тот факт, что реальный DPI монитора не имеет ничего общего с 96 DPI.

Вот тут я не понял. Реальный DPI монитора должен быть реальным DPI. Ну то-есть, честным DPI. Если у тебя монитор 96 dpi (горизонтальный) то предполагается что SDL2 вернет именно его и промасштабирует как dpi/dpi-темы. dpi-темы можно указать, но если она не указана - то считается что тему разработали на 96 dpi, что не очень далеко от правды, если говорить о стандартных темах.

> Например, в последних версиях Gnome этот параметр всегда принудительно устанавливается 96 DPI для любых мониторов.

Я на gnome сейчас вот в браузере пишу этот текст и у меня масштаб INSTEAD разный на двух системах. От 0.96 до 1.6. Забавно, что xdpyinfo во всех случаях показывает 96x96, но вот SDL api всё-таки возвращает откуда то "честное" dpi.

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

Это возможно только в reinstead. Там изначально масштабируемый интерфейс. А вот в INSTEAD это невозможно.

Опять зацепил не ту клавишу

hugeping> Кроме видеорежима хорошо бы сказать размеры монитора, тогда бы мы проверили действительно ли dpi равен 101 :)

Не веришь джентльмену на слово? Это же смертельное оскорбление :)

Согласно данным производителя, диагональ экрана 21.5", отношение сторон 16:9. Рассчёт показывает 476ммx268мм, xdpyinfo говорит 480ммx270мм - почти не врут. Значит DPI или 102.4x102.4 или 101.6x101.6, смотря кому доверять больше. RandR берет DPI из EDID монитора, лень сейчас туда лезть и смотреть, что там прописано - и так ясно.

hugeping> А вообще, в таком случае можно указать параметр -dpi число -- чтобы инстед брал именно его, а не тот, что стоит в системе. То-есть, например -dpi 150 -- коэффициент масштабирования станет 150/96

hugeping> Эту настройку можно записать в профиле инстед. Я сейчас точно не скажу где он лежит (это зависит от ОС и от сборки) но в Linux думаю проще опцию добавить (командной строки).

Это мне как раз известно и указать -dpi 144 я могу. Вопрос, что делать остальным, кто окажется в моём положении? Я тут уже высказывал мнение, что это слишком косвенный и непонятный способ задать просто коэффициент масштабирования 1.5. И, кстати, опять вопрос, что тогда всё-таки делать с дробным DPI?

hugeping> Мы исходим из того, что сегодня DPI всё-таки указывается верно. Ну по кр мере, я вижу на своих Linux системах что действительно в зависимости от размера экрана картинка масштабируется корректно (в оконном режиме!).

А у меня - нет. DPI 96x96 если только я не выставляю его сам вручную. Gnome версии около 44.2 (трудно понять из такого зоопарка для его разных компонентов). В предыдущей версии такого безобразия вроде не было, но интернет подтверждает, что это их официальное решение.

vvs>> Если просто вычислить размер экрана, соответствующего разрешению 800x600 и DPI 96, то получается 10" по диагонали - это очень маленький экран.

hugeping> Это если ты меряешь dpi по диагонали. В инстеде используется "горзонтальный" dpi.

Нет: 800 / 96 = 8.33" и 600 / 96 = 6.25", по теореме Пифагора диагональ - 10.42".

vvs>> Особенно мешает тот факт, что реальный DPI монитора не имеет ничего общего с 96 DPI.

hugeping> Вот тут я не понял. Реальный DPI монитора должен быть реальным DPI. Ну то-есть, честным DPI. Если у тебя монитор 96 dpi (горизонтальный) то предполагается что SDL2 вернет именно его и промасштабирует как dpi/dpi-темы. dpi-темы можно указать, но если она не указана - то считается что тему разработали на 96 dpi, что не очень далеко от правды, если говорить о стандартных темах.

У меня честный DPI - 101.6 (см. выше). Для темы 800x600 и DPI 96 - это значит, что она была разработана для 10" монитора, где шрифт нечитаем.

Как я уже упоминал, DPI 96 не соответствует никакому реальному монитору и был рассчитан на мониторы Apple в незапамятные времена, с поправкой Microsoft на то, что мы сидим от экрана на треть дальше, чем от книги. Давай сначала зададимся вопросом, для какого разрешения и диагонали экрана был это DPI? Ну уж точно не для 800x600 10".

hugeping> Я на gnome сейчас вот в браузере пишу этот текст и у меня масштаб INSTEAD разный на двух системах. От 0.96 до 1.6. Забавно, что xdpyinfo во всех случаях показывает 96x96, но вот SDL api всё-таки возвращает откуда то "честное" dpi.

У меня и xdpyinfo, и SDL, и INSTEAD видят то, что я им укажу. По умолчанию 96x96, я специально меняю на DPI монитора с помощью `xrandr --dpi from-output`, но это даёт 101.6, т.е. 101.6 / 96 = 1.058333, а не 1.5, как я бы ожидал в реальности.

hugeping> Мы исходим из того, что сегодня DPI всё-таки указывается верно. Ну по кр мере, я вижу на своих Linux системах что действительно в зависимости от размера экрана картинка масштабируется корректно (в оконном режиме!).

Ты мне сейчас кое-что напомнил: действительно, некоторые дистрибутивы линукса патчат гном. Так что я не удивлюсь если где-то до сих пор DPI отличается от 96.

vvs> Ты мне сейчас кое-что напомнил: действительно, некоторые дистрибутивы линукса патчат гном. Так что я не удивлюсь если где-то до сих пор DPI отличается от 96.

У меня xdpyinfo показывает 96, но SDL2 возвращает что-то иное, так что масштаб становится 1.5.
Что именно берет SDL2 я не знаю, но это честный какой-то DPI.

> У меня и xdpyinfo, и SDL, и INSTEAD видят то, что я им укажу. По умолчанию 96x96, я специально меняю на DPI монитора с помощью `xrandr --dpi from-output`, но это даёт 101.6, т.е. 101.6 / 96 = 1.058333

А какие темы-игры? В принципе, можно поменять dpi с 96 на 72.

Какие решения ещё тут могуть быть?

hugeping> Какие решения ещё тут могуть быть?

Ты предлагаешь настройку "масштаб" сделать в меню?

hugeping> У меня xdpyinfo показывает 96, но SDL2 возвращает что-то иное, так что масштаб становится 1.5.
hugeping> Что именно берет SDL2 я не знаю, но это честный какой-то DPI.

Странно. А это точно SDL? Может ты раньше прописал масштаб в профиль инстеда и забыл? Если удалить файл конфигурации тоже масштабирует 1.5:1? А какая версия SDL? Нет ли там каких-то патчей специфичных для дистрибутива?

У меня в гноме установлено масштабирование шрифта 1.5 и все приложения гнома имеют нормальный масштаб и даже Firefox. Индивидуальных настроек требуют все не GTK-приложения, как INSTEAD, mupdf, wine, RetroArch или DOSBox. Но кроме INSTEAD никто больше не использует DPI. В wine есть свой собственный DPI, но он совсем какой-то другой масштаб даёт и не связан с монитором вообще.

hugeping> А какие темы-игры? В принципе, можно поменять dpi с 96 на 72.

Я тестировал только на Tutorial. Кстати, я там случайно заметил баг в описании командной строки: написано "-windows", а должно быть "-window" - это на русском, на английском всё правильно.

Менять на 72 я особого смысла не вижу. А почему тогда именно 72? Это опять какая-то магическая константа. Мне так больше подходит 67, а кому-то может и нет.

hugeping> Какие решения ещё тут могуть быть?

hugeping> Ты предлагаешь настройку "масштаб" сделать в меню?

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

Разве что идея растягивать окно, но ты говоришь, что это невозможно. А почему? Разве нельзя написать обработчик, который будет динамически менять масштаб если тянуть мышкой за угол окна? Или придётся каждый раз делать рестарт?

Кстати, я заметил, что Tatham's puzzles имеют нормальный размер шрифта, хотя сами вроде используют только x.org. Похоже, что гном что-то меняет и для сервера шрифтов x.org тоже: http://www.chiark.greenend.org.uk/~sgtatham/puzzles/

P.S. А-а, теперь вижу, что там GTK используется.

P.S. Edited: 2024-01-30 15:41:20

vvs> Странно. А это точно SDL?
Да, я вывожу printf dpi из C кода в момент взятия:

157.825241 -- это НАСТОЯЩИЙ dpi
DPI scale: 1.644013
Video mode: 1315x986@32bpp (opengl)
peter@t480:~/Devel/instead$ xdpyinfo | grep 96
  resolution:    96x96 dots per inch -- это ФИКТИВНЫЙ о котором ты говоришь 

vvs> У меня в гноме установлено масштабирование шрифта 1.5 и все приложения гнома имеют нормальный масштаб и даже Firefox.

Там куча разных настроек. Я сейчас уже не помню детали, но на масштаб шрифта есть свои хитрости, типа Xft.dpi - это к нам не относится.

vvs> Менять на 72 я особого смысла не вижу. А почему тогда именно 72? Это опять какая-то магическая константа. Мне так больше подходит 67, а кому-то может и нет.

Нужно вручную вписать dpi в темы так, чтобы они выглядели нормально. То-есть не меняя системное dpi - меняй dpi каждой темы пока она не станет хорошо. А я проверю это у себя.

vvs> Просто DPI - это достаточно окольный и ненадёжный параметр для масштабирования.

Мне пока кажется что он надёжен. Я пока не видел систем где DPI возвращается неправильно. Даже в windows оно работает как надо. Я тебе верю, но мне нужен какой-то опыт. Но я исходил из 2х предпосылок:

1) Нативные темы НОРМАЛЬНО смотрятся на ЧЕСТНЫХ dpi 96
2) SDL2 даёт верный dpi

Пп1 - возможно, я не прав. Но тогда нужно взять конкретную тему и предложить тот dpi в которой она нормально смотрится. Я попробую у себя и сравним ощущения.

Пп2 можно проверить. Воткни в graphics.c в функции gfx_get_dpi() в конце printf("%f\n", hdpi) и сравним с твоим реальным dpi;

vvs> Разве что идея растягивать окно, но ты говоришь, что это невозможно. А почему?

Потому что INSTEAD поддерживает другую парадигму -- игра жёстко привязана к определенным пропорциям и выглядит одинаково вне зависимо от масштаба. Все игры уже написаны так что привязаны к своему разрешению виртуальному. На лету это не меняется в принципе. Если это менять -- то это уже INSTEAD4. Есть другие мои движки где по другому: reinstead и rein-- если и будет инстед4 то он будет на rein.

hugeping> Нужно вручную вписать dpi в темы так, чтобы они выглядели нормально. То-есть не меняя системное dpi - меняй dpi каждой темы пока она не станет хорошо. А я проверю это у себя.

Ну тут всё совсем плохо :(

Запускаю Tutorial: масштаб 1.058333, режим 846x634, окно, шрифт - мелкие. Выхожу, указываю -dpi 144: масштаб 1.5, режим 1200x900, окно, шрифт - нормальные. Выбираю в меню игру "Кнопка": масштаб 1.5, режим 1920x1080, окно не помещается на экране, глюки, ни текста, ни курсора нет вообще. Переключаюсь между окнами и обратно: текст появляется нормального размера, окно так и не умещается, курсор тормозит. Выхожу, не указываю -dpi: окно нормальное, текст мелкий. Выбираю в меню опять Tutorial: всё, как и раньше - всё мелкое.

hugeping> Пп2 можно проверить. Воткни в graphics.c в функции gfx_get_dpi() в конце printf("%f\n", hdpi) и сравним с твоим реальным dpi;

Да, ты прав. SDL действительно видит настоящий DPI - 101.599998, хотя xdpyinfo и показывает 96x96, т.е. для инстеда менять его нет необходимости. Но это ничего не даёт на практике :(

vvs> Запускаю Tutorial: масштаб 1.058333, режим 846x634, окно, шрифт - мелкие. Выхожу, указываю -dpi 144: масштаб 1.5,

А надо было сделать не это, надо было сделать _другое_.
А именно - открыть тему которую ты используешь (.ini файл) и в теме написать
scr.dpi = 72 (или другое число)

vvs> Да, ты прав. SDL действительно видит настоящий DPI - 101.599998, хотя xdpyinfo и показывает 96x96, т.е. для инстеда менять его нет необходимости. Но это ничего не даёт на практике :(

На практике это даёт возможность разработчику темы написать scr.dpi = и тот dpi на котором они её разработали (на котором она хорошо смотрится). Это всё что нужно.. Вот я тебя и прошу - найди такой хороший dpi для стандартных тем, сообщи мне - и я попробую на своих мониторах..

https://instead-games.ru/forum/discussion/comment/13852/#Comment_13852

На всякий случай ещё раз укажу на сообщение в котором это написано.