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
Es programar como antes, sacando partido al hardware. Ahora cualquier programa mierda ocupa 100MB en memoria. No importa el consumo de recursos, si el usuario puede comprar más memoria, ¿no?
#2 ¿No hay un iconito de aplauso?
#2 #5 Ni optimización ni pollas simplemente programación procedural.
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
#8 muchos algoritmos y efectos de los juegos vienen de la demoscene, y si optimizacion.
#9 no sabes de lo que hablas.
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"
#10 fijate si no tengo ni puta idea que llevo viendo demos desde la second reality. no digo que ese tamaño sea por la optimizacion. la mayoria de esas demos estan en ensamblador. Mi comentario de la optimizacion hace referencia a #2 y es un problema moderno. Ahora los equipos van sobrados, antes tenias que programar un juego en un disquette.
pero en fin, tu eres el listo, sabras mas
#13 y yo llevo viendo despegues de la NASA desde que el hombre piso la luna pero eso no me hace ingeniero aeronautico.
#11 es un troll dejalo #15 da la casualidad de que programo juegos.
#16 oh! entonces hay que darte la razón no? jajaj pues vas de culo por que yo también.
#19 pues cuando hagas una demo de 4k me vienes a decir que la optimizacion no es importante so troll
#19 #20 Bueno, pues como yo no programo juegos no me meto, pero precisamente porque no programo llama muchísimo la atención que 4k den para eso, aun teniendo parte de lo visual y audio en el SO. Vale, hay un repositorio pero hay que programar para que ofrezca esto
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...
#24 Ah curioso que no salte otro programador
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.
#26 De 24: 'Vale, hay un repositorio pero hay que programar para que ofrezca esto'
#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.
#24 Aunque yo no hablaba de programas, tampoco lo veo así. Ahora son más complejos los programas y los compiladores optimizan más. Cada linea de código esta ahí por alguna razón. Y se utilizan librerías standard mayormente más que optimizadas.
El "paint" sigue ocupando una mierda. Pero claro el photoshop no, y no es por que no este optimizado.
#24 El audio suele ir a base de samples (al estilo midi), no guardas todo el sonido grabado (que ocupa mucho) sino la "partitura" y la forma de generar las notas (que ocupa muy poquito).
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.
#65 Gracias por la explicación Entiendo, os he entendido, pero sigue estando el matiz que ya he comentado antes. No era tanto en cuanto a juegos como en programas en general, de uso cotidiano. Dejando esto ya y hablando de juegos, capas y físicas. Dos de ellos espectaculares, uno de hace ya algunos años y que precisamente por eso era brutal, avanzadísimo -o a mi me lo parecía y sigue haciéndolo- era el Extrem Assault. Más recientemente y sobretodo por su física el LFS (live for Speed)
#68 Avanzadísimos para su época el motor del ultima underworld (mapeado de texturas, físicas, completamente 3d), la iluminación dinámica en un entorno completamente 3d y con movimiento libre del descent (luego dicen que el revolucionario fue el quake, pero anda que los dos que he nombrado...), las físicas y el deformado de modelos del carmageddon (todo por software)... antes podías y tenías que dedicarle más tiempo a la parte técnica y jugabilidad del juego que a la parte artística. Ahora el peso de un desarrollo se lo lleva la parte artística y la programación del mismo porque la parte técnica te la resuelven los middlewares. Y con esto del HD y los mundos abiertos, hacer un solo escenario o nivel donde no te cante nada, aproveches los recursos y asombre a los jugadores cada día cuesta más.
#70 En el segundo lo alucinante era la física A ver el nuevo como se comporta
#24 Dile a los "mega-programadores" que te expliquen porque en un juego las texturas a veces están en formatos como PCX y BMP y no en PNG o JPG que ocupan mucho menos. Cuando apenas hay un cambio de calidad, especialmente en el primer caso.
¿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
cc #94
Ya sabéis chicos... a desembuchar
#94 Sí, ese, jejejeje. Mola ver que alguien se acuerda de memoria después de tantos años. Lo que pasa es que en su día awesome.com estaba pillado y un amigo me dio la idea de cambiarlo por Awezoom, y ahora mi propia empresa de diseño se ha acabado llamando así.
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.
#13 No te jode y antes se trabaja con sprites de unos kb y ahora con texturas 4k de alta resolución de 10mb o más mb por texturas. Anda que...
#18 Si supieras de procedurales sabrias que no se usan sprites en demos de 4k, si no que las texturas son generadas en tiempo real. Y ya que la optimizacion no tiene nada que ver, iluminanos, como puede una demo de 4k tener musica? Como la generan?
#20 No digas tonterías anda
#20 Por si lo preguntas realmente: https://www.shadertoy.com/view/MdSXzG. Pincha en Sound.
(Se entiende algo mejor https://www.shadertoy.com/view/ldXXDj)
#81 Me lo imaginaba, pero nunca habia visto el codigo.
Gracias por el aporte!
#18 Cuando trabajas con procedurales, básicamente describes las formulas que generan el contenido. Con una formula gigante, pero aún así ridícula en cuanto a espacio de disco, puedes generar una textura de 4k de alta resolución bastante chula.
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
#36 #41 Explícaselo al otro/otros hombre que es el pesado diendo que los juegos estan mal optimizados por eso ocupan mucho.
#43 Ninguno de los comentarios que referencias ha dicho eso pero, en cualquier caso, es verdad. Los juegos ocupan mucho porque no están optimizados en tamaño.
Y la razón es porque el desarrollo de juegos tiene muchos problemas, pero el tamaño en disco no es uno de ellos.
#44 Las texturas que es lo que ocupan se comprimen, las meshes se reutilizan (pero es más por rendimiento que por espacio), ya me diras exactamente que se puede optimizar para que ocupen menos tamaño un simple juego o demo que con 20 texturas a 2k o 4k te ocupa 100mb-200mb... campeon.
#45 Que no haga falta optimizar el espacio en disco, no significa que no haya que optimizar el tamaño de las texturas. Hoy en día el tamaño de las texturas se optimiza y mucho por la sencilla razón de que tienen que entrar las más posibles en la memoria de GPU y en GPU una textura no se puede comprimir mucho mas allá que 4:1 (S3TC) por lo que la compresión no es la solución.
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.
#52 Un poquito más
http://www.arm.com/files/event/Developer_Track_5_ASTC-The_Future_of_Texture_Compression.pdf
#8 Lo que dices no es incompatible con lo que comenta #2
#11 Esta comparando un demo procedural con un juego y diciendo que ahora un juego mierda ocupa 100mb y metiendo las culpas a la optimización. Es totalmente incorrecto y mi comentario si viene a cuento.
#11 Tienes razón, pero si en texturas el juego te ocupa 20 gigas, que los binarios me ocupen 100 megas pues como que me la bufa.... Otra cosa es la pésima optimización que tienen muchos juegos.
#2 Es programar como ahora. Ahora las 4K no son más que un miniframework de OGL, un polígono de 4 vértices y un fragment shader. Toda la chicha está en el último. De hecho hay toda una scene nueva basada en los fragment shaders (www.shadertoy.com) Poco ensamblador verás hoy en día.
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.
#36 No optimizan una mierda ahora mismo esta pasando lo que paso en los 80 y 2007 entre que se portea de consolas a pc de forma chapucera y tenemos rendimientos de meirdas por la memoria unficada de las consolas vs a la vram de la vga y mientras la ram del sistema tocandose las pelotas la vram esta petada.
#8 Sé que decir esto es un pecar de tramposo, ¿pero llegaste a jugar al Kkrieger?
http://web.archive.org/web/20110717024227/http://www.theprodukkt.com/kkrieger#20
96 kb pesaba el jueguecito.
#8 Se pueden crear texturas y shaders procedurales
#8 Perdona pero no estamos hablando de una demo de la categoría de 64KB.
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.
#56 4k? Con gcc si.
" cout "
C.
Prueba con pcc y tcc y sobre todo evita GLIBC.
#89 ¿Ejecutable para Windows (PE) como la demo?.
#2 #3 Es fácil rajar sin conocer las implicaciones. Una demo visual de 2 minutos donde solo tienes un único objetivo y pocos requisitos se puede optimizar.
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.
#39 No te falta razón en lo que dices, pero no me refiero a la sobrecarga que suponen los aspectos de los que hablas.
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.
#48 Lo de que se puede optimizar te lo certifico, lo de que al equipo de desarrollo le han dado 2 jornadas para implementar bajo la directriz de: antes funcionaba, dejalo igual y arreando, también.
¿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
#48 Pero es que hoy en día es más barato la CPU y la RAM, que las horas de programador.
#2 Optimizacion
#2 ahora hacen algunos programas y juegos para que ocupen más, quizá para justificar su precio entre otras cosas.
#1 #2 #0 alguien me explica como es ppsible que ocupe tan poco??? no lo entiendo
#58 Es que hay mucha diferencia entre generar las texturas/modelos/escenas o cogerlos hechos. En el primer caso se crea todo en la memoria en tiempo real, en el segundo caso se cargan de donde están almacenados.
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.
#58 Lo explican en la noticia, hace uso de las librerías gráficas del SO y usa los sonidos del mismo.
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.
#58: Generación procedimental.
http://www.vadejuegos.com/noticias/generacion-procedimental-el-futuro-de-los-videojuegos-20150130.html
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-.
http://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.
Por cierto, Portal 2 también tenía algo de esto en cuanto a la banda sonora de Mike Morasky.
https://mundosafines.wordpress.com/2014/07/12/portal-2/
#58 Mira lo que se hace ahora, shadertoy.com tienes que tener una gráfica potentilla, si te fijas a un lado ves todo el código, puedes hacer cambios y ver el resultado..(ese código que son 3000 caracteres) y con eso te hacen un océano realista.
Bueno lo que ves ahí son shaders, que aunque en algunos casos parezcan objetos 3D, son planos con un shader, un shader puede hacer que un objeto plano pareza agua y se mueva, o que parezca metal o madera, o lava... en fin,
La verdad es que me paso el día haciendo shaders, pero nunca supe como explicar lo que es a alguien no sepa nada de esto..
Saludos.
P.D te puede tardar un rato en compilar...
#2 Pues la animación chupa gráfica que es un alucine.
#2 ¿Tú te crees que esa animación la mueve cualquier PC? Más te vale que tengas una buena gráfica.
La voyager I sólo tenía 40 kb de memoria, eso sí que es aprovechar
Voy a votar errónea, por la sencilla razón de que, aunque el programa en cuestión mida 4k, el engine o las librerías de las que hace uso también debería contar. No creo que el total sean 4k.
#26: Tampoco hace falta ser tan estricto votando negativo, aunque tienes toda la razón en que el tamaño total debería incluir las bibliotecas que hagan falta.
#26, #31, eso me preguntaba yo... cuando veía las demos/intros que venían en los CDs de las revistas noventeras, TODO estaba incluido en el ejecutable, ¿verdad?
#38 No, el DOS, no estaba en el paquete. El DOS, aportaba por ejemplo, gestión de memoria, interrupciones, acceso a disco, teclado, juego de caracteres...
Y mucho de esto además estaba masado en lo que había en la BIOS.
#31 Dudo mucho que incluir el tamaño de OpenGL/Direct3D (y de paso del sistema opeativo) sea una práctica habitual.
#26 Se acepta que el sistema operativo base (sin añadidos) provea "servicios" a la demo (intro en este caso), o librerías básicas de entrada/salida siempre que sean propias del sistema o muy extendidas (caso de SDL, BASS audio library...) . Salvo que quieras programar un wrapper de OpenGL a pelo y que tire en todas las gráficas por ahí fuera (idem para el audio) ya me dirás.
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
Un par de ejemplos.
Por cierto, Crinkler y KKrunchy también ayudan con el tamaño del ejecutable.
Link para verlo directamente por Youtube:
#1 Gracias. Para los de LD ni un click.
Que el binario ocupe poco no tiene nada que ver con la optimización y mucho menos con el uso de RAM durante su ejecución.
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.
#34 De hecho un procedural de estos suele ser bastante duro en cuanto a uso de CPU. Pero aún así, son unos putos cracks.
Bueno bueno bueno, múltiples referencias veo yo:
- 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...
Me toca un poco las pelotas eso de "subcultura". Joder... CULTURA, así en mayúsculas y sin prefijos de mierda. Que detrás de cada producción de la Demoscene hay el trabajo y el talento de mucha gente, durante mucho tiempo. Si Leonardo Da Vinci u Orson Welles hubieran nacido en 1975 sin duda habrían sido grandísimos sceners.
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.. http://www.pouet.net/
#35 "Subcultura" no quiere decir que sea inferior. Los prefijos no siempre significan lo mismo.
A lo mejor hay que leer más.
Aunque naturalmente hace uso de las librerías de 3D y sonido ya instaladas en los ordenadores Windows
buuuuu, es un exe, yo crei que era un gif o png
Qué recuerdos...
.Aunque éste me sigue pareciendo mejor que el de la noticia: .
Y había una hecha por españoles de animales en la Euskal Enconter pero no me acuerdo del nombre.
Ni es una animación gráfica ni está comprimida.
#61 La generación procedural es a todos los efectos una forma de compresión.
#86 no lo es, puedes obtener resultado parecidos pero es como comparar el hacer un dibujo en Photoshop punto por punto con utilizar curvas Bezier, no creo que lo último sea considerado una compresión.
Considerar un L-system como compresión, por poner otro ejemplo, tampoco me parece muy acertado.
#93 La línea entre compresión y generación procedural no es tan gorda. La compresión no es más que un reconocimiento de patrones generables proceduralmente. Por ejemplo, en tu primer ejemplo, el reconocimiento sería un paso de vectorización.
Si que es verdad que si el humano entrega directamente los datos ya comprimidos, no existe ningún paso de compresión.
donde se puede ver el código fuente de la demo?
Juraría que esto ya salió por aquí...aunque no estoy seguro de que se la misma...de todas formas es acojonante...
Es parecida a la cdak que, de hecho, me sigue gustando más
Esto ya venía en el winamp hace siglos.
Mola mucho. Muy currada. Pero el titulo es erróneo. No esta comprimida en 4k, ya que:
"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."
Mola, pero era mucho mas espectacular cuando no echaban mano de librerías ni el hardware pintaba solo.
por ejemplo: http://www.pouet.net/prod.php?which=482
Esto es un poco como escribir un libro que empieza así:
"Erase una vez un tío que abre un libro y se pone a leer así:
A mi siempre me encantó esta:
Este envío cuenta con el @freddyncalm seal of approval.
Un poco coñazo hasta que salen las naves.
Putos aficionados
Lo suyo sería comprirlo todo a un bit...
#32 El big bang bit
No supera elevated del 2009 http://www.pouet.net/prod.php?which=52938 pero esta muy bien, sobretodo el sonido.
#73 Hablando de Elevated: https://www.shadertoy.com/view/MdX3Rr
Me ha recordado a un paseo por Aperture Science.
Grafistas dice el articulo.. /facepalm.
Eso es puro pico y pala.
Jo, qué raro ver cosas sobre la demoscene en meneame. Aquí un ex-scener de la época en que la Euskal parte servía para aprender a programar y crear y no sólo para partidas online. Awesome era mi nombre en esa época aunque ahora no ha cambiado mucho hay más gente por aquí de esa época?
Menuda brutalidad
seguro que no está hecho en java ...
Pues yo lo veo más bien dorado, no se de dónde sacáis eso de que es negro en 4k. Mi tele es 4K pero le he metido el .exe en un pendrive pero no se vé en 3D ni nada así que nada sigo jugando a mi Resident Evil Zero.
#0 más que una animación comprimida en 4k diría que es un programa de 4k que genera una animación
Estos no han programado una democracia en un msx2 o un c 64. Tanto rollo.