Про интерфейсы взаимодействия немного расскажу. В халфе это была основная головная боль, потому что между пользовательской дллкой и движком формировался-набирался некий уникальный интерфейс, и вот что в нём было - то и доступно пользователю. А если тот, кто формировал этот интерфейс о чём-то забывал, то всё, жопа. Или бывало так, что в интерфейс всё-таки добавлялись недостающие функции приходилось мучительно проверять их наличие по версиям, размеру апи и прочей глупости. Это дико неудобно, не говоря уже о том, что для каждой новой библиотеки надо было набивать этот интерфейс заново. Я отказался от этой порочной практики и ввёл таблицу интерфейсов. Таблицы поименованные, в имени дополнительно содержится и номер версии интерфейса. Таким образом для каждой новой пользовательской библиотеки одновременно доступен весь набор функций, достаточно просто её позвать. В обратную сторону это тоже работает, но как правило от пользовательской библиотеки достаточно одной-единственной таблицы экспорта. Но можно сделать и несколько.
То есть, все движковые функции, доступные на клиенте, будут доступны и на сервере и в меню тоже. Ну а если понадобится расширить какой-то интерфейс без потери бинарной совместимости, то от базового достаточно объявить наследный класс, добавить в него недостающие функции и дать ему новое имя в табличке. И всё, совместимость не теряется ни при каких обстоятельствах. Ну а если всё же случится беда, будет виндовая ошибка Pure Virtual Function Call или что-то вроде этого, вместо загадочного вылета по 0x000005, который мог означать вообще всё что угодно.
Добавлено 13-04-2020 в 13:02:
А, вот еще какой любопытный момент. Вот это физическое разделение таблиц экспорта в принципе позволяет сливать несколько пользовательских библиотек в одну, сохраняя разделение кода. Ну скажем клиент и сервер.
Оба в одной дллке, память не пересекается, но иногда, если очень-очень надо, они могут напрямую друг-другу что-то модифицировать, например в сингл-плеере. В халфе, где было именно 2 изолированные дллки такое не прокатит, народ порою шёл на грязные хаки - грузил из hl.dll client.dll, искал там торчащий наружу экспорт и по нему брал какую-то информацию.
Дядя Миша
А в сорсе видел как сделано? Там каждой подсистеме при инициализации передается функция, возвращающая интерфейсы по имени. Таким образом подсистему вообще не волнует, где и как интерфейс реализован - она лишь проверяет его наличие. И еще каждая дллка экспортит такую функцию - она возвращает интерфейсы реализованные в этой дллке.
Забавно, у меня тут недавно возникла аналогичная проблема. Вообще, я стараюсь избегать использования длл - модульность на бинарном уровне как правило бывает не нужна, но тут мне понадобилась отдельная длл.
Поскольку экзешник и длл собираются отдельно, нужно было обеспечить какую-то систему версионирования. Требований к системе у меня было только два:
1. Система должна понимать, что существуют обратно совместимые интерфейсы - если в интерфейс добавилась новая функция, то старый клиент все еще может использовать новый интерфейс также как он использовал старый.
2. Система должна быть удобной для использования во время активной разработки, когда в интерфейс постоянно добавляются новые функции, а старые иногда меняются или удаляются.
Вариантов у меня было два: абстрактные классы (они же "интерфейсы") и структуры с указателями на функции - как в хл.
Соответствие абстрактных классов п.1 для меня так и осталось загадкой. В теории они ему не соответствуют - конпилятор имеет право расположить указатели в vtable так как ему удобно. А вот как обстоит дело на практике я так и не понял. Вроде как MSVC распологает их в порядке объявления и вроде как я даже где-то когда-то видел код который этот факт использовал. Но тут встает другая проблема - клиент как-то должен узнать, что поддерживаются обе версии интерфейса. Сорс (см. пред. ссылку) для этого предлагает экспозить интерфейс два раза. Для сорса это не проблема - движок уже достаточно взрослый и интерфейсы в нем меняются нечасто. Но в развивающемся коде это приведет к тому, что этих версий придется поддерживать целый список, а это противоречит п.2.
В итоге я остановился на структурах с указателями. Порядок работы следующий:
1. Новые функции добавляются в конец структуры - больше ничего делать не нужно.
2. При поломке совместимости версия увеличивается на 1.
Запрашивая интерфейс, клиент передает номер версии и размер своей структуры. Если номер версии отличается, значит интерфейс не совместим - возвращаем false. Далее, если размер интерфейса на клиенте больше, значит у клиента более новая версия - возвращаем false. Если все в порядке - копируем столько байт структуры сколько запросил клиент (у него может быть более старая версия).
Еще в моей реализации клиент вызывает все интерфейсные функции через врапперы, имя которых соответствует именам функций, реализованных в длл. Это позволило реализовать статическую сборку, при которой вместо длл используется либ и никаких интерфейсов вообще не используется - все вызовы осуществляются напрямую.
Статическую сборку я использую для финального билда.
Government-Man писал: А в сорсе видел как сделано?
Ну у меня в чём-то похожая система, но проще, не такая замороченная.
Цитата:
Government-Man писал: когда в интерфейс постоянно добавляются новые функции, а старые иногда меняются или удаляются.
пока над исходным кодом работает один человек на совместимость можно плевать. Главное - устаканить интерфейсы к релизу.
Цитата:
Government-Man писал: Но тут встает другая проблема - клиент как-то должен узнать, что поддерживаются обе версии интерфейса
Ну это легко. Зовём обновлённый интерфейс, получаем хрен, зовём старый интерфейс.
Цитата:
Government-Man писал: Запрашивая интерфейс, клиент передает номер версии и размер своей структуры. Если номер версии отличается, значит интерфейс не совместим - возвращаем false. Далее, если размер интерфейса на клиенте больше, значит у клиента более новая версия - возвращаем false. Если все в порядке - копируем столько байт структуры сколько запросил клиент (у него может быть более старая версия).
Всё верно, в NT 2015-го года именно такая схема и была реализована.
Вообще дллка нужна для того чтобы отделить неизменный код от изменямого. Скажем движок не меняется, а разные там энтити - вполне.
Цитата:
Government-Man писал: Статическую сборку я использую для финального билда.
што ты там такое делаешь? Юнити?
Добавлено 13-04-2020 в 23:39:
И кстати к вопросу о неизменности - в идеале ядро движка не должно содержать ни одного константного пути. На практике просто надо свести их к минимуму.
Дядя Миша писал: Вообще дллка нужна для того чтобы отделить неизменный код от изменямого.
Я преследовал две цели.
Во-первых, в какой-то момент интерфейс действительно должен устаканиться и тогда собирать уеч нужно будет горазо реже, а сравнительно небольшую игровую длл - часто. Но на деле эта проблема не то чтобы стоит остро - если не чистить промежуточные файлы сборки уеча, то по сути он тоже будет перекомпилировать только одну длл.
Основная задача в моем случае - отделить свой код от чужого. По задумке авторов уеча игры на нем делаются путем расширения классов движка. При этом код твоей игры какбы становится модулем движка и все это потом собирается кастомной билд-системой. Собрать свой код отдельно от движка ты уже не сможешь. В принципе это правильно - это удобнее и гибче, чем апи из сотни функций, но код игры при этом становится прочно завязан на архитектуру движка. Я решил избавиться от архитектурных ограничений и перенести большую часто своего кода в длл, отгородившись от движка при помощи апи.
Цитата:
Дядя Миша писал: Ну это легко. Зовём обновлённый интерфейс, получаем хрен, зовём старый интерфейс.
Но длл тогда получается должна отзываться на каждую версию, которую она поддерживает? Если интерфейс меняется нечасто то это не проблема, а вот если часто - уже проблема, потому что версий накопиться целая телега.
Government-Man писал: По задумке авторов уеча игры на нем делаются путем расширения классов движка.
Ядро - суть абстракция, оно не знает ни про какие энтити и прочее. В движке у нас файловая, консоль, рендерер, менеджер моделей, менеджер сети, звуковая подсистема. В игровой части физика, AI, механизм выделения и освобождения энтить, таблицы дельта-кодирования по сети, сейврестор. Всё это завязано на конкретную игру и может кардинально изменяться. А из движка торчат только те функции, которые в принципе поменяться не могут - отправка сообщений в консоль, чтение-запись файлов, отправка приём сетевых сообщений и так далее.
Цитата:
Government-Man писал: Но длл тогда получается должна отзываться на каждую версию, которую она поддерживает?
так я же говорю, новое API получается путём наследования старого + еще несколько функций.
Добавлено 14-04-2020 в 10:44:
Вот к примеру как реализован механизм смены\загрузки уровней в ядре?
Есть три функции:
Пользовательская часть вызывает их из любого места, движок сохраняет две или три переменных - имякарты\сейва, имя ландмарка, флаг бэкграунда, далее, в начале кадра, вызываются соответственно четыре экспорта из самой дллки.
SpawnServer - это загрузка новой карты, в движке никакие пути не проверяются, что ты там собрался грузить движок не волнует абсолютно, хоть шрифт вместо уровня загрузи, если ты 2д игру делаешь с тайтлами.
Движок в ворлдмодель не лезет и ничего про нее не знает. Единственно что - он пытается у этой модели найти PVS и что-нибудь по нему отсечь, но если не находит, тоже не расстраивается.
Потом, соответственно, если SpawnServer вернул true вызывается одна из трёх функций ниже. Опять таки - движок в эти переменные не смотрит, кроме бэкграунда конечно. То есть вполне возможно реализовать такой абстрактный механизм, когда игра полностью контролируется из пользовательской части.
Может и не туда пишу, но поиск по форуму не пашет, поэтому спрошу здесь.
Кто редактировал XashMod_v062_JH1.fgd?
Подключил этот фгд, пропало несколько фгд, оказалось зачем-то снесли переменную targetx, а сам этот таргет так и остался в энтитях, плюс по-моему зачем-то триггер автосейва был продублирован (или это в другой версии фгд ксаша было...).
__________________ Tiger! Tiger! burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?
Так товарищи. По скриншотам вот какие у меня соображения назрели. На данный момент, как вы знаете есть два основных типа скриншотов.
команды scrshot и snapshot. Первая сохраняет скрины в папку мода\scrshots
Вторая - в корень игры. Я поймал себя на мысли, что первой командой за много лет не пользовался вообще никогда, она просто не нужна.
А у второй есть существенный недостаток - поскольку она работает через стандартную систему экзекции буффера, невозможно сделать скриншот в меню, а в консоли приходится вручную вбивать команду. Всё это дико неудобно. Поэтому я решил сделать так: повесить действие команды snapshot на кнопку Print Screen. А для эмуляции привычного функционала - писать его в буффер при зажатом альте. Думаю это будет наилучшим решением.
В тред призывается Психопат, вот какая интересная мысль мне пришла в голову. У Кармака в третьем дууме есть волшебные функции BitsToFloat и FloatToBits. Они позволяют изготовить переменную с плавающей точкой для любого кол-ва бит. Ну ладно, ладно, не для любого. Минимум 4 бита надо.
Преимущества такого подхода очевидны - плавающая арифметика всегда имеет большую точность, нежели фиксированная точка. У него там эта штука использовалась для отправки флоатов по сети, практически без потерь. Но вот что я думаю. BestFitNormals при помощи таблички, по сути занимается подбором оптимального множителя для FixedPoint. Т.е. множителя, на котором потеря дробной части будет минимальна для выбранного значения. Преимущество подхода очевидно - для декодирования достаточно вызвать normalize. Минус в том, что это работает только для вектора и то что надо таскать с собой эту табличку. А что если эти самые флоаты сохранить в плавающую точку величиной с байт?
Взять скажем 2 бита для мантиссы и 5 бит для экспоненты (один бит на знак уйдет). И посмотреть насколько будет гулять точность, в сравнении с тем же BFN.
здрасти-приехали. На кой же тогда чёрт изобретали плавающую точку, если фиксированная лучше?
Цитата:
ncuxonaT писал: Какие ты видишь сценарии использования самодельных флоатов?
ну вот нормали сохранить. Те же три байта, но точность должна быть выше, чем с BFN. Правда и распаковка - сложнее.
Добавлено 15-04-2020 в 18:59:
Собсно наилучший пример того, насколько губительно использование фиксированной точки отражается на точности мы все с вами долгие годы наблюдаем на халфовских модельках, у которых постоянно едут текстурные координаты. Я сперва рассудил, что раз координаты там всё равно никогда не выходят за пределы 0-1, то надо просто выбрать максимальный множитель для увеличения точности. Ну и взял 32768. Так вот - это нихрена не помогло по сути. Как оно съезжало, так и продолжило съезжать. Тогда я подумал, есть же халф-флоаты, попробую их. И да - с ними исчезли практически все проблемы. Ну кроме конечно тех случаев, когда моделлёр нарочно двигает текстуру неправильно, пытаясь компенсировать потерю точности, типо после округления, оно съедет обратно.
Фиксированная арифметика это полное днище, её вообще нельзя никак использовать. Ну разве что для квантизации пространства, да и то...
| IP: 
12-04-2020 11:57
