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

- МЕТАПАРСЕР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

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

* исправлено падение при вызове 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

Выпустил 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/

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

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

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

Результат-то практически тот-же, только вместо -dpi 144 я тогда пишу scr.dpi = 67 (72 тоже пойдёт, но несколько мельче). И всё-равно в "Кнопке" слишком большое окно, графические глюки и тормозит курсор. Единственное отличие - в главном меню INSTEAD теперь тоже нормальный шрифт (если последней была загружена нормальная тема).

И сразу видно, что если на моём мониторе коэффициент 1.5, то на твоём мониторе тогда будет уже двойное масштабирование. Не уверен, что это всем понравится.

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

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

А вот в игре "Переход" ни этот параметр, ни -dpi 144 почему-то не действуют.

Надо потестировать и в других играх, но сегодня уже поздно.

vvs> Результат-то практически тот-же, только вместо -dpi 144 я тогда пишу scr.dpi = 67 (72 тоже пойдёт, но несколько мельче).

Возможно, стоит попробовать 72 как "умолчательный" dpi. Тогда по кр мере дефолтные темы будут везде выглядеть более правильно.

vvs> И всё-равно в "Кнопке" слишком большое окно, графические глюки и тормозит курсор.

Это всё-таки уже особенностями конкретной игры.
Большое окно, значит нужно scr.dpi в теме для кнопки другое выставить и перезалить в репозиторий.
Графические глюки - не видел никогда, не знаю. Нужно воспроизведение. Пока этого нет я ничего ответить не могу. Ради интереса, можно выставить -software, если пропадут - то глюки скорее всего относятся к SDL+драйверы. Если не пропадут, возможно, к самой кнопке.

А курсор рывками, думаю, потому что игра сама отрисовывает свои кадры, в таком режиме курсор тоже отрисовывается с частотой кадров игры. То-есть, стоит скажем 25 fps и курсор рисуется так же. Так что, я думаю, это "фича" "кнопки". В прочем, там такое было только в заставках. Если не изменяет память. В INSTEAD есть режим использовать системный курсор, кстати.


Единственное отличие - в главном меню INSTEAD теперь тоже нормальный шрифт (если последней была загружена нормальная тема).

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

vvs> Кстати, курсор тормозит явно из-за отсутствия его аппаратной поддержки. В остальных (не INSTEAD) играх и приложениях такое не наблюдается.

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

vvs> А вот в игре "Переход" ни этот параметр, ни -dpi 144 почему-то не действуют.

vvs> Надо потестировать и в других играх, но сегодня уже поздно.

Я скачал кнопку и запустил. Машина 12 летней давности. Запускал и без аккселерации и с ней. Работает очень гладко. Не знаю, я не смогу помочь наверное. Возможно какие-то особенности конкретной системы. Ради интереса, поставь wine и запусти windows версию. Я думаю проблемы уйдут.

Проверил 72 на разных мониторах. Я считаю что 96 как стандартный dpi лучше, всё-таки. В общем, не знаю даже, пока проблемы я не увидел. Поддержку highdpi можно выключить если она мешает сняв HQ в настройках. Вообще, предполагается что она нужна в основном для 2K и 4K мониторов.

Загрузка процессора в самой игре - 3%. В общем, не знаю. Нужно отлаживать конкретно на твоей системе.

hugeping> Возможно, стоит попробовать 72 как "умолчательный" dpi. Тогда по кр мере дефолтные темы будут везде выглядеть более правильно.

У меня-то будут, а, например, у тебя? Я так понял, что тебя и 96 вполне устраивает, поскольку на экране твоего монитора это уже достаточно большой шрифт. А как тогда это будет выглядеть на 4k?

vvs>> И всё-равно в "Кнопке" слишком большое окно, графические глюки и тормозит курсор.

hugeping> Это всё-таки уже особенностями конкретной игры.
hugeping> Большое окно, значит нужно scr.dpi в теме для кнопки другое выставить и перезалить в репозиторий.

Не поможет. Там либо окно слишком большое, либо шрифт слишком мелкий. А вот "Переход" - совсем не реагирует на масштабирование. А это, по-моему, одна из лучших игр на INSTEAD.

hugeping> Графические глюки - не видел никогда, не знаю. Нужно воспроизведение. Пока этого нет я ничего ответить не могу. Ради интереса, можно выставить -software, если пропадут - то глюки скорее всего относятся к SDL+драйверы. Если не пропадут, возможно, к самой кнопке.

Нет, у меня такие глюки были и в других играх INSTEAD, только я не всегда могу их воспроизвести. Возможно зависит от размера окна? Выглядит так, как будто после переключения режима буфер не в фокусе и не обновился, а после переключения окон внезапно отображается.

hugeping> А курсор рывками, думаю, потому что игра сама отрисовывает свои кадры, в таком режиме курсор тоже отрисовывается с частотой кадров игры. То-есть, стоит скажем 25 fps и курсор рисуется так же. Так что, я думаю, это "фича" "кнопки". В прочем, там такое было только в заставках. Если не изменяет память. В INSTEAD есть режим использовать системный курсор, кстати.

Там есть когда рывками, а есть когда он начинает ползти с запаздыванием. И не только в "Кнопке" и только в большом разрешении. Явно OpenGL не используется, а отрисовывается процессором и производительности ему не хватает. У меня 3 ГГц, если что. А вот OpenGL только версии 2.1. Но в традиционных приложениях и играх ничего такого не ощущается, а INSTEAD тоже вроде не AAA видео игра.

vvs> У меня-то будут, а, например, у тебя?
vvs> Не поможет. Там либо окно слишком большое, либо шрифт слишком мелкий.

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

Другое дело, что игроку может не понравится то, как видит игру автор. Кто-то очень любит мелкий шрифт, кто-то наоборот. Для этого придётся менять масштаб шрифта под себя, как по другому?

vvs> А вот "Переход" - совсем не реагирует на масштабирование. А это, по-моему, одна из лучших игр на INSTEAD.

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

vvs> Выглядит так, как будто после переключения режима буфер не в фокусе и не обновился, а после переключения окон внезапно отображается.

У меня подобные проблемы были с nvidia + gnome. Правда не только в инстеде. Я не помню, как я их решил. Попробуй -software.

vvs> Явно OpenGL не используется

Да нет, используется. Спрайты грузятся заранее и потом блитятся SDL2, который ускорение должен использовать. Чтобы его отключить, пишешь -software. В общем, мне все-таки кажется что с SDL2 что-то не так. Кстати, иногда я встречал проблему когда люди собирали инстед как-то странно, и там была сместь SDL2 и SDL1 библиотек. Проверь на всякий случай ldd sdl-instead.

vvs> а INSTEAD тоже вроде не AAA видео игра.

Инстед очень нетребовательное приложение. Оно разрабатывалось с учетом того, чтобы работать даже по vnc протоколу (и хорошо кстати работает), потому что оно отрисовывает только изменения. Грубо говоря, когда ты ведешь курсор - ничего кроме курсора не меняется. Надо ли говорить, что даже в софтварном режиме производительности на это любого процессора достаточно? А ведь инстед хорошо работал и на АРМ КПК с 100-400 мгц.