gettext хорошо решает задачу сбора строк в перевод по исходному коду проекта, изменение, добавление, удаление. Fluent же вообще к этим задачам не относится, поэтому их нельзя сравнивать целиком.
Как формат Fluent гораздо мощнее .po
P.S. В .po даже есть msgid_plural, но его не называли «Концепцией асимметричной локализации — ключевой инновацией»
В gettext есть msgctx, в чём проблема то была?
Доработки со стороны программистов всё равно останутся, передавать переводчикам контекст всё равно придётся, число, пол и т.д.
По-хорошему переводить её заново всё равно придётся, просто старый перевод может висеть довольно долго (и не всегда это правильно). Мелкие правки неплохо закрывает fuzzy, ну и можно держать английские тексты как перевод (en.po) и править мелочи там, не трогая код.
Адаптация bitset как части стандартной библиотеки к конкретному железу — вещь полезная, но вот пример с клавиатурой на мой взгляд выбран неудачно.
Из-за этого на опрос сложно ответить объективно, например я считаю:
А. Конкретно для клавиатуры особо быстрый bitset не особо нужен, и оптимизировать его излишне, ну не зажимают часто быстро большое количество кнопок (преждевременная оптимизация);
Б. Для других задач оптимизация bitset может быть необходима;
Как-то нераскрыта обратная связь, ведь имплант в теории можно использовать не только для чтения «ввода» (мозг-компьютер), но и для «вывода» (компьютер-мозг), и это совершенно новые возможности, на порядок круче, чем текущий VR или игры вообще. :)
Майнили не только биткоин. Не думаю что гуглу нужно покупать железо, прогоревшие майнеры сами потащат железо гуглу за процент от аренды/подписки с игрушек. Ведь именно площадка — сервис привлекает пользователей. При виртуализации железо легко сменить, гугл практически ничем не рискует. Игрушки всё-таки венчурный бизнес, вот пусть майнеры и рискуют окупаемостью железа :).
Конечно все хотят продать по-дороже и цена на видеокарты не спешит падать.
Если не можешь продать железо, то будешь хотя-бы сдавать его в аренду. А как иначе окупить?
Стоимость железа постоянно падает, нужно как-то держать волну спроса и куда-то его девать/обновлять. Вот недавно была волна с майнерами биткоинов, после них, думаю, осталась масса неплохого железа. Его надо куда-то девать, ведь уже нового наделали :)
Среднестатистические 20 баксов. И эти 20 баксов считались исходя из предполагаемых объёмов продаж. Поскольку сейчас они лишь портируют уже существующие игры на эту платформу, то основную часть затрат они уже отбили за счёт старых-добрых продаж. А учитывая, что число потенциальных пользователей браузера на порядок больше, то и цену можно сделать на порядок меньше. Проблем с мощностями нет, можно сказать что они даже простаивают если Google решил пустить их на игрушки :)
Как правило рассчитываются исходя из необходимой точности для приятного внешнего вида, косвенно привязаны к количеству пикселей/уровню детализации. Нет смысла генерировать карту теней 4096х4096 если окошко 640х480. В зависимости от реализации, например если оба игрока находятся в одной комнате — карту теней можно повторно использовать без вычисления.
GI
Не совсем понимаю связь с Global Illumination — она довольно сложно считается сама по себе, игры обычно используют заранее вычисленные значения/текстуры. Самих текстур может потребоваться больше — да, но текстуры скорее всего будут повторно использоваться. Кроме того для меньшего окна можно использовать и текстуру по-меньше. Всякие пост-процессинг фильтры обычно завязаны непосредсвенно на пискелях.
Симуляции
Как и GI — вы правы что они не зависят от количества пикселей, но и от количества игроков они тоже не явно зависят. Одиин игрок вполне может создать больше хаоса своими действиями, там что-нибудь большое взорвать, чем несколько других игроков вместе взятых. Да, в теории они все будут творить по-максимуму, но это скорее исключение. Накладные расходы сетевой игры на симуляцию даже больше чем в split screen, но игры делаются.
Затраты на обработку геометрии
Использование уровней детализации геометрии решает эту проблему
особенно о консолях
Как ни странно split screen намного более распространён на консолях, чем на ПК
Вот допустим в самом худшем случае добавление второго игрока будет требовать в два раза больше ресурсов, но не больше же.
Если игра уже прекрасно идёт с родной частотой работы монитора — значит ресурсов ей достаточно. И добавление второго игрока, пусть даже с просадкой FPS в два раза (а из-за запаса это будет меньше чем в 2 раза) вполне допустимо. Т.е. для меня как игрока это не проблема, я согласен — дайте мне эту возможность!
Сейчас один играет 120 FPS, а вдвоём упадёт до 60ти.
Это правда существенно, даже в наихудшем случае? Я так не считаю
Думаю пользовательские данные — каждое действие в игре, движение мышкой будут накапливаться, анализироваться. После набора нужного количества ценных данных введут подписку :)
Лучше было бы сказать что split screen не обязательно требует значительно больше ресурсов, т.к. пикселей больше не становится на одном и том же экране игры.
Проблема ресурсов для split screen игр немного надуманая, наиболее распространённые жанры в режиме split screen не требуют чего-то недостижимого в плане ресурсов. Я даже готов пожертововать FPS (даже пополам разделить) ради поддержки второго монитора.
В плане разработки добавить split screen обычно проще, чем реализовать игру по сети.
Почему же не будут, какой смысл разработчикам работать над пачкой форматов — игры как раз будут эксклюзивом для этой стриминговой платформы, и ни в каком другом формате распространяться не будет :)
Если правильно помню, старое железо не любило прозрачность. После прорисовки второго «зеркального» мира с альфа смешиванием рисовалась сама поверхность зеркала, и конкретно на этом примере FPS проседал заметно больше, чем в два раза.
Разработка игры не всегда ограничивается лишь самим движком. Часто это ещё и инфраструктура для сборки, всякие плагины, конвертеры и редакторы, средства отладки и профилирования где как раз всё логично и понятно. (и медленно и падает) :)
В моём понимании блокчейн используется для того, чтобы преодолеть кризис доверия. Т.е. при частном недоверии участников, само большинство считается вполне честным, не сговорившимся. Результат работы блокчейна и есть тот, с которым согласно большинство. Фактически ответственность с какого-то конкретного участника «размазывается» по всем, по меньшей мере по большинству.
Я вижу аналогию с «усреднением под большинство» в самом блокчейне.
Большинство пользователей не будет разворачивать свою ноду для подтверждения, а будут использовать какую-нибудь публичную, которой доверяют. А так как они доверяют ноде, то блокчейн там или не блокчейн уже не важно — чистый маркетинг.
Как формат Fluent гораздо мощнее .po
P.S. В .po даже есть msgid_plural, но его не называли «Концепцией асимметричной локализации — ключевой инновацией»
Доработки со стороны программистов всё равно останутся, передавать переводчикам контекст всё равно придётся, число, пол и т.д.
Из-за этого на опрос сложно ответить объективно, например я считаю:
А. Конкретно для клавиатуры особо быстрый bitset не особо нужен, и оптимизировать его излишне, ну не зажимают часто быстро большое количество кнопок (преждевременная оптимизация);
Б. Для других задач оптимизация bitset может быть необходима;
Конечно все хотят продать по-дороже и цена на видеокарты не спешит падать.
Если не можешь продать железо, то будешь хотя-бы сдавать его в аренду. А как иначе окупить?
Среднестатистические 20 баксов. И эти 20 баксов считались исходя из предполагаемых объёмов продаж. Поскольку сейчас они лишь портируют уже существующие игры на эту платформу, то основную часть затрат они уже отбили за счёт старых-добрых продаж. А учитывая, что число потенциальных пользователей браузера на порядок больше, то и цену можно сделать на порядок меньше. Проблем с мощностями нет, можно сказать что они даже простаивают если Google решил пустить их на игрушки :)
Ну что-же, давайте по порядку:
Как правило рассчитываются исходя из необходимой точности для приятного внешнего вида, косвенно привязаны к количеству пикселей/уровню детализации. Нет смысла генерировать карту теней 4096х4096 если окошко 640х480. В зависимости от реализации, например если оба игрока находятся в одной комнате — карту теней можно повторно использовать без вычисления.
Не совсем понимаю связь с Global Illumination — она довольно сложно считается сама по себе, игры обычно используют заранее вычисленные значения/текстуры. Самих текстур может потребоваться больше — да, но текстуры скорее всего будут повторно использоваться. Кроме того для меньшего окна можно использовать и текстуру по-меньше. Всякие пост-процессинг фильтры обычно завязаны непосредсвенно на пискелях.
Как и GI — вы правы что они не зависят от количества пикселей, но и от количества игроков они тоже не явно зависят. Одиин игрок вполне может создать больше хаоса своими действиями, там что-нибудь большое взорвать, чем несколько других игроков вместе взятых. Да, в теории они все будут творить по-максимуму, но это скорее исключение. Накладные расходы сетевой игры на симуляцию даже больше чем в split screen, но игры делаются.
Использование уровней детализации геометрии решает эту проблему
Как ни странно split screen намного более распространён на консолях, чем на ПК
Вот допустим в самом худшем случае добавление второго игрока будет требовать в два раза больше ресурсов, но не больше же.
Если игра уже прекрасно идёт с родной частотой работы монитора — значит ресурсов ей достаточно. И добавление второго игрока, пусть даже с просадкой FPS в два раза (а из-за запаса это будет меньше чем в 2 раза) вполне допустимо. Т.е. для меня как игрока это не проблема, я согласен — дайте мне эту возможность!
Сейчас один играет 120 FPS, а вдвоём упадёт до 60ти.
Это правда существенно, даже в наихудшем случае? Я так не считаю
Проблема ресурсов для split screen игр немного надуманая, наиболее распространённые жанры в режиме split screen не требуют чего-то недостижимого в плане ресурсов. Я даже готов пожертововать FPS (даже пополам разделить) ради поддержки второго монитора.
В плане разработки добавить split screen обычно проще, чем реализовать игру по сети.
Я вижу аналогию с «усреднением под большинство» в самом блокчейне.