Ancho De Banda

[zupervaca]

 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

[CoLSoN2]

 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.

[TheAzazel]

 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...

[senior wapo]

 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.

[tewe76]

 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:  

[Pogacha]

 No entiendo por que no comprimir los recursos  :huh:

[zupervaca]

 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)

[ethernet]

 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

[CoLSoN2]

 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."

[Pogacha]

 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.

[ethernet]

 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.

[senior wapo]

 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.

[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.

[zupervaca]

 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.

[senior wapo]

 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).