El mercado indie o shareware crece en los foros con lo que estaría bien saber que ancho de banda disponemos y así hacer un pequeño estudio sobre cuanto deben de ocupar los juegos u otro tipo de aplicaciones, este estudio esta claro que puede que no refleje el ancho de banda de un usuario normal ya que nosotros podemos tener algo mas al ser programadores y estar todo el día actualizando nuestras webs :lol:.
PD: No se si es este el sitio correcto para ponerlo.
PD2: La medición es kilobytes por segundo
El tema de "tamaño óptimo" es algo extraño. Hace un par de años se creía que más de 5 MB no podía pesar un juego casual. Luego fueron 10, ahora ya hay juegos de 20... Y luego te encuentras con un juego de más de cien megas que está en el top 10 de RealArcade durante varias semanas.
En cuanto a los juegos indie sin más (no casuales), los hay de todos los tamaños.
Mi opinión sobre el tema es que optimices lo que puedas (compresión LZMA en el instalador y recursos sin comprimir, tilear cuando sea posible, etc.) pero que si un juego lo vale la gente bajará lo que haga falta. Sin embargo, ten en cuenta que cuanto más ocupe, al menos la demo, más costes tendrás de ancho de banda.
Mas de uno se va a equivocar... porque has puesto las medidas en kilobytes en lugar de kilobits que es lo que te ofrecen en el mercado???
La gente va a tener que sacar la calculadora y dividir sus kilobits por 8 para sacar los kilobytes...
Yo te digo más o menos lo mismo que Colsón. Para un juego indie que además sea también "casual", yo procuraría limitarlo a 10-14MB, 10 mejor que 14 si es posible :P
Los recursos déjalos sin comprimir a menos que tengas la oportunidad de usar compresión con pérdida: los recursos gráficos que sean susceptibles de compresión JPEG (ajustando el grado de calidad a mano), los de audio que puedan ir como .ogg, etc...
La compresión SIN pérdida la delegas al instalador (LZMA). Tu juego ocupará más en disco, pero menos en la descarga.
Los usuarios más "hardcore" (no casuales) descargan lo que haga falta.
1-Es un tema interesante
2-Nadie ha contestado la pregunta, ni siquiera tú :P
3-Esa estadística no tiene mucho sentido porque somos pocos, somos gente especial, y, sobre todo, no somos gente de USA, UK o Alemania que son el mercado fundamental del share, por lo que nuestro ancho de banda no tiene mayor importancia.
4-Estoy de acuerdo con Colson (él siempre sabe lo que se dice B) ). Cuanto menos ocupe el juego, mejor, pero si lo vale y coge fama, la gente descargará lo que sea, aunque ten en cuenta que tú gastarás más en ancho de banda.
Edit: uy, retiro el punto 2, no me dí cuenta de que era una encuesta :rolleyes:
No entiendo por que no comprimir los recursos :huh:
En referente a lo que ha dicho Colson yo también estoy de acuerdo, es lógico que mientras menos ocupe mas rápido se descarga, pero a veces tal vez es necesario sacrificar el tamaño por unos buenos gráficos o sonido, el problema es saber cual es el limite de ese sacrificio.
Sobre el punto 3 de tewe76 esta claro que somos especiales y por eso lo digo en mi primer post.
Si se comprimieran los recursos en formato zip por ejemplo y luego comprimes el juego en formato zip para su descarga lo mas seguro es que aumentara de tamaño ya que el segundo zip no comprimiría nada. (Me imagino que se refieren a esto)
este tipo de problemas yo no los tengo XD. Creo que voy a empezar una serie de juegos en 8kb XD Unos cuantos jueguecillos en 32kb...
http://www.pouet.net/top10.php?type=32k&pl...atform&x=38&y=1
No soy ningún experto en la materia, así que no me pidáis explicaciones, pero es un hecho que un juego con los gráficos en TGA sin comprimir (para gráficos con alpha) y BMP/GIF para sin alpha, al pasarlo por un instalador que comprima bien (inno setup, por ejemplo) resulta en un setup de tamaño menor que si haces lo mismo con gráficos con compresión (PNG, TGA comprimido...). Como dice senior wapo, "Tu juego ocupará más en disco, pero menos en la descarga."
No creo que le saques menos de un 10% con esto y le agregas unos 30 megas en disco duro al usuario, ademas de que la carga de tu juego será mas lenta ... no estoy para nada seguro de esto, habria que hacer el experimento.
Saludos.
No creo que esto último tenga mucho sentido porque estás dando por hecho que formatos de compresión de propósito general lo hacen mejor que formatos específicos para imágenes como png. Entonces mejor usamos la compresión de inno setup para las imágenes y nos olvidamos de formatos comprimidos.
Podría ser que el compresor generalista lo hiciera mejor debido a que tiene todo el contenido para hacer sus tablas (o lo que sea) y dado que suele haber imágenes muy similares pues puede que comprima más, pero de otra forma no tiene sentido.
El instalador usa un algoritmo de compresion (LZMA) más eficiente que deflate (el usado por los .zip, .png), LZW (.gif), LZSS o RLEs (BMP). Hablamos de compresión SIN pérdida.
Los algoritmos de compresión con pérdida sacrifican fidelidad de los datos a cambio de una mayor reducción, con lo que la compresión del instalador (LZMA) no puede superarla.
Se trata simplemente de elegir el mejor algoritmo de compresión para cada tipo de información, y resulta, que casualmente, a dia de hoy, Inno Setup y NSIS implementan algoritmos de compresión más eficaces que los que incluyen los formatos gráficos SIN pérdida más conocidos.
A menos que vosotros implementéis un formato más eficaz aún, dejad que el LZMA comprima todo.
En el caso de imágenes y sonido, podeis usar formatos con pérdida como JPG u OGG, o al menos su algoritmo de compresión, aunque las cabeceras las eliminéis.
Una imagen PNG con alpha se puede dividir en 2 imagenes: una con las componentes RGB y comprimirla mediante la libreria libjpeg, y una imagen 8bits de la componente alpha que podeis guardar sin comprimir (y que la comprima el instalador sin pérdida, que los bordes quedarían feos con pérdida).
Un archivo de sonido es mejor guardarlo como MP3/OGG que como wav porque el instalador jamás reducirá un wav a menor tamaño que un OGG equivalente.
... A mi juego lo bajo de 10mb a 7mb en la compresion de recursos, incluso cuando la mayoria son PNGs ;) y luego a 5mb en la compresion del instalador ... tendria que descomprimir los png y pasarlos a tga para luego guardarlos en el instalador de recursos sin comprimir para probar con la compresion del instalador solamente, a ver que resultados tengo, pero es demasiado trabajo para una cosa que en este momento no me traeria beneficios.
Vuelvo a repetir, la compresion de recursos tiene su principal ventaja en la velocidad de carga del juego!, si fuese mas rentable una unica compresion para el ensamblado del instalador entonces lo que se me ocurre seria mas eficiente seria crear el instalador con los recursos sin comprimir y una vez instalado comprimir los recursos.
Este metodo se llama "Metodo de optimización de instalador de Pogacha" todos los derechos reservados.
Saludos.
He hecho estas pruebas con el innosetup usando su wizard para evitar posibles fallos ya que no conozco este programa:
He cogido una imagen del quake3 de 128x128, la he aumentado a 256x256, su nombre es "proto_grueldark2", la he guardado en dos formatos, bmp (192 KB (196.662 bytes)) y jpeg (20,2 KB (20.786 bytes)), las dos guardadas con photoshop, el jpeg a calidad 100%.
Resultados:
- Tamaño del setup con BMP 359 KB (368.252 bytes)
- Tamaño del setup con JPEG 299 KB (307.034 bytes)
Podeis descargaros desde
aquí los instaladores y las imagenes que use.
PD: Pasarle el antivirus por si acaso, nunca se sabe.
Pero hombre, no compares peras con melones :D
Estas comparando la compresión LZMA sin pérdida con la compresión JPEG con pérdida. Siempre ganará JPEG (salvo casos muy especiales).
Compara TIFF comprimido, PNG, GIF, o similares, no JPEG.
Los ficheros que contengan datos comprimidos dile al instalador que no los comprima. Un archivo sin redundancia al intentar comprimirlo crece notablemente. Lo suyo es que el compresor lo detecte y lo copie sin comprimir, pero nunca se sabe.
PD: Nota pedante: 100% en JPEG no preserva la imagen, siempre hay pérdida debido a la fase de cuantización. Nunca metas un % mayor a 95% porque al aumentar el % en el rango 95%-100% la imagen no mejora de manera perceptible al ojo humano. Para mas info al respecto: el FAQ jpeg o el de comp.sys.compression (espero haber puesto bien el nombre).
Cita de: "Pogacha"... A mi juego lo bajo de 10mb a 7mb en la compresion de recursos, incluso cuando la mayoria son PNGs ;) y luego a 5mb en la compresion del instalador ... tendria que descomprimir los png y pasarlos a tga para luego guardarlos en el instalador de recursos sin comprimir para probar con la compresion del instalador solamente, a ver que resultados tengo, pero es demasiado trabajo para una cosa que en este momento no me traeria beneficios.
Vuelvo a repetir, la compresion de recursos tiene su principal ventaja en la velocidad de carga del juego!, si fuese mas rentable una unica compresion para el ensamblado del instalador entonces lo que se me ocurre seria mas eficiente seria crear el instalador con los recursos sin comprimir y una vez instalado comprimir los recursos.
Este metodo se llama "Metodo de optimización de instalador de Pogacha" todos los derechos reservados.
Saludos.
Bueno, obviamente depende del tipo de juego que vayas a hacer. Si se trata de un juego que va en un CD y que necesita cargar 300 imágenes de disco cada vez, mejor que las cargue rápido a que pese poco. Pero para un juego casual con pocos recursos, mejor que ocupe 10 MB en vez de 20 aunque eso aumente tres segundos el proceso de carga.
CitarCompara TIFF comprimido, PNG, GIF, o similares, no JPEG.
- BMP 192 KB (196.664 bytes); Setup 359 KB (368.277 bytes)
- GIF 45,7 KB (46.831 bytes); Setup 325 KB (332.980 bytes)
- JPEG 20,2 KB (20.786 bytes); Setup 299 KB (307.035 bytes)
- PNG 40,7 KB (41.756 bytes); Setup 320 KB (327.829 bytes)
- TIFF 207 KB (212.352 bytes); Setup 365 KB (373.984 bytes)
La proporción sigue igual ;)
He subido todo otra vez, podéis descargar las imágenes utilizadas como sus setups desde
aquí
Para ser objetivos creo que deberías probar a comprimir un set de imágenes representativo de lo que es un juego (en vez de una sola de unos pocos kb's), por ejemplo, 50 imágenes, la mitad de ellas mayores de 512x512, otras tantas pequeñas, etc. Todas en el mismo formato. Hay batch converters por ahí para ahorrarte el curro de cambiar de formato tantos ficheros.
Si te sirve de algo, conseguí reducir unos 3 MB del setup del Cursed Wheel haciendo eso (pasando PNGs a TGA/BMP y comprimiendo a tope en el instalador).
El problema es que no es la misma imagen. En unos casos esta en 24BPP y en otros cuantizada a 8BPP, por eso se dan esas diferencias, porque en algunos casos se esta comprimiendo una imagen que de por si ya es la tercera parte de tamaño (en bytes).
Estoy haciendo unas pruebas yo mismo, las posteo dentro de un rato.
PD: Al margen de que cada imagen en particular se comprima mejor con un algoritmo que otro.
Pero aun así la idea es tener muchas imagenes parecidas, una animación o algo así ... que sean png comprimidas contra tga sin comprimir.
Aqui es donde no se que pueda pasar ...
Cita de: "CoLSoN2"Cita de: "Pogacha"... A mi juego lo bajo de 10mb a 7mb en la compresion de recursos, incluso cuando la mayoria son PNGs ;) y luego a 5mb en la compresion del instalador ... tendria que descomprimir los png y pasarlos a tga para luego guardarlos en el instalador de recursos sin comprimir para probar con la compresion del instalador solamente, a ver que resultados tengo, pero es demasiado trabajo para una cosa que en este momento no me traeria beneficios.
Vuelvo a repetir, la compresion de recursos tiene su principal ventaja en la velocidad de carga del juego!, si fuese mas rentable una unica compresion para el ensamblado del instalador entonces lo que se me ocurre seria mas eficiente seria crear el instalador con los recursos sin comprimir y una vez instalado comprimir los recursos.
Este metodo se llama "Metodo de optimización de instalador de Pogacha" todos los derechos reservados.
Saludos.
Bueno, obviamente depende del tipo de juego que vayas a hacer. Si se trata de un juego que va en un CD y que necesita cargar 300 imágenes de disco cada vez, mejor que las cargue rápido a que pese poco. Pero para un juego casual con pocos recursos, mejor que ocupe 10 MB en vez de 20 aunque eso aumente tres segundos el proceso de carga.
Acuerdate que el jugador casual tiene poca paciencia ;)
He hecho un png comprimido a 24bpp y el tga sin comprimer a 24bpp, resultados
aquí:
- PNG 441 KB (452.099 bytes); Setup 717 KB (734.377 bytes)
- TGA 768 KB (786.476 bytes); Setup 767 KB (785.439 bytes)
PD: Tambien incluyo en el .rar general el archivo en bmp desde el que he convertido a los demas formatos, lo hice con el photoshop.
No tengo ningún lugar donde subir las imágenes, pero las pruebas han sido hechas con una imagen de fondo renderizada con PovRay de un paisaje (con alpha) y 3 secuencias de animación de sprites de 32 fotogramas cada una rotando a lo largo de los 3 ejes (wings3d->PovRay, con alpha).
Si alguien me puede facilitar un alojamiento para subir los archivos, que me mande un PM.
Resultados:
Imágenes sin comprimir en formato TGA 24 bits RGB + 8 bits alfa
1.024.018 chopper1_strip.tga
1.024.018 chopper2_strip.tga
1.024.018 chopper3_strip.tga
271.277 landscape.tga
Imágenes comprimidas en formato PNG 24 bits RGB + 8 bits alfa
87.638 chopper1_strip.png
99.388 chopper2_strip.png
101.719 chopper3_strip.png
125.141 landscape.png
Imágenes comprimidas en formato JPEG 24 bits RGB
44.799 chopper1_strip_color.jpg
36.857 chopper2_strip_color.jpg
31.583 chopper3_strip_color.jpg
21.254 landscape_color.jpg
Componente alfa sin comprimir, en formato RAW 8 bits
256.000 chopper1_strip_alpha.bin
256.000 chopper2_strip_alpha.bin
256.000 chopper3_strip_alpha.bin
76.800 landscape_alpha.bin
Resultados de los instaladores:
172.216 setup_jpg.exe ( *.JPG + *_alpha.bin )
320.135 setup_tga.exe ( *.tga )
445.253 setup_png.exe ( *.png )
Claramente, y como era de esperar, jpg+alpha sin comprimir da mejor resultado, seguido de TGA sin comprimir, y el peor, PNG.
Todos los instaladores han sido generados con la opcion "Best Compressor" de NSIS, que comprime con los distintos compresores y sólo se queda con el mejor resultado para ese conjunto de archivos.
Que estadisticas tan controversiales ...
Eso era lo que yo queria ver, de todos modos habrá variaciones según algunos datos ... lo que si desde ya el JPEG no me gusta para nada por la perdida de calidad.
Saludos.
PD: Muchas gracias por el trabajo de investigación (ole) . Zupervaca y senior wapo trabajaron duro para suplir los experimentos que los flojos como nosotros nunca haremos :P
¿Senior wapo que instalador estas usando? es que estoy buscando la opción que mencionas y no la veo.
Utilizo el
NSIS de NullSoft (opensource)Si que es verdad que esa imagen se comprime sensiblemente mejor con PNG, que con los algoritmos del instalador. Los filtros o reordenamientos (previa compresión) que aplica PNG parecen tener mucho efecto en esta imagen porque el compresor es el mismo que usa el ZIP (deflate) y no comprime tanto a pelo.
@Pogacha: No descartes tan rápido JPG, porque no se nota tanto en la mayoria de las imágenes, sobre todo si son renderizadas (en las fuentes de letra, dibujos con pocos colores hechos a mano, y similares puede que sii).
Un detalle interesante sobre los bordes: Si usas imagenes compiladas como tiras RLE o simplemente usas alpha, da igual que los bordes cambien, porque el propio alpha/RLE recorta sobre la imagen original, no la leída desde JPG. Evidentemente, esto requiere que precalcules el RLE sobre la imagen original y lo guardes aparte, o bien, que el alpha lo guardes sin pérdida.
Además puedes ajustar el grado de calidad individualmente en cada imagen. Sin ir más lejos, "Ricochet" y "Wik & The Fable of Souls" usan JPG y se ven de miedo. Algunas imágenes se guardan al 60% de calidad, la mayoria 95% o asi. Abre su editor y podrás verlo.
Después de estas pruebas me parece que voy a integrar libjpeg en mi motor.
Aparte de las imágenes, para el programa y dlls lo que más comprime (según mi experiencia) es el CAB. He comparado ZIP y RAR y siempre me ha dado mejores resultados el CAB. Imagino que los instaladores utilizarán compresión cab para las DLL, ¿o quizás ZIP?
Para el instalador de mi plugin hice mi propio proyecto, metiendo los ficheros DLL del plugin comprimidos en CAB como resources en Visual Studio. Después los descomprimo y copio utilizando la API de cabinet.dll que está en todos los sistemas Windows. Calculo que el instalador ocupa unos 35KB de los 210KB totales del plugin. Lo podeis ver aqui:
http://www.devalvr.com/installPor cierto, creo que la gente está respondiendo la encuesta en Kbits y no Kbytes. Una cosa que poca gente sabe es que KB significa KBytes y Kb significa Kbits, lo digo porque yo me enteré tambien hace no mucho.
un saludo
Yo ya tengo la jpeglib en mi framework, hice unas pruebas hace un tiempo y para dibujos como los del dylo lamentablemente reduce muy poco sin que se note la perdida ... pero es sabido que para fotos o imagenes fotorealisticas (entiendase complicadas ) es la mejor opción.
Saludos.
He probado con archivos de texto plano y se comprimen que da gusto, ocupa menos comprimido con el rar un formato 3d en texto que en binario.