Portada
mis comunidades
otras secciones
#3:
#2 Te explico: Esta hecha para la arquitectura AGA, que es la sucesora de la original OCS que llevaba tanto el 100 como el 500. La AGA tiene como modo "normal" 256 colores, que además es el usado en gran parte de la demo. Además luego tiene le modo HAM8 que efectivamente puede mostrar 24 bits (aunque se suela decir 18 bits porque los inútiles del dep. de marketing de de Commodore no se habían dado cuenta de que el límite teórico que presuponían en realidad no era tal), pero esos colores se consiguen aplicando una especie de "compresión" de color (parecida a la de Mpeg) que penaliza el rendimiento, por lo que solo la usan puntualmente.
Aunque la primera aceleradora montada sería aproximadamente del 96, el sistema salió en 1992 (tanto el 1200 como el 4000) y el procesador en el 94, pero no es determinante para ejecutarla porque también se puede correr en un 68040 de 1990, solo que irá un poco más lenta.
Aunque la primera aceleradora montada sería aproximadamente del 96, el sistema salió en 1992 (tanto el 1200 como el 4000) y el procesador en el 94, pero no es determinante para ejecutarla porque también se puede correr en un 68040 de 1990, solo que irá un poco más lenta.
#4:
#1 Concuerdo, pero no quería abrumar al personal con demasiadas "frikadas". Aquí tienes algo de parte de uno de sus autores
https://www.pouet.net/prod.php?which=88640#c920727
Eso sí: ya te aviso que es MUY técnico, para entenderlo necesitarás releerlo al menos un par de veces
"Some rant about the code in here.
The zoomer:
It is an infinite zoomer inspired by TBL's spectacular zoomer in Magia. Large images (up to 8192x8192) with lots of detail get converted to polar images. The bigger the polar image, the further we can zoom in. The neat thing about this conversion is that only the details that are important while zooming towards a single point are kept, while the rest of the details get discarded. The original filesize of some of these images maybe 200 MB or so.
The polar image gets mapped on your typical tunnel table of U,R coordinates. Instead of scrolling the r-coordinate, as you would in a tunnel, it is scaled by a zoom factor. To avoid choppy movement, there is some subtexel precision on the radius and angle coordinates allowing very smooth movement. Without the subtexel precision the slow movement is impossible. The LUT itself was made piecewise linear to avoid reading so much table data from RAM. The effect is embedded in the c2p to save further bandwidth.
At first we tried automatically stitching together multiple smaller images, but the seams between the images always turned out blurred. Painting these images is also a huge amount of work. I seem to remember TBL saying Louie spent a lot of effort on that Magia zoomer and I'm really impressed at how long it zooms and its seamless transitions.
In the end we came up with the idea of using gigantic fractal images and we called upon Evilryu to help out with coding these in Shadertoy. He tried several kind of fractal formulas and color combinations. The most detailed ones caused too much aliasing and in the end the techno world you see in the demo was chosen. The images are blurred before conversion to polar to reduce some aliasing. Since many images were made I'm tempted to release another demo just featuring all of these variations. Lots of cool stuff.
While this was going on Farfar modeled the mask object which fit very well inside this technomaze imagery.
Skybox:
6 fractal images rendered with 90 degrees field of view from a single point mapped on a cube.
The 3d-engine/exporter:
I really wish it was a movieplayer as suspected above as that would be more impressive I suspect the reason it looks like a movie is because the "glow" adds some mpeg like artefacts.
The exporter is taking a lightly extended GLTF format. It has got a few custom properties exported from Blender to describe particle systems. One very convenient thing about the exporter is that it works on a 24-bit original scene and collects all textures, overlays, shadetables into a common palette that everything gets remapped to. The palette generator tries to make sure there are colors for transparent effects such as particles and glow. Without this automation it is very painful to manage the palette for Amiga 3d scenes.
Animation:
- Node animation and hierarchy
- Shape morphs
Polyfillers:
- Flat
- Affine texture
- Perspective correct texturemapping (unused)
- "Normalmap"
- "Normalmap" + Texture (unused)
The "normalmap" is actually a cylinder map with (angle,y) components. So just adding an constant to this angle will make a light fly around the object on a fixed axis. The angle-constant is calculated using:
math_function_trying_to_calculate_an_angle_somehow(camera_position,object_positi on)+sin(time)*i_want_to_see_the_light_moving_abit_more
It is not going to please the phyics professors, but it is minimal overhead to get some dynamic looking lighting on Amiga. I suggest consulting the papers of Larusse, Kippenes et al for more on this technique.
Particles:
- Motion: turbulence field, velocity, dampening ..
- Compiled sprites
- Colored particles that can blend against eachother in 256 colors
- Export time clustering to fake more particles
The particle images are pieces of code that draw the particle. This way no extra cycles are spent on blending fully transparent areas within the particle image. Whether this gave any performance advantage is yet to be measured, however I always wanted to try it so left it in there.
Antialiasing/post processing:
Antialiased polygons are quite rare on the amiga scene. This AA method works by first detecting the silhouette of a mesh while backface culling. Edges that are shared between a backfaced culled triangle and a visible triangle make up the silhouette edge set.
As these edges are encountered during rendering, the coverage data and background of the edge is recorded before the triangle is drawn. Then this data is blended back in after the triangle has been drawn. Sometimes this leads to bleedthrough artefacts, but these are then cleverly concealed by blinking and viewers attention are trivially diverted by the MPEG artefact like "glow".
Glow:
It is not limited to glowing towards light, but also glows toward darkness. The image brightness gets sampled in 16x16 interval grid. This gets linear interpolated across the surface and sent through Tone-Loc mapping before written to the surface. This glow has the property that it looks MPEG-ish. Making people think they are watching a Video-CD thing in 1998.
FPU temporary registers:
The demo changes the FPU rounding/internal precision mode so that 32-bit values can be stored in FPU registers without getting corrupted. This way one can store addresses and integers in tmp FPU regs instead of spilling them to RAM.
Music:
The music routine is approximating an original 16-bit signal in chunks of 512 samples using normalized_8_bit_signal[i] x amiga_channel_volume[chunk]. This gives more bit resolution in low volume parts of the track making the output better than pure-8-bit and without the volume loss of the traditional 14-bit technique. If the best approximation would be an volume of 31.5, then amiga_channel_volume of channel 0 would be set to 30 and of channel 1 to 32 etc. Hopefully giving a next multiplier of 31.5.
For more about this technique consult Kippenes et al."
https://www.pouet.net/prod.php?which=88640#c920727
Eso sí: ya te aviso que es MUY técnico, para entenderlo necesitarás releerlo al menos un par de veces
"Some rant about the code in here.
The zoomer:
It is an infinite zoomer inspired by TBL's spectacular zoomer in Magia. Large images (up to 8192x8192) with lots of detail get converted to polar images. The bigger the polar image, the further we can zoom in. The neat thing about this conversion is that only the details that are important while zooming towards a single point are kept, while the rest of the details get discarded. The original filesize of some of these images maybe 200 MB or so.
The polar image gets mapped on your typical tunnel table of U,R coordinates. Instead of scrolling the r-coordinate, as you would in a tunnel, it is scaled by a zoom factor. To avoid choppy movement, there is some subtexel precision on the radius and angle coordinates allowing very smooth movement. Without the subtexel precision the slow movement is impossible. The LUT itself was made piecewise linear to avoid reading so much table data from RAM. The effect is embedded in the c2p to save further bandwidth.
At first we tried automatically stitching together multiple smaller images, but the seams between the images always turned out blurred. Painting these images is also a huge amount of work. I seem to remember TBL saying Louie spent a lot of effort on that Magia zoomer and I'm really impressed at how long it zooms and its seamless transitions.
In the end we came up with the idea of using gigantic fractal images and we called upon Evilryu to help out with coding these in Shadertoy. He tried several kind of fractal formulas and color combinations. The most detailed ones caused too much aliasing and in the end the techno world you see in the demo was chosen. The images are blurred before conversion to polar to reduce some aliasing. Since many images were made I'm tempted to release another demo just featuring all of these variations. Lots of cool stuff.
While this was going on Farfar modeled the mask object which fit very well inside this technomaze imagery.
Skybox:
6 fractal images rendered with 90 degrees field of view from a single point mapped on a cube.
The 3d-engine/exporter:
I really wish it was a movieplayer as suspected above as that would be more impressive I suspect the reason it looks like a movie is because the "glow" adds some mpeg like artefacts.
The exporter is taking a lightly extended GLTF format. It has got a few custom properties exported from Blender to describe particle systems. One very convenient thing about the exporter is that it works on a 24-bit original scene and collects all textures, overlays, shadetables into a common palette that everything gets remapped to. The palette generator tries to make sure there are colors for transparent effects such as particles and glow. Without this automation it is very painful to manage the palette for Amiga 3d scenes.
Animation:
- Node animation and hierarchy
- Shape morphs
Polyfillers:
- Flat
- Affine texture
- Perspective correct texturemapping (unused)
- "Normalmap"
- "Normalmap" + Texture (unused)
The "normalmap" is actually a cylinder map with (angle,y) components. So just adding an constant to this angle will make a light fly around the object on a fixed axis. The angle-constant is calculated using:
math_function_trying_to_calculate_an_angle_somehow(camera_position,object_positi on)+sin(time)*i_want_to_see_the_light_moving_abit_more
It is not going to please the phyics professors, but it is minimal overhead to get some dynamic looking lighting on Amiga. I suggest consulting the papers of Larusse, Kippenes et al for more on this technique.
Particles:
- Motion: turbulence field, velocity, dampening ..
- Compiled sprites
- Colored particles that can blend against eachother in 256 colors
- Export time clustering to fake more particles
The particle images are pieces of code that draw the particle. This way no extra cycles are spent on blending fully transparent areas within the particle image. Whether this gave any performance advantage is yet to be measured, however I always wanted to try it so left it in there.
Antialiasing/post processing:
Antialiased polygons are quite rare on the amiga scene. This AA method works by first detecting the silhouette of a mesh while backface culling. Edges that are shared between a backfaced culled triangle and a visible triangle make up the silhouette edge set.
As these edges are encountered during rendering, the coverage data and background of the edge is recorded before the triangle is drawn. Then this data is blended back in after the triangle has been drawn. Sometimes this leads to bleedthrough artefacts, but these are then cleverly concealed by blinking and viewers attention are trivially diverted by the MPEG artefact like "glow".
Glow:
It is not limited to glowing towards light, but also glows toward darkness. The image brightness gets sampled in 16x16 interval grid. This gets linear interpolated across the surface and sent through Tone-Loc mapping before written to the surface. This glow has the property that it looks MPEG-ish. Making people think they are watching a Video-CD thing in 1998.
FPU temporary registers:
The demo changes the FPU rounding/internal precision mode so that 32-bit values can be stored in FPU registers without getting corrupted. This way one can store addresses and integers in tmp FPU regs instead of spilling them to RAM.
Music:
The music routine is approximating an original 16-bit signal in chunks of 512 samples using normalized_8_bit_signal[i] x amiga_channel_volume[chunk]. This gives more bit resolution in low volume parts of the track making the output better than pure-8-bit and without the volume loss of the traditional 14-bit technique. If the best approximation would be an volume of 31.5, then amiga_channel_volume of channel 0 would be set to 30 and of channel 1 to 32 etc. Hopefully giving a next multiplier of 31.5.
For more about this technique consult Kippenes et al."
#7:
Madre mía la demoscene, los .mod, los trackers, ¡ay póngame ya vacuna!
Comentarios
Madre mía la demoscene, los .mod, los trackers, ¡ay póngame ya vacuna!
#7 Je je... lo he buscado y aún me alucina la música que hacía el colega Purple Motion:
#25 ¿Esta gente no hizo el Scream Tracker?
#26 Hasta donde sé y hasta donde recuerdo, Future Crew solo hacía demos para PC.
#31 La WIki dice que "Scream Tracker es un tracker. Fue creado por Psi del grupo demo finlandés Future Crew "
#31 Creo que si. Clasicazo la second reality y creo que la primera vez que los pc conseguían plantar cara seriamente al Amiga en demos. La música y la propia demo han sido versioneadas a otras plataformas (hasta Spectrum).
#7 ¿Mono de PARTY?
#33
#33 ¿Posadas anyone? ¿O Capacitor?
#10 ¿Entonces cualquiera que sepa manejar esas tablas y un visual studio puede hacerlo no?
Y ya puestos: ¿puedes explicarnos perfectamente cada plano y técnica utilizados no? porque ningún "inutil" en Pouet (sitio trufado de programadores de alto nivel) ha podido explicarlo hasta ahora. Y de lo de la técnica de sonido sin descubrir en más de 30 años (el Paula es del 85) ni hablemos
#13 puesto a seguir con el troleo...
Lo que los de pouet no saben es qué matemáticas hay detras y que valores se han usado en el array de datos pre-calculados, vamos que lo de ser precalculado no tiene por que quitar merito
la pregunta es si eso lo esta haciendo el amiga realmente o si la genialidad está en las formulas que han generado los datos que usa la demo
#22 Los mapas de luces y sombras del quake también son precalculados y los pcs de la época tenían que renderizar igualmente... una cosa es que adelantes o evites cálculos y otra cosa es que luego lo que hagas con ellos sea gratis. Una tabla de cosenos te evita tener que hacer unos cálculos muy costosos, pero igualmente te sirve para realizar otros cálculos y esta vez en tiempo real con ellos (como una transformada, por ejemplo, para decodificar audio).
#44 la cosa es si la tabla tiene cosenos o tiene ya otros valores que te ahorran aun mucha capacidad de procesamiento que utilizar cosenos, ahí si puede haber genialidad. Por ejemplo precalcular matrices o trayectorias o respuestas o cuantizar mucho. Eso no quita mérito a los programadores pues lo has tenido que precalcular con código y conocimiento de matemáticas y ejecutarlo para los valores, pero no lo calcula el amiga en si mismo en el momento de ejecución.
La demoscene tiene mucho de ilusionismo y es como ser mago, parece que hace una cosa asombrosa cuando en realidad por dentro hace otra que una vez que la comprendes dice "ostia que chorrada de truco de magia"
Y no lo digo como algo negativo, al contrario es ingenio puro, al igual que los magos. Por eso algunos no quieren revelar los trucos. Y forma parte del pique casi siempre sano que tiene la demoscene.
#46 Muy bien, te ahorra cálculos. Pero te quita espacio en memoria, que también es muy valioso. Meter todo el empaque visual que mete en esta demo no es sencillo y ha hecho compromisos en varios frentes para conseguirlo, incluso aunque no sea un amiga estándar y tenga expansión de memoria. Por otro lado, cuando tienes mucha información en memoria, por mucho precálculo que tengas, si es una cantidad ingente como puede ser el caso, pasarla de un lado a otro consume un ancho de banda precioso (necesario por ejemplo, para refrescar los pixels en pantalla a una velocidad determinada, para acceder a la música, etc. y eso por otro lado también consume unos cuantos ciclos de cpu).
La demoscene tiene mucho de ilusionismo, es cierto. Pero una cosa es que algo sea sencillo como concepto y otra que sea simple como implementación. Si la demoscene es tan impresionante no es tanto por lo bonitas que luzcan las demos o por lo vistoso que sean los efectos, sino por poder conseguir meterlos con todas las restricciones que hay en el sistema.
#47 suscribo todo
#46 #47 Algo que se suele decir cuando vemos Demos espectaculares modernas es si los cálculos que precalculan se podrían haber hecho en la misma época sin esperar años a terminar. Con la comodidad de los emuladores actuales, y la velocidad de los procesadores se pueden hacer cosas más rápido y hacer cálculos mucho más complejos que la potencia de los ordenadores antiguos no permitían
#59 No es cuestión de overclock encubierto, sino de precalcular cosas. En lugar de y=cos(x), una tabla donde ya tengamos precalculado el cos, ahorrándonos un cálculo muy costoso y simplemente accediendo una vez a memoria (o interpolando, si la función es muy costosa y la memoria muy preciosa y podemos perder algunos ciclos calculando valores intermedios si es preciso). A lo que yo comentaba era la cuestión de "hasta qué punto estás haciendo cosas en el amiga y no le estás dando al amiga todo mascado para que no tenga que hacer nada", algo así como la diferencia entre un render en tiempo real y un CGI.
#66 creo que no has entendido lo que he querido decir. Con los ordenadores actuales puedes hacer tablas precalculadas con cálculos que serían muy difíciles o incluso imposibles hacerlos en los tiempos del Amiga sin tener que esperar días, meses o años cada vez que se necesitara hacer un cambio. Eso hace que ahora puedas hacer en algunos casos efectos espectaculares que no se podrían haber hecho en esa época.
También la facilidad de depurar con un emulador, y que no se te cuelgues el ordenador entero al acceder directamente a registros gráficos del ordenador acelera bastante el tiempo de desarrollo.
Creo que esto es más cierto para ordenadores de 8 bits, que de 16, aunque incluso en la época se usaban ordenadores más potentes para precalcular operaciones costosas. Sólo digo que ahora esos cálculos pueden ser más complejos y con resultados más espectaculares
#67 No he visto el código, igual generan las tablas antes de ejecutar la demo en el mismo amiga (y no, no tienen por qué tardar tanto en esos cálculos, simplemente se hacen tablas porque necesitas ejecutar cosas en tiempo real y los precálculos ahorran tiempo). O igual generan externamente un fichero de datos que se usa en la demo (que pueden hacerlo desde un ordenador cualquier o en el propio amiga). Igualmente, esto que tú pones como un pero, lleva haciéndose desde hace la tira de años en todos los ámbitos, demos incluídas. Si todos "se dopan" igual, no veo el problema ¿no crees?, todos deberían ser capaces de hacer las mismas cosas, trabajan en igualdad de condiciones.
Te dejas unas cuantas cosas... programar en emuladores te expone a errores en los propios emuladores (y que luego no funcione en una máquina de verdad o en otro emulador diferente). Y una cosa tan tonta como no tener pantallas de tubo es una gran diferencia, porque muchos efectos se pueden realizar gracias a sincronizarte con los tiempos de trazado del rayo de luz o a las propiedades de la pantalla (muchos microordenadores tenían instrucciones para pintar el área de la pantalla... y para pintar por fuera del área de la pantalla. También dejas de poder usar o descubrir características no documentadas, que hay muchas.
#32 Lo que tu pides está contemplado en otro apartado del concurso, se llama oldskool (https://www.pouet.net/party.php?which=1550&when=2021). Y lo de la "peghatina" ya lo han hecho muchos: distros de linux, telefonos con la marca Amiga, pcs con WInUAE. Pero no es lo mismo, y no reconocerlo es trolear. Las reglas de lo que "es" (en este caso, para el concurso) las marca la organización, no nosotros.
La diferencia es que esa RAM está corriendo en el equipo original, de hecho, hay aceleradoras que permiten hasta 256MB, y ahora que se ha descubierto como usar una Pi como aceleradora, podrían hasta 4gb, pero no es el caso, han sido conservadores. El 060 tampoco es del 92, pero tanto eso como la ram son expansiones de la época (algo como decir que a tu pc le pones una soundblaster, o actualizas el 486 a pentium), asi que no es como para decir que "eso no es un Amiga"
#35 he leído un amiga de 1992, había 32 megas en esos años? A nivel comercial
#38 Sí.
#38 En 199X (no recuerdo el año exacto) tuve una aceleradora Blizzard powerpc para el A1200 con 64+32 megas de RAM. Antes de eso tenía una Blizzard 1260 con kit scsi en el que metía dos módulos de 32 megas. No recuerdo la fecha exacta porque la memoria me folla pero si no era en 1992 rondaba esa fecha
#35 Hombre, el 486 podías ponerle un Pentium Overdrive, no dejaba de ser un 486 con instrucciones del procesador superior a fin de cuentas.
Aquí tengo uno en mi colección personal de procesadores.
#52 Sí. Sin mirar demasiado (es una que tuve):
http://amiga.resource.cx/exp/blizzard1230mk1
Acepta hasta 64MB de RAM, con dos SIMMs de 32MB
https://en.wikipedia.org/wiki/Amiga_3000
#32 En AliExpress hay un adaptador de SSD a IDE44, que es el conector estándar de un A1200. ¿Conectarle un SSD lo hace "menos" Amiga? Al fin y al cabo, el cuello de botella de velocidad está en el IDE de la máquina, en ese aspecto, la velocidad, le vas a sacar poco provecho al SSD, pero se puede hacer.
Y los Amiga, del primero al último, han soportado SCSI desde el principio, con la expansión adecuada (para eso están los puertos de expansión).
No quiero ser muy cabrón, pero esto parece microblogging de libro (la entradilla no aparece ni resume nada del envío) y, además, erróneo. La demo es impresionante, pero esto no es raytracing, ni es posible conseguirlo en tiempo real en un amiga.
#19 No he encontrado links con explicación del video, que me parece absolutamente necesaria para los no especializados en el tema. Te aseguro que no tenía ni la menor gana de currarme la descripción, que me ha llevado un buen rato. Me disculpo por el clickbait del título: inicialmente había puesto "efectos de raytracing" pero me pareció demasiado enrevesado y lo cambié.
De todas formas no es mentira: se trata de "fakear" raytracing, parecido a lo que hacen las tarjetas para tiempo real aún hoy en día, porque simular raytracing "a pecho" no es posible ni una 3090, de lo que se trata es de que tenga el aspecto.
#24 Hombre, no sé qué decirte, pero incluso eso lo veo discutible. No veo ninguno de los típicos efectos logrados mediante raytracing (reflejos, sombras, etc). Lo que sí me ha llamado la atención es un efecto de "bump mapping" o "normal mapping" donde imagino que habrá hecho falta mucha magia negra, pero este efecto no se logra mediante raytracing tampoco. No he votado negativo, el envío me gusta, solo considero que la entradilla no es muy honesta.
#24 pero es que no es raytracing, es raster como el que llevamos usando 30 años en todos los videojuegos, como el que te da el mismo OpenGL. Que es increible para el hardware, sin duda, pero que de raytracer tiene cero.
#41 Raytracer como tal no, es cierto, pero se trata de reflejar el resultado. ¿Como le llamo si no? ¿cuanta gente del público general sabe lo que es un raycaster? solo intentaba poner un título descriptivo
#43 tampoco es un raycaster, es un render de modelo 3D o raster.
Como digo siempre AMIGA RUUUULEEEEES!!!
#68 INTEL OUTSIDE!
#69 Vale, se acabó. Te he puesto como "amigo" en menéame. Hay un un grupo de Telegram en el que somos 161 amigueros de España ¿qué haces que no estás ahí?
#71 ¿Que no lo concocía? pasa link y encantado
Vaya, impresionante. Mis 10! (No estaría de mas algo de explicación técnica)
#1 Concuerdo, pero no quería abrumar al personal con demasiadas "frikadas". Aquí tienes algo de parte de uno de sus autores
https://www.pouet.net/prod.php?which=88640#c920727
Eso sí: ya te aviso que es MUY técnico, para entenderlo necesitarás releerlo al menos un par de veces
"Some rant about the code in here.
The zoomer:
It is an infinite zoomer inspired by TBL's spectacular zoomer in Magia. Large images (up to 8192x8192) with lots of detail get converted to polar images. The bigger the polar image, the further we can zoom in. The neat thing about this conversion is that only the details that are important while zooming towards a single point are kept, while the rest of the details get discarded. The original filesize of some of these images maybe 200 MB or so.
The polar image gets mapped on your typical tunnel table of U,R coordinates. Instead of scrolling the r-coordinate, as you would in a tunnel, it is scaled by a zoom factor. To avoid choppy movement, there is some subtexel precision on the radius and angle coordinates allowing very smooth movement. Without the subtexel precision the slow movement is impossible. The LUT itself was made piecewise linear to avoid reading so much table data from RAM. The effect is embedded in the c2p to save further bandwidth.
At first we tried automatically stitching together multiple smaller images, but the seams between the images always turned out blurred. Painting these images is also a huge amount of work. I seem to remember TBL saying Louie spent a lot of effort on that Magia zoomer and I'm really impressed at how long it zooms and its seamless transitions.
In the end we came up with the idea of using gigantic fractal images and we called upon Evilryu to help out with coding these in Shadertoy. He tried several kind of fractal formulas and color combinations. The most detailed ones caused too much aliasing and in the end the techno world you see in the demo was chosen. The images are blurred before conversion to polar to reduce some aliasing. Since many images were made I'm tempted to release another demo just featuring all of these variations. Lots of cool stuff.
While this was going on Farfar modeled the mask object which fit very well inside this technomaze imagery.
Skybox:
6 fractal images rendered with 90 degrees field of view from a single point mapped on a cube.
The 3d-engine/exporter:
I really wish it was a movieplayer as suspected above as that would be more impressive I suspect the reason it looks like a movie is because the "glow" adds some mpeg like artefacts.
The exporter is taking a lightly extended GLTF format. It has got a few custom properties exported from Blender to describe particle systems. One very convenient thing about the exporter is that it works on a 24-bit original scene and collects all textures, overlays, shadetables into a common palette that everything gets remapped to. The palette generator tries to make sure there are colors for transparent effects such as particles and glow. Without this automation it is very painful to manage the palette for Amiga 3d scenes.
Animation:
- Node animation and hierarchy
- Shape morphs
Polyfillers:
- Flat
- Affine texture
- Perspective correct texturemapping (unused)
- "Normalmap"
- "Normalmap" + Texture (unused)
The "normalmap" is actually a cylinder map with (angle,y) components. So just adding an constant to this angle will make a light fly around the object on a fixed axis. The angle-constant is calculated using:
math_function_trying_to_calculate_an_angle_somehow(camera_position,object_positi on)+sin(time)*i_want_to_see_the_light_moving_abit_more
It is not going to please the phyics professors, but it is minimal overhead to get some dynamic looking lighting on Amiga. I suggest consulting the papers of Larusse, Kippenes et al for more on this technique.
Particles:
- Motion: turbulence field, velocity, dampening ..
- Compiled sprites
- Colored particles that can blend against eachother in 256 colors
- Export time clustering to fake more particles
The particle images are pieces of code that draw the particle. This way no extra cycles are spent on blending fully transparent areas within the particle image. Whether this gave any performance advantage is yet to be measured, however I always wanted to try it so left it in there.
Antialiasing/post processing:
Antialiased polygons are quite rare on the amiga scene. This AA method works by first detecting the silhouette of a mesh while backface culling. Edges that are shared between a backfaced culled triangle and a visible triangle make up the silhouette edge set.
As these edges are encountered during rendering, the coverage data and background of the edge is recorded before the triangle is drawn. Then this data is blended back in after the triangle has been drawn. Sometimes this leads to bleedthrough artefacts, but these are then cleverly concealed by blinking and viewers attention are trivially diverted by the MPEG artefact like "glow".
Glow:
It is not limited to glowing towards light, but also glows toward darkness. The image brightness gets sampled in 16x16 interval grid. This gets linear interpolated across the surface and sent through Tone-Loc mapping before written to the surface. This glow has the property that it looks MPEG-ish. Making people think they are watching a Video-CD thing in 1998.
FPU temporary registers:
The demo changes the FPU rounding/internal precision mode so that 32-bit values can be stored in FPU registers without getting corrupted. This way one can store addresses and integers in tmp FPU regs instead of spilling them to RAM.
Music:
The music routine is approximating an original 16-bit signal in chunks of 512 samples using normalized_8_bit_signal[i] x amiga_channel_volume[chunk]. This gives more bit resolution in low volume parts of the track making the output better than pure-8-bit and without the volume loss of the traditional 14-bit technique. If the best approximation would be an volume of 31.5, then amiga_channel_volume of channel 0 would be set to 30 and of channel 1 to 32 etc. Hopefully giving a next multiplier of 31.5.
For more about this technique consult Kippenes et al."
#4 vamos que se hace con magia
#5. Acabo de percatarme; la palabra 'magia' contiene las mismas letras con las que se forma la palabra "amiga".
(CC #4 #0)
#8 OH MY GOD
#8 Es una vieja expresion recurrente en el mundo amiguero, hay una demo que lo usa
#4 Gracias! Ahora es incluso más impresionante.
#1 demoscene, tecnica que no se ha podido identificar = tabla de valores pre-calculados
#29 No, pero tampoco discos duros SSD y configuraron un interface hace unos años para poder instalarle una memoria SSD....
La cosa es que juego de instrucciones y microprocesador tiene, eso es un amiga.
#30 eso no es un amiga, un amiga sería toda la arquitectura, para eso que le cambien todo y le pongan una pegatina
#15 Aunque cueste creerlo, es lo que tiene. De ahi que creo que merezca portada.
#17 Jejeje, hay muchos usuarios de Amiga que no tienen ni eso
#52 Buscando un poco más:
http://amiga.resource.cx/exp/proram3000
De 1991, el A1200 todavía no existía.
#29 Cualquiera que tuviera expansión de memoria. Mi aceleradora del Amiga 1200 admite hasta 256MB de RAM.
#51 repito 32 megas en 1992? Hablamos de memoria ram
Recuerdo mis tiempos de estudiante, que una revista traía el POV-Ray y venía con algunos ejemplos. Quise renderizar uno que generaba una imagen de 1024x768 píxles con mi 386 SX. Después de 2 días con el ordenador encendido, lo dejé por imposible.
#62 Yo con un 486 sin copro dejaba a las noches de un día para otro y probablemente a resolución 320x200. Para hacer las pruebas recuerdo hacerlas a tamaños minúsculos que "sólo" tardaban unos minutos
#64 Típicas historias de finales de los 80, principios de los 90 . Tengo una más recoambolesca: En Amiga, en los 80, cuando los discos duros costaban un riñon, conocí gente que renderizaba A DISKETTES. y encima tenía que ir intercambiando entre el disco del programa 3D y el de guardar el render
#70 La hostia. Todavía recuerdo los PCs esos XT, o como fueran, con 2 disketeras de 5 1/4 en las que en una se ponía el sistema operativo y en la otra el Wordstar. Y en el MSX recuerdo a mi padre guardar en cinta los datos del programa de contabilidad casera. Prácticamente era más fácil hacerlo a boli pero lo que molaba teclearlo en el ordenador
Abstenerse epilépticos
Un vídeo impresionante, grande el Amiga. El Amiga 500 es una de las máquinas que más cariño le tengo. Si Commodore habiese hecho mejor las cosas, igual podría haber sido la Apple de hoy en día.
#18 s/habiese/hubiese/
#20 No me he dado cuenta al escribir
#18 Justo leí sobre eso ayer: Commodore llegó a ganar 1 BILLÓN DE DOLARES, y consiguieron fundírselo en un apr de años. Es muy dificil conseguir cargarse la empresa a la velocidad que lo consiguieron
Por cierto: el título tiene miga. No conocía ese efecto, al menos no con ese nombre, pero da una explicación y dimensión a la demo.
en los antiguos juegos en d.o.s a veces los grupos de la scene warez colaban una de esas cosas. es algo que me hubiese agradado que me gustara pero no hubo caso.
#0 El primer Amiga, el Amiga 1000, tenia una paleta de 4096 colores. Eso de chip gráfico de 256 colores me sonaba muy raro.
Al final del video dice que la CPU es una 68060, que unicamente se uso en el Amiga 4000T del 1996:
24-bit color palette (16.8 Million colors)
Up to 256 on-screen colors in indexed mode
262,144 on-screen colors in HAM-8 mode
#2 Te explico: Esta hecha para la arquitectura AGA, que es la sucesora de la original OCS que llevaba tanto el 100 como el 500. La AGA tiene como modo "normal" 256 colores, que además es el usado en gran parte de la demo. Además luego tiene le modo HAM8 que efectivamente puede mostrar 24 bits (aunque se suela decir 18 bits porque los inútiles del dep. de marketing de de Commodore no se habían dado cuenta de que el límite teórico que presuponían en realidad no era tal), pero esos colores se consiguen aplicando una especie de "compresión" de color (parecida a la de Mpeg) que penaliza el rendimiento, por lo que solo la usan puntualmente.
Aunque la primera aceleradora montada sería aproximadamente del 96, el sistema salió en 1992 (tanto el 1200 como el 4000) y el procesador en el 94, pero no es determinante para ejecutarla porque también se puede correr en un 68040 de 1990, solo que irá un poco más lenta.
#2 32 megas es algo que patina ahí
#6 What? he estado buscando y no he podido confirmarlo, el tamaño de la demo es de 32Mb pero aún es posible que pueda ejecutarse con solo 16. ¿Qué es lo que te extraña?
#12 32 MB de RAM
#6 Es un amiga....
He visto burradas rulando en un amiga con 2Mb de Ram....
#21 pero que amiga del 1992 tenía 32 megas ?
#2 Hombre, que el sistema pueda hacer eso no implica que sea lo más práctico para todo. ¿Sabías que (mediante trucos) un msx puede mostrar imágenes de más de 100 colores (cuando sólo puede usar 16 colores normalmente)?
¿Por qué no se usa esto siempre, aparte de en imágenes fijas o en efectos simples? pues porque tiene otras implicaciones, como un excesivo consumo de memoria, tener que calcular timings muy preciosos a la hora de generar las imágenes, etc.
Aquí pasa lo mismo, probablemente usar esos modos de muchos colores se coma toda la memoria y sea muy costoso en cuanto a ciclos y salvo cosas muy específicas no te sea adecuado.
#45 Yo soy más de Spectrum :
Engine nirvana unicamente para 128K
#60 Si vas a poner algo pon al menos una demo, que con el modo gigascreen se han hecho cosas preciosas
#2 "la CPU es una 68060, que unicamente se uso en el Amiga 4000T del 1996"
Para los AMIGA 1200 hay aceleradoras con 060, yo mismo tengo una Blizzard 1260 (http://amiga.resource.cx/exp/blizzard1260).
Técnicamente es una sobrada... pero como demo me parece aburrida; lenta, sin mucho ritmo, las transciones son puros fades...
Siempre he preferido las demos que no son "lo máximo" en técnica, pero con mejor disenyo y sincro con la música. Pero bueno, cuestión de gustos.
#34 Hombre: es muy rollo "new Age" pero a partir del 2:20 es cuando pilla ritmo, y una de las cosas que mas se le alaban es, como otras grandes demos, que integra todos los efectos en una historia y están un poco al servicio de esta, y en este caso además que te de la sensación del "Martini effect" (que no es pasarse de Martinis, aunque se parezca)