Не отвечает.

А я скажу. Скажу, что по несколько реплик и даже линий разговоров персонажей в одном архиве лежат (мне знакомые показывали) - это говорит о том, что есть адресация в теле архива до разных файлов, значит можно всю игру в один архив отчасти положить и оттуда разные файлы включать, теоретически. Говорят, разные команды разные обновы даже лепили после ухода bloodlust из проекта, может надо выписать отдельную БНС разработчиков команду на постоянной основе и тогда половина проблем решится?

 

можно. но корейцам об этом не сказали. вообще, тогда ты каждый раз перекачивал бы 20гб патчи. сам архив они вряд-ли разрешат патчить локализатору, тем более на клиентской стороне. да и просто, модульность. не говоря о том, что архив по сути придётся каждый раз пересобирать. анрил же. судя по релизу это даже не udk 3.

10 янв 2019

это правда, даже каждый крупный патч, разные люди. заметно по уровню проработки самих локаций, и данжев с рейдами. при том, они механики делают вроде, а никто почти через них не играет на корее. ожидаешь что-то скилловое уровня старкрафта с миллионами кликов в секунду. а на деле, катающийся лицом по клаве или на макросе плюшкин.

если только это сделает одна команда, и полный реворк игры. но каждый последующий патч будет снова добавлять некоторые архивы, по причине которую я уже назвал. его собрать обратно не очень реально в том виде в котором было. это не рар в который ты можешь докидывать файлы. вообще, конкретно с анрильскими файлами и иерархией не дружу сильно, и всё на опыте пары модов

 

А теперь представь как на ПК с не большим объемом ОЗУ подобный архив весом 32ГБ+ будет обрабатываться? Быстрее обработать, найти и извлечь что нужно из нескольких небольших архивов, чем копаться в одном большом.

 

Спойлер: а теперь посмотрим какие архивы у БНС

Вы же понимаете, что я не собираюсь класть всю игру в один архив. Постоянно распаковывать тысячи разных архивов наверняка сложнее, чем держать в памяти 30-40 открытых архивов.

 

А теперь представь как клиент начнет фризить от того что ему надо распаковать в память из архива весом допустим примерно 1 ГБ файл объемом 500 KB который был до этого в архиве объемом 1 МБ. А если учесть что архивы закодированы, то перед доступом к файлу в нем его (архив) надо раскодировать (архив не просто открывается как обычный rar или zip, он обрабатывается полностью и каждый раз при доступе к нему). По сути то на то и выходит, движок игры в памяти держит не архивы игры, а данные полученные из них, поэтому как бы по барабану из скольки архивов они были взяты, единственное на архивы большего объема требуется больше времени на работу с ними. Для примера возьми функцию y=(x/2), где x - это объем файлов, а y - это время затрачиваемое на работу с ним. Эта же формула применима и в случае если x - это количество архивов, а y - это затрачиваемое время на работу с ними, в любом случае график будет линейным.
Возьми инсталлятор какой либо программы который предоставляется одним файлом, допустим 1 ГБ (тот же ломаный фотошоп с торрента) и инсталлятор той же программы взятый с оф источника (как правило он будет построен на InstallShield) который состоит из исполнительного файла и архивов. Уверен пр запуске первого до момента появления окна установки пройдет примерно десяток секунд, если не больше. Во втором же случает пройдет не более 5 сек. При этом инсталлятор производит линейные действия, в нем заложены последовательные задачи по одноразовой распаковке архивов, операции по доступу к реестру опустим. В игре же доступ к каждому из архивов может осуществляться сколько угодно раз, а следовательно из за большего объема самих архивов время затраченное на их обработку будет не сопоставимо с получаемой на выходе производительностью. Время загрузки локаций может сровняться со временем запуска самой игры, если и вовсе не превысит ее нынешнюю.
Про обновления говорить не буду, уже сказали. Так себе перспектива перекачивать половину клиента перед и после начала какого либо ивента.

 

вот кстати и фризы на швах (секторах). Текстуры бывает и меньше занимают.

 

А теперь перестань фантазировать и положи всю локацию в один архив, чтобы он лежал в памяти полностью и не заставляй компьютер делать лишнюю работу. БНС итак кушает несколько гигабайт памяти постоянно, шевеля там своими микроархивами. Объясни, почему нельзя положить файлы в один архив так, чтобы хватило его одноразовой загрузки в оперативку без последующей распаковки.

В общем, ты хочешь сказать, что лучше, чем уже есть, сделать невозможно?

 

и да, и нет. дело только в движке и аохиваторе.

потому что тебе понадобится рамдиск уже ) ещё можешь попробовать подкачку отключить чтоб понять что та оперативка которую жрёт бнс ещё только вершина айсберга и в реальности её раздувает и до 3+ в 32 битной архитектуре и куда больше 8 в 64. как минимум чаще будут нужны операции с кешем, и загрузкой-выгрузкой.

 

Фантазируешь тут только ты, пытаясь создать утопию не прилагая к этому никаких усилий, а только вещая как было бы хорошо если бы так было. Как NCшки сделают так и будет и ни мое, ни твое мнение тут не то что не к месту его по сути вообще нет, для корейцев, им пофиг как удобнее так и сделают. Сейчас они послушали и сделали как ты просишь. Короче это все лирика.

11 янв 2019

А все по тому что все это полуторопоточный пережиток прошлого. Если бы архиватор мог в полноценный многопоток было бы куда лучше, однако может он и может, тогда в таком случае все упирается в движок.

 

самое смешное, даже на не особо поточных интулях это боль

 

Я уже как то писал что движок ue3 писался еще в времена пня 4-го, без ht когда двух ядерные атлоны еще не вышли, это потом уже после выхода х2 атлона интуль сделали ht на пне 4-м, ну да ладно. Изначально движок заточен под однопоток, но по мере развития цп разработчики не переделывали его, а просто внедряли костыли которые давали возможность работать с 4 ядрами процессора (если не хватает попугаев на ядро), но костыли они и в африке костыли и хоть движок и задействует 4 ядра, правда полезная загрузка их сомнительна, некоторое время назад спецом снижал частоту на райзене для получения меньшей производительности на ядро (с 3700 в бусте до 1600 МГц, это минимальный множитель) и больше 4 ядер задействовано так же не было что прискорбно.

 

Это знаю, правда одно дело какой-то тредриппер. А другое дело та же почти архитектура что в пнях прескотах, с некоторыми изменениями и этим ht, казалось бы должно быть лучше, но корейцы снова всех переиграли. Кстати, я не помню работает ли комплект udk с этим ht, и было бы лучше временно портировать игру туда) мне кажется проще уже действительно режим ждуна включить и надеяться что игра доживёт до ue4. Кстати, я игрался с контроллером, шиной и ht, и в отличии от разных ждалкеров не глядя на костыли, лучше ht не отключать) я узрел натуральное слайд-шоу.

 

Слишком нагло себя едешь. Смени тон и объясни нормально, что с большими архивами не так, когда там лежат все файлы.

12 янв 2019

А лучше кинь ссылку на статьи по теме, где ты нашел взял такие сказки про распаковщики.

 

Если смотреть от простого, они имеют разметку и прежде чем его открыть надо разметку считать. Далее есть некоторая компрессия, и в оперативке это будет немного больше чем в архиве даже, но на копейки. И без того не самые быстрые загрузки станут заметно дольше. За примером далеко не ходи, взгляни на кривособранный quake champions где архивы длинные, а загрузки прилично долгие. Не говоря о подгрузках которые вызовут уже заметно большие фризы и боль в мягких тканях седалища .+ Построение локаций во многих мморпг по секторам происходит.

12 янв 2019

Если бы сказки) в лс скину.

 

Конечно же, архивы не только закрывают всю ненужную игрокам информацию, но и, кроме прочего, сжимают что могут, для экономии места на диске. но. Локации в тут не такие большие, чтобы архив одной карты занимал много места, если учесть, что фактически данных не так много, те же повторяющиеся текстуры в игре зачастую берутся из одной картинки, воспроизводясь повторно много раз. Так же и с анимацией и звуками.
Можно поинтересоваться, где Вы про работу с архивами UPK прочитали? Впервые вижу, чтобы всерьез утверждалось о таких преимуществах маленьких игровых архивов перед большими.

 

одновременно соглашусь, и не соглашусь. просто помимо обычных текстур есть различные звуки привязанные к окружению, или сами по себе модели. не говоря уже об информации, так на пример надо посчитать коэф дропа с моба и собственно отрисовать туда иконки. надо считать его последовательность ударов. ну и за всё это отвечают разные архивы игровые. потому просто поместить в один не очень можно.

 

От чего же мой тон ты считаешь наглым, от того что описанное мной совершенная правда?
Упаковать все в один архив это только где то 30% всей работы по так называемой твоей оптимизации клиента, помимо этого надо полностью перерабатывать инструкции работы с файлами к которым обращается декомпилятор для получения данных из архива, т.е. их расположение изменится, а файлов в архивах ой как не мало (одних архивов только 37k+).
Допустим для распаковки архива с текстурой брони npc объемом 10 МБ занимает 300 мс, если поместить указанную текстуру в один общий архив с текстурами npc то допустим его объем будет 500 МБ, время доступа за одной единственной указанной ранее текстурой уже будет в 50 раз больше и составит 15 секунд. по твоему подобный пример не стоит внимания? Ок, теперь возьми текстуры из какого либо данжа которые запакованы в архив объемом допустим 1.5 ГБ, время обработки такого архива так как это пример возьмем из описанного выше и составит 45 сек, при этом если в данже есть нпс, монстры, а так же игроки из пати чьи текстуры хранятся в других архивах, это приведет в текущем случае к большому времени ожидания загрузки локации из за доступа к другим архивам, в указанном примера оно может составить где то около 2 минут. Ок 2 минуты, так 2 минуты, зато архивов меньше.

 

прежде, чем хаять архивы, вы, ребят, упускаете из виду один "замечательный" хмл-файлик. если бы корейцы действительно хотели уменьшить проблемы с игрой, для достижения достаточно большого эффекта достаточно было бы оптимизировать его. там огромное количество мусора. тупиковые ссылки, дублирующиеся ссылки (причём иногда указывающие на разные предметы), неактуальные ссылки и т.д. если в первую очередь починить эту мешанину, а затем вычистить упкшки на предмет неиспользуемого, то нагрузка на железо неплохо снизится, сам клиент станет легче, плюс поведение клиента станет в разы стабильнее. но, опять же, это нафиг никому не нужно, ибо требует неопределённое количество жопочасов у текущей команды, дабы разобраться в каше, оставленной предыдущими командами, и ещё более неопределённое количество этих самых жопочасов для редактирования.

 

Я упомянул про инструкции со ссылками, которые надо перерабатывать вместе с архивами, это и есть те xml-ки на которые отводится больше половины всей работы по переработке клиента =)

 

ну, я думал, что твой пост был про кривоальфобилд анрилэнджина в целом, а не конкретно про то, что корейцы с бд там наворотили...