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

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

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 мгц.

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

Ты не учитываешь ни физический размер экрана, ни расстояние, на котором он находится, ни другие различия между системами и выдаёшь желаемое за действительное. Давай рассмотрим факты.

Я только что пошёл и запустил INSTEAD на Windows XP, где другой компьютер и графическая карта, но такой же точно монитор и видео режим. И я вижу, что во-первых размер окна "Кнопки" примерно равен 31 см, но на моём компьютере он равен примерно 33 см. Дальше я вижу, что в душе слово "кран" находится в начале второй строки, а у меня в конце первой, т.е. размер шрифта тоже разный. Это легко объяснить если посмотреть даже на коэффициент масштабирования, который в Windows равен 1.0, а у меня - 1.058333. Это при том, что я ничего не меняю и использую DPI по умолчанию (96).

Теперь, если я указываю в Windows -dpi 102, то коэффициент масштабирования уже ближе к моему и размер окна почти совпадает, но шрифт по-прежнему - нет. А кто вообще сказал, что при масштабировании TrueType шрифтов используется DPI? Не говоря уже о том, что даже указать точно такой же DPI я уже не могу, поскольку он дробный.

Теперь насчёт "честного" dpi, а где его взять? В Windows нет ничего, кроме dpi экрана, который может быть любым, какой я укажу или 96 по умолчанию. В Linux у меня есть xdpyinfo, который показывает 102 если я использую для его установки xrandr --dpi, несмотря на то, что на самом деле он вообще-то тут равен 101.6. Если я переключаю видеорежим с помощью xrandr из 1280x720 в 1920x1080, то он тогда равен 144. Если же я переключаю видеорежим из управляющей панели гнома, то он всегда будет равен 96. А вот SDL всегда видит "честный" dpi: 101.6 на Linux и 96 на Windows XP. Кстати, википедия утверждает, что DPI вообще нет в Windows 8 а в остальных версиях у него косметический характер.

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

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

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

"Переход" перестаёт масштабироваться, когда разрешение по вертикали достигает максимума для данного видеорежима. Просто у него изначально уже достаточно большое разрешение.

Для "Кнопки" и "Перехода", из-за большого размера окна, не остаётся никакой другой возможности масштабирования, кроме масштабирования шрифта. К сожалению это глобальный параметр и для каждой игры его приходится настраивать каждый раз заново. Это, разумеется, справедливо для всех игр с большим окном на мониторе с не очень большим DPI. И если для темы 800x600 изменение DPI обычно помогает, то тут это бесполезно. При этом на экране 1280x720 шрифт с -dpi 96 (по-умолчанию) будет выглядеть нормально, а на 1920x1080 - уже нет. Замечу, что это может быть один и тот же монитор. Изменение умолчания scr.dpi = 67.7 поможет в обоих случаях, однако рассчитать масштаб для командной строки становится уже совсем затруднительным, например даже -dpi 96 уже может означать самый разный коэффициент масштабирования для разных тем. Но даже смена уже заранее известного DPI выполняется только методом проб и ошибок, пока результат не будет удовлетворительным. Текущее умолчание 96 работает нормально по-видимому только на экранах с достаточно большим DPI (мониторы 21.5" оказываются в невыгодном положении). Хотя что тогда говорить про смартфон с DPI 480? Пользоваться виртуальным экраном?

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

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

Окно уходит из фокуса и не обновляется (и даже иногда не отображается) при переключении режима если оно не помещается на рабочем столе. При переключении из другого окна оно сразу отображается корректно. Похоже, что если окно не умещается на десктопе, то создаётся уже за его пределами.

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

hugeping> Да нет, используется. Спрайты грузятся заранее и потом блитятся SDL2, который ускорение должен использовать. Чтобы его отключить, пишешь -software.

Курсор перестаёт тормозить если указать -nocursor, причём загрузка процессора остаётся совершенно такая же: за 30% для opengl и до 100% -software. При разрешении монитора 1280x720 торможение не заметно. В чём тут загвоздка мне неизвестно.

Более того, я проверил это и на Windows XP и там то же самое. А видеокарта там совсем другая и даже OpenGL 3.3. Это особенно хорошо заметно в окне, когда курсор пролетает через весь экран и проходит то десктоп, то окно INSTEAD попеременно.

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

В NixOS такое обычно невозможно, только если специально постараться.

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

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

Я тут проверил список требуемых библиотек с помощью ldd и получил следующий список. "Нетребовательность" - понятие относительное, а так вообще INSTEAD немного похож на маленькую операционную систему. Только без обид ;)

linux-vdso.so.1 libz.so.1 liblua.so.5.3 libm.so.6 libSDL2-2.0.so.0 libSDL2_mixer-2.0.so.0 libSDL2_image-2.0.so.0 libSDL2_ttf-2.0.so.0 libgtk-3.so.0 libgdk-3.so.0 libpangocairo-1.0.so.0 libpango-1.0.so.0 libharfbuzz.so.0 libatk-1.0.so.0 libcairo-gobject.so.2 libcairo.so.2 libgdk_pixbuf-2.0.so.0 libgio-2.0.so.0 libgobject-2.0.so.0 libglib-2.0.so.0 libc.so.6 libdl.so.2 libreadline.so.8 libncursesw.so.6 ld-linux-x86-64.so.2 libX11.so.6 libXext.so.6 libXcursor.so.1 libXi.so.6 libXfixes.so.3 libXrandr.so.2 libXss.so.1 libpthread.so.0 librt.so.1 libmodplug.so.1 libfluidsynth.so.3 libopusfile.so.0 libtiff.so.6 libwebp.so.7 libsharpyuv.so.0 libgmodule-2.0.so.0 libpangoft2-1.0.so.0 libfontconfig.so.1 libfribidi.so.0 libepoxy.so.0 libatk-bridge-2.0.so.0 libtracker-sparql-3.0.so.0 libxkbcommon.so.0 libwayland-client.so.0 libwayland-cursor.so.0 libwayland-egl.so.1 libXdamage.so.1 libXcomposite.so.1 libXinerama.so.1 libthai.so.0 libfreetype.so.6 libgraphite2.so.3 libpixman-1.so.0 libEGL.so.1 libpng16.so.16 libxcb-shm.so.0 libxcb.so.1 libxcb-render.so.0 libXrender.so.1 libGL.so.1 libjpeg.so.62 libmount.so.1 libselinux.so.1 libffi.so.8 libpcre2-8.so.0 libstdc++.so.6 libmvec.so.1 libgcc_s.so.1 libgomp.so.1 libgthread-2.0.so.0 libsndfile.so.1 libpulse-simple.so.0 libpulse.so.0 libasound.so.2 libjack.so.0 libogg.so.0 libopus.so.0 liblzma.so.5 libdeflate.so.0 libbz2.so.1 libbrotlidec.so.1 libexpat.so.1 libatspi.so.0 libdbus-1.so.3 libjson-glib-1.0.so.0 libxml2.so.2 libsqlite3.so.0 libdatrie.so.1 libGLdispatch.so.0 libXau.so.6 libXdmcp.so.6 libGLX.so.0 libblkid.so.1 libpcre.so.1 libFLAC.so.12 libvorbis.so.0 libvorbisenc.so.2 libmpg123.so.0 libmp3lame.so.0 libpulsecommon-16.1.so libcelt0.so.2 libbrotlicommon.so.1 libsystemd.so.0 libcap.so.2

vvs> ни физический размер экрана, ни расстояние, на котором он находится

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

vvs> выдаёшь желаемое за действительное.

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

vvs> размер окна "Кнопки" примерно равен 31 см, но на моём компьютере он равен примерно 33 см.

Это прекрасный результат, на мой взгляд. Я думаю что на xp кстати dpi не берется.

> торый в Windows равен 1.0, а у меня - 1.058333.

Вот и подтверждение. dpi где-то может не работать. А на win 10, например, он работает.

vvs> А кто вообще сказал, что при масштабировании TrueType шрифтов используется DPI?

Код INSTEAD.

Про дробность dpi даже нечего сказать. Этл совершенно непринципиальная погрешность.

vvs> Теперь насчёт "честного" dpi, а где его взять?

Если оч. интересно, надо изучать код SDL. Мои факты: работает на всех моих линуксах и Win10. Те. откуда то, берет. Как написано в мануале сдл, так и работает.

vvs> Курсор перестаёт тормозить если указать -nocursor, причём загрузка процессора остаётся совершенно такая же: за 30% для opengl и до 100% -software. При разрешении монитора 1280x720 торможение не заметно. В чём тут загвоздка мне неизвестно.

Да, 100% - это явная аномалия. У меня нп eepc даже близко такого нет. Проблема не в коде инстеда. Либо ты смлтришь анимации кнопки, там мб что угодно.

vvs> Более того, я проверил это и на Windows XP и там то же самое. А видеокарта там совсем другая и даже OpenGL 3.3. Это особенно хорошо заметно в окне, когда курсор пролетает через весь экран и проходит то десктоп, то окно INSTEAD попеременно.

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


vvs> Я тут проверил список требуемых библиотек с помощью ldd и получил следующий список. "Нетребовательность" - понятие относительное, а так вообще INSTEAD немного похож на маленькую операционную систему. Только без обид ;)

Инстед собирается с SDL. SDL можно собрать по разному. Кроме того, можно собрать с gtk3 для файлового диалога. Но в любом случае, это не антидовод на мой тезис о том, что во время отрисовки курсора меняется маленькая область. Буквально десятко пикселей на десятлк пикселей. Даже на питоне я бы не смог написать такой код, чтобы жрать 100% при этом.

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

Гм, например, ты пишешь что смена -dpi не влияет на шрифт. Можно 2 скриншота с -dpi 72 и -dpi 150, например?

vvs>> ни физический размер экрана, ни расстояние, на котором он находится

hugeping> Учитывактся физический размер картинки. Предполагается, что экран должен попасть в поле обзора человека, так что расстояние от экрана не так сильно должно влиять на корректность масштаба. Естественно, идеала не будет, но будет видно при запуске на 4к мониторе. А вот без механизма - не будет.

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

vvs>> выдаёшь желаемое за действительное.

hugeping> Я пользователь инстед и мой опыт говорит, что текущее решение приемлемо.

Это субъективно. Мне, например, требуется очень сильно напрягать зрение, пытаясь разглядеть мелкий шрифт на 1920x1080. А вот 1280x720 для меня вполне комфортно. Причём монитор один и тот же и ограничение выглядит искусственно.

hugeping> Вот и подтверждение. dpi где-то может не работать. А на win 10, например, он работает.

И? То есть механизм далеко не универсален и его результат во многом зависит от удачи.

vvs>> А кто вообще сказал, что при масштабировании TrueType шрифтов используется DPI?

hugeping> Код INSTEAD.

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

hugeping> Про дробность dpi даже нечего сказать. Этл совершенно непринципиальная погрешность.

Может и так, но она тоже выглядит совершенно искусственной. Почему нельзя указать дробный DPI? Ведь в системе он именно такой.

vvs>> Теперь насчёт "честного" dpi, а где его взять?

hugeping> Если оч. интересно, надо изучать код SDL. Мои факты: работает на всех моих линуксах и Win10. Те. откуда то, берет. Как написано в мануале сдл, так и работает.

Вопрос был о разработчике игры. Он тоже должен изучать код SDL, чтобы указать правильный DPI в своей теме? А какие у него сегодня альтернативы? Как этот механизм должен работать на практике?

vvs>> Более того, я проверил это и на Windows XP и там то же самое. А видеокарта там совсем другая и даже OpenGL 3.3. Это особенно хорошо заметно в окне, когда курсор пролетает через весь экран и проходит то десктоп, то окно INSTEAD попеременно.

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

Это во всех играх и зависит только от режима (размера окна) и курсора. Почему-то системный курсор не тормозит совсем. Я не знаю почему. Сначала грешил на драйвер, но на другом компьютере то же самое.

hugeping> Инстед собирается с SDL. SDL можно собрать по разному. Кроме того, можно собрать с gtk3 для файлового диалога. Но в любом случае, это не антидовод на мой тезис о том, что во время отрисовки курсора меняется маленькая область. Буквально десятко пикселей на десятлк пикселей. Даже на питоне я бы не смог написать такой код, чтобы жрать 100% при этом.

Это и не был никакой "антидовод" ни на что - это была шутка. И я специально указал смайлик, чтобы это было очевидно.

hugeping> В общем, я завершаю этот диалог. Мне обиднл, конечно, что ты считаешь что инстед работает так плохо, но я не могу ничего поделать. Я не наблюдаю проблем о которых ты мне сообщил, и сделать ничего не могу. А свои доводы я уже 3й раз написал.

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

> Ты сам рисуешь все шрифты или используешь чужие библиотеки? И ты веришь, что эти библиотеки всегда дают одинаковый результат на разных системах?

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

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

>> Ты сам рисуешь все шрифты или используешь чужие библиотеки? И ты веришь, что эти библиотеки всегда дают одинаковый результат на разных системах?

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

И если всё так и есть, то почему же при -dpi 102 я вижу одно и то же слово в разных строках на разных системах? Где логика?

hugeping> Я читаю твой текст и ничего не понимаю. Например ты говоришь о разных разрешениях на однои и том же мониторе... Что это вообще значит и какой в этом смысл?

То есть? Теперь уже я ничего не понимаю. Я переключаю разрешения на одном мониторе и сравниваю результаты. Весь же разговор и начался с того, что я перешёл с разрешения 1280x720 на 1920x1080 и что из этого вышло. А почему я предпочитал меньшее разрешение я тоже упоминал неоднократно: потому что там шрифт крупнее, а моё зрение мне дорого, как память и читать мелкий шрифт - глазам больно. Ты же в последних сообщениях уже говоришь, что это всё не имеет значения. Ну извини, но для меня имеет, ещё какое. Хотя ты сначала доказывал, что размер изображения должен везде совпадать при "честном" dpi. Отсюда и вопросы: что это такое, где его взять и почему размер всё равно разный?

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

P.S. Было бы странно если бы Птолемей набросился с бранью на Галилея, за то, что тот утверждал, что Солнце вращается вокруг Земли, а не наоборот.

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

1) Если в настройках инстеда стоит HQ опция, разрешение стоит как "тема" и не стоит полный экран то:
2) Смотрится dpi в теме игры, если dpi не задано - то это принимается за 96
3) Выбирается масштабирование как: dpi системы/dpi темы
4) Масштабирование влияет как на шрифт так и на само изображение (одинаково), но масштабируется не картинка целиком, а "векторно" - масштабируются шрифты, картинки и координаты - тем самым 100% идентичности может не быть, но в целом -- будет близко
5) В некоторых системах/сборках получить dpi системы невозможно.
6) В таком случае можно задать -dpi через опцию
7) Разработчику игры с собственной темой в scr.dpi в теме нужно указать dpi (или диапазон) своего экрана на котором он разрабатывал тему

В процессе нашего обсуждения я проверил следующие утверждения:
1) При изменении -dpi масштабируется картинка, но не масштабируется шрифт - НЕ ПОДТВЕРЖДЕНО
2) В Гноме dpi всегда 96 -- НЕ ПОДТВЕРЖДЕНО (xdpyinfo показывает 96, но SDL возвращает честный dpi), проверено на разных системах с разным dpi, DPI всегда совпадает с реальным.

Проблему тормозов курсора объяснить я не смог. Мне нужна воспроизводимость, которой нет ни на одной из моих систем (bsd, несколько linux, windows, смартфон).

Я считаю, что даже не смотря на проблемы, фича с масштабированием dpi решает конкретную проблему - готовность работать на 2k/4k экранах. Если она не устраивает - ее можно
1) отключить
2) прислать другие решения - но конкретные

Больше я ничего писать на эту тему не буду.
P.S. Edited: 2024-01-31 18:38:32

hugeping> В процессе нашего обсуждения я проверил следующие утверждения:
hugeping> 1) При изменении -dpi масштабируется картинка, но не масштабируется шрифт - НЕ ПОДТВЕРЖДЕНО

А я и не это утверждал, а совсем другое: шрифт и картинка имеют разное масштабирование. Это видно уже потому, что при одинаковом dpi одно и то же слово находится в разных строках. EDIT: Был не прав, проблема в точности дробного DPI.

hugeping> 2) В Гноме dpi всегда 96 -- НЕ ПОДТВЕРЖДЕНО (xdpyinfo показывает 96, но SDL возвращает честный dpi), проверено на разных системах с разным dpi, DPI всегда совпадает с реальным.

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

hugeping> Проблему тормозов курсора объяснить я не смог. Мне нужна воспроизводимость, которой нет ни на одной из моих систем (bsd, несколько linux, windows, смартфон).

Объяснить я её тоже не могу. Но у меня это на всех системах наблюдается. Запишем в загадки.

Да, я забыл упомянуть, что когда курсор находится в окне INSTEAD, то загрузка процессора заметно подскакивает. Причём это не зависит от того, какой курсор я использую: и курсор INSTEAD и системный - одинаково. Это делает всё ещё более загадочным.

hugeping> Я считаю, что даже не смотря на проблемы, фича с масштабированием dpi решает конкретную проблему - готовность работать на 2k/4k экранах. Если она не устраивает - ее можно
hugeping> 1) отключить
hugeping> 2) прислать другие решения - но конкретные

Наверное, но вот мою проблему она не решает. Отключение же её мне тоже никак не поможет, а вот другое решение меня очень интересует.

И я тоже ещё раз повторю свои проблемы:

1. Масштабирование неинтуитивное и шрифт обычно получается слишком мелкий, коэффициент приходится подбирать опытным путём для каждой системы и монитора.
2. Для игр с большим окном масштабирование просто невозможно, приходится отдельно масштабировать шрифт и менять его для каждой игры.
3. При переключении видеорежима надо опять менять все настройки.
4. При большом окне (или что то же самое - его разрешении) начинает тормозить курсор INSTEAD и приходится его отключать.
5. При слишком большом масштабировании окна (больше доступного места на рабочем столе) оно перестает нормально работать и требуется переключаться туда-сюда между окнами, пока оно не начинает отображаться правильно.

Всё это у меня происходит только в видеорежиме 1920x1080, а в 1280x720 - всё работает более-менее нормально (я не утверждаю, что там совсем нет проблем, но я их обычно не замечаю).

P.S. Edited: 2024-01-31 23:52:12

hugeping>> Про дробность dpi даже нечего сказать. Этл совершенно непринципиальная погрешность.

vvs> Может и так, но она тоже выглядит совершенно искусственной. Почему нельзя указать дробный DPI? Ведь в системе он именно такой.

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

Сейчас делал скриншоты и нарвался на этот самый факт. На Linux я на самом деле раньше при проверке не задал -dpi 102, поскольку тоже посчитал это "непринципиальной погрешностью", а напрасно. Если задать целый dpi, то никакой разницы в положении слова не будет совершенно (но можно ведь задать и 101 :)). Так что слово "кран" (и даже из целых четырёх букв) было там в разных строках именно из-за разности между 102 и 101.6. Ну кто бы мог подумать :/

Так что своё утверждение о разном масштабировании окна и шрифтов я беру обратно - был не прав. Вот и проводи тестирование в таких условиях, может хоть это убедит тебя добавить поддержку дробных аргументов? Кстати, это в полной мере справедливо и для тем с scr.dpi, где для точного масштабирования нужно было указывать 67.73333. Вот тебе и "честный" DPI ;)

hugeping>> Проблему тормозов курсора объяснить я не смог. Мне нужна воспроизводимость, которой нет ни на одной из моих систем (bsd, несколько linux, windows, смартфон).

vvs> Объяснить я её тоже не могу. Но у меня это на всех системах наблюдается. Запишем в загадки.

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

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

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

Курсор отрисовывается по координатам событий от мышки в окне. Пришло событие от SDL с указанием координат - рисуем курсор. Так что "скорости" движения не причём.

hugeping> Курсор отрисовывается по координатам событий от мышки в окне. Пришло событие от SDL с указанием координат - рисуем курсор. Так что "скорости" движения не причём.

Я не вижу здесь никакого противоречия. Соответствие движения мыши координатам в окне - это не константа, а функция, которую определяет SDL и он же должен их масштабировать. В системе я такое масштабирование вижу, при изменении разрешения экрана и оно нелинейное - профиль ускорения. У меня пока нет никаких оснований считать, что SDL полностью дублирует тот же профиль, что и гном. А это неизбежно означает возникновение расхождений, что я и наблюдаю. По крайней мере, это полностью объясняет, почему системный курсор ведёт себя иначе. У тебя есть другое объяснение?

> У тебя есть другое объяснение?

Мне сложно объяснять то, что я не видел.

>> У тебя есть другое объяснение?

hugeping> Мне сложно объяснять то, что я не видел.

Странно. А хотя бы объяснить то, что я уже описал раньше? Или я просто вру? Хорошо, а чем моё объяснение тебя не устраивает? Твои аргументы меня не убеждают и я детально объяснил почему. Ты же никакого другого объяснения не предложил, кроме: "этого не может быть, потому что не может быть никогда". Это не выглядит добросовестной и равноправной дискуссией. Между прочим, это не я автор и мне больше других не нужно. Я уже потратил на всё это много дней бесплатного тестирования, в надежде, что это кому-то, всё-таки, зачем-то понадобится, но теперь я уже и не знаю, для кого я вообще что-то пишу.

Ну, по крайней мере, я могу сказать в свою защиту, что уже потратил несколько дней, чтобы придумать хотя бы такое объяснение. А если бы ты меня вдруг спросил, то на твоём месте я мог бы, например, взять и сильно поменять профиль ускорения в гноме, так чтобы твой курсор летал через весь десктоп. А потом открыть в центре большое окно инстеда и равномерно провести курсор по диагонали, наблюдая за изменением скорости его движения. Потом повторить этот опыт с -nocursor. Но кто я такой, чтобы давать советы специалистам? И зачем тебе тратить на меня своё драгоценное время? Однако, такое отношение к собеседнику очень разочаровывает.

Ладно, это уже больше совсем не техническая дискуссия. Вообще-то я тоже не заинтересован в том, чтобы кого-то переубеждать в чём-то, тем не менее, я старался, как мог. Если ты мне не веришь и желания разобраться нет, то на нет и суда нет. Пойду и займусь каким-то другим, более полезным делом. Извини, если что-то не так сказал :(

Когда в программе баг, его можно исправить. Но если баг у меня не воспроизводится, какой смысл гадать? Я уже написал что объяснений 100% загрузки процессора при движении мышки у меня нет. Причем тут верю тебе или нет? У меня нет версий. Никаких, кроме той, что SDL как то странно работает на твоих машинах.

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

# Оправдания

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

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

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

# Откровенность за откровенность

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

Да, твой "багрепорт" бесполезен. Потому что:
1) Слишком много текста, иногда частично противоречивого. Описание бага должно быть:
- конкретным, лаконичным и формально точным.

Когда я получаю противоречивые и непонятные сообщения, в которых свалено сразу несколько вещей. Я не занимаюсь "докапыванием". Это бесперспективно. Я одно обдумываю сообщение, одну деталь. А мне в ответ - охапка новых впечатлений. Это тупик. Начали с того, что dpi в системах не настоящий. Начал проверять, получил несколько новых выводов -- насчёт тормозов, глюков итд. В итоге я даже уже не понимаю что именно мы обсуждаем. Кривая какая-то вылезла гнома про ускорение. Функция какая-то SDL...

2) Часть вещей о которых ты говорил оказались не тем, что я думал в начале.
- Начали с DPI которое в гноме 96, но оказалось что это всё-таки не так и масштабирование работает так, как написано. Для меня это "звоночек"-- проблема не в том, что что-то не работает технически, а в том, что тебе не нравится как это работает. А что именно не нравится - я так и не понял. Например "шрифт слишком мелкий" -- ну, что это значит конкретно? Я такое утверждение просто пропускаю, оно для _диагностики_ -- бесполезно. Наверное стоило бы хотя бы скриншоты ситуаций привести с размерами. Типа - размер этого изображения на моем мониторе AxB.

3) Навязывание своих правил игры при ведении дискуссии

Да, я оставляю за собой право не объяснять свои мысли и выводы. Во-первых -- чтобы не обижать. Во-вторых -- я знаю SDL2 и INSTEAD лучше, но чтобы объяснять свои выводы я должен написать кучу всего. Вопрос -- зачем? Если я считаю, что данных недостаточно - я никогда не гадаю -- я просто говорю -- версий нет. Что касается твоих репортов, я пробовал воспроизводить, конечно, нечто подобное. Я даже спрашивал в чате инстед. Но никто мне ничего такого не вспомнил. Я обязан был отчитаться тоже за проделанную работу, чтобы не получить порцию негатива? :)

4) Да, я потратил своё время. Которое мог бы отдохнуть, например. И я его ценю. Оно драгоценно.

5) Да, я писал свои сообщения корректно, ни в одном из них я не вижу нападок. Поэтому попытка вызвать вину у меня -- нечестный приём с твоей стороны.

# Гипотезы по тому, что я понял

Ты просил написать о том, что я думаю по проблемам. Чтобы это обсуждать. Думаю я вот что:

- масштабирование работает так, как задумано
- артефакты отрисовки -- проблема с системной SDL2 или зависимых библиотек
- 100% загрузка даже при движении мыши: либо неправильная диагностика (тормозит в "кнопке" во время кат сцен, но не в обычных играх), либо проблема с системной SDL2.
- ускорение мышки при прохождении окна инстеда. Воспроизвести не смог, возможно следствие смены экрана разрешения + работа SDL - но код инстеда тут не причём и контролировать это я не могу в любом случае (нет смысла вообще рассматривать этот "баг")

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

# Заключение

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

P.S. Давно подумываю о том, что Клуб себя изжил. Возможно, стоит оставить только станцию в gemini. Время форумов - ушло, пора и мне уже на покой.

P.S. Edited: 2024-02-03 09:13:22

Ютуб подсунул эту лекцию и я её целиком послушал. В детстве я (как и многие в то время) бредил космосом. Надеялся что застану первый межзвёздный полёт. С возрастом, конечно, начал понимать, что не всё так просто. И в техническом и в социальном плане. Поэтому было очень интересно услышать свои озвученные мысли. Например, критика warp drive:

https://www.youtube.com/watch?v=ExdWAm3H65M&t=3355s

> Варп-драйв это... Ну это просто чушь собачья...

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

> Это (warp drive) -- не решение... Это .. релятивистская инженерия...
> Эта штука нарушает принцип причинности... Это очень мощная вещь -- принцип причинности...

И отличное заключение на тему "зачем":

> Мы в гораздо большей степени моральные, чем материальные существа... Для нас важна музыка, искусство, литература... Познание. Для нас важна красота этого мира... Мы существа не завязанные полностью на практическую пользу.

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

И всё-равно, верю, что мечту так просто не украсть. Думаю, прямо сейчас её ростки прорастают в чьей-то детской душе. А как по-другому? По-другому просто не может быть...
P.S. Edited: 2024-02-03 10:38:13

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

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

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

Фокусник, выполняя фокус с перемещением, не знает точно какой субъективный опыт его ждёт. Вот, он заходит в машину. Что будет в следующий миг? Мучительная смерть в закрытом резервуаре с водой или выход к публике под оглушительный гром аплодисментов?

Наивный ответ звучит так. Конечно, он испытает ужас смерти. Субъект -- это фокусник, заходящий в машину. Что тут думать?

Этот ответ (вернее, лёгкость с которой он был дан) разделит людей на тех, для кого трудная проблема сознания существует, и тех -- для кого никакой проблемы нет и "всё понятно".

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

Словно адресные пространства процессов в операционной системе. Процессы могут быть порождены одинаковым выполняемым файлом, но у каждого -- своя виртуальная память, свой стек, свой указатель команд. За счёт механизма виртуальной памяти они изолированы друг от друга так, что каждый ощущает себя единственным. Очевидно, что "сознание" процесса -- не только содержимое памяти. Работу обеспечивает ядро операционной системы. Само ядро остаётся "за кадром". Процесс не замечает как его вытесняет другой процесс. И как устроено ядро он может лишь косвенно оценить по интерфейсу системных вызовов. Интересно, что если мы просто сделаем копию процесса, то это ничего не даст. Запустить процесс можно только с помощью специального системного вызова. А для работы виртуальной памяти нужна аппаратная поддержка.

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

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

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

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

А я так и не понял сути этой проблемы. Сколько ни читал (статейки по верхам) и не беседовал с тобой, так и не понял в принципе в чём суть проблемы. Как будто бы мой мозг старательно избегает этого понимания :)

hugeping> Мир устроен удивительно. Кому-то для осознания этого достаточно увидеть падающую снежинку. Другому -- потребуется погрузиться в мир квантовой механики. Но не замечать этого -- невозможно.

Вот тут согласен. Мир -- удивительнейшая штука.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Даже на ЛОР новость есть, а тут тишина.

Василий Воронков (автор игр "Переход", "Материк" и "Лидия") выпустил новую игру "Бездна Света".

Игра для «классического» INSTEAD, использующая графику и музыку. Время прохождения — более 6 часов.

Экипаж ГКМ «Грозный» отправляется к орбитальной станции «Кабирия», последнему рубежу
исследованного человеком космоса, где ему предстоит столкнуться с чем-то нечеловеческим.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Василий, конечно, гигант. По-моему вообще аналогов его игр в ИЛ нет. Техническое исполнение - на высоте. Музыкальное оформление тоже атмосферное. На linux.org.ru в этот раз довольно благосклонная публика :) В общем, удачный релиз.

hugeping, на твоей станции (а может и не только на ней), если вставить в конец ссылки символ запятой или скобки или точки, то эти символы попадают в саму ссылку и она не открывается.

К примеру, я хочу написать несколько ссылок через запятую https://linux.org.ru, https://opennet.ru(или так https://nethack.org), или пример с точкой https://crawl.develz.org.

btimofeev> К примеру, я хочу написать несколько ссылок через запятую https://linux.org.ru, https://opennet.ru(или так https://nethack.org), или пример с точкой https://crawl.develz.org.

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

В итоге я решил что компромисс это включать всё до пробела или перевода строки и просто учитываю это когда размещаю ссылки. Вообще, я бы хотел чтобы стандартом форматирования idec был gmi :)

Отличная игра по оформлению и сюжету. Классная идея с терминалами (только вот медленно они загружаются).

Было две неочевидных головоломки, что пришлось лезть в код. А также не смог пройти игру до конца, так как в 14.lua выпал в бесконечный цикл из двух комнат, которые ссылаются одна на другую.

Оказалось, что игрушка скачана у меня давно (версия 0.11), а последняя уже давным-давно 1.2. Поэтому баг с бесконечным циклом.

Думаю вам стоит оставить свой отзыв на форуме Инстед. Там его увидит автор.
https://instead-games.ru/forum/discussion/791/igra-bezdna-sveta
Ему будет приятно

Отзыв написал, спасибо за указание.

Перезалил ролики на rutube.

https://rutube.ru/channel/39535814/

Есть такая штука как tiled, которая является инструментом для создания двухмерных карт для игр. Позволяет создавать их как для изометрического вида, так и для вида сбоку (платформеры). Особенностью является возможность работы со разными слоями тайлов и объектами.

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