275 meneos
15501 clics
Una asombrosa animación gráfica comprimida en sólo 4096 bytes
La demoscene, o escena como se la llama en España, es una subcultura informática nacida con los ordenadores de 8 bits, especialmente el Commodore 64, pero que vivió su apogeo en los años 90 gracias al PC y al Commodore Amiga. La escena se ha empeñado en no desaparecer, y buena prueba de ello es esta intro, ganadora del primer premio del TokyoDemoFest, que ocupa sólo 4k
|
comentarios cerrados
www.youtube.com/watch?v=HkNYKvwqCVY
- El quinto elemento
- tron (original)
- odisea 2001
- star wars la estrella de la muerte
- blade runner
¡Vivan los fractales!
Sinceramente, no me parece para tanto...
No podéis comparar un juego con una intro de la demoscene. Una simple textura de alta resolución ya ocupa bastante más que eso y no hay optimización que valga.
cc:/ #3
y si hay expertos en juegos que dan el salto desde la demoscene, bien conocen la programación, pero no tiene que ver.
Y si bien no se puede decir que no estén optimizados, no tiene que ver el tamaño comparandolo con un juego "por la optimización"
pero en fin, tu eres el listo, sabras mas
buuuuu, es un exe, yo crei que era un gif o png
Por otra parte 19, lo que decía de #2 sigue siendo válido, ahora con la cantidad de RAM cualquier cosilla te quita 100 o 200 Mb y seguro que programando de otra forma se podría ajustar mucho más, pero como parece que hay RAM a expuertas...
Hay que programar evidentemente y saber mucho, y tiene mucho merito en ningun sitio dije lo contrario. Las empresas del sector se rifan a los mejores de la demoscene.
La segunda parte es lo incorrecto, no puedes comparar con un juego "normal", el 99% de esos MB seguramente sean texturas en alta resolución como e dicho. La parte de codigo en una demo visual que no tenga ni lógica ni nada es mínima, aunque aun sea bastante mayor que si haces programación procedural. Lo que ocupa tiene muy poco que ver con la optimización del código.
Ahora con la cantidad de RAM que hay en vez de ponerte texturas cutres te ponen texturas de alta resolución, no hay más.
#27 Pues sí, curioso En cuanto a la segunda parte vuelvo a lo que decía 2 y yo en el anterior, no nos referimos sólo a juegos, por supuesto que ahí entran texturas y demás. Hablamos de que en programas 'normales' parece que haya una despreocupación a la hora de minimizar consumo/tamaño dada la cantidad de RAM más o menos habitual. Es el juego de siempre, programas más pesados para mejorar el hardware y viceversa.
El "paint" sigue ocupando una mierda. Pero claro el photoshop no, y no es por que no este optimizado.
Se está hablando de que el ejecutable solo ocupa 4Kb sin contar librerias (obviamente). Es simplemente una forma de clasificar a las demos que "compiten" en la demoscene.
Se ha hablado por ahi arriba de optimización a la hora de hacer una demo 4k... que mas dará la resolución cuando usas algoritmos escalables? Son operaciones matematicas que generan los datos necesarios para que las GPU rendericen los gráficos. Estás demos no usan texturas, casi todo son datos generados en tiempo de ejecución. Por mucho que optimices la generación de los datos para el renderizado, vas a necesitar una cantidad de memoria gráfica determinada a poder pintar eso en pantalla.
Pero por si alguien quiere profundizar un poco en todo este tema, aquí os dejo la mayor base de datos de producciones esceners del planeta.. www.pouet.net/
Ahora cualquier programa mierda ocupa 100MB en memoria.
Las 4K de antes, ocupaban un cojón en RAM, porque al empezar la demo se tiraban 5 minutos haciendo precálculos y guardándolos en RAM. Hoy ya no se precalcula tanto.
#8 Se puede optimizar el uso de CPU, de RAM, de disco, de energía, de red, incluso el tiempo de desarrollo. Simplemente, la optimización del espacio en HDD de un juego no es en absoluto prioritaria.
www.youtube.com/watch?v=RCh3Q08HMfs
Un programa de 100 megas tiene módulos compartimentados con prioridades y compromisos de diseño diversos, varios equipos de trabajo, hereda de plataformas antiguas, estándares que han ido variando en el tiempo y un nivel de complejidad y abstracción brutal.
Es como decir que vaya mierda los camiones, consumen una burrada, el otro día vi un vehículo solar monoplaza experimental que hacía 200 km con un litro. Que vagos los diseñadores de camiones.
Aunque éste me sigue pareciendo mejor que el de la noticia: www.youtube.com/watch?v=mZdlSWLqumw.
Y había una hecha por españoles de animales en la Euskal Enconter pero no me acuerdo del nombre.
Evidentemente esto consume bastante CPU, por lo que los programas digamos "normales" lo que hacen es guardar la textura ya generada, que ocupa un montón de memoria pero ya no hay que computar nada.
Es básicamente la diferencia de tamaño entre los planos de la casa y la casa
Y la razón es porque el desarrollo de juegos tiene muchos problemas, pero el tamaño en disco no es uno de ellos.
Y mucho de esto además estaba masado en lo que había en la BIOS.
Ni tampoco a los videojuegos, que evidentemente tienen que meter gráficos en memoria y pesan mucho.
Me refiero a los paradigmas de programación. Se trata de programar a bajo nivel, con un alto nivel de esfuerzo, para optimizar el uso de recursos, o bien tirar de bibliotecas estándar, evolucionadas de otras más antiguas, y que arrastran bastante basura que no se utiliza. ¿Es razonable que Notepad ocupe 1,5MB sólo por estar abierto? Estoy seguro de que se puede optimizar el consumo de memoria, y muchas veces de CPU también.
web.archive.org/web/20110717024227/http://www.theprodukkt.com/kkrieger
96 kb pesaba el jueguecito.
¿Se puede rascar hasta sacar el rendimiento óptimo? Fijo ¿Alguien va a hacerlo? No es prioritario, si se puede hacer vale, si no no merece la pena el esfuerzo.
Yo cuando pico solo tengo una máxima directriz de rendimiento, que no se cargue de trabajo el servidor, si esa es la especificación crítica de mi código todas las medidas a tomar son de cara a salvaguardar servidor y base de datos, y el usuario q se joda si su maquina se queda tostada 15 minutos. Si a los tipos q hacen el notepad solo les indican que el objetivo es velocidad de desarrollo y a lo sumo interfaz amigable ya te puedes imaginar lo q se preocupan. Y no, este tipo de cosas no se hacen porque las compañías sean malvadas, si no que elaboras un planing de que necesita el usuario y mas valora, si ves que el usuario estandard no valora el hecho de que su aplicacion le coma la mitad de la ram (un saludo Chrome) porque no es algo que valore (y seamos sinceros igual no somos ni tu ni yo usuarios promedio, la mayoría de la gente no tiene un monitor de carga del sistema encendido mostrandole el consumo) pues no se hace. No aporta valor añadido no lo van a pagar ni a valorar.
Es triste si, pero estas cosas funcionan así y no es culpa de las compañías ni de los programadores. Voy a ganar karma: La culpa la tienen los mercados
La mayoría de las técnicas se basan en usar varias texturas como primitivas y combinarlas en texturas complejas en la fase de sombreado y aplicar la resolución necesaria a cada una. Por ejemplo una textura de oclusión no necesita la misma resolución que una de desplazamiento o una difusa. Sin esas optimizaciones las texturas de un juego ocuparían ordenes de magnitud más.
El cuello de botella en cuanto a espacio está en la GPU. Si las optimizaciones para GPU tienen el efecto lateral de ocupar menos en disco, pues mira qué bien. No tiene ningún sentido que las texturas ocupen menos en disco que en memoria. Si así fuese, se llevarían las optimizaciones a otro nivel, fuera de la fase de sombreado y en disco se guardaría exclusivamente el trabajo del artista en la herramienta de creación de texturas en vez de guardar el resultado final, en la fase de subida se generaría el asset. Esto, llevado al extremo, es como creó Pixar los bosques de Brave, es decir, que hoy en día sí existen workflows así, de nuevo, no era el espacio en disco el problema que querían resolver.
www.youtube.com/watch?v=G1Q9LtnnE4w
Tengo cierta experiencia en programación gráfica y te aseguro que incluso tirando de fractales para absolutamente todo (música incluida) es una auténtica virguería meter todo eso en 4k.
Máxime para un ejecutable de Windows.
Cogete varios compiladores y escribe un "hola mundo" en C. que solo tenga un include, main y cout o printf.
Lo compilas para release con todas las opciones de debug quitadas y pones todas las optimizaciones ce compilacion y enlazado orientadas a tamaño.
Luego me dices si consigues que el ejecutable te abulte menos de 4k.
Y estamos hablando de un hola mundo.
Eso es puro pico y pala.
"Aunque naturalmente hace uso de las librerías de 3D y sonido ya instaladas en los ordenadores Windows, todos los gráficos y música entran en ese espacio."
Tu programa puede ocupar poquito, pero tener rutinas que generen todo lo necesario. Puedo tener un fichero de texto que me almacene cosas como "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" o puedo crear un programa que repita aes, lo cual puede ser un poco más complejo (o un mucho).
Normalmente lo que realmente ocupa de los programas son los datos y no los programas en si.
Añado que además, los programas son como rompecabezas de librerías: en lugar de hacer tu las cosas, utilizas librerías programadas por otros que te resuelven esas cosas. El problema es que además añaden un montón de funcionalidades que tu posiblemente no uses y que engordan un montón el asunto.
En la demoscene se crean todas las herramientas para lograr lo que muestran, que sean lo más ligeras y eficaces posibles, sin recurrir a librerías de terceros que tengan más cosas de las necesarias.
Los gráficos son todos pregenerados o calculados en tiempo real.
El problema de las aplicaciones y juegos no es que no se optimicen, es que poco se puede optimizar. Trabajas con middlewares (o sea, muchas capas intermedias que te resuelven problemas como gráficos, físicas, etc.) que se conectan unos con otros con mejor o peor fortuna, los engines son muy complejos y modificarlos cuesta huevo y medio, así que te limitas a exprimirlos todo lo posible dentro de tus posibilidades (hay estudios que saben eludir sus limitaciones y/o aprovechar sus potencialidades y otros que simplemente cargan las escenas y ya). Igual que tunear una base de datos o configurar un servidor web lleva su tiempo y necesitas muchos conocimientos, aquí pasa igual, y sinceramente, es más fácil trabajar con las cosas que sabes que tienen mucho impacto en el rendimiento (shaders más ligeros, bajar todo lo posible la carga poligonal, no saturar de efectos, que la IA no te cree cuellos de botella, las físicas meterlas lo menos posible y donde solo tengan relevancia, etc) que ponerte a exprimir el hardware haciendo optimizaciones a bajo nivel.
Hoy en día se lleva más el sandboxing, que consiste en todo lo contrario, en empaquetar todo lo necesario para que el ejecutable para limitar los recursos a los que se accede.
www.arm.com/files/event/Developer_Track_5_ASTC-The_Future_of_Texture_C
"Erase una vez un tío que abre un libro y se pone a leer así:<<En un lugar de La Mancha, de cuyo nombre no quiero acordarme...
por ejemplo: www.pouet.net/prod.php?which=482
(Se entiende algo mejor www.shadertoy.com/view/ldXXDj)
Otra cosa es que metas un 4Kb y le enchufes una librería tuya con toda la mandanga dentro.
Si quieres "hardcore", mira la categoría de 256 bytes/MSDOS en pouet.net
www.youtube.com/watch?v=R35UuntQQF8
www.youtube.com/watch?v=f1joQfp78Yo
Un par de ejemplos.
Por cierto, Crinkler y KKrunchy también ayudan con el tamaño del ejecutable.
Gracias por el aporte!
A lo mejor hay que leer más.
www.vadejuegos.com/noticias/generacion-procedimental-el-futuro-de-los-
Si te manejas con el inglés aquí tienes un ejemplo real de un videojuego que la usa en abundancia, Spore -que luego fue una decepción, pero esa es otra vaina-.
en.wikipedia.org/wiki/Development_of_Spore#Procedural_generation
Ahora está por salir este otro "No man's sky", que sigue el mismo esquema de plantear su contenido de esa forma. www.youtube.com/watch?v=nmwG6Sj1Yfg
Por cierto, Portal 2 también tenía algo de esto en cuanto a la banda sonora de Mike Morasky.
mundosafines.wordpress.com/2014/07/12/portal-2/
" cout "
C.
Prueba con pcc y tcc y sobre todo evita GLIBC.
Considerar un L-system como compresión, por poner otro ejemplo, tampoco me parece muy acertado.
¿Qué me digan los "mega-programadores" porque hacen un programa en lenguaje de alto nivel y no en ensamblador. Porque se utilizan tropecientas herramientas como motores 3D, librerías específicas?... básicamente por comodidad. Porque todos lo hacemos programemos poco o mucho.
¿Qué te digan "los mega-programadores" porque cada vez hay más juegos que son pura fachada, que además de estar mal optimizados, están mal programados. Y se nota porque salen casi con más fallos que código. Lo que dice el mal trabajo que se ha hecho en la fase beta, que se supone que es para depurar y optimizar el código?
Juegos que son pura fachada que están mal programados y mal optimizados. Entre ellos, sí, el espacio en disco. Que esto es como la memoria RAM, parece que es infinita, pero no. Y en especial en los ordenadores, que rara vez sólo está un programa o juego ejecutándose.
#90 ¿El de Inside y Wild Bits? ¡Flipo! Para mí érais magos de la demoscene. En realidad toda la demoscene, porque me parece increíble las maravillas que hacéis en tan poco espacio.
Salu2
Ya sabéis chicos... a desembuchar
Si que es verdad que si el humano entrega directamente los datos ya comprimidos, no existe ningún paso de compresión.
Y sí, la magia de la demoscene de esos años es algo irrepetible. Siempre, toda mi vida, recordaré la primera vez que vi un prodigio de la técnica llamado Second Reality. Aun hoy es entretenida de ver, pero es que en su día fue como ver la escena del Troll en Moria en los 80. Algo fuera de este mundo.