>>224732 (OP)
Если тебе интересны готовые решения, зачем пишешь на крестах вместо чтобы взять готовое решение типа юнити-анрылу?

>>224762
лучше использовать свои костыли, чем чужие. так или иначе все равно придется ебаться с кодом, зачем тогда трогать недокод чисто для движка?

>>224732 (OP)
zlib

>>224796
и все твои ресурсы доступны любому Васе.

>>224807
Да и хрен с ним. Любой Вася спиздит ресурсы из чего-нибудь поприличнее, нафига ему твои кривые спрайты?

Зашел в тред чтобы написать >>224796

>>224807
И? Ну, придумай конвертер для ресурсов, контейнеры самодельные, обрезай хедеры и свои ставь. Неужели шифровать хочешь?

>>225189
меня сжатие интересует. без сжатия и так все понятно. вчера посмотрел Lzma и lzma2 в составе 7zip, но там без поллитры или нормальной документации хрен разберешься.

Зачем тебе это? Ложи файлы в открытую. Текстуры и так сжатые, скрипты займут мегабайт 5 в ААА-игре в худшем случае.

>>224807
Запакуй до кучи RSA. Даже если Васян сможет распаковать данные - запаковать их обратно с такой же парой ключей не сможет. Хуй знает, для чего тебе это нужно, лол.

>>224732 (OP)
Всё итак сжато, ты в какому веке живёшь. Чёт проиграл с тебя.

>>225451
Если хранить текстуры в каком-нибудь BMP - то нихуя не сжато.

>>225453
Но зачем?

Если кому интересно, сейчас остановился на варианте с zlib с инвалидским compress2/uncompress.

>>224732 (OP)
Что пишешь?

zlib + шифрование, как и сказали тебе в треде.
RSA не вариант, ибо шифрует/дефшифрует вери медленно, а ресурсы твои все равно спиздят, достав ключ из исходников.
Я бы AES использовал. Но все равно, если захотят - достанут.

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

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

До сих пор 2-4 ядра со средней частотой от 3-4 гигагерц, как 5 лет назад, а 5 лет это огромный срок сегодня. Прогресс уткнулся. Ждём квантовых процессоров.

>>224732 (OP)
zlib уже советовали?

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

>>234129
О да, конечно блядь, и в первом думе тоже для того чтобы ос не охуела и касперский минус первой версии проц не пожег.
Пакуют ресурсы в архивы пидоры ради своей пидорской гнойной выгоды в том, чтобы не попиздили ресурсы, как будто кому-то они в хуй всрались.

>>234541
Он всё правильно написаал, только не ос, а файловая система, и не "чтобы не охуевала", а чтобы быстрее грузилось. Да и сжимают до сих пор тоже, потому что тут как по сети - скачать архив на 800 метров и распаковать - быстрее, чем скачать два гига.

>>234129
Всё верно сказал. Не забываем про гранулярность — проще хранить и читать один большой файл, чем тыщу маленьких, которые места занимают процентов на 10 больше.
>>233141
Ты хочешь данные сразу ключом RSA шифровать? Лол.
Ну т.е., конечно, такая возможность есть, но ведь обычно делают как: шифруют данные сессионным, сессионный шифруют приватным и сохраняют зашифрованный сессионный. Но это если ему только для чтения нужны ресурсы (хотя обычно исходные ресурсы игры не меняются у игрока); впрочем, для кастомных ресурсов можно и не делать защиту — это же не драгоценные ресурсы ОПа.
Так что вот, шифруй у себя закрытым ключом, а расшифровывать будешь открытым. Если очень хочется, можешь и его запрятать.

>>224732 (OP)
Если хочешь йоба-быстрое сжатие можешь попробовать blosc. Есть еще более общая библиотека - HDF5.

>>235001
> Не забываем про гранулярность — проще хранить и читать один большой файл, чем тыщу маленьких,

Кому, чем? Чем эрзац ФС лучше чем фс? Т.е. когда мы в самом файле осуществляем то, чем занимается ФС средствами ФС мы выигрываем в скорости? А если я всю ФС вхуячу в файл, и буду читать через винду, у меня вдвое быстрее винт начнет работать (ну файл же один, читать же легше)? А если я в том файле еще один файл сделаю и буду его подключать в файле как файл так я вообще побью скорость света? Маленькие файлы лучше лезут в кэши, кстати, так что относительно "скорости" это серьезно напоминает гнилой пиздежь.

>>234604
>Он всё правильно написаал, только не ос, а файловая система, и не "чтобы не охуевала", а чтобы быстрее грузилось

Тот же вопрос. Я делаю виртуалку в своей тачке, она будет работать вдвое быстрее? А если в ней еще одну виртуалку, втрое? Или вчетверо? Чем тебе дополнительный слой абстракции добавит "скорости"?

>скачать архив на 800 метров и распаковать - быстрее, чем скачать два гига.

Ойдатычо? Единственное приемущество - качать по сети быстрее за счет того что объем меньше, на этом все преимущества заканчиваются.

>>235630
Почему люди пишут свои менеджеры памяти, если ось уже их имеет? Я не знаю, как тебе доказать, что зимой холодно. Ну, создай три тысячи файлов по 16Кб и один большой в 16*3000Кб в двух разных папках и пооткрывай их в проводнике да сравни. Добавляй количество файлов, пока не почувствуешь разницу (перезагрузиться только не забудь, чтобы они не кэшировались, а то не увидишь разницу и скажешь, что я тебя наебать пытаюсь).
>Я делаю виртуалку в своей тачке, она будет работать вдвое быстрее?
Внезапно, да. Если твоя виртуалка заточена подо что-то одно, и с предположением, что получать она будет только правильные данные, и в процессе пердолинга этих данных ошибки произойти не может, то и в два раза вполне возможно, а то и больше.

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

>Почему люди пишут свои менеджеры памяти, если ось уже их имеет?

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

>Внезапно, да.

Таки заебок же! Я смогу на своей пеке эмулировать весь топ500 суперкомпов! Всего-то нужно достаточное количество вложенности замутить!

>>236787
> примерно одинаково будет
Давай с тобой просто посчитаем абстрактные системные вызовы в вакууме.

10к объединенных в один блоб файлов (без сжатия): open+read+close=3 системных вызова. Плюс немного юзермодного кода на бинарный поиск в простейшем отсортированном оглавлении типа filename,offset,length.

10к файлов в фс: opendir+readdir10001+open10000+read10000+close10000+closedir=40003 системных вызова.

Но незачем фантазировать. Напиши скриптик, который генерит несколько тысяч файлов с рандомным содержимым, размером по 4к каждый. И блоб с этими файлами. Ребутнись (чтобы кэш не влиял), посчитай чексумму для всех мелких файлов, ребутнись, посчитай чексумму блоба, сравни время.

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

>>235630
Ты понимаешь. что ты поехавший уже, всё. Не я, блядь, поехавший, не он, бля, а ты!
Я где-то писал про скорость? Нет! А вот то, что результирующий файл занимает меньше места — это да. Специально для тебя:
пусть размер кластера — 4 Кб, и у нас есть файлы размером 1+0.5…4 Кб;
тогда на диске они будут занимать 4×7=28 Кб, в то время как в едином файле — 17.5 Кб (принимаем размер заголовков пренебрежимо малым по сравнению с размером файлов).
Чуешь разницу? Собственно, >>236287 тебе уже об этом написал.
И да, скорость может быть даже чуть выше (самую малость), потому что система не обращается то к таблице размещения файлов, то к самим данным, а всё хранится в одном месте, рядом.
А по поводу вложенности файлов/виртуалок/пр. для увеличения скорости ты написал откровенную хуиту, в крайности пошёл.

>Единственное приемущество - качать по сети быстрее за счет того что объем меньше, на этом все преимущества заканчиваются
ORLY? Т.е. у тебя производительность сети выше, чем производительности дисковой системы и памяти настолько, что скачивание 2 Гб происходит быстрее, чем скачивание 800 Мб? И это ещё с учётом того, что распаковка этого добра не происходит вся сразу, а только по требованию.

>>236787
Специалист уровня /gd/, сразу видно.

>>236973
> Плюс немного юзермодного кода на бинарный поиск в простейшем отсортированном оглавлении типа filename,offset,length.
Дебил с дивана

>>237142
Ну раз ты у нас не дебил, и не с дивана, то, наверное, знаешь, что происходит после CreateFile в Windows. Расскажи нам, а мы послушаем. Можешь и про Linux рассказать, если тебе проще. Или даже про OSX, например. А можешь и не рассказывать, а просто подумать, будет ли это все быстрее частной реализации, заточенной под поиск в своем собственном контейнере.

>>236973
>Но незачем фантазировать. Напиши скриптик, который генерит несколько тысяч файлов с рандомным содержимым, размером по 4к каждый. И блоб с этими файлами. Ребутнись (чтобы кэш не влиял), посчитай чексумму для всех мелких файлов, ребутнись, посчитай чексумму блоба, сравни время.

Просто фонтан долбоебизма. Ребенок, зачем мне читать ВСЕ мелкие файлы СРАЗУ (inb4 - ко-ко-ко все сразу в оперативку вхуячить штоп ище быстрее было!!11)? Хотя, у вас тут и виртуалка работает быстрее чем хостовая машина, и архивированный файл читается быстрее чем обычный. И юзерспейс-код системные драйвера обгоняет. Прям люблю разел, одна история охуительней другой просто.

>>238101
> зачем мне читать ВСЕ мелкие файлы СРАЗУ
Не все, но посчитай, сколько у тебя всего в сцене задействовано. Алсо, да, при запуске неплохо бы пройтись по всем ассетам, чтобы обновить устаревшие, например.

> юзерспейс-код системные драйвера обгоняет
Переключение контекста - само по себе дорогостоящая операция. Кроме того, "системные драйвера" - это несколько слоев кода, которому нужно сделать очень много разных вещей. Это полезные вещи, поэтому да, частная реализация, которая минимизирует их количество, будет быстрее. Вот если ты полноценную ФС в контейнере захочешь реализовать (с записью, правами доступа и прочими транзакциями), тогда код ОС может тебя обогнать, потому что на него положено больше знаний и усилий.

лол, а я всего лишь про сжатие ресурсов спрашивал.

ОП

>>235251
два чая тебе, анон. блоск очень даже ничего с виду, читаю про hdf. надо будет потестить все это дело.

ОП

>>238101
>зачем мне читать ВСЕ мелкие файлы СРАЗУ
А поиск имени файла в таблице не зависит, наверное, от количества файлов в директории? Не говоря уже о том, что при старте игры она именно это и делает.
>виртуалка работает быстрее чем хостовая машина
Ты же дурачок. Виртуалка (а виртуальная машина - это не вмваря (точнее, не только она), добро пожаловать в реальный мир), заточенная под одно конкретное действие будет делать это действие быстрее, чем что-то общего назначения, под это дело не заточенное.
>Прям люблю разел
Это хорошо. Заходи почаще, ума-разума, может, наберёшься.

>>236787
> выигрышь
> марионеткаь

>>238243
Нахуя искать файлы? Ты ебанутый? Алсо, для поиска по имени совсем не обязательно их полностью читать.

>>238302
>Нахуя искать файлы?
Даже не знаю. Когда ты хочешь подрочить на картинку с ниграми, файловая система, наверное, из астрала получает адрес этой картинки на диске.

>>238302
У него вм, выполняемая в ОС быстрее чем нейтив код для ОС. Что взять с решеткодебила?

>>238243
>А поиск имени файла в таблице не зависит, наверное, от количества файлов в директории?

Ты удивишься, но нет. Можешь почитать учебники информатики откроешь для себя множество удивительных вещей. Хотя, не, не откроешь. Ты же дебил который думаешь, что explorer.exe это единственное что может получать список файлов в директории.

>>224732 (OP)
>на крестах
>>238538
>с решеткодебила
Кажется, кто-то только что публично обосрался!

>>238542
Тут ты немного не прав. Разумеется, если у него 100500 файлов, а он ищет 100499-й, то поиск будет выполнять… ммм, несколько дольше, чем если бы он искал 15-й файл, например.
Алсо, надеюсь, ОП всё-таки не перечитывает каждый раз содержимое архива с диска, а хранит какое-то подобие FAT (хотя бы банальный список файлов со смещениями и размерами) в памяти для ускорения доступа.

>>239436
>если у него 100500 файлов, а он ищет 100499-й, то поиск будет выполнять… ммм, несколько дольше, чем если бы он искал 15-й файл, например.
Дольше будет только если он догадается циклом по ним всем пойти. Он же не такой даун? Если имена файлов хранятся деревом, то поиск любого файла будет примерно одинаков по времени. Вот, например: https://en.wikipedia.org/wiki/Radix_tree

>>239548
Ну, я рассматривал предельный случай, если он таки немного даун. А если такое дерево или подобное, то ещё быстрее, конечно.

Казалось бы, возьмите описание конкретной файловой системы и посмотрите, как там что хранится и сколько чего там занимет. Нет, будут гадать.

>>239582
Так дело-то не в конкретной файловой системе. Дело в вопросах, поднятых в треде. И ответы такие:
1) Паковать все в большой блоб для ускорения загрузки имеет смысл.
2) Сжимать блоб не имеет смысла. Если очень хочется, пусть инсталлер игры жмёт.
3) Шифровать не имеет смысла. Можно обфусцировать каким-нибудь однобайтовым xor для самоуспокоения, но если кому-то захочется достать ресурсы, то его одинаково не остановят ни xor, ни RSA.

>>239582
Конкретная ФС — это чересчур, потому что весь богатый набор фич (даже такой небольшой, как у FAT32) здесь не нужен. Возможно, ОПу придётся потрахаться с дефрагментацией, но если ему не надо рантайм-обновление или он реализует его попроще, пусть и более накладно, то ФС-подобное творение ему ни к чему. Здесь надо действовать по принципу KISS.

>>239629
Почему не имеет смысла? Если ресурсы довольно сжимаемы, то можно применить какое-то лайтовое сжатие, чтобы и производительность не проседала, но и места было чуть побольше. Тот же вопрос интересует про шифрование.

>>239629
Вообще я не понимаю, какие тут могут быть сравнения. При считывании из блоба ты ставишь файловый пойнтер в нужную позицию и читаешь данные. При считывании из файла тебе нужно открывать файл каждый раз. А открытие файла это поиск его в файловой системе, проверка прав доступа (про это забыли?), создание объекта операционной системы. На большом количестве файлов это может дать заметный проигрышь по времени.

Плюс, инсталляция будет намного дольше.

Странно, что никто еще не написал. Опчик, раз ты пишешь на крестах, вот твое спасение https://msdn.microsoft.com/en-us/library/windows/desktop/aa380369(v=vs.85).aspx
Зависимости никакой, брат жив. Решает все твои проблемы!
__МИНУСЫ:__ (кроме описанных в доках)
эта штука только для ШINDOШS, поэтому если ты планируешь делать свою йобу мультиплатформенной, то тут ты соснешь хуйца
фрагментация. Решается пересохранением через IRootStorage
короткие почти как член опа имена файлов. Решается тем, что ты делаешь окейфейс и используешь имена файлов длиной не более 32 символов
__ПЛЮСЫ:__
эта няша поддерживается во всех виндах, даже в тех, которые теперь не поддерживаются и на которых твоя игра просто не взлетит!
короткие имена файлов компенсируются их юникодностью, т.е. ты можешь хранить имена файлов на японском, тамильском, санскрите и О БОГИ!!! русском! (правда, придется и йобу делать юникодной, либо изменять кодировку при надобности)
этот механизм готов к употреблению, но ты можешь как допилить его под себя, так и переписать полностью!
ультрафаст чтение и сохранение, ведь система позаботится о фрагментации за тебя!
Не знаю что еще добавить, но плюсы явно перевешивают. А туда ты сможешь уже сам навесить шифрование/сжатие/прочий иной рарджпег.

/THREAD

>>239942
Это говно. Даже те, кто раньше использовал его для хранения документов, давно уже с него перекатились (в основном на .xml+.zip, которые для игр ниочень подходят). Оно очень уязвимо к некорректному закрытию потоков (программа вывалилась, и в следующий раз файл может не открыться). Оно заточено под read/write, а в играх обычно хватает readonly. Есть несколько версий структуры, и если захочешь парсить вручную (в Linux) - охуеешь я парсил. Фрагментация никуда не делась, она только больше за счет того, что файл будет фрагментирован и на уровне фс, и на уровне внутренней структуры. Юникод в именах поддерживают все современные ОС, ты опоздал.

>>239954
Ну опу еще и сохранение надо, как я понял, он же редактор хочет для всего этого запилить. Проблем с этим у меня не было ни разу, а Linux ему не нужен вроде как. Один хер он фрагментированный файл только в редакторе будет использовать, а для йобы своей экспортнет его без фрагментации.

Ах да, там можно же без проблем запилить ФС с папками, а не хранить все файлы в корне. Не придется заморачиваться со своей реализацией папочной структуры.

>>239957
> ФС c папками
Для игры папки не нужны (достаточно искать ассеты по полному пути и в контейнере в имени ресурса полный путь хранить), а для редактора дерево "папок" можно и динамически при загрузке строить, а хранить все те же "плоские" пути.

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

>>239436
ашто, и так можно?

ОП

>>239629
сжимать блоб имеет таки смысл, мне кажется, если распаковка не очень затратна. игрулины, весящие гигов по 40 могли бы занимать меньше, пусть хотя бы на 2 гига. жалко место жи.

>>232928
rts. и да, я ебанутый.

ОП

>>240066
По всякому можно так то. Глянь, сколько тебе тут вариантов написали, выбирай не хочу!

>>240083
Это был сарказм. Без описанной выше таблицы хранить данные - очень плохая идея.

ОП

>>240089
ну и ок
Анон нынче очень добрый: смотри, сколько предлагает. Грех не воспользоваться и удачи с твоей йобой

>>224732 (OP)
лол, сколько вас там таких?

>>240112
каких таких?

ОП

>>240166
йобапесателей в твоей команде

>>240037
> поиск в дереве выполняется быстрее
Похэшировать (хранить и имя, и хэш, а лучше вообще посчитать perfect hash), ебануть bsearch, и будет достаточно быстро.
> полный путь в имени ресурса будет много места занимать
Как я уже говорил выше, в эпоху терабайтных винтов говорить "много места" про строки несколько некорректно.

>>224732 (OP)
WINRAR ебанарот, кто-то о нем не знает? Я в ахуе.

>>240383
Мда, аудитория тут та еще.

>>240392
Аудитория как и на всём дваче