Comments 4
наручный Pip-Boy в Fallout
В контексте статьи в голову сразу приходит ужасный интерфейс первого Fallout (проходил недавно) с неинтуитивными кликами левой/правой кнопкой, постоянным скроллингом инвентаря и т.д.
А в целом написание интерфейса с нуля для тех, кто начинал программировать под DOS или раньше, выглядит не так страшно. Простейшую библиотечку для Turbo C с менюшками и полями ввода в графическом режиме переписывал два раза (сначала с школе, потом на первом курсе - как то не сохранил исходники).
я посмотрел https://habrastorage.org/r/w1560/getpro/habr/upload_files/180/dea/d0d/180dead0decfff87340fabb2e29f1470.png - ваш скриншот, так там глобал стейт(есть же люди, которые изучают, понятно, что на проде возможно по другому, а иначе не было бы изучения правильно ?) ), и гуй привязан к базе данных скорее всего, сюда же добавим, что скорее всего вам придётся написать WindowManager(https://godbolt.org/z/5c8ra9G57 - типо такого, можно улучшить, он как раз масштабируется до оконного менеджера) - это и есть система GUI - если по простому - система которая отслеживает кто чей родитель и ловит клики, а так же умеет рисовать окошки. Здравствуй WindowManager - почему Window ну потомучто это просто рект с кнопками.
с таким темпом можно сразу перейти к обзору того самого эмулятора и не мучать время )
сегодня всё что в 3д будет с шейдерами, то что идёт другим путём по IPC c shared, ни в одной ОС не может быть совместимо в 1 контектс.
гдето тут оставлю на всякий случай тоже картинку,
Скрытый текст
к жожалению придётся изучать эмулятор, там есть один из лучших эмуляторов тоже АзеротКакойто), потомучто лучше покачто нету, в ТЕСО например есть глобал илюминейт через конус-воксель, нафиг никому не нужный, который бьет по ресурсам, кстати, это тоже можно обсудить!), а игра про азерот даёт тебе честную картинку, на момент 2020 года даже - что является офигительным показателем и при этом еще являлся полностью тем самым костыльным легаси.
Но это всё сказки по сравнению с легаси WindowManager ) в пору вспомнить что такое было NEXTSTEP )
Ваш комментарий к предыдущей статье был более осмысленным. Этот я опять не понял
по контексту 3д.
суть в том, что:
1 на любом устройстве или ОС, есть апи к вызову окна, используем мы либо библиотеку готовую, или пишем сами
2 окно даёт выбор контекста это 2д - софтверная отрисовка будь то X11, winAPI, GDK(XBOX не XBOX)
-gdiplus-gdi-start - тот самый софтвер, на иксах строго такое же деление софтовая отрисовка через механизмы IPC/или привязка к окну контекста расширенного (GL/Vulkan)
3 соотв если мы делаем привязки по апи для 2д(тот самый системный 2д урезанный, который только для 2д - тоесть софтвер контекст через IPC), 3д туда уже не привязать, или привязка 3д, тогда те апи условно GDI, туда не привязать, потомучто активная поверхность будет привязана к 3д.
учитывая эти нюансы получается, что если нужен расширенный контекст(Vulkan/opengl/DirectX/Molten) у нас будет сцена 3д, а это шейдеры.
по глобал стейту,
если у нас ММО, то как не крути, интерфейс после сервера персонажей будет обновляться контрольным пакетом или смотря какая архитектура запроса, далее, когда будет активная сессия, сервер другой уже будет в своих рамках синхронизировать и обновлять метаданные игрока, да мы можем сериализировать это локально на клиенте, но приоритет будет у базы данных, и точно так же по кулдаунам, управление будет не локальное как раз, а через базу данных.
по квейку и причем тут он, и почему виндов менеджер:
дело в том что система, которая помогает в управлении окнами(а иногда и композитингом) исторически это X11(на самом деле на винде оно по логике такое же просто реализовано иначе по дизайну), у нас есть сессия, в момент логина мы регистрируем права доступа условно это нужно для запросов к ядру, далее инициализируем подсистему управления окнами(если по старинке это файлик .xinit), соотв если в такой парадигме мы хотим свои костыли, мы делаем тоже самое просто на уровне системы(оконный менеджер, причем что интересно, управление будет таким же за исключением только того, что у библиотечки есть АПИ на каждый чих по окну, вплоть до Parent - составляющей, это механизм привязки к тайлу окна, самого приложения, чтобы можно было через фрейм управлять состоянием окна-привязанного приложеия к фрейму). У Мака они написали свои прослойки придётся читать их документации как там вызывать окно и связывать контексты.
Как игровой GUI пишут заново (Ч.2)