Який стан сучасної доставки графічних ігор, таких як невеликі файли BMP? [зачинено]


9

У нас є маса невеликих BMP-файлів, які, на мою думку, було б простіше скопіювати, якби ми об'єднали їх у великий TAR / ZIP / що завгодно.

Який сучасний стан доставки ігрової графіки?

Ми використовуємо C # і знаємо про zlib. Просто мозковий штурм, щоб побачити, чи є якісь інші рішення кращі, ніж zlib.

Відповіді:


7

Ви також можете заглянути в SharpZipLib або DotNetZip - DotNetZip надає вам доступ Streamбезпосередньо, що корисно, оскільки більшість C # бібліотек там можуть завантажуватись із потоків (на відміну від файлів). Крім того, DotNetZip використовує Ms-PL (BSD-Like) замість GPL за юридично сумнівним винятком.

Іншим варіантом є використання текстурних атласів - замість того, щоб мати багато маленьких зображень, мати кілька великих. Вони насправді завантажуються трохи швидше і трохи швидше під час виконання, якщо ви розумні, як їх малювати.

Нарешті, ви можете запустити кожен тип активів через відповідний компресор без втрат (PNG, FLAC тощо) та зберігати їх у плоскому файлі (в основному, zip-файл із відключеною компресією). Пам'ятайте, щоб уникнути стиснення стислих даних, оскільки це збільшить розмір у більшості випадків.

Деякі рівні техніки:

  • MPQ : Мабуть, настільки ж хороший, як і для ігрових активів, пошуки розроблені таким чином, щоб вони були швидкими (дискова хеш-таблиця тощо). Кожен тип файлу (який підтримується) має унікальний компресор.
  • Quake PAK : Це в основному плоска структура файлів.
  • Doom WAD : Дещо специфічний для Doom, але варто переглянути.

1

Варіант - зберігати зображення у тому ж форматі стиснення, який ви використовуєте для створення стислих текстур. Це має перевагу в тому, що ви не збираєтесь перетворювати один формат втрати в інший, але ви зберігаєте дані у форматі втрат. Залежно від текстур, все-таки можна щось отримати, зберігаючи такі файли в стислому архіві.

Дивіться цю відповідь для отримання додаткової інформації про стислі текстури: https://gamedev.stackexchange.com/a/5177/3505


0

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

Ось як ви можете це зробити.

Це в C, але не повинно бути таким важким для вивчення, оскільки C # є деяким, як C і C ++.

Звичайно, люди, які все ще володіють вищими знаннями, можуть зловити ваші ресурси, ви можете додати трохи шифрування, якщо хочете, не надто важко.

Це може бути дуже корисно, але воно просто приєднається до ваших файлів. Для стиснення також є два варіанти.

  1. Створіть весь файл ресурсів, стисніть його та відправляйте.
    Цей метод простий, але не дуже хороший, вам слід видалити все, якщо ви хочете взяти лише один ресурс.

  2. Стисніть кожен ресурс і додайте їх до стисненого файлу.
    Це теж непогано, поряд із методом 1 ви маєте невелике збільшення розміру, оскільки кожен файл стискається окремо, але краще, якщо ви хочете гнучкість.

У кожного методу є свої недоліки, слід вибирати з розумом. Як правило, якщо у вашій грі досить низька кількість ресурсів, метод 1 повинен бути кращим, якщо у вас ЛОТИ, метод 2 повинен вам підходити, тому що розмір усіх ресурсів разом переповнить зайву суму, яку ви отримаєте.

Для компресійних ліфтів у вас є:

  • Найвідоміший засіб, Зліб
  • Той, що прискорює декомпресію, LZO
  • Великий коефіцієнт стиснення, 7-Zip

Я б пішов з LZO, якщо я хочу швидкий доступ до ingame, тому ви не повинні боятися розпакування в режимі реального часу, 7-Zip, якщо я хочу, щоб файли були скороченими LOT або самим Zlib, якщо я хочу збалансоване коефіцієнт декомпресії та розмір.
Вибір за вами: D

Ну, звичайно, є й інші алгоритми стиснення даних, і ви можете знайти ці гуглі .

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.