¿Cuál es el estado del arte en el envío de gráficos de juegos, como muchos archivos BMP pequeños? [cerrado]

Tenemos muchos archivos BMP pequeños que creo que serían más fáciles de copiar si los combinamos en un gran TAR / ZIP / lo que sea.

¿Cuál es el estado del arte en el envío de gráficos de juegos?

Estamos usando C # y conocemos zlib. Simplemente haga una lluvia de ideas para ver si hay otras soluciones mejores que zlib.

También puede buscar en SharpZipLib o DotNetZip : DotNetZip le da acceso a un archivo Streamdirectamente, lo cual es útil ya que la mayoría de las bibliotecas de C # pueden cargarse desde secuencias (en lugar de archivos). Además, DotNetZip utiliza el Ms-PL (BSD-Like), en lugar de la GPL con una excepción legalmente cuestionable.

Otra opción es usar atlas de texturas ; en lugar de tener muchas imágenes pequeñas, tenga algunas grandes. En realidad, estos se cargan un poco más rápido y son un poco más rápidos en tiempo de ejecución si eres inteligente con la forma en que los dibujas.

Finalmente, podría ejecutar cada tipo de activo a través del compresor sin pérdida relevante (PNG, FLAC, etc.) y almacenarlos en un archivo plano (básicamente un archivo zip con compresión deshabilitada). Recuerde evitar comprimir datos comprimidos, ya que eso aumentará el tamaño en la mayoría de los casos.

Alguna técnica anterior:

• MPQ : Probablemente tan bueno como sea posible para los activos del juego, las búsquedas están diseñadas para ser rápidas (tabla hash basada en disco, etc.). Cada tipo de archivo (que es compatible) tiene un compresor único.
• Quake PAK : Esta es básicamente una estructura de archivo plano.
• Doom WAD : algo específico para Doom, pero vale la pena analizarlo.

Una opción es almacenar imágenes en el mismo formato de compresión que utiliza para crear texturas comprimidas. Esto tiene la ventaja de que no va a convertir de un formato con pérdida a otro, pero almacena los datos en un formato con pérdida. Dependiendo de las texturas, puede haber algo que ganar almacenando dichos archivos en un archivo comprimido.

Vea esta respuesta para obtener un poco más de información sobre texturas comprimidas: https://gamedev.stackexchange.com/a/5177/3505

ZLIB podría ser una buena respuesta, pero si sabe que la gente está abriendo sus activos, también puede crear su propio formato de archivo para almacenar sus activos, aunque no es tan difícil.

Aquí 's cómo puede hacerlo.

Está en C, pero no debería ser tan difícil de aprender, ya que C # es algo así como C y C ++.

Por supuesto, las personas que todavía tienen un mayor conocimiento pueden capturar sus recursos, puede agregar poca encriptación si lo desea, no demasiado.

Esto puede ser muy útil, pero solo unirá sus archivos. Para la compresión también, tienes dos opciones.

1. Cree su archivo de recursos completo, comprímalo y envíelo.
   Este método es fácil, pero no muy bueno, debe descomprimir todo si desea tomar solo un recurso.

2. Comprima todos los recursos y agréguelos al archivo de recursos.
   Eso también es bastante bueno, tendrá un ligero aumento en el tamaño junto al método 1, porque cada archivo se comprime por separado, pero es mejor si desea flexibilidad.

Cada método tiene sus propios inconvenientes, debe elegir sabiamente. En general, si tu juego tiene una cantidad bastante baja de recursos, el método 1 debería ser mejor. Si tienes MUCHOS, el método 2 debería ser adecuado para ti, porque el tamaño de todos los recursos juntos abrumará el extra que ganes.

Para libs de compresión, tienes:

• El medio más famoso, Zlib.
• El que tiene la descompresión más rápida, LZO
• La excelente relación de compresión, 7-Zip

Iría con LZO si quiero acceso rápido en el juego, por lo que no debes temer descomprimir en tiempo real, 7-Zip si quiero que los archivos se reduzcan MUCHO o Zlib si quiero una relación de descompresión equilibrada y tamaño.
La elección es tuya: D

Ah, por supuesto, hay otros algoritmos para comprimir datos, y puedes encontrarlos en Google .