Последние 8 лет держу видеонаблюдение на AvReg — в прошлом LinuxDvr. Если понимать, что именно надо от видеонаблюдения, то просто замечательное решение. Использую его на Intel NUC с безголовой Ubuntu именно для наблюдения, в т.ч. через интернет. Отдельно у меня стоит аппаратный NVR, он пишет полноценные H265 потоки от камер на винт в полном разрешении, для архива.
С каждой моделью телефона у меня субъективно меняется прием, но никакого вывода сделать из этого нельзя. Где-то корпус металлический, какой-то частоты не все поддерживает, у одного чехол с металлической вставкой для автомобильного холдера. Хз о чем статья и комментарии выше, тут количество листьев на дереве или положение вазона у соседа может больше влиять, чем сам аппарат.
Ну вот если бы была относительно простая возможность задать хук (или вручную вызвать какую-то функцию как разделитель кадров) и стартовать без Unity, я бы проверил на DX9, DX11, OpenGL и Vulkan, а может еще и на сервере. Но т.к. у меня нет Unity и в целом аллергия на него, то я даже не могу запустить профайлер и посмотреть его работу в живых условиях. А без этого патчить полностью незнакомый проект как-то не удобно.
Ну а если речь об игре на MonoGame, OpenTK и т.д. — можно привязаться к какому-нибудь SwapBuffers() или там IDXGISwapChain::Present() для разделения по кадрам?
1. Если напрямую сравнивать сравнивать, то вообще BeginReceive/BeginSend в 80% случаев выполняется синхронно, тогда внутренняя структура OverlappedAsyncResult сразу попадает в Gen 0 (или Gen 1, если в отдельном потоке) и удаляется условно очень дешево, по сравнению с буферами. Но, как я писал, использование IOCP или прямой доступ к сокетам еще быстрее и удобнее. А сейчас мы вообще перешли на GameNetworkingSockets от Valve.
2. Тут накопилось столько всего, что сработал эффект домино — DynamicMethod и ILGenerator.Emit, динамическая кодогенерация через Microsoft.CSharp, объектная БД (DataTable/DataSet), Performance Counters, да и просто множество мест, где порушилась сериализация, is для структур и т.д. При том, что .Net Core 2 работал медленнее, это переделывать вообще не было смысла. Сейчас уже много чего подчищено и код компилируется c TargetFrameworks=net461;net5.0;netstandard2.0, но все-равно местами вылазят потрясающие вещи вроде разного поведения Directory.GetCurrentDirectory (не спрашивайте).
1. Внутренность BeginSend и SendAsync существенно не отличается — оба вызывают тот же самый WSASend, разница только в том, как именно выстреливается колбек. Ну и производительность обоих методов заметно ниже, чем у IOCP.
2. Для какой цели? Core 2.x вышел в 2018м году, его производительность уступала Mono на Linux и особенно .Net 4.7 на Windows, а совместимость с старым кодом была не очень хорошей. Отрефакторить же 200000 строк кода бизнес логики ради перехода на него было бы откровенной ошибкой. Уже в 3.0 производительность была получше, но миграция все еще вызывала вопросы. Только .Net 5.0 позволил мигрировать без изменения бизнес логики, только с небольшим допиливанием ядра. Его производительность все еще чуть меньше, чем у Mono, но порядок тот же и этим уже можно пользоваться без сильной головной боли. Следующий проект будет уже на нем.
На самом деле у нас было большое, хоть и не очень дружное сообщество разработчиков и многие исследования делались совместно. У меня хорошо выходило копаться в протоколе, кто-то был гуру в шифровании, один коллега мастерски расшифровывал БД клиента. Ну а когда кто-то играл на официальном сервере и выкладывал дампы, то это было праздником для всех :)
Верю. Но игра в целом соревновательная (шутер) и в обычном ПВП режиме у игрока преимущество за счет правильного использования навыков, бонусов и т.д. Поэтому это хороший соревновательный элемент. А уже именно для интересного геймплея нужны живые соперники, но их не оказалось.
За это время было целых три проекта, которые использовали этот движок. И все закрылись до релиза или сразу после него. До боевого тестирования по-сути дожил только последний, четвертый.
Знаете, я и так сделал весьма мощный АИ (не нейросеть, скриптовый), с ним интересно играть, потому что у него есть полная информация. Конечно, это не полная имитация игроков — он не может прокачиваться и брать квесты. Но чтобы сделать именно подключаемых по сети ботов, надо потратить вагон времени на игру с неполной информацией — без знания всей карты, положения врагов, точек куда лететь для захвата флага и т.д.
Нет, если самому все делать, то можно с ума сойти :) В случае с эмулятором за все время человек 15 поучаствовало, кто базы наполнял, кто скрипты писал. В новом же проекте я собрал маленькую инди фирму. Пусть и кодеров было только двое, но это тоже немало.
Тут две разные истории. Легаси код начинался с версии .Net 1.1, дожил до полноценного перехода 4.0, был хорошо вычищен и отрефакторен, достиг неких высот.
Вторая история про то, как через много лет, уже далекий наследник этого кода (опять же, переписанный и вычищенный не один раз) неожиданно повторил тот же самый путь. В основном, потому что при рефакторинге вместе с водой выплеснули и ребенка — старые проблемы забылись, их методы решения тоже.
Я соглашусь, что вышло в целом сумбурно — много рассуждений, мало технических деталей, мало описаний инструментов, только основные подходы к решению проблем.
Чтобы сохранить большую часть старого кода, разумно было мигрировать только на .Net 5.0. А он вышел уж слишком поздно. Я на тестовом сервере перенешел на него, порадовался появлению давно забытых на Mono номеров строк в Exceptions релизной версии. Да и все на этом.
Иногда предпочитают разобраться и взять толкового человека, который сумеет выучиться и работать, а не того, который зазубрил методичку «ответы на вопросы собеседований». К сожалению, далеко не всегда.
Они плотно запаяны в пленку, я ее вскрывать не стал, но на ощупь только аккумы, без BMS. Как дойдут руки, попробую зарядить/разрядить для определения емкости, а потом и снять пленку и узнать больше деталей.
2. Тут накопилось столько всего, что сработал эффект домино — DynamicMethod и ILGenerator.Emit, динамическая кодогенерация через Microsoft.CSharp, объектная БД (DataTable/DataSet), Performance Counters, да и просто множество мест, где порушилась сериализация, is для структур и т.д. При том, что .Net Core 2 работал медленнее, это переделывать вообще не было смысла. Сейчас уже много чего подчищено и код компилируется c TargetFrameworks=net461;net5.0;netstandard2.0, но все-равно местами вылазят потрясающие вещи вроде разного поведения Directory.GetCurrentDirectory (не спрашивайте).
2. Для какой цели? Core 2.x вышел в 2018м году, его производительность уступала Mono на Linux и особенно .Net 4.7 на Windows, а совместимость с старым кодом была не очень хорошей. Отрефакторить же 200000 строк кода бизнес логики ради перехода на него было бы откровенной ошибкой. Уже в 3.0 производительность была получше, но миграция все еще вызывала вопросы. Только .Net 5.0 позволил мигрировать без изменения бизнес логики, только с небольшим допиливанием ядра. Его производительность все еще чуть меньше, чем у Mono, но порядок тот же и этим уже можно пользоваться без сильной головной боли. Следующий проект будет уже на нем.
На самом деле у нас было большое, хоть и не очень дружное сообщество разработчиков и многие исследования делались совместно. У меня хорошо выходило копаться в протоколе, кто-то был гуру в шифровании, один коллега мастерски расшифровывал БД клиента. Ну а когда кто-то играл на официальном сервере и выкладывал дампы, то это было праздником для всех :)
Вторая история про то, как через много лет, уже далекий наследник этого кода (опять же, переписанный и вычищенный не один раз) неожиданно повторил тот же самый путь. В основном, потому что при рефакторинге вместе с водой выплеснули и ребенка — старые проблемы забылись, их методы решения тоже.
Я соглашусь, что вышло в целом сумбурно — много рассуждений, мало технических деталей, мало описаний инструментов, только основные подходы к решению проблем.