При покупке этого автомобиля СЕГОДНЯ мы подарим Вам МЕСЯЦ ПОДПИСКИ на услугу AutoFill. AutoFill — новое слово в УДОБСТВЕ пользования автомобилем, ведь Ваш транспорт теперь ВСЕГДА будет ЗАПРАВЛЕН!* Мы узнаем где Вы живете и прикатим к вашем автомобилю ночью (или в любое другое время, когда Вы спите, ведь это мы тоже узнаем) цистерну на колесиках*** и ЗАПРАВИМ ВАШУ МАШИНУ ВСЕГДА И ВСЮДУ ****.
мелкий неразборчивый текст
* — Пользование услугой автоматически означает согласие на отсылку ежеминутной телеметрии автомобилем (GPS-координаты, уровень топлива, информацию об объеме вытесненного воздуха в салоне,видеопоток и записи с оченьнезаметныхкамервсалоне,MitM'ed SSL from in-car WiFi-AP and hiddenSDR, etc) **
** — Также мы оставляем за собой право предоставлять копию собранных данных третьим лицам (включая, но не ограничиваясь: NotEvil LCC, Pear Inc., и т.д.).
*** — При хранении ТС дальше 1.35м от асфальтированной дороги (а мы узнаем об этом заранее) приедет не только бензовоз, но ещё и пассажирский автобус с бригадой мускулистых туристов и множеством канистр. Вы обязаны по первому требованию предоставить им ключи от гаража.
**** — SLA: минимальный уровень топлива 0000000.09999999999% не реже 99.9% (ДЕВЯНОСТОДЕВЯТИ ПРОЦЕНТОВ) времени запущенного двигателя.
ФПСа может на винде и больше, но знакомые киберспортсмены личности, имеющие больший ранг чем у меня, говорят, что по циферкам fps упал, но также упал и input-lag, а следовательно и играть стало комфортнее. i5, 940m или схожая мобильная графика, нативный порт csgo, ubuntu 16.04. А, ну и из-за его матчмейкерского бэкграунда я посоветовал пересобрать ядро сделать apt install linux-rt — input-lag стал ещё меньше, но и fps упал до неприлично низких значений.
Ключ расшифровки - на серверах самого мессенджера, т.к. серверу верить можно (в нем точно не будет злого умысла).
Ещё есть TOTP. Я уверен, что его принципы работы здесь не применимы, но если все же был бы закрытый ключ, который будет действителен только указанное время, то было бы круто.
Скорее всего, из-за названия самой первой части bf 1942. Ну, и сайфайный сеттинг вида "ровно через 100/200 лет после WWII снова в разгаре огромная война" звучит нормально.
P.S. а ремейк 2142 мне бы было интересен, но по сравнению со 2 и бк1 частями он радикально никому не интересен.
Я не говорю именно про текущую реализацию RTX/DXR. Я говорю про сам способ рендеринга трассировкой лучей. А шумодавы нужны для подавления шума, который появляется из-за недостаточного количества лучей.
Основной же мой ответ можно увидеть в соседней ветке.
Проблема текущей реализации RT - в том, что она очень и очень медленно считается. Когда вырастет производительность аппаратных ускорителей не в десятки раз, а в сотни-тысячи десятков раз и мы сможем полноценно считать кадр одними лишь лучами за вменяемое время (все современные инженерные и кинематографические визуализаторы из разных CAD'ов и 3dsmax'ов так считают, например), то вот тогда мы сможем полностью отказаться от растеризации.
Все же, реальный мир "рендерится" исключительно лучами (ну, насколько я могу судить из той программы физики, что мне преподавали), так что для получения максимальной "реалистичности" картинки надо просто повторить то, что уже было создано далеко до первого изобретенного способа растеризации.
Лично мое мнение заключается в том, что для получения хорошей картинки с современным развитием технологий (ну, может лет через 2-5 развития видеоадаптеров) нам помогут нейросети (они же уже аппаратно плохую картинку с фото-матрицы телефона поднимают до уровня средне-бюджетных зеркалок).
Да, есть один максимально простой для разработчика и максимально естественный способ рендеринга... Если память не изменяет, то там что-то про трассировку и лучи.
Так что, для светлого графического будущего осталось всего ничего: выпустить действительно производительный аппаратный ускорятор рейтрейсинга и сделать его популярным (скажем, чтобы оно точно было хотя бы у 95% целевой аудитории). И чтобы единственная градация железа была лишь в том, сколько десятков километров дальности видимости, или сотен тысяч объектов частиц надо нарисовать.
За лучами будущее, и так считают многие в индустрии.
Мое долгое нытье про (не)стабильность яблочной техники
Решил перейти на инопланетные технологии небожителей (судя по восторженным отзывам в Интернете). Макбук эйр на интеле (и это, КМК, была моя главная ошибка) как печатная машинка с ssh'ем и браузером, и первый айфон как единственная мобилка...
К странности софта я уже почти привык (хотя, после года пользования все равно иногда возникают вопросы). Но вот стабильность железа (или все же качества низкоуровневого софта) - полная и беспросветная бездна.
Особенно плохо с вайфаем - при нагрузке и (возможно) небольших проблемах с сетью, стабильный кернел паник (или как этот экран с белыми буквами и иконкой выключения на черном фоне называется). Так оно ещё и подвисает постоянно в таких сценариях. Но здесь модуль intel, ладно, простим (ведь x86 больше никому не нужны, да?).
Иногда были кернел паники, с систрейсом указывающим на драйвер APFS...
Вообще, ноутбук обычно работает пару месяцев, и это, кажется, нормально... Для 2005 года. Сейчас у меня основной рабочий десктоп на винде (и немного разогнанный моими кривыми ручками) работает гораздо стабильнее (ни единого бсода за последний год).
За пару месяцев пользования айфоном было несколько фризов на несколько минут, но яблочный саппорт посоветовал сбросить через файндер... Так и сделал, уже несколько недель - полет стабильный.
Резюмируя: железо у эппла отменное (особенно тачпад и корпус макбука очень нравятся), но вот качество драйверов в частности и ОСи в целом - ужасное (постоянные краши, фризы, баги и тому подобное).
Попрошу отметить, что API того же openGL не заставляет использовать третье измерение
Да, именно так. Когда я писал "мы стали даже 2D рисовать как 3D", я имел ввиду, что после перехода на гибкий конвейер, видеокарте стало абсолютно безразлично что считать, и что весь смысл, который есть в данных - вкладываем в него мы (ну, ещё есть выходной буфер, который имеет уже одно конкретное заранее назначенное разработчиками OpenGL'я предназначение, но суть не об этом).
2д графика не подразумевает вращение и масштабирование спрайтов
Увы, но почти всегда это не наш случай. Хотя бы масштабирование, но матрица (или не матрица, но с матрицами, возможно, будет быстрее) преобразований должна быть почти всегда, так что её нигде кроме, допустим, того же SRP (как Scriptable Rendering Pipeline в Unity) не найти в готовых движках.
Я выше написал "с матрицами будет быстрее", предполагая, что для матриц есть аппаратное ускорение, и что оно выполнится так же быстро (условно - за один такт), как и просто перемножение/сложение векторов. Но данных будет однозначно больше (впрочем, можно и на процессоре большую часть матриц перемножить). Однако, надо профилировать, в разных вариантах, и на разных видеокартах.
можно будет отключить буфер глубины и использование z-координаты в принципе
И как же тогда определять порядок отрисовки? Допустим, z-координата (или слой, или как угодно это можно называть) будет лишь на стороне процессора. И мы будем регулировать порядок отрисовки порядком вызовов отрисовки (т.е. метод художника). Хорошо, это будет работать, но не факт, что это будет быстрее, потому что таким образом мы ломаем параллелизм видеокарты и большинство ядер (особенно при отрисовке маленьких спрайтов, или при огромном количестве ядер) будет простаивать, ожидая отрисовки этого маленького спрайта (чтобы случайно его не закрасить). А ещё, отказавшись от Z-буфера мы выиграем целых 8мб видеопамяти.
не использовать мип-мап
выбрать режим GL_NEAREST
Во многом это зависит от визуального стиля (пиксель-арту точно пойдет на пользу), но обычно при очень маленьком масштабе рисуемый объект становится раздражающе не-сглаженным, что, зачастую, не самый желанный эффект.
наблюдение за некоторыми мобильными поделками, тормозящими на сотне-тысяче спрайтов
Я почти уверен, что там проблема в (случайно) убитом батчинге и инстансинге. Но без конкретных примеров (а ещё лучше с возможностью модифицировать их исходники и произвести оптимизацию) говорить об этом бессмысленно. Сделать плохо можно на любом движке, и с любым рендером.
P.S. Я не осуждаю, но мне и правда интересно: это Вы поставили мне минус в карму, и если да, то, неужели, за мой комментарий?
Disclaimer: я не имею желание очернить, обелить или оскорбить любого человека или технологию в нижележащем тексте. Фактологических ошибок в статье немного, но я значительно не согласен с идеей статьи. Не стоит принимать мой токсичный комментарий (хотя я честно пытался сделать его менее "токсичным") близко к сердцу.
Почему на нем?
Он долго запускается, игры, которые должны весить 0,3-0,5 Гб, на нем весят 1,5-2 Гб.
Если под "долго запускается" имеется ввиду редактор, то ему это позволительно делать (можно привести аналогию с простым "блокнотом", который потребляет пару МБ ОЗУ и запускается мгновенно, и с "блокнотом для программистов", который потребляет ГБ ОЗУ и может запускаться до нескольких минут на огромных проектах). Если же речь про сам итоговый билд игры, то, исходя из моего опыта, запуск может казаться долгим лишь из-за лого самого юнити в бесплатной версии.
Про объем билда могу лишь не согласиться. Только что проверил на актуальной LTS-версии - сделал за пару часов аналог flappyBird'a используя шаблон 2D (не прибегая к тюнингу для снижения размера итогового файла). И при размере ассетов в 200кб, билд windows-x64 занимал 59.8МБ, а файл .apk для android лишь 18.3МБ. Разумеется, это в 18 раз больше, чем на нативных для платформы ЯП (хотя для винды нужен будет ещё msvc-redist), но где Вы последний раз видели игру меньше, хотя бы, 10 мегабайт?
нормальную поддержку 2D в нее добавили относительно недавно, да и то, по сути, костылем
Думаю, что поддержка 2D в UE4 Вас шокирует... Касательно юнити, там очень хорошая поддержка 2D, даже физика не от 3D, так что претензии на 3D-корни движка мне не ясны. Если конкретно идет речь про оверхед от математики, то он предельно низок, и, на самом деле, выгоды от использования именно 3D-математики больше. Если же важна именно скорость рендеринга (т.е. аппаратное ускорение 2D-отрисовки), то, увы, но её, вроде бы, теперь вообще нигде нет. После популяризации DirectX10/OpenGL3 все ушли с фиксированного конвейера рендеринга, то есть, ради возможности использовать пост-процессинг и кастомные материалы (гуглится по запросу "2d shaders") мы стали даже 2D рисовать как 3D. Возможно, что за счет упрощения математики в шейдере из-за отказа от 3-го измерения в Godot'е, будет некоторое увеличение скорости, но оно будет несоизмеримо мало по сравнению с грамотной работой с ассетами, хотя бы, в том же юнити.
ООП как по учебнику
прочтите про сцены, узлы, экземпляры
Прочитал. В терминах юнити это будет: префабы, компоненты, экземпляры (инстанцы, если пользоваться общеупотребильной терминологией). На самом деле, идея с иерархией компонентов - достаточно интересная, но как и в том же анриле, вызывает сомнения. На ум приходит лишь польза от перемещения дочерних объектов вместе с родительскими, но это применимо лишь для тех компонентов, что имеют координаты в сцене. Погуглив, четкого ответа на вопрос "зачем так сделано" я не нашел.
У юнити есть множественно крайне сомнительных решений в архитектуре, но здесь это не оно, по моему мнению.
Сигналы
В Unity есть множество callback'ов (функций, что вызываются в скрипте, когда происходит какое-то событие) как от компонентов (OnTriggerEnter2D), так и от движка (Start, Update). Также можно делать собственные callback'и через UnityEvent (ну, или event из самого C#). Вообще, концепция событийно-ориентированного программирования развита в юнити достаточно не плохо, но если Godot достигает в этом аспекте новых вершин, то это действительно хороший повод к нему приглядеться.
не нужно постоянно проверять нажата ли кнопка или не покинул ли объект экран
Я не знаю, получилось это случайно, или при написании статьи в качестве опорного референса излишне использовались официальные туториалы по Godot Engine, но эта формулировка звучит очень похоже на заголовок из главы про сигналы.
UI-элементы
В первом все возможности заточены больше для меню и настроек
И это более правильный подход, потому что организовать интерактивный GUI гораздо сложнее, чем обычный счетчик патронов или hp-bar.
внутриигровые метрики, вроде шкалы здоровья, создаются со скрипом и сложностями
Я, хоть и не использую юнити в качестве основного инструмента, но ни разу за время моего пользования им (вернее, "новой" UI-системой, которая используется по умолчанию с 20..18(?) года) я не испытывал какой-то особой боли. Даже сейчас в пустом проекте я создал и настроил несколько счетчиков и полосок (хотя, с прогресс-баром возникли сложности, да, поэтому я его сделал из слайдера). Возможно, что проблемы начинаются при попытках переиспользовать настроенные GUI-префабы, но, если я правильно понял, то Godot не преподносит в этом плане ничего нового.
А в Godot – характеристики игрока внутри игры.
Что намекает на то, что интерактивные, сложные, многослойные интерфейсы на нем проектировать не стоит.
C# или GDscript
Некоторые штуки, описанные в документации, делаются в одну строку в GDScript и в пять строк на C#
Подозреваю, что остальные 4 строчки в C# состоят исключительно из { и }.
у C# больше возможностей, и с GDScript будет просто невозможно сделать какие-то вещи
Если я правильно понимаю, то GDscript полон по Тьюрингу, что означает, то, что, технически, на нем можно сделать абсолютно все. На практике же, ограничения появляются в недоступности некоторых API, чего, по идее, быть не должно, если движок действительно проектировался под GDscript и этот ЯП до сих пор поддерживается.
Почти счастливый пользователь Home Assistant здесь!
Сразу же с создания системы на HA заглядываюсь на NodeRED (т.к. подобное event-flow программирование лично мне кажется куда более логичным и удобным чем конфиги HA и даже чем обычный код), но менять ядро пока не готов, а одновременно использовать две конкурирующих технологии — очень сомнительное архитектурное решение.
Почему Home Assistant
Красивый GUI (в планах, купить дешевые б/у айпады или другие планшеты, и прикрепить их на стену, т.к. Lovelace по ощущениям, проектировался именно под это).
Поддержка кучи интеграций (я в начале был не очень умен и собирал на решениях разных вендоров и HA помог мне все это связать воедино, сейчас же последние 10 добавленных устройств исключительно Esp8266 + Паяльник + ESPHome (крутая штука, кстати)).
Удобство настройки из GUI (и особенно печально, когда приходится для настройки какой-то интеграции лезть в сonfiguration.yaml).
Против HA
Все же иногда приходится лезть в конфиги, так как даже банальные алерты через гуй не сделать (то есть, иногда приходится остужать пыл ожидания типичной быстрой настройки и неторопливо поднимать ssh-сессию в LXC-контейнер (да, у меня venv-инсталляция)).
Некоторые проблемы с оптимизацией и багами (очень медленное отображение истории недавно починили, но вот recorder все равно при перезапуске инстанца заставляет себя ждать по 5-30 минут, да и полный перезапуск вкладки в хроме можно объяснить виной самого хрома но так происходит только с HA).
Очень неудобные автоматизации (кмк, не хватает переменных, более удобных и настраиваемых триггеров, более компактных шаблонов (jinja не то чтобы плох, но у HA он получился слишком явным) и много чего ещё (сейчас я думаю, про автоматизацию исключительно на алертах, но потребность для каждого делать отдельный binary sensor мгновенно рушит всю мотивацию сделать «красиво и на века»). NodeRED выигрывает на тысячи очков вперед в этом вопросе, а без автоматизации «Умный дом» не такой уж и «умный». Хотя, сейчас думаю про pyscript, но пока ещё не решился его настроить и перевести все свои автоматизации (они, к счастью, пока очень простые, т.к. даже на элементарную «снижать уровень синего у лампочек к ночи, если никто вручную лампочки за последнее время не выставлял» потребовало больше 5 часов моего времени).
P.S. Очень надеюсь, что все мои проблемы — исключительно из-за прямоты моих рук, и сейчас мне здесь доходчиво объяснят почему я не умею правильно готовить HA и покажут как надо.
P.P.S. В самой стать неоднократно идет ссылка на некоего Алекса Квазиса (про которого я впервые слышу, вероятно, потому что я ни с какими сообществами автоматизаторов не взаимодействовал, а постигал все сам исключительно с документации HA), и так как наши взгляды в этом вопросе (исхожу исключительно из статьи и пары оставленных Вами комментариев здесь же) по большей части схожи, то интересует Ваше субъективное мнение о ценности его видео (т.к. в самой статье ощущается сильная противоречивость его личности).
P.P.P.S. Прошу прощения за графоманию и другие проблемы моего языка (хоть он и является моим родным).
Если еспорт гейм будет убивать тех кто за угол зайдёт
Удивительно, но прямо сейчас оно именно так и работает.
Ты заходишь за угол — и умираешь. Оказывается, что ты уже был мертв когда заходил за угол, но тебе об этом сервер не успел сообщить. Та же самая ситуация, когда в дуэли ты убиваешь врага и сразу умираешь, а он жив(на самом деле тебя убили на пол-пинга (предположим, что это такая мера времени) раньше и ты не мог никого больше убить).
Чтобы в этом убедиться, можешь искусственно увеличить пинг в киберспортивных играх на несколько сотен мс, ну или играть настолько «на грани пинга» (т.е. убивать на пол-пинга позже, чем убили тебя по мнению того клиента) и прочувствовать всю эту боль «но я же уже за стеной был!».
что опять же рефлекс убавит
Рефлекс убавит только локальный пинг «движение мыши -> изменение направления взора на мониторе» (эти данные не зависят от сетевого пинга, т.к. местоположение врагов (почти) всегда известно клиенту, особенно если он может быть в поле прямой видимости). Этот самый рефлекс должен быть полезен даже в динамичных синглплеерных играх. На сколько убавит — другой вопрос, который мы узнаем не раньше выхода первых мониторов с этой технологией.
Ладно. Возможно я был не прав, и у подавляющего большинства игр пинг от 50-300мс.
Однако, в свою защиту скажу, что я упоминал лишь киберспортивные дисциплины. И у них (сам я играл только в cs:go и overwatch) я действительно видел лишь низкий пинг.
«Отрисовочная» и сетевая — это сильно разные задержки. Первая про то, чтобы мышкой навести прицел на врага и начать стрелять, а вторая про то, как быстро после фактической смерти начнет проигрываться анимация смерти (если по мнению клиента попадания были, то «фонтаны крови» и прочие ошметки будут отображаться локально, т.е. не ожидая «разрешения» от сервера, поэтому можно мгновенно скорректировать прицел если пули идут не туда). Современный киберспорт отдает предпочтение убийце, так что точно стрелять (точность прицеливания зависит от задержки мышь->монитор) все же важнее, чем красиво уклоняться (а тут роляет только пинг).
А, ну и у правильного киберспорта сервера по всему миру есть (в популярном шутере от одного автоконцерна я не видел пинга больше 30мс, хотя живу в глубокой-глубокой России), так что либо игра не очень популярная, либо вайфай медленный (я тут подразумеваю и иные проблемы с интернетом со стороны игрока).
Что там распознают текущие нейросети? Ничего, ну или то же самое, что и одноглазый человек.
А вот обучить нейронку на декодирование подобных стереокартинок — задача интересная (и датасет можно легко найти)…
Я скорее поверю в «Магию Apple»*, чем в настолько эффективное сжатие (до 30 раз).
* Под «Магией Apple» я подразумеваю то, что раз уж они делают железо и софт, то вполне могли разработать какой-то аппаратный ускоритель для их алгоритма сжатия (если оно настолько эффективно), ну или инсталлировать чипы какой-то более медленной (чем обычная DRAM) и дешевой энергозависимой памяти под своп.
P.S. Я, вероятно, как-то неправильно пользуюсь телефоном, но никогда не обращал внимание на «выгрузку» приложений. Они просто чуть дольше переключаются (т.е. они засвопились и стали читаться вместо быстрой RAM из медленной ROM, но это все равно достаточно быстро, т.е. вместо условных 100мс я ждал 1000мс).
ABI у плюсов — вещь условная (MSVC, например, обещает, что если поменялась версия компилятора, то все сломается). Поэтому, самым верным способом для библиотек будет использовать FFI (т.е. использовать ABI от C). Ну, либо всегда компилировать одним компилятором, на одной машине и в один день (а лучше вообще линковать статически).
P.S. Разве плюсовый манглинг не поможет в случае, когда у измененных методов другая сигнатура? Или vtable не содержит в себе самих символов?
киберспортсменыличности, имеющие больший ранг чем у меня, говорят, что по циферкам fps упал, но также упал и input-lag, а следовательно и играть стало комфортнее. i5, 940m или схожая мобильная графика, нативный порт csgo, ubuntu 16.04. А, ну и из-за его матчмейкерского бэкграунда я посоветовалпересобрать ядросделать apt install linux-rt — input-lag стал ещё меньше, но и fps упал до неприлично низких значений.К сожалению, большинство этих фреймворков требуют boost.asio, из-за чего элегантно встроить http-бэкэнд в уже имеющееся приложение мне не удалось.
Не самое красивое решение, но единственный официальный способ - реализовывать класс hash в своем неймспейсе и передавать его как шаблонный параметр.
Ключ расшифровки - на серверах самого мессенджера, т.к. серверу верить можно (в нем точно не будет злого умысла).
Ещё есть TOTP. Я уверен, что его принципы работы здесь не применимы, но если все же был бы закрытый ключ, который будет действителен только указанное время, то было бы круто.
Скорее всего, из-за названия самой первой части bf 1942. Ну, и сайфайный сеттинг вида "ровно через 100/200 лет после WWII снова в разгаре огромная война" звучит нормально.
P.S. а ремейк 2142 мне бы было интересен, но по сравнению со 2 и бк1 частями он радикально никому не интересен.
Я не говорю именно про текущую реализацию RTX/DXR. Я говорю про сам способ рендеринга трассировкой лучей. А шумодавы нужны для подавления шума, который появляется из-за недостаточного количества лучей.
Основной же мой ответ можно увидеть в соседней ветке.
Проблема текущей реализации RT - в том, что она очень и очень медленно считается. Когда вырастет производительность аппаратных ускорителей не в десятки раз, а в сотни-тысячи десятков раз и мы сможем полноценно считать кадр одними лишь лучами за вменяемое время (все современные инженерные и кинематографические визуализаторы из разных CAD'ов и 3dsmax'ов так считают, например), то вот тогда мы сможем полностью отказаться от растеризации.
Все же, реальный мир "рендерится" исключительно лучами (ну, насколько я могу судить из той программы физики, что мне преподавали), так что для получения максимальной "реалистичности" картинки надо просто повторить то, что уже было создано далеко до первого изобретенного способа растеризации.
Лично мое мнение заключается в том, что для получения хорошей картинки с современным развитием технологий (ну, может лет через 2-5 развития видеоадаптеров) нам помогут нейросети (они же уже аппаратно плохую картинку с фото-матрицы телефона поднимают до уровня средне-бюджетных зеркалок).
Да, есть один максимально простой для разработчика и максимально естественный способ рендеринга... Если память не изменяет, то там что-то про трассировку и лучи.
Так что, для светлого графического будущего осталось всего ничего: выпустить действительно производительный аппаратный ускорятор рейтрейсинга и сделать его популярным (скажем, чтобы оно точно было хотя бы у 95% целевой аудитории). И чтобы единственная градация железа была лишь в том, сколько десятков километров дальности видимости, или сотен тысяч объектов частиц надо нарисовать.
За лучами будущее, и так считают многие в индустрии.
Мое долгое нытье про (не)стабильность яблочной техники
Решил перейти на инопланетные технологии небожителей (судя по восторженным отзывам в Интернете). Макбук эйр на интеле (и это, КМК, была моя главная ошибка) как печатная машинка с ssh'ем и браузером, и первый айфон как единственная мобилка...
К странности софта я уже почти привык (хотя, после года пользования все равно иногда возникают вопросы). Но вот стабильность железа (или все же качества низкоуровневого софта) - полная и беспросветная бездна.
Особенно плохо с вайфаем - при нагрузке и (возможно) небольших проблемах с сетью, стабильный кернел паник (или как этот экран с белыми буквами и иконкой выключения на черном фоне называется). Так оно ещё и подвисает постоянно в таких сценариях. Но здесь модуль intel, ладно, простим (ведь x86 больше никому не нужны, да?).
Иногда были кернел паники, с систрейсом указывающим на драйвер APFS...
Вообще, ноутбук обычно работает пару месяцев, и это, кажется, нормально... Для 2005 года. Сейчас у меня основной рабочий десктоп на винде (и немного разогнанный моими кривыми ручками) работает гораздо стабильнее (ни единого бсода за последний год).
За пару месяцев пользования айфоном было несколько фризов на несколько минут, но яблочный саппорт посоветовал сбросить через файндер... Так и сделал, уже несколько недель - полет стабильный.
Резюмируя: железо у эппла отменное (особенно тачпад и корпус макбука очень нравятся), но вот качество драйверов в частности и ОСи в целом - ужасное (постоянные краши, фризы, баги и тому подобное).
Да, именно так. Когда я писал "мы стали даже 2D рисовать как 3D", я имел ввиду, что после перехода на гибкий конвейер, видеокарте стало абсолютно безразлично что считать, и что весь смысл, который есть в данных - вкладываем в него мы (ну, ещё есть выходной буфер, который имеет уже одно конкретное заранее назначенное разработчиками OpenGL'я предназначение, но суть не об этом).
Увы, но почти всегда это не наш случай. Хотя бы масштабирование, но матрица (или не матрица, но с матрицами, возможно, будет быстрее) преобразований должна быть почти всегда, так что её нигде кроме, допустим, того же SRP (как Scriptable Rendering Pipeline в Unity) не найти в готовых движках.
Я выше написал "с матрицами будет быстрее", предполагая, что для матриц есть аппаратное ускорение, и что оно выполнится так же быстро (условно - за один такт), как и просто перемножение/сложение векторов. Но данных будет однозначно больше (впрочем, можно и на процессоре большую часть матриц перемножить). Однако, надо профилировать, в разных вариантах, и на разных видеокартах.
И как же тогда определять порядок отрисовки? Допустим, z-координата (или слой, или как угодно это можно называть) будет лишь на стороне процессора. И мы будем регулировать порядок отрисовки порядком вызовов отрисовки (т.е. метод художника). Хорошо, это будет работать, но не факт, что это будет быстрее, потому что таким образом мы ломаем параллелизм видеокарты и большинство ядер (особенно при отрисовке маленьких спрайтов, или при огромном количестве ядер) будет простаивать, ожидая отрисовки этого маленького спрайта (чтобы случайно его не закрасить). А ещё, отказавшись от Z-буфера мы выиграем целых 8мб видеопамяти.
Во многом это зависит от визуального стиля (пиксель-арту точно пойдет на пользу), но обычно при очень маленьком масштабе рисуемый объект становится раздражающе не-сглаженным, что, зачастую, не самый желанный эффект.
Я почти уверен, что там проблема в (случайно) убитом батчинге и инстансинге. Но без конкретных примеров (а ещё лучше с возможностью модифицировать их исходники и произвести оптимизацию) говорить об этом бессмысленно. Сделать плохо можно на любом движке, и с любым рендером.
P.S. Я не осуждаю, но мне и правда интересно: это Вы поставили мне минус в карму, и если да, то, неужели, за мой комментарий?
Disclaimer: я не имею желание очернить, обелить или оскорбить любого человека или технологию в нижележащем тексте. Фактологических ошибок в статье немного, но я значительно не согласен с идеей статьи. Не стоит принимать мой токсичный комментарий (хотя я честно пытался сделать его менее "токсичным") близко к сердцу.
Почему на нем?
Если под "долго запускается" имеется ввиду редактор, то ему это позволительно делать (можно привести аналогию с простым "блокнотом", который потребляет пару МБ ОЗУ и запускается мгновенно, и с "блокнотом для программистов", который потребляет ГБ ОЗУ и может запускаться до нескольких минут на огромных проектах). Если же речь про сам итоговый билд игры, то, исходя из моего опыта, запуск может казаться долгим лишь из-за лого самого юнити в бесплатной версии.
Про объем билда могу лишь не согласиться. Только что проверил на актуальной LTS-версии - сделал за пару часов аналог flappyBird'a используя шаблон 2D (не прибегая к тюнингу для снижения размера итогового файла). И при размере ассетов в 200кб, билд windows-x64 занимал 59.8МБ, а файл .apk для android лишь 18.3МБ. Разумеется, это в 18 раз больше, чем на нативных для платформы ЯП (хотя для винды нужен будет ещё msvc-redist), но где Вы последний раз видели игру меньше, хотя бы, 10 мегабайт?
Думаю, что поддержка 2D в UE4 Вас шокирует... Касательно юнити, там очень хорошая поддержка 2D, даже физика не от 3D, так что претензии на 3D-корни движка мне не ясны. Если конкретно идет речь про оверхед от математики, то он предельно низок, и, на самом деле, выгоды от использования именно 3D-математики больше. Если же важна именно скорость рендеринга (т.е. аппаратное ускорение 2D-отрисовки), то, увы, но её, вроде бы, теперь вообще нигде нет. После популяризации DirectX10/OpenGL3 все ушли с фиксированного конвейера рендеринга, то есть, ради возможности использовать пост-процессинг и кастомные материалы (гуглится по запросу "2d shaders") мы стали даже 2D рисовать как 3D. Возможно, что за счет упрощения математики в шейдере из-за отказа от 3-го измерения в Godot'е, будет некоторое увеличение скорости, но оно будет несоизмеримо мало по сравнению с грамотной работой с ассетами, хотя бы, в том же юнити.
ООП как по учебнику
Прочитал. В терминах юнити это будет: префабы, компоненты, экземпляры (инстанцы, если пользоваться общеупотребильной терминологией). На самом деле, идея с иерархией компонентов - достаточно интересная, но как и в том же анриле, вызывает сомнения. На ум приходит лишь польза от перемещения дочерних объектов вместе с родительскими, но это применимо лишь для тех компонентов, что имеют координаты в сцене. Погуглив, четкого ответа на вопрос "зачем так сделано" я не нашел.
У юнити есть множественно крайне сомнительных решений в архитектуре, но здесь это не оно, по моему мнению.
Сигналы
В Unity есть множество callback'ов (функций, что вызываются в скрипте, когда происходит какое-то событие) как от компонентов (OnTriggerEnter2D), так и от движка (Start, Update). Также можно делать собственные callback'и через UnityEvent (ну, или event из самого C#). Вообще, концепция событийно-ориентированного программирования развита в юнити достаточно не плохо, но если Godot достигает в этом аспекте новых вершин, то это действительно хороший повод к нему приглядеться.
Я не знаю, получилось это случайно, или при написании статьи в качестве опорного референса излишне использовались официальные туториалы по Godot Engine, но эта формулировка звучит очень похоже на заголовок из главы про сигналы.
UI-элементы
И это более правильный подход, потому что организовать интерактивный GUI гораздо сложнее, чем обычный счетчик патронов или hp-bar.
Я, хоть и не использую юнити в качестве основного инструмента, но ни разу за время моего пользования им (вернее, "новой" UI-системой, которая используется по умолчанию с 20..18(?) года) я не испытывал какой-то особой боли. Даже сейчас в пустом проекте я создал и настроил несколько счетчиков и полосок (хотя, с прогресс-баром возникли сложности, да, поэтому я его сделал из слайдера). Возможно, что проблемы начинаются при попытках переиспользовать настроенные GUI-префабы, но, если я правильно понял, то Godot не преподносит в этом плане ничего нового.
Что намекает на то, что интерактивные, сложные, многослойные интерфейсы на нем проектировать не стоит.
C# или GDscript
Подозреваю, что остальные 4 строчки в C# состоят исключительно из { и }.
Если я правильно понимаю, то GDscript полон по Тьюрингу, что означает, то, что, технически, на нем можно сделать абсолютно все. На практике же, ограничения появляются в недоступности некоторых API, чего, по идее, быть не должно, если движок действительно проектировался под GDscript и этот ЯП до сих пор поддерживается.
Сразу же с создания системы на HA заглядываюсь на NodeRED (т.к. подобное event-flow программирование лично мне кажется куда более логичным и удобным чем конфиги HA и даже чем обычный код), но менять ядро пока не готов, а одновременно использовать две конкурирующих технологии — очень сомнительное архитектурное решение.
Поддержка кучи интеграций (я в начале был не очень умен и собирал на решениях разных вендоров и HA помог мне все это связать воедино, сейчас же последние 10 добавленных устройств исключительно Esp8266 + Паяльник + ESPHome (крутая штука, кстати)).
Удобство настройки из GUI (и особенно печально, когда приходится для настройки какой-то интеграции лезть в сonfiguration.yaml).
Некоторые проблемы с оптимизацией и багами (очень медленное отображение истории недавно починили, но вот recorder все равно при перезапуске инстанца заставляет себя ждать по 5-30 минут, да и полный перезапуск вкладки в хроме можно объяснить виной самого хрома но так происходит только с HA).
Очень неудобные автоматизации (кмк, не хватает переменных, более удобных и настраиваемых триггеров, более компактных шаблонов (jinja не то чтобы плох, но у HA он получился слишком явным) и много чего ещё (сейчас я думаю, про автоматизацию исключительно на алертах, но потребность для каждого делать отдельный binary sensor мгновенно рушит всю мотивацию сделать «красиво и на века»). NodeRED выигрывает на тысячи очков вперед в этом вопросе, а без автоматизации «Умный дом» не такой уж и «умный». Хотя, сейчас думаю про pyscript, но пока ещё не решился его настроить и перевести все свои автоматизации (они, к счастью, пока очень простые, т.к. даже на элементарную «снижать уровень синего у лампочек к ночи, если никто вручную лампочки за последнее время не выставлял» потребовало больше 5 часов моего времени).
P.S. Очень надеюсь, что все мои проблемы — исключительно из-за прямоты моих рук, и сейчас мне здесь доходчиво объяснят почему я не умею правильно готовить HA и покажут как надо.
P.P.S. В самой стать неоднократно идет ссылка на некоего Алекса Квазиса (про которого я впервые слышу, вероятно, потому что я ни с какими сообществами автоматизаторов не взаимодействовал, а постигал все сам исключительно с документации HA), и так как наши взгляды в этом вопросе (исхожу исключительно из статьи и пары оставленных Вами комментариев здесь же) по большей части схожи, то интересует Ваше субъективное мнение о ценности его видео (т.к. в самой статье ощущается сильная противоречивость его личности).
P.P.P.S. Прошу прощения за графоманию и другие проблемы моего языка (хоть он и является моим родным).
Удивительно, но прямо сейчас оно именно так и работает.
Ты заходишь за угол — и умираешь. Оказывается, что ты уже был мертв когда заходил за угол, но тебе об этом сервер не успел сообщить. Та же самая ситуация, когда в дуэли ты убиваешь врага и сразу умираешь, а он жив(на самом деле тебя убили на пол-пинга (предположим, что это такая мера времени) раньше и ты не мог никого больше убить).
Чтобы в этом убедиться, можешь искусственно увеличить пинг в киберспортивных играх на несколько сотен мс, ну или играть настолько «на грани пинга» (т.е. убивать на пол-пинга позже, чем убили тебя по мнению того клиента) и прочувствовать всю эту боль «но я же уже за стеной был!».
Рефлекс убавит только локальный пинг «движение мыши -> изменение направления взора на мониторе» (эти данные не зависят от сетевого пинга, т.к. местоположение врагов (почти) всегда известно клиенту, особенно если он может быть в поле прямой видимости). Этот самый рефлекс должен быть полезен даже в динамичных синглплеерных играх. На сколько убавит — другой вопрос, который мы узнаем не раньше выхода первых мониторов с этой технологией.
Однако, в свою защиту скажу, что я упоминал лишь киберспортивные дисциплины. И у них (сам я играл только в cs:go и overwatch) я действительно видел лишь низкий пинг.
Я имел ввиду то, как происходит компенсация пинга для точного аима в динамичных сетевых играх.
Здесь это хорошо объяснено: habr.com/ru/post/303006
«Отрисовочная» и сетевая — это сильно разные задержки. Первая про то, чтобы мышкой навести прицел на врага и начать стрелять, а вторая про то, как быстро после фактической смерти начнет проигрываться анимация смерти (если по мнению клиента попадания были, то «фонтаны крови» и прочие ошметки будут отображаться локально, т.е. не ожидая «разрешения» от сервера, поэтому можно мгновенно скорректировать прицел если пули идут не туда). Современный киберспорт отдает предпочтение убийце, так что точно стрелять (точность прицеливания зависит от задержки мышь->монитор) все же важнее, чем красиво уклоняться (а тут роляет только пинг).
А, ну и у правильного киберспорта сервера по всему миру есть (в популярном шутере от одного автоконцерна я не видел пинга больше 30мс, хотя живу в глубокой-глубокой России), так что либо игра не очень популярная, либо вайфай медленный (я тут подразумеваю и иные проблемы с интернетом со стороны игрока).
А вот обучить нейронку на декодирование подобных стереокартинок — задача интересная (и датасет можно легко найти)…
* Под «Магией Apple» я подразумеваю то, что раз уж они делают железо и софт, то вполне могли разработать какой-то аппаратный ускоритель для их алгоритма сжатия (если оно настолько эффективно), ну или инсталлировать чипы какой-то более медленной (чем обычная DRAM) и дешевой энергозависимой памяти под своп.
P.S. Я, вероятно, как-то неправильно пользуюсь телефоном, но никогда не обращал внимание на «выгрузку» приложений. Они просто чуть дольше переключаются (т.е. они засвопились и стали читаться вместо быстрой RAM из медленной ROM, но это все равно достаточно быстро, т.е. вместо условных 100мс я ждал 1000мс).
P.S. Разве плюсовый манглинг не поможет в случае, когда у измененных методов другая сигнатура? Или vtable не содержит в себе самих символов?