Comments 209
Смешалось все: графон, производительность, RTX и так далее.
А теперь минутку внимания. Игры весят так много ради того, чтобы сократить количество случайных обращений к файлам во время игры относительно текущей позиции считывания с HDD/SSD по секторам.
Наиболее показательный пример: Marvel Spider-Man, эксклюзив PS4. Директор студии (или кто-то из их топов, не помню), объяснил вес игры очень просто, далее вольный пересказ цитаты:
«Человек-паук весит так много, потому что нам постоянно приходилось дублировать одни и те же файлы для того, чтобы снизить нагрузку на накопитель и обеспечить бесшовный игровой опыт без внезапных пролагов и загрузок посреди игры. Многие текстуры и прочие графические файлы продублированы в игре по 7-8 раз».
Стремление сделать игровой опыт бесшовным — вот основная причина таких размеров современных игр. А не графон и все остальное прочее. Если убрать дублирование из топовых тайтлов, они вполне себе похудеют до привычных 20-25 гигов, вот только локации будут сильно ограничены, лоад-скринов станет на порядки больше, да и загрузки эти будут не сильно быстрыми.
И не пахнет тут никакой «хреновой оптимизацией» и «игроки заплатят». Это просто ограничения HDD, потому что большинство не может себе позволить терабайтный SSD для «игор», да и не нужен он, при такой цене за гиг на классических блинах.
А теперь минутку внимания. Игры весят так много ради того, чтобы сократить количество случайных обращений к файлам во время игры относительно текущей позиции считывания с HDD/SSD по секторам.
Наиболее показательный пример: Marvel Spider-Man, эксклюзив PS4. Директор студии (или кто-то из их топов, не помню), объяснил вес игры очень просто, далее вольный пересказ цитаты:
«Человек-паук весит так много, потому что нам постоянно приходилось дублировать одни и те же файлы для того, чтобы снизить нагрузку на накопитель и обеспечить бесшовный игровой опыт без внезапных пролагов и загрузок посреди игры. Многие текстуры и прочие графические файлы продублированы в игре по 7-8 раз».
Стремление сделать игровой опыт бесшовным — вот основная причина таких размеров современных игр. А не графон и все остальное прочее. Если убрать дублирование из топовых тайтлов, они вполне себе похудеют до привычных 20-25 гигов, вот только локации будут сильно ограничены, лоад-скринов станет на порядки больше, да и загрузки эти будут не сильно быстрыми.
И не пахнет тут никакой «хреновой оптимизацией» и «игроки заплатят». Это просто ограничения HDD, потому что большинство не может себе позволить терабайтный SSD для «игор», да и не нужен он, при такой цене за гиг на классических блинах.
Сильно сомнительно. Мы ведь имеем кучу примеров из тех же 90-х, когда игры игрались комфортно, без особых задержек на подзагрузки. Как-то выходили из положения же… По сравнениею с теми временами скорости ЖД выросли в 20-30 раз, нет никаких проблем считывать файлы столько, сколько нужно.
Дублирование данных для ускорения доступа к ресурсам стало широко применяться как раз в 90-х, на первых же CD-приставках. Оно повсеместно используется на 3DO, PS1, и прочем подобном железе.
3D акселерация на PC появилась только в середине-конце 90-х.
Тогда поступали просто — грузили всё в видеопамять и никакого стриминга.
Стриминг появился уже потом, в 00-х.
А вот на PS1 он уже вовсю использовался в 90-х.
Где-то в параллельной вселенной, где уже вышла PS6.
Тогда поступали просто — грузили всё в видеопамять и никакого стриминга.
Стриминг появился уже потом, в 00-х.
А вот на PS1 он уже вовсю использовался в 90-х.
нет никаких проблем считывать файлы столько, сколько нужно.
Где-то в параллельной вселенной, где уже вышла PS6.
Тогда поступали просто — грузили всё в видеопамять и никакого стриминга.
Кстати, насчёт видеопамяти не скажу, но тот же первый Doom (1993 год) подгружает не все данные подряд сразу. Если запустить игру напрямую с CD — видно, как фризится игра при первых подгрузках недостающих звуков (первый раз стреляешь из дробовика и т.п.)
Так в том то и дело же. Скорости выросли всего лишь в 20-30 раз, а объёмы в тысячи. Так что проблемы как раз таки есть, и существенные.
В PlayStation 5 обещают SSD вместо обычного жесткого дика как в 4 версии и сильное «похудание» игр именно из исчезновения необходимости дублировать данный для оптимизации загрузки с hdd
Только вот тут есть парадокс — если убрать «продублированные файлы» и похудеть игры до 20-25 гигов, то внезапно оказывается, что даже на WD Green на 240 гигабайт за три тысячи можно спокойно разместить операционку, пяток игр и ещё место останется. А поскольку любой SSD обладает низкой задержкой при доступе к данным — то и нет проблемы «пролагов» от того, что файл лежит не в том месте накопителя.
Разработчикам нужно ориентироваться на минимальную конфигурацию, а консоли текущего поколения выпускаются только с хдд. Так что разработчикам приходится продолжать дублировать ресурсы, а обладатели быстрых ссд продолжают страдать)
В новом поколении консолей ссд будет стандартом, и та же Сони, рассказывая о ПС5, делает на этом акцент, заявляя что у разработчиков больше не будет в этом необходимости и все новые игры «похудеют».
В новом поколении консолей ссд будет стандартом, и та же Сони, рассказывая о ПС5, делает на этом акцент, заявляя что у разработчиков больше не будет в этом необходимости и все новые игры «похудеют».
GTA V на PS3 весит около 9 гигабайт (на пк я буквально недавно скачивал 92 гигабайта). Мне кажется, на вряд ли, тут дело в дублировании для оптимизации, ведь на PS3 256 мегабайт оперативной памяти и столько же видеопамяти, а на ПК требует в минималка 4 и 1 соответственно. На PS3 одноядерный процессор, а на ПК требует 4 ядра, но тут скорее всего дело в архитектуре процессора.
Всё это я к тому, что и оптимизировать умеют и относительно небольшие размеры делать.
Всё это я к тому, что и оптимизировать умеют и относительно небольшие размеры делать.
То, тчо вы сказали, является правдой, но только для игр, загружаемых с CD-дисков. Там это имело смысл, особенно для низкоскоростных болванок. А вот для HDD дисков это уже менее существенно. Для SSD вообще не имеет значения. Более того, для современных ПК такое дублирование наносит больше вреда, чем пользы, потому что диски используют кэширование и дублирующиеся данные вполне могут находиться в кэше, давая мгновенный доступ. Дублируя данные разработчик по факту отказывается от кэширования данных на диске.
даже больше: кроме диска эти данные кэширует ещё и ОС
в Wolfenstein: Tides of War на xbox в каждый файл уровня запакованы все необходимые файлы и дублируются
У многих игр, в которых ресурсы упакованы/зашифрованы, все необхоимые для уровня данные упакованы в один файл. С одной стороны, из-за возможного дублирования растёт объём файлов. С другой стороны, это упрощает разработку и сборку дистрибутива. Отдельная группа работает над отдельным уровнем и работает с теми ттекстурами-моделями, котоыре им нужны, может их свободно редактровать и т.д. и т.п. Если бы все тексуры хранились в одном мега-паке или в открытую в папке лежали, то можно было бы дубликаты убрать, но это может несколько затруднить разрботку и взаимодействие левел-дизайнеров.
Скорее всего, сейчас дублирование ресурсов происходит не в целях оптимизации загрузки, а в целях оптимизации времени разработки.
Не говоря о том, что в архивах игры есть куча неиспользуемых ресурсов, которые дата-майнеры выковыривают после релиза (типа пистолета в Дум Этёрнал).
Скорее всего, сейчас дублирование ресурсов происходит не в целях оптимизации загрузки, а в целях оптимизации времени разработки.
Не говоря о том, что в архивах игры есть куча неиспользуемых ресурсов, которые дата-майнеры выковыривают после релиза (типа пистолета в Дум Этёрнал).
Интересно, что мешает при упаковке дубля вставлять ссылку на уже упакованный экземпляр, чтобы не пухлить архив?
А кто знает, что они дубли? Если уровни делаются и пакуются разными командами, то каждая из них работает со своей копией. Дубли можно было бы определять на этапе финальной сборки, написав какой-то дедупликатор, который бы эти айдишники и вставлял. С другой стороны, я подозреваю, что системы стриминга современные очень бы плохо это восприняли. Жесткому диску тоже не понравится, когда его отправят собирать по всему диску кусочки секции уровня, которую надо подгрузить за считанные миллисекунды, чтобы игру не пришлось ставить на жесткую паузу и подгружать синхронно.
Так разработчики же и знают, а если нет — действительно перед релизом прогнать через дедупликатор, оптимизировать однажды 200 ГБ, сжать с параноидальными настройками, чтобы у клиентов летало.
А жёсткому диску разве не нагрузка лишние десятки гигабайт лопатить? Или сейчас, с дублями в отдельных паках, всё оптимизировано? Да и отыграли своё они, по крайней мере при нынешней плотности записи. SSD действительно предпочтительны, а у них со случайным доступом всё хорошо.
А жёсткому диску разве не нагрузка лишние десятки гигабайт лопатить? Или сейчас, с дублями в отдельных паках, всё оптимизировано? Да и отыграли своё они, по крайней мере при нынешней плотности записи. SSD действительно предпочтительны, а у них со случайным доступом всё хорошо.
Жесткому диску плевать сколько у него места занято. Ему совсем не плевать на последовательность секторов, которые от него требуют. Seek time то огромный. И вот если этот дедупликатор данные раскидает по всему диску в целях экономии, то система стриминга будет просто вешать намертво игру, потому что диск не успевает отдать данные вовремя. Поэтому намного лучше в каждый пак каждого уровня засунуть все ресурсы, которые нужны на этом уровне. И отдельно можно сделать один пак с общими ресурсами для всех уровней куда, например, моделька ГГ пойдет, звуки многие и т.д. и т.п.
Разрабы спайдермена на пс4 действительно рассказывали, что дублируют данные так, чтобы система стриминга всегда линейно читала данные. А это игра с открытым миром, где все поделено на зоны. И в каждой зоне, по сути, будут какие-то дупликаты.
Разрабы спайдермена на пс4 действительно рассказывали, что дублируют данные так, чтобы система стриминга всегда линейно читала данные. А это игра с открытым миром, где все поделено на зоны. И в каждой зоне, по сути, будут какие-то дупликаты.
И я о том же, играть с жёсткого диска некомфортно именно из-за больших задержек при произвольном доступе. SSD предпочтительны.
В современных играх этот некомфорт виден только при медленных загрузках. Далее системы стриминга отлично справляются на скоростях HDD. SSD как раз полезны, чтобы эти загрузки сократить, и то разве что в сингле. В мультиплеер тебя все равно скорее всего заставят ждать всех остальных, у кого может быть WD Green какой-нить.
Годах этак в 2008-2009 я как раз такую систему пилил. Работал тогда в Creat Studios ныне почившей, делали игры для PS3. Была своя навороченная система упаковки-распаковки данных, как раз для того, чтобы избежать рандомных обращений к диску.
Но это все шло из еще более ранних консолей, из тех времен когда реально бились за каждый байт. А по ощущениям где-то начиная с того поколения консолей к этому стали менее серьезно относиться — мощности стало достаточно. Все еще меньше чем на ПК, и с особенностями, но уже не так чтобы игры в пару Мб пихать.
Разработчики игр уже не видят разницы между Dev-версией и релизной сборкой? А может, они сейчас и бинарники debug-сборки в релиз пускают, вместе со всей отладочной информацией и влинкованными исходниками?
А примерно так и есть. Раз уж они в дистрибутив игры помимо защищённых файлов кладут и исходные не защищённые…
А не могли бы вы привести пример на комментарий к статье 2017 года? %)
У if-else есть один большой недостаток: ошибка копипасты. В switch невозможно по ошибке написать два одинаковых case, в if-else это случается постоянно.
Создал аккаунт на Хабре именно чтобы это узнать. Но оказалось, что оставлять комментарии под старыми статьями мне нельзя.
Такие вопросы надо задавать вот тут, аккаунт у вас уже есть: qna.habr.com
Пример? Ctrl+C, Ctrl+V… (отвлёкся)… Ещё раз Ctrl+V, редактируешь новое условие, забыв про предыдущее. Обнаруживаешь статическим анализатором или при тестировании.
Пример? Ctrl+C, Ctrl+V… (отвлёкся)… Ещё раз Ctrl+V, редактируешь новое условие, забыв про предыдущее. Обнаруживаешь статическим анализатором или при тестировании.
У PUBG в самой обычной релизной сборке лежат .pdb файлы рядом с .exe. Внутрь не заглядывал, но если это в самом деле дебажные символы, то это 10/10 сразу же — игра, которая ""«боролась»"" с читерами.
Совершенно не факт, что способ кэширования файлов операционной системой — самый правильный, и подходит под конкретную задачу. Например, если ты качаешь торренты, то у торрент-качалки сильно больше понимания семантики происходящих операций, чем у операционной системы. (Какая там семантика у стриминга в играх — я хз, поэтому правильный пример подобрать не смогу)
UFO just landed and posted this here
Я бы даже сказал, что кэш винды частенько ухудшает производительность. Особенн префетчер, который загружает в память все файл из открытой папки и её подпапок. Часто с таким сталкивют, что он накэширует 32 гигабайта ненужных файлов, из которых я только один файл открывать собираюсь (например, из папки с резервными копиями). А потом пытается свопиться или просто тратит время на удаление из памяти ненужных данных, чтобы начать кэшировать следующие ненужные…
Но, если говорить конкретно про игры. Напрмиер, ресурсы без дубликатов весят 10 гигабайт, а с дубликатами они весят 50 гигабайт (цифры от балды, могу ошибаться на порядки в любую сторону). В первом случае весь пак ресурсов может остаться в кэше ОС, а во втором случае у подавляющег большинства пользователей он уже в кэше не останется и для загрузки следующего уровня снвоа придётся читать с диска.
Но, если говорить конкретно про игры. Напрмиер, ресурсы без дубликатов весят 10 гигабайт, а с дубликатами они весят 50 гигабайт (цифры от балды, могу ошибаться на порядки в любую сторону). В первом случае весь пак ресурсов может остаться в кэше ОС, а во втором случае у подавляющег большинства пользователей он уже в кэше не останется и для загрузки следующего уровня снвоа придётся читать с диска.
Допустим, а нереальный вес каких нить WoWs чем объяснить где бесшовность даром ненужна?
Если раньше текстуры делались под FUllHD, то теперь под 4к. Но финальный бандл содержит текстуры разного качества, от наименьшего до наивысшего. То есть, если текстуры под FullHD весили 20Гб, то если добавить еще 4к, то будет грубо говоря 20 * 4 + 20, итого 100 Гб. Что тут оптимизировать не понятно, сжимать и пережимать, чтоб текстуры превратились в мыло? Это и так делают. Но зачем тогда тратить силы на качественные текстуры?
Ну так вроде прошли те времена, когда узнать характеристики пользовательского железа можно было лишь после запуска игры. Сейчас-то у нас Steam и подобные же вещи. Так если у игрока до сих пор 1024x768, то может ему и не надо HD-текстуры? Дать скачать минималистичный дистрибутив и всё на том.
Да в крайнем случае вообще можно сделать как в EVE Online, когда скачивание моделей/текстур происходит поштучно, по требованию — по мере того, как они реально становятся нужны игроку.
Да в крайнем случае вообще можно сделать как в EVE Online, когда скачивание моделей/текстур происходит поштучно, по требованию — по мере того, как они реально становятся нужны игроку.
Текстурка нужна, а интернета нет. Или текстурок надо на гиг, а играть хочется прям сейчас. Для нетребовательной сетевой игры в космосе такое прокатит. А для тяжелого синглового блокбастера нет.
Вообще у некоторых такое было. Помнится в танках (WoT) был какой-то отдельный HD-клиент.
А вообще это в первую очередь лень разработчиков. Зачем париться и что-то там делать? Ведь куда проще сделать жирнющий клиент, с текстурами на от экрана тостера до 8К, да еще и озвучку на 16 языков впихнуть. Ах, и еще дорожка для роликов-синематиков отдельным файлом — это сложно, поэтому засунем в клиент повторный видеоряд 16 раз.
Могу напомнить, что полтора года назад был скандал с Rainbow Six Siege, когда разработчикам было лень делать отдельный клиент для Китая, поэтому изменения под цензуру собирались сделать для всего мира.
А вообще это в первую очередь лень разработчиков. Зачем париться и что-то там делать? Ведь куда проще сделать жирнющий клиент, с текстурами на от экрана тостера до 8К, да еще и озвучку на 16 языков впихнуть. Ах, и еще дорожка для роликов-синематиков отдельным файлом — это сложно, поэтому засунем в клиент повторный видеоряд 16 раз.
Могу напомнить, что полтора года назад был скандал с Rainbow Six Siege, когда разработчикам было лень делать отдельный клиент для Китая, поэтому изменения под цензуру собирались сделать для всего мира.
А вообще это в первую очередь лень разработчиков. Зачем париться и что-то там делать? Ведь куда проще сделать жирнющий клиент, с текстурами на от экрана тостера до 8К, да еще и озвучку на 16 языков впихнуть.А не встанете ли вы потом в первых рядах ныть, что современные игры намертво приколочены к интернету?
Да-да, череп в баре и неоновую ножку стриптизерши отстояли буквально с боем :)
Но насчет радуги — я до сих пор не понимаю, что там на 20 небольших картах весит под 70 гигов. В такой объем не то что ультраХД текстуры — можно полнометражное кино в 720 качестве снять про каждого игрового оперативника в отдельности.
Но насчет радуги — я до сих пор не понимаю, что там на 20 небольших картах весит под 70 гигов. В такой объем не то что ультраХД текстуры — можно полнометражное кино в 720 качестве снять про каждого игрового оперативника в отдельности.
Эти двадцать небольших карт могут использовать свои уникальные наборы ассетов каждый, что даёт на каждую по 3.5 Гб.
Посмотрим на первое попавшееся мне видео — Map Starter Guide Consulate. Там 3 этажа, по ~20 комнаток в каждом, каждая содержит с десяток различных объектов — это даёт порядка 600 текстур. Плюс есть ещё открытое пространство — допустим, это ещё 400 текстур. Тогда на каждую приходится всего 3.5 мб — что совсем немного, ведь даже простая несжатая картинка 24-bit 1920x1080 весит 6 мб — а для правильного отображения материалов в разных условиях освещённости может быть необходимо сразу несколько их для учёта карт нормалей и прочего, причём там и близко не пахнет сжимаемостью современных видеокодеков.
Посмотрим на первое попавшееся мне видео — Map Starter Guide Consulate. Там 3 этажа, по ~20 комнаток в каждом, каждая содержит с десяток различных объектов — это даёт порядка 600 текстур. Плюс есть ещё открытое пространство — допустим, это ещё 400 текстур. Тогда на каждую приходится всего 3.5 мб — что совсем немного, ведь даже простая несжатая картинка 24-bit 1920x1080 весит 6 мб — а для правильного отображения материалов в разных условиях освещённости может быть необходимо сразу несколько их для учёта карт нормалей и прочего, причём там и близко не пахнет сжимаемостью современных видеокодеков.
Мне кажется, вы немного перегибаете.
1) Консульство — среднестатистическая карта без извратов, есть покрупнее, есть поменьше. Комнат там дай Бог по 10 на этаж со всякими закоулками.
2) Однотонные стены и регулярные рисунки типа паркетов вряд ли представляют из себя большие текстуры.
3) Очень много объектов типа столов, гаражных дверей, холодильников, ограждений не уникальны. Серверная комната или детская есть вообще на каждой карте.
Я все же склоняюсь к указанной вами ресурсоемкости освещения + разрушаемости объектов. Но для классического шутана без открытого мира в сто километров все равно многовато.
1) Консульство — среднестатистическая карта без извратов, есть покрупнее, есть поменьше. Комнат там дай Бог по 10 на этаж со всякими закоулками.
2) Однотонные стены и регулярные рисунки типа паркетов вряд ли представляют из себя большие текстуры.
3) Очень много объектов типа столов, гаражных дверей, холодильников, ограждений не уникальны. Серверная комната или детская есть вообще на каждой карте.
Я все же склоняюсь к указанной вами ресурсоемкости освещения + разрушаемости объектов. Но для классического шутана без открытого мира в сто километров все равно многовато.
на каждую приходится всего 3.5 мб — что совсем немного, ведь даже простая несжатая картинка 24-bit 1920x1080 весит 6 мб
Так а зачем их несжатыми хранить? Для реалистичных текстур — jpeg, для мультяшных — png.
Это же просто ориентир для сравнения.
И текстуры только в редких случаях можно сжимать с потерями:
Если вылезут артефакты сжатия — то это может очень резко бросаться в глаза в виде областей пикселей совершенно левого цвета.
И текстуры только в редких случаях можно сжимать с потерями:
В современных ААА проектах используется физически корректный рендер — PBR. Суть этой технологии: есть отдельная карта чистого цвета объекта без бликов и затенений, карта отвечающая за силу отражений, и карта передающая гладкость/шершавость поверхности, которая отвечает за размер блика.+ это всё накладывается на развёртку модели.
Если вылезут артефакты сжатия — то это может очень резко бросаться в глаза в виде областей пикселей совершенно левого цвета.
Это не только "лень", а тупо стоимость поддержки. Все эти дополнительные опции требуют дополнительных разработчиков. Чем больше разработчиков — тем медленней они работают (и каждый человек отдельно, и все вместе как команда). Медленные релизы и повысившаяся стоимость игры снижают ее качество на коммерческий успех.
Та же Близзард в некоторых своих играх это реализовывала, так Диабло и Старкрафт становились доступными для игры с частично скачаным клиентом. Майкрософт реализовывала подобное в Halo 2. Но большинство разработчиков похоже просто не имеют времени/денег/желания для такой оптимизации.
У близов реализовано несколько иначе. Тебе не загружается контент, который будет недоступен на начальных этапах игры. Но со временем загрузится все, и хорошо если это произойдет быстро, в противном случае будешь тыкаться в невидимые стены, деревья и тд. Это личный опыт. Подобная вещь не решает проблему с местом на накопителе, она лишь позволяет начать играть немного раньше. Это было актуально для тех, у кого скорость интернета была слабоватой.
До сих пор например скачивая SC2 через лаунчер можно поставить загрузку на паузу после прохождения отметки playable. Что это дает: нет файлов кампании, нет файлов с высоким качеством текстур и т.д. и т.п. Докачиваться файлы до настроек графики клиента начинают по мере необходимости, например, если параметры графики стоят высокие, то прямо во время игры на ладдере можно наблюдать, как размытые текстуры и модельки становятся более высокого качества.
Такое уже есть, но используется, к сожалению, не всеми. Тот же Rainbow 6:Siege предлагает ультра текстуры отдельной опцией(как бесплатное DLC), добавляющей дополнительные ~40 ГБ.
Ожидание: анализ ресурсов игр.
Реальность: покупайте наших слонов.
Реальность: покупайте наших слонов.
а зачем ожидать какого-то серьёзного анализа в корпоративном блоге?
блогеры на ютубе придумывают интеграцию рекламы в видео, а здесь придумывается статья под рекламу. крайне редко кто-то из корпораций обладает энтузиазмом писать какие-то статьи прст так. в подавляющем большинстве статья пишется для рекламной вставки. лишь варьируется степень вложения ресурсов в «техничность» статьи. где-то поверхностный обзор и реклама, а где-то хоть сколько-нибудь годное исследование.
блогеры на ютубе придумывают интеграцию рекламы в видео, а здесь придумывается статья под рекламу. крайне редко кто-то из корпораций обладает энтузиазмом писать какие-то статьи прст так. в подавляющем большинстве статья пишется для рекламной вставки. лишь варьируется степень вложения ресурсов в «техничность» статьи. где-то поверхностный обзор и реклама, а где-то хоть сколько-нибудь годное исследование.
Риторический вопрос или нужен ответ? Если кратко, то это моё недовольство несоответствием названия содержанию.
Аналогично habr.com/ru/company/wd/blog/503368/?reply_to=21650620#comment_21648786.
Аналогично habr.com/ru/company/wd/blog/503368/?reply_to=21650620#comment_21648786.
Милфгард нас тут разбаловал.
Ну хз, например, я недавно писал в блоге работодателя статью про организацию пультовых для онлайн-трансляции конференций. Писал как на духу, было интересно поделиться и посмотреть, что скажут наши конкуренты, которые тоже у себя что-то организуют. Руководство не ставило задачи "написать статью под рекламу", скорее — "мы тут делаем крутые штуки, расскажи о них что-нибудь интересное". Вот, рассказал. На этой неделе напишу, как превратить офис в съемочную площадку. Единственная "реклама" там в том, что это не какая-то абстрактная схема реализации пультовых, а опыт конкретной команды, и об этом не стесняясь сказано несколько раз.
В смысле, не надо сразу так уж всех под одну гребенку. Кто-то старается, кто-то нет. Тут первая часть статьи была довольно интересная. Например, я как раз хотел пособирать данные о размерах дистрибутивов разных свежих игр — и оп, автор за меня посчитал размер Колды. Отлично же, ну. Печально, что статья где-то на середине пошла на спад — вероятно, тупо не хватило времени. Еще немножко бы автор дожал, и случилась бы нетленка.
А по-моему, вообще разные люди писали. Скорее всего было так: вот тут у нас есть рекламный текст, разбавьте его немного, чтобы не сильно был на рекламу похож. Но ничего лучше не придумали, кроме как прилепить интересное начало к рекламе
Для меня отчётливой границей (прямо в глаза бросилась и порезала) стала фраза:
"за счет чего оказывается на 60% быстрее, демонстрируя устойчивую скорость 2400 МБ/с в операциях последовательного чтения против максимальных 1500 МБ/с, если сравнивать с NVMe SSD, использующими урезанный PCIe × 2."
После неё тут же перемотал к комментам, так как понятно что сама статья там кончилась.
UFO just landed and posted this here
Так ведь на размер игры влияют в первую очередь текстуры, а не наличие открытого мира. Думаю, самый яркий пример — Minecraft: какого размера там открытый мир, и сколько при этом весит сама игра.
UFO just landed and posted this here
На самом деле мир в Minecraft не занимает место только пока он не сгенерирован, если его сгенерировать весь, то по данным вики он займёт более 70 ПетаБайт
Minecraft тут не уместен вообще. В Minecraft мир генерируется процедурно по мере продвижения по карте и вполне может разрастаться до десятков гигабайт.
Minecraft вообще не пример. Потому что Minecraft имеет процедурно-генерируемый мир. В каком шутере с сюжетом вы видели процедурно генерируемый мир?
UFO just landed and posted this here
PCIe 1x последовательная
PCIe 4x какая?
Группа из четырёх последовательных интерфейсов?
PCIe 4x какая?
Группа из четырёх последовательных интерфейсов?
UFO just landed and posted this here
Да, но. К примеру, никто не скажет, что DVI — параллельный интерфейс. При этом три линии несут взаимосвязанные данные, и все три необходимы для корректного воспроизведения сигнала (на самом деле — нет, можно принимать только один цвет, мало того — его можно подать на все три, будет монохромное изображение — раньше, по крайней мере, работало). А DVI dual link — параллельный или последовательный ;)
С другой стороны, устройство в pci-e может трактовать данные, принимаемые по разным линиям, независимо и использовать в разных целях. С третьей — с точки зрения тактирования сигнала, все линии в каком-то смысле параллельны. А ещё, вероятно, можно эмулировать на pci-e шину pci (на сигнальном, не программном уровне) — она будет параллельная или последовательная?..
Кстати, если сгруппировать два эзернета, они тоже перестанут быть независимыми. Есть ещё RAID…
С другой стороны, устройство в pci-e может трактовать данные, принимаемые по разным линиям, независимо и использовать в разных целях. С третьей — с точки зрения тактирования сигнала, все линии в каком-то смысле параллельны. А ещё, вероятно, можно эмулировать на pci-e шину pci (на сигнальном, не программном уровне) — она будет параллельная или последовательная?..
Кстати, если сгруппировать два эзернета, они тоже перестанут быть независимыми. Есть ещё RAID…
Есть несколько видов параллельной работы на линях связи. Первая — эмуляция. QoS и стек TCP/IP. Несколько пакетов отправляются одновременно и каждый из них независимо проходит свой путь, но используют одну линию связи. Второй: со-зависимые данные. К примеру, шина данных, когда одна линяя передает только один конкретный байт какого-либо байта, слова, двойного слова и т.п. Как вы понимаете, тут максимальная скорость, но данные зависимы. Более того, если у меня шина данных 256бит, а нужен только один байт, то остальные линии будут передавать не те данные. Третий вид: полная параллельность. К примеру, к свитчу подключены 32 пользователя гигабитным кабелем(те же самые 256 линий связи) и каждый из них абсолютно независимо друг от друга ползает в инете. Минус: дополнительная нагрузка на линии связи в виде заголовков пакетов. Плюс: большая независимость и гибкость.
Все верно, оптимизация для быстрой загрузки, в первую очередь, на консолях, это открыто заявляется уже давно. Новые консоли прямо сейчас презентуют на очень быстрых SSD, по этому есть шанс, что в будущем размер игр так быстро расти не будет. Текстур будет все больше конечно, но они не будут дублироваться.
UFO just landed and posted this here
Потому что у некоторых есть привычка отмечать все галочки при установке. Лично у меня весит два с половиной.
У меня Android Studio совсем без галочек ставится на Linux из ZIPа и занимает 1.4 гига, но со временем (а время тикать начинает с момента начала открытия первого проекта или его создания) разрастается, и сейчас уже занимает 9.8 гигов (дистрибутив + SDK + NDK + ~/.gradle) и при этом всё равно при открытии других проектов норовит подкачать чего-нибудь ещё из интернета раз за разом.
Потому что для SDK лежат lib, obj, pdb файлы, плюс слишком много ненужных галочек при инсталляции выбрано было.
Всего 50?
В играх, как в современном кино, в погоне за красивой картинкой и эффектами забыли про сюжет и общее впечатление от игры.
А вы забыли про геймплей.
а разве сюжет не одна из составляющих геймплея?
«Сюжет в игре — как сюжет в порнофильме. Он должен быть, но он не так уж важен.»
Какой сюжет у Тетриса?
Геймплей широкое определение. Сюжет очень часто самая важная часть геймплея, если включать туда персонажи, диалоги и прочие следствия наличия сюжета. Механика, сам процесс беготни/стрельбы/прочего очень часто становится второстепенным. Часто, он может вообще отсутствовать, как в тетрисе. Игры бывают разные.
В общем, вы правы, только замечание:
Сюжет без геймплея (aka геймплей, состоящий только из сюжета) = фильм
Геймплей без сюжета = игра
Отсюда я бы сказал, что сюжет — важная, но не ключевая составляющая геймплея.
Сюжет без геймплея (aka геймплей, состоящий только из сюжета) = фильм
Геймплей без сюжета = игра
Отсюда я бы сказал, что сюжет — важная, но не ключевая составляющая геймплея.
Геймплей это всеобъемлющее определение, которое включает весь игровой опыт. Туда входит и просмотр катсцен, и чтение записок, и болтовня с глазу на глаз. Игра без геймплея это отсутствие вообще всего. Вы скорее про отсутствие игровых механик, но таких игр и не бывает. Это действительно уже не игра, если игроку нечем управлять. Поэтому даже банальные QTE типа хэви рейна это полноценная игра со своей механикой, где в центре геймплея прежде всего сюжет.
Специально же уточнил, чтобы не спорить о терминах:
aka геймплей, состоящий только из сюжетаОк, пусть будут «игровые механики»
Вы скорее про отсутствие игровых механик, но таких игр и не бываетЯ про то же: игровые механики обязательны, сюжет — нет. Да, некоторые игры механик кладут мало, а сюжета — много. На мой взгляд, такие «игры» колеблются где-то между играми и другими видами искусства (есть даже термин такой «визуальная новелла»). Про игры без сюжета, но с механиками такого сказать нельзя.
Ок, пусть будут «игровые механики»
Это важно, потому что отсюда и растут ноги у подобных споров, особенно приверженцев «старой школы», у которых любая катсцена показатель деградации. Геймплей в шутере это далеко не только стрельба.
В визуальной новелле точно так же есть игровая механика и это всего лишь один из жанров игр, без кавычек. Я начал про определения, потому что вы закончили фразой
«Отсюда я бы сказал, что сюжет — важная, но не ключевая составляющая геймплея»
Сюжет может быть ключевой составляющей геймплея, а может не быть. Упомянутый хэви рейн — игровая механика там не имеет никакого значения. На минимальности сложности она заключается в нажатии одной кнопки, проиграть практически невозможно. Ключевой элемент геймплея это сюжет и его составляющие. Практически визуальная новелла только в 3д.
Ну так можно дойти до того, чтобы признать, будто бы книги, фильмы и комиксы тоже обладают отличным геймплеем.
Сид Мейер как-то дал определение: «игра — это коллекция интересных выборов». И он был полностью прав. Чем меньше действия игрока влияют на ход событий, тем меньше там собственно игры.
Если в VN'ке игрок только и может, что жать далее-далее-далее, и нет ни одного выбора, влияющего на сюжет, то чем это отличается от комикса? Это что угодно, только не игра.
В принципе, большинство VN'ок можно вообще в виде книг выпускать. Обычных, не электронных даже. И особой разницы заметно не будет.
Сид Мейер как-то дал определение: «игра — это коллекция интересных выборов». И он был полностью прав. Чем меньше действия игрока влияют на ход событий, тем меньше там собственно игры.
Если в VN'ке игрок только и может, что жать далее-далее-далее, и нет ни одного выбора, влияющего на сюжет, то чем это отличается от комикса? Это что угодно, только не игра.
В принципе, большинство VN'ок можно вообще в виде книг выпускать. Обычных, не электронных даже. И особой разницы заметно не будет.
Ну тогда все-таки вы геймплеем называете то, что геймплеем не является. Alexey2005 хорошо написал, я только добавлю ссылку на википедию:
ru.wikipedia.org/wiki/Геймплей
ru.wikipedia.org/wiki/Геймплей
интерактивное взаимодействие игры и игрока
сюжет как участие в нём игрокаИменно как участие, т.е. взаимодействие, а не просто просмотр. Когда взаимодействие сведено к минимуму, то про геймплей говорить трудно.
Геймплей это всеобъемлющее определение, которое включает весь игровой опытВот графика, например, определенно является частью игрового опыта — но не частью геймплея.
На мой взгляд, такие «игры» колеблются где-то между играми и другими видами искусства (есть даже термин такой «визуальная новелла»).
Да, на самом деле даже "визуальная новелла" без особых каких-то игровых механик (по сути, только перемещение по карте, "активация" и диалоги, состоящие из выбора предопределённых фраз/действий) вполне себе неплохо так может поколебать психическое состояние игрока своими базовыми текстовыми диалогами дополненными изображениями (если реально вжиться в игру).
И новеллы на это и рассчитаны.
Мне ваш диалог видится примерно так:
«В хорошей книге очень важную роль играет сюжет!» — «Какой сюжет у словаря или телефонного справочника?» ;)
«В хорошей книге очень важную роль играет сюжет!» — «Какой сюжет у словаря или телефонного справочника?» ;)
Т.е. вы согласны, что бумажное изделие может содержать текст или картинки, ноты или иероглифы, а может и вообще ничего содержать — и он самодостаточен?
Да. Подобно тому, как и фильм тоже может не предусматривать сюжета, если он документальный или справочно-обучающий, или специально изготовлен для целей релаксации и демонстрации в комнате отдыха сотрудников предприятия.
Просто вообще неплохо было бы уточнить, какие классы игр требуют наличие сюжета, а не задаваться пространным вопросом о том, требует или нет наличия сюжета сферическая игра в вакууме.
Другое дело, что сюжет забывают завозить даже туда, где он действительно необходим, как это отмечено в комментариях выше. А если и завезут, то это часто недоваренная каша из клюквы, заезженых штампов и стереотипов.
Просто вообще неплохо было бы уточнить, какие классы игр требуют наличие сюжета, а не задаваться пространным вопросом о том, требует или нет наличия сюжета сферическая игра в вакууме.
Другое дело, что сюжет забывают завозить даже туда, где он действительно необходим, как это отмечено в комментариях выше. А если и завезут, то это часто недоваренная каша из клюквы, заезженых штампов и стереотипов.
Про который тоже забыли в погоне за способами монетизации
Я такое называю «в игру забыли добавить игру»
Чем дальше, тем чаще встречаются «игры» с классным визуальным дизайном, иногда даже с историей, иногда интересный мир придуман, но игры внутри нет и делать там нечего :)
Чем дальше, тем чаще встречаются «игры» с классным визуальным дизайном, иногда даже с историей, иногда интересный мир придуман, но игры внутри нет и делать там нечего :)
Как по мне, беда в больших бюджетах (то же самое и в кино). Если раньше игра стоила, скажем, полмиллиона — то можно рискнуть, придумать что-то необычное в геймплее, написать сложный сюжет и выкинуть на рынок в надежде на успех. Сейчас же бюджет игры ААА может и за сто миллионов перевалить, а такими деньгами рисковать дураков нет. Вот и наблюдаем ворох римейков, сиквелов и просто мультиплеерных примитивностей вроде фортнайтов всяких. И в кино — абсолютно то же самое, одни самоповторы. Бюджеты слишком высоки чтобы ими рисковать.
С текстурами есть ещё одна сказочная проблема — нет общеупотребимых lossless форматов. Если дизайнеры хотят, чтобы какая-то конкретная текстура (UI?) была в 24-битном, а не 16-битном цвете, без мыла и артефактов, да ещё и с прозрачностью и mipmaps, то проще всего использовать несжатую текстуру. Для разрешения 4096*4096 это около 85 мегабайт на один файл. Его можно заархивировать, конечно, но перед отправкой на видеокарту надо будет распаковать, а это время CPU. Собственно, если кому-то интересно, могу написать статью с обзором этой проблемы и распространенными методами решения.
Разве не "png хватит всем"? Или у него таки есть проблемы?
Есть у него проблема — в видеопамять его не загрузить.
Можно подробнее? Лемпель-Зив или Хаффман плохо переносятся на GPU?
А зачем вы меня спрашиваете? Спросите производителей видеокарт.
Но вообще да, для хранения/использования в видеопамяти он малоприменим.
Но вообще да, для хранения/использования в видеопамяти он малоприменим.
Проблема консерватизма индустрии да, глубока и непреодолима стандартными подходами.
Спросил без издёвки, действительно интересно, чем png не пролазит в GPU.
Спросил без издёвки, действительно интересно, чем png не пролазит в GPU.
Смотрите какая ситуация: в видеопамяти блочные форматы (DXT/BC, PVRTC, ASTC, ETC, etc) хранятся в том же запакованном виде, что и на диске. За счет constant-rate сжатия в момент обращения к случайному текселю можно сразу же найти его блок (обычно 4х4). Далее делается его распаковка за ничтожное время и данными можно пользоваться. Если же у нас текстура сжата variable-rate методом (LZW или Huffman), то случайный доступ не возможен и единственный вариант работы — распаковать её целиком в видеопамять перед использованием. Саму распаковку можно сделать на GPU, но она обычно не распараллеливается, да и гораздо проще сделать это на CPU.
Плюс отдельная проблема в том, что сам формат png не хранит mipmaps. Если же их хранить в разных файлах или слепить в один контейнер, то выходит оверкилл, проще просто хранить несжатую текстуру в архиве ZIP/LZMA/RLE*/Binominal.
* Кстати, я использую именно самописный RLE (привет 14й стандарт!) и он дает космические скорости при распаковке, небольшой размер файлов, еще и распараллеливается. Но об этом в будущей статье, вместе с исходниками.
Плюс отдельная проблема в том, что сам формат png не хранит mipmaps. Если же их хранить в разных файлах или слепить в один контейнер, то выходит оверкилл, проще просто хранить несжатую текстуру в архиве ZIP/LZMA/RLE*/Binominal.
* Кстати, я использую именно самописный RLE (привет 14й стандарт!) и он дает космические скорости при распаковке, небольшой размер файлов, еще и распараллеливается. Но об этом в будущей статье, вместе с исходниками.
png совсем неплох для сгенерированных изображений, а если их специально оптимизировать, то и вовсе хорош.
Оказывается png не одинаково полезен — разный софт может по разному трактовать гамма-коррекцию. Для текстур с альбедо это не сильно критично, но когда вы смешиваете разную информацию в разных каналах, может начинаться боль. А ведь в текстурах может храниться не только цветовая информация, а и вектора для смещений и нормали. Потому получается что удобные форматы для передачи из одного редактора в другой и в движок — это скорее TGA и TIFF, которые хоть и не сжатые, но ведут себя понятно.
А после того как "сырая" текстура попадает в движок (например общепринятые Unity/UE), он их перепаковывает в какой-то DXT или PVRTC, которые могут выполнять контекстное сжатие – например вырезать одну из координат из нормали, потому что ее проще считать в реальном времени из оставшихся двух.
У пнг проблема одна — очень медленная загрузка.
Конечно пишите!
И не будет общеупотребимого формата, пока OpenGL и DirectX не договорятся об универсальном формате сжатия с/без потерь. И пока производители видеокарт не договорятся об общем формате и не реализуют аппаратную подержку этого *открытого* формата. А ещё, пока разработчики графических редакторов не начнут этот формат поддерживать «из коробки», поэтому важно, чтобы формат был открытым.
А то рисуешь текстуру в условном фотошопе, потом сжимаешь без потерь в формат для DirectX с аппаратной подержкой, потом сжимаешь в другой формат для работы под Андроид, потом в другой формат для порта на Линукс… А потом забиваешь и просто сохраняешь bmp.
А то рисуешь текстуру в условном фотошопе, потом сжимаешь без потерь в формат для DirectX с аппаратной подержкой, потом сжимаешь в другой формат для работы под Андроид, потом в другой формат для порта на Линукс… А потом забиваешь и просто сохраняешь bmp.
В целом, уже есть универсальные форматы для OpenGL/DirectX/Vulkan/Metal. Речь о BC1-BC7, они же DirectX 11 Level, теоретически должны в 2020м году поддерживаться везде. К сожалению, BC7 все еще не завезли в половину интегрированных видеокарт, а на мобильных свой собственный зоопарк, который и не собирается как-то меняться.
Другой вопрос, что даже BC7 не дает Lossless.
Другой вопрос, что даже BC7 не дает Lossless.
Так руками-то не нужно сжимать. Вот питонный скрипт, который чистым фотошопом через WIN32 COM API сохраняет картинку в jpeg с помощью всем известного модуля Save for Web. А еще там многое доступно через JavaScript API, и это сильно приятней COM.
from win32com.client import Dispatch
infile = "test.psd"
outfile1 = infile[:-4] + "_export.jpg"
app = Dispatch("Photoshop.Application")
app.Open(infile)
app.Preferences.RulerUnits = 1 # pixels
doc = app.Application.ActiveDocument
options = Dispatch('Photoshop.ExportOptionsSaveForWeb')
options.Format = 6 # JPG
options.Quality = 80
doc.ResizeImage(1000)
doc.Export(ExportIn=outfile1, ExportAs=2, Options=options)
doc.Close(Saving=2) # 2 = psDoNotSaveChanges
app.Quit()
Можно на этапе билда конвертировать
Статья несомненно была бы интересна. Можно приурочить ко вчерашнему юбилею пасьянса «Косынка».
ранее занимавшейся исключительно созданием игровых автоматов
В первом же абзаце статьи про Famicom в Википедии упоминается, что это не первая приставка Nintendo, ранее они выпускали клоны Pong'а.
Доступную память картриджа они распределили следующим образом
Это не авторы так распределили, это приставка так устроена.
1 спрайт имеет размеры 8 × 8 пикселей и может использовать 4 оттенка.
Три 'оттенка'. В таких малых масштабах это существенная разница.
Классная, правдивая статья. Почему игры такие тяжёлые? Потому что покупайте наши SSD :)
Конечно, если сравнивать детище Crytek с любым современным AAA-проектом, в глаза будут бросаться более четкие текстуры, более точное освещение, большее количество полигонов, большая дальность прорисовки. Но так ли уж нужны визуальные улучшения, если теперь, для того чтобы с комфортом поиграть в AAA-релиз при стабильном фреймрейте, не обойтись без топовой машины, мощность которой будет избыточна даже для многих профессиональных задач?Дааа, а Crysis-то, конечно, не требовал топовой машины. Он, собственно, и сейчас её требует.
Это если вовремя переходить на свежие версии движка. Некоторые проекты героически продолжают использовать однопоточный CryEngine 2.0.
Насколько помню, Кризис был знаменит тем, что требовал не просто топовой машины, а топовой машины из будущего. То есть даже топовое современное ему железо не тянуло в максимальных настройках.
В топ-10 незаслуженно обидели авиасимуляторы.
Полная версия DCS World занимает 175 гигабайт (минимальная, если ничего не покупать, порядка 70), требования к ОЗУ у нее 32 гигабайта, я лично видел как было 27 занято (при игре на сервере, синглом 16 хватает впритык). И это при FHD, 4К ожидаемо потребует больше ОЗУ.
MS FlightSimulator 2020 минимально занимает 150 гигабайт, рекомендуется 400 для кеширования высокого разрешения. Игра привязана к сети, общий объем контента 2 петабайта. Канал рекомендуется от 20 мегабит, а лучше 50…
Полная версия DCS World занимает 175 гигабайт (минимальная, если ничего не покупать, порядка 70), требования к ОЗУ у нее 32 гигабайта, я лично видел как было 27 занято (при игре на сервере, синглом 16 хватает впритык). И это при FHD, 4К ожидаемо потребует больше ОЗУ.
MS FlightSimulator 2020 минимально занимает 150 гигабайт, рекомендуется 400 для кеширования высокого разрешения. Игра привязана к сети, общий объем контента 2 петабайта. Канал рекомендуется от 20 мегабит, а лучше 50…
Ну в симуляторах это действительно оправдано.
Игра привязана к сети, общий объем контента 2 петабайта.
Майкрософты обещали же карту всей Земли в игру впихнуть, из-за этого объём и вырос, да и качество картинки наверно будет очень высоким.
Вроде бы разработчики WoT несколько лет назад рассказывали, как они в одном из обновлений работали с солнечным светом, небом и облаками, придавая им естественность, улучшали визуализацию… Может кто-то и рассматривал игру солнечных зайчиков сквозь листву нарисованных деревьев, но когда сам геймплей убивает интерес к игре, то, имхо, никакая навороченная графика проект не спасёт.
Да, карту всей Земли, реальный воздушный траффик (ой, а где же он?), реальную карту погоды (перед выходом из дома сделай вылет на разведку погоды).
Разработчики WoT балансируют между геймплеем и монетизацией, а это само по себе не легко дается. Вероятно, одних лишь новых юнитов и карт мало, нужна и топовая графика. Смотрел как то скриншоты, вот мол, тень от лопаты на корпусе танка теперь реалистичная. Есть ощущение, что это как бы никому не нужно в такого рода. С другой стороны, за двадцать лет из таких мелочей складывается современная игра.
Разработчики WoT балансируют между геймплеем и монетизацией, а это само по себе не легко дается. Вероятно, одних лишь новых юнитов и карт мало, нужна и топовая графика. Смотрел как то скриншоты, вот мол, тень от лопаты на корпусе танка теперь реалистичная. Есть ощущение, что это как бы никому не нужно в такого рода. С другой стороны, за двадцать лет из таких мелочей складывается современная игра.
UFO just landed and posted this here
Шуттеру тоже может быть нужен полезен приколен шлем VR, но конечно, по цене и разнообразию подключаемой периферии авиасимулятор никто не побъет. Я пока обхожусь trackir5 + cobra m5 + gametrix ecs + самопальная панель переключателей. Но народ собирает умопомрачительные кокпиты, в том числе с подвижной платформой.
Если цель игры это результат на серверах, местный народ настоятельно рекомендует мониторы максимально высокого разрешения. Часто, обнаружение противника и его ракет только визуальное, на FHD ничего издалека не видно.
Если цель игры это результат на серверах, местный народ настоятельно рекомендует мониторы максимально высокого разрешения. Часто, обнаружение противника и его ракет только визуальное, на FHD ничего издалека не видно.
Видео про создание Micro Mages, если не видели.
Grand Theft Auto V — 76 ГБ
Текущая версия (та, что из Epic GS) — 89 Г(и)Б (95,6 ГБ).
UFO just landed and posted this here
Незначительна? У самого дешманского PCIex4 NVMe реальная скорость на запись как у SATA теоретическая, а на чтение в 2 раза выше. Притом с гораздо меньшими просадками на рандомном доступе.
Да и где это они сильно дороже?
Да и где это они сильно дороже?
Пару месяцев назад выбирал себе SSD под игры. По результатам изучения форумов и тестов: для игр можно не выделываться и взять какой-нибудь goodram cx400. NVMe ощутимого сокращения времени загрузки не дает.
ПО тестам (видел на ютубах) скорости загрузки игровых уровней — не особо это давало преимущества. NVMe под системный диск — это да, будет польза
Для примера
samsung evo 860 1TB — 12200 руб
samsung evo 960 1TB — 18500 руб
Это все таки сильно дороже, а за пределами бенчмарков разницы между ними не будет в домашней области применения. NVMe на потребительском рынке сейчас это довольно бесполезная вещь. Реальный толк от них получает только корпоративный рынок.
samsung evo 860 1TB — 12200 руб
samsung evo 960 1TB — 18500 руб
Это все таки сильно дороже, а за пределами бенчмарков разницы между ними не будет в домашней области применения. NVMe на потребительском рынке сейчас это довольно бесполезная вещь. Реальный толк от них получает только корпоративный рынок.
Ну эта скорость пока он новый, потом резко падает.
Лайнус с канала Linus Tech Tips как раз на днях извинялся за то, что сравнил скорость SSD PS5 и сторонних SSD для ПК просто по скорости записи и чтения, и выпустил видео о том, что в конструкции SSD полно бутылочных горлышек. У меня вот в ноутбуке стоят и NVMe, и SATA, и разница в скорости загрузки игр если и есть, то на грани сознания.
Эти цифры говорят о том, что потребность во вместительном накопителе становится более чем очевидной. Но что насчет производительности? Быть может, удастся обойтись обычным HDD? Увы, нет.
В таблице ниже приведены данные о потреблении оперативной памяти и VRAM наиболее прожорливыми играми, вышедшими за последние годы (измерения проводились на ультранастройках при разрешении 4K).
А если не выкручивать настройки в край, то мой выделенный под игры старый (10 лет есть точно) жесткий диск (в половину терабайта), все это будет спокойно тянуть, как тянул и раньше. Тем более, что не играю «в графику», и не собираюсь, ибо это путь в никуда. Так что, обойдемся без вашего твердотельника
Дело же не только в объёме накопителя, мой пк многие современные игрушки не вытянет и с терабайтником за счёт старой видеокарты, 1 Гб видеопамяти — это требование игр 5-6 летней давности, сейчас подавай 2-4 и более.
Самая интересная часть статьи — про Micro Mages, имхо
UFO just landed and posted this here
Я так и не понял, как связана производительность приложения с его объемом: )
Call Of Duty: Modern Warfare — уже 210 ГБ, на старте была 150
Кстати, графика в Micro Mages, на мой взгляд, откровенно слабая, если сравнивать с некоторыми древними играми для NES. Тот же Mario занимал всего 31Кб, но насколько он разнообразнее! Если в Micro Mages с уровнями меняется разве только цвет каменных блоков, то в Mario есть несколько типов уровней, которые отличаются принципиально. Поверхность, подземелье и вода — и сразу видно работу дизайнера. В воде ещё и механика движения другая совсем, что создаёт разнообразие.
ИМХО, даже 25 лет назад Micro Mages вряд ли вошла бы в топ-50 лучших игр NES.
ИМХО, даже 25 лет назад Micro Mages вряд ли вошла бы в топ-50 лучших игр NES.
youtu.be/uQeF0RLeYLM?t=1527
Тут интересный разбор RTX в игре Metro, показаны малозаметные, но впечатляющие нюансы.
В целом технология крутая, но еще сырая и малоприменимая на должном уровне.
Тут интересный разбор RTX в игре Metro, показаны малозаметные, но впечатляющие нюансы.
В целом технология крутая, но еще сырая и малоприменимая на должном уровне.
Почему современные игры так много весят?
Потому что лень.
Демосцена — шикарнейший пример оптимизации и генерации ресурсов «на лету», не надо хранить десятки гигабайт текстур, если их можно делать по ходу. И производители железа не в накладе — потребность в мощных процессорах и оперативке останется.
А сейчас игры выходят кое-как, где-то сюжета нет, где-то сложность отсутствует, где-то вообще релиз идёт с кучей багов, и потом долго допиливают и выпускают заплатки.
Потому что лень.
Демосцена — шикарнейший пример оптимизации и генерации ресурсов «на лету», не надо хранить десятки гигабайт текстур, если их можно делать по ходу. И производители железа не в накладе — потребность в мощных процессорах и оперативке останется.
А сейчас игры выходят кое-как, где-то сюжета нет, где-то сложность отсутствует, где-то вообще релиз идёт с кучей багов, и потом долго допиливают и выпускают заплатки.
Процедурная генерация текстур очень далека и от реализма, и от управляемости, т.е. художественности. С ней можно получить только то, на что способен алгоритм (довольно абстрактный арт), а не то, что требует видение дизайнера. Даже элементарный арт уровня первого Doom перевести на процедурную генерацию, сохранив уровень детализации и художественности, едва ли реально — по крайней мере, не придя к необходимости писать уникальный и довольно сложный код для каждой текстуры в отдельности.
Ну в kkrieger как-то сумели 1 уровень шутера впихнуть в 96кб — конечно это было чисто для демонстрации что они так могут, и с кодом там поработали знатно, но не обязательно до такой степени оптимизироваться, но на лету и вполне по сюжету.
Учитывая давность этого единственного примера, всем давно понятно, как именно впихнули, ничего особо сложного там нет, уж точно и близко не сравнимо с уровнем сложности кода современных игр. Можно сделать одну такую игру, дизайн которой подразумевает абстрактное однообразное окружение и противников, две, три, пять. Но все игры такими не сделать.
И кстати, тормозил kkrieger в своё время знатно. Не самый выгодный обмен, компактность ресурсов на скорость работы (которая непосредственно влияет на отзывчивость, а значит и на геймплей) или компактность ресурсов на уровень детализации. Увы, но если бы процедурный подход имел бы реальные преимущества хоть в чём-то, мы давно имели бы множество подобных игр, а у нас до сих пор только одна демка.
И кстати, тормозил kkrieger в своё время знатно. Не самый выгодный обмен, компактность ресурсов на скорость работы (которая непосредственно влияет на отзывчивость, а значит и на геймплей) или компактность ресурсов на уровень детализации. Увы, но если бы процедурный подход имел бы реальные преимущества хоть в чём-то, мы давно имели бы множество подобных игр, а у нас до сих пор только одна демка.
Не обязательно писать сложный код под каждую текстурку отдельно, достаточно написать движок генератора (некое ядро графического редактора) и затем программы к нему (скрипты действий художника, которые записываются когда он собственно создаёт текстуру с нуля).
И почему-то мне кажется, что это получится существенно компактнее и (возможно) даже быстрее, чем качать все пакеты текстур под все разрешения, а затем подгружать их с диска.
К примеру, сценарий: качается только движок игры, движок генератора текстур+скрипты генерации и карты уровней. Затем запускается генератор, который оценивает производительность машины и затем прорисовывает сложные текстуры и сохраняет их на диск, а простые (которые на данной конкретной машине быстрее нарисовать заново чем грузить с диска) генерирует на лету при загрузке уровня.
Плюс, можно обрабатывать текстуры для первого уровня перед запуском игры (в момент загрузки), а текстуры для остальных уровней — фоном во время игры, на свободных ресурсах (когда игрок копается в инвентаре/крафтит/болтает с неписью/whatever).
затем подгружать их с диска.
Все текстуры с диска никто и не подгружает. В нормальных двигах грузятся только нужные мип уровни.
О чём вы вообще? Даже распаковка текстур (если под это нет отдельного аппаратного декодера) может отнимать больше времени, чем загрузка не сжатых текстур даже с HDD. А вы их предлагаете их на лету генерировать.
Неужели, всё настолько плохо, что в AAA-играх диск стал узким местом, а процессор настолько простаивает, что его можно загружать генерацией текстур в реальном времени?
Неужели, всё настолько плохо, что в AAA-играх диск стал узким местом, а процессор настолько простаивает, что его можно загружать генерацией текстур в реальном времени?
Движок генератора и скрипт действий — это то, как объясняли Farbrausch технологию в своём FR-08 16 лет назад. Теперь это очевидно, когда речь идёт о генерации текстур. Что не так очевидно, это уникальность деталей. Условная художественность текстур сводится к уникальным деталям, а уникальность деталей требует очень длинных и сложных скриптов. Чтобы не подменить объём текстур объёмом скриптов, потребуется вводить более сложные, так сказать, примитивы графического редактора (типа брашей для волос), которые будут рисовать очень неуниверсальные элементы, но зато быстро и компактно. В итоге это может выродиться в значительной мере уникальный код для каждой текстуры.
Потому что лень.
Всегда веселит такое невежество. Игры много весят, потому что качество ассетов с каждым годом растет. Потому что современные PBR графические движки требуют больше текстур для отображения материалов (вы же понимаете, что цвет это всего лишь один тип текстур из множества, которые требуются для отображения материалов в играх). Набирает популярность фотограмметрия. Unreal Engine 5 вон показывает, что возможно в новых играх железо сможет переваривать модели по много миллионов полигонов.
Все это закономерно и верно и демо сцена никаким местов не актуальна здесь. Все подходы там абсолютно не применимы к играм.
И зачем эти миллионы полигонов например для тела персонажа, если поверх него одежда тоже с высокой детализацией? И из-за того что лень оптимизировать (хотя бы выкинуть детализацию того, что скрыто) приходится таскать и обрабатывать кучу лишних данных? Хотя я не эксперт, и могу ошибаться.
Почему же не актуальна? В видео прошли эволюцию от потока jpg до высокоэффективных кодеков (и место экономит, и вычислительные мощности занимает); в картинках конечно пока не дошло до превращения фоток в подобие svg, но тоже реально. Так и тут вместо хранения всех типов всех текстур как есть наверняка можно многое выкинуть и заменить алгоритмом. Вот только если сейчас они всё это создают в адских условиях долгие месяцы, чуть ли не живя на работе, то заниматься перегонкой всего в алгоритмы потребует не меньше времени.
Почему же не актуальна? В видео прошли эволюцию от потока jpg до высокоэффективных кодеков (и место экономит, и вычислительные мощности занимает); в картинках конечно пока не дошло до превращения фоток в подобие svg, но тоже реально. Так и тут вместо хранения всех типов всех текстур как есть наверняка можно многое выкинуть и заменить алгоритмом. Вот только если сейчас они всё это создают в адских условиях долгие месяцы, чуть ли не живя на работе, то заниматься перегонкой всего в алгоритмы потребует не меньше времени.
И зачем эти миллионы полигонов например для тела персонажа, если поверх него одежда тоже с высокой детализацией? И из-за того что лень оптимизировать (хотя бы выкинуть детализацию того, что скрыто) приходится таскать и обрабатывать кучу лишних данных? Хотя я не эксперт, и могу ошибаться.
Вы сами то поняли, что тут написали? Я нет.
А миллионы полигонов нужны, чтобы картинку красивее сделать. Теже лица. Полигоны нужны, чтобы морщины показывать, работу мышц.
в картинках конечно пока не дошло до превращения фоток в подобие svg, но тоже реально
И занимать это будет намного больше, чем в растровом представлении. Векторные форматы здесь вообще не актуальны.
Так и тут вместо хранения всех типов всех текстур как есть наверняка можно многое выкинуть и заменить алгоритмом.
Нельзя. Я фотограмметрию не случайно упомянул, почитайте, что это такое. Эффективных кодеков полно и современные GPU позволяют хранить текстуры прямо в сжатом виде в видеопамяти. Консоли следующего поколения будут иметь аппаратную поддержку сжатия на уровне файловой системы, новый формат сжатия текстур.
Ну а алгоритмы это вообще не решение проблемы. Внезапно, создание игры это практически полностью создание ассетов. Последнее это творческая работа множества людей, задача которых сделать так, как задумал человек, а не так, как выплюнул алгоритм. Для многих тайтлов теже персонажи это лицо франчайза. Каждая их деталь доводится до идеала. У алгоритмов есть своя узкая ниша — автоматизации рутины и игры это вполне применяют там, где могут. Компаниям пофиг на место на диске, зато совсем не пофиг на работу художников. Если алгоритм может сэкономить их время без ущерба остальному, то его применяют. Так у нас и появляются хитрые системы растительности, ландшафтов, помещений и прочее и прочее. Вам стоит глубже разобраться в вопросе, прежде чем обвинять кого-то.
> Потому что лень.
> Баги
Как размер ресурсов связан с багами? Вы с пикабу сбежали? Вам 55 лет?
> Баги
Как размер ресурсов связан с багами? Вы с пикабу сбежали? Вам 55 лет?
Размер ресурсов — отсутствие оптимизации, если людям лень/некогда/… ресурсы оптимизировать, то и заниматься полным тестированием и устранением багов тоже не будут.
Нет.
Нет.
Нет.
Нет.
> В огороде бузина, а в Киеве дядька.
Много ААА тайтлов зашипили? Давайте честно, вы же умничаете в посте про игры.
> ресурсы оптимизировать
Кроме как текстурных атласов, PVRTC/DXTC компрессии, мержа геометрии, запекания света в лайтмапы и оптимизации формата вершин? Это уже давно автоматизировано на билд серверах.
Много ААА тайтлов зашипили? Давайте честно, вы же умничаете в посте про игры.
> ресурсы оптимизировать
Кроме как текстурных атласов, PVRTC/DXTC компрессии, мержа геометрии, запекания света в лайтмапы и оптимизации формата вершин? Это уже давно автоматизировано на билд серверах.
Не потому что лень, а потому что человеко-часы напрямую влияют на стоимость разработки.
32bit RGBA pixel requared 4 bytes
1k texture = 4Mb
2k texture = 16Mb
4k texture = 64Mb
PBR 1k texture = 12Mb
PBR 2k texture = 48Mb
PBR 4k texture = 192Mb
4k 2k 1k
2500 textures 450Gb 112Gb 30Gb
2000 textures 320Gb 100Gb 24Gb
500 textures 90Gb 25Gb 6Gb
Вот почему.
1k texture = 4Mb
2k texture = 16Mb
4k texture = 64Mb
PBR 1k texture = 12Mb
PBR 2k texture = 48Mb
PBR 4k texture = 192Mb
4k 2k 1k
2500 textures 450Gb 112Gb 30Gb
2000 textures 320Gb 100Gb 24Gb
500 textures 90Gb 25Gb 6Gb
Вот почему.
Поиграл вчера в игрушку Aeroplane Adventure на pico-8. Как же это здорово!
А теперь признайтесь, только честно: были ли после Crysis игры, которые произвели на вас такой же вау-эффект? Не глубиной геймплея, не сюжетом, не отдельными фишками, вроде лицевой анимации в L.A. Noire или физики огня в Alone in the Dark, а именно превосходной картинкой?
Сейчас, к сожалению, в такое не играют. Сейчас в моде майкрафты всякие, аркады типа фортнайта с пиксельной или мобильной графикой. Лично я в 2000-х после фар края и крайзиса ожидал от 2020 года фотореалистичной графики неотличимой от реальности, желательно в шлеме VR, а не вот это:
UFO just landed and posted this here
UFO just landed and posted this here
Сейчас, к сожалению, в такое не играют
Играют и подобных игры полно. Игр, которые поражают картинкой, выходит с завидным постоянством каждое поколение. Это я не знаю, каким игроком надо быть, чтобы не видеть огромный прогресс со времен кризиса первого, который сегодня выглядит устаревшим и убогим.
Игры есть, но они далеко не так популярны как всякие майнкрафты, фортнайты и другие.
Но все же согласитесь что разница между играми конца 90-х и кризисом (2007) на порядки больше чем между кризисом и современными (какая там сейчас самая крутая в плане графики, метро эксодос?)
Это я не знаю, каким игроком надо быть, чтобы не видеть огромный прогресс со времен кризиса первого, который сегодня выглядит устаревшим и убогим.
Но все же согласитесь что разница между играми конца 90-х и кризисом (2007) на порядки больше чем между кризисом и современными (какая там сейчас самая крутая в плане графики, метро эксодос?)
Согласитесь, что и разница между прогрессом в железе за те же периоды не меньше.
Игры есть, но они далеко не так популярны как всякие майнкрафты, фортнайты и другие.
Правильно. Потому что как было раньше, так есть и сейчас — графика не продает игры. Крузис продался еле еле, а сама игра, как и вся серия, в общем-то, была провальной, где ничего кроме графона и не было. Такая же судьба была у Ryse. Crytek бездарны как разработчики игр, но вполне способны как инженеры. Правда вот, продать этот свой инженерный талант у них так и не получилось. CryEngine никто не использует.
Но все же согласитесь что разница между играми конца 90-х и кризисом (2007) на порядки больше чем между кризисом и современными (какая там сейчас самая крутая в плане графики, метро эксодос?)
Это закономерный процесс. Чем ближе мы к фотореализму, тем выше становится стоимость улучшений, которые все меньше видны глазу. Раньше достаточно было фильтрацию текстур сделать хорошую, чтобы сделать революцию. Сейчас для небольшого улучшения качества освещения требуется написание научной работы, разработка сложной системы, которая еще не факт что заработает на железе, которое у людей реально есть.
UFO just landed and posted this here
Причем на минимальных настройках Fortnite на GTX570 (2010) еле шел на ~35 FPS (на лето 2017). Для сравнения, Crysis 2 на средних в свое время (с прекрасной графикой) выдавал 50+ FPS. Куда у Epic Games делась оптимизация — вопрос. За исключением спрайтов(?) травы не вижу куда мог уйти бюджет на полигоны.
Процедурно генерируемый контент мог бы пофиксить задачу. Но тут нужны спецы, которые с детства будут изучать чисто 3д матан, чтобы вообразить объект или текстуру любой сложности несколькими формулами.
Не может. Каждая игра, которая когда-либо бралась за процедурную генерацию, упиралась в одном и тоже — убогость и однообразность этой генерации и явную искусственность. У процедурной генерации есть смысл только в очень узких областях в помощь художникам. Заменить вряд ли получится в ближайшее время, если вообще получится.
ты видимо путаешь с процедурной генерацию мира типо NMS.
Глянь shadertoy что там рисуют с помощью чистого матана.
Глянь shadertoy что там рисуют с помощью чистого матана.
Давай лучше примеры. NMS это далеко не единственный пример попыток процедурной генерации. Все они так или иначе провалились, от чего все это направление по сути мертво. Процедурная генерация требует правильного и умного применения для помощи, а не замены художников. Только тогда это дает результат, который понравится игроку.
мм пожалуй нет.
наоборот, умер целый класс художников с вводом shader graph в UE и Unity, позволяющий нодами генерировать реалистичные текстуры.
наоборот, умер целый класс художников с вводом shader graph в UE и Unity, позволяющий нодами генерировать реалистичные текстуры.
Умер? Текстуры было и есть одно из основных трудозатрат в производстве игр и то, что занимает место на диске. Целые библиотеки качественных снятых фотограмметрией текстур продаются. О чем ты вообще? Да, какие-то текстуры генерируют процедурно. Так было всю жизнь. detail текстуры, нормали, displacement текстуры, height текстуры. Да кучи всего генерировали и продолжают. Это и есть «для помощи, а не замены художников». Художники при этом никуда не делись. Наоборот, нагрузка на них все время только растет. Люди прибегают все к более изощренным техникам снятия множества текстур, которые требуются для современных материалов в играх. Снимают их часто в реальных объектов. Вон, посмотреть что для the order 1886 делали, чтобы достичь такого качества материалов.
И как-то странно получается, начал с упора на процедурную генерацию, а теперь умер целый класс художников. Так что в итоге?
И как-то странно получается, начал с упора на процедурную генерацию, а теперь умер целый класс художников. Так что в итоге?
как раз таки реальность создана из чистой функции и подчиняется функции.
А когда её рисует художник, то получается искусственная пластика.
А когда её рисует художник, то получается искусственная пластика.
(Анти)Топ-игр конечно хорош, но в нем нет настоящего лидера
Если задуматься феномен Crysis для многих (для меня точно) заключается в том что чтобы в него поиграть многим пришлось покупать и апгрейдить старые компьютеры на которых они сидели довольно долго. Если хотите достичь похожего вау-эффекта — просто не обновляйте железо пока ваша видеокарта физически не сможет запустить новую игру даже на самых низких настройках. У меня похожий с кризисом эффект повторился когда я проапгрейдил комп чтоб запустить Battlefield 1. После того как я длительное время был вынужден наблюдать корявую графику на самых низких настройках, баттл 1 после запуска на максималках на новом железе меня действительно впечатлил. Да еще и геймплей отличный
Одно радует- сейчас глаз с трудом видит разницу между «средние» настройки и «ультра». Поэтому, я играю в БФ1 1440р на средних и фпс отличный. Хотя, вру, всё равно подрубаю ультра, но если бы надо было, то на низких без проблем, графон то всё равно отменный!
Несомненно так. Однако вспоминая свои вынужденные апрейды, может случиться так что ты не сможешь физически запустить современную игру из-за отсутствия поддержки необходимых технологий. В моем случае это была видеокарта с устаревшей версией шейдеров в первый раз и отсутствие поддержки direct x10 во второй раз. Если в ближайшем будущем не планируется внедрять новый dirextX без обратной совместимости или обязательная поддержка видеокартой RTX, то на старой сборке еще можно будет посидеть
Sign up to leave a comment.
Гигантомания: почему современные игры так много весят?