Portada
mis comunidades
otras secciones
#9:
#6 En el caso de Saturn, añadir la segunda CPU fue una decisión de última hora en respuesta a la playstation de Sony, para poder competir con su potente apartado 3D. El caso es que se complicaron la vida porque además compartían bus, asi que aunque aprovecharas muy bien programando multiproceso (cosa que antes, sin kits de desarrollo adecuados y al más bajo nivel no era algo sencillo, que se lo digan por ejemplo a la ps2), luego no ibas a tener ancho de banda para aprovechar esa potencia.
Pero es que aparte de estos, tenían un procesador específico (el saturn control unit o SCU) con módulos para hacer DMA (acceso directo a memoria, con lo que puedes acceder a la misma liberando a la CPU) y un DSP (procesador de señales, básicamente un procesador vectorial para acelerar cálculos matriciales y demás para el 3D), que en principio está bien, pero que tenía más limitaciones de las que hubiera sido deseable.
Pero es que a parte de estos, tenían dos procesadores para el display gráfico (VDP1 y 2) y cada uno estaba especializado en cosas distintas: VDP1 dibuja sprites y hace transformaciones geométricas simples sobre cuadrados como rotaciones y escalado (con antialiasing), puede aplicar sombreado sobre vectores (hace interpolación entre los colores de cada uno de los vértices del plano que define el sprite) y transparencia entre dos mapas de bits no opacos. Pero hablamos de planos "pequeños", para sprites, no es algo que pueda aplicarse al 3D en todo el escenario; es más una muestra de la potencia 2D de la máquina y se usaba tanto para los propios sprites como para el postprocesado porque dibujaba sobre el framebuffer. El VDP2 está enfocado al manejo de grandes superficies como fondos, también con capacidades de rotación y escala, pero dibuja sobre la pantalla, no sobre framebuffer, funcionaba como un motor de tiles o embaldosados clásico, en parte, uno de esos tiles era el propio framebuffer del VDP1, era capaz de componer planos (hasta cuatro planos 2D y uno 3D o dos planos 3D). Al tomar en consideración la profundidad a la hora de hacer rotaciones, el VDP2 era capaz de hacer corrección de perspectiva, necesaria para el mapeado de texturas en 3D. Otra cosa que podía hacer VDP2 era "traducir" los colores de paleta de sprites del VDP1 al color real de 24 bits que manejaba la máquina cuando se hacía el fundido de planos. Al final, el VDP2 era el encargado de dibujado 3D, con superposición de cosas del VDP1, apoyado por las dos CPUs SHA-2 y acelerado por las capacidades vectoriales del SCU, que entre los tres añadían elementos gráficos.
Para más inri, los dos megas de memoria tampoco eran lineales ni homogeneos. Un mega era de memoria bastante rápida y otro de una memoria memoria lenta, que tampoco ayudaba mucho a programar cosas a poco que se quisieran aprovechar todos los recursos del sistema, y el SCU sólo podía acceder al primero (que tiene sentido que tire de la memoria más rápida, pero te restringe la cantidad de texturas, modelos o recursos gráficos a los que puedes acceder sin tener que hacer copias de una memoria a otra). Luego ya vimos que en el VDP introducían una cosa muy buena que era un framebuffer (no dibujaba directamente a la pantalla, sino a un espacio de memoria designado y cuando ya estaba todo dibujado, lo presentaba en pantalla), que permitía todo tipo de efectos de postprocesado por software, pero que también implicaba que "perdías" parte de la memoria en ese buffer "invisible" (y más si lo hacías en alta resolución, que requiere más memoria).
Como vemos, la gestión de recursos de la máquina de SEGA para aprovechar sus características y potencia era una auténtica locura, lo normal era que a los juegos les costara hacerlo.
Pero es que aparte de estos, tenían un procesador específico (el saturn control unit o SCU) con módulos para hacer DMA (acceso directo a memoria, con lo que puedes acceder a la misma liberando a la CPU) y un DSP (procesador de señales, básicamente un procesador vectorial para acelerar cálculos matriciales y demás para el 3D), que en principio está bien, pero que tenía más limitaciones de las que hubiera sido deseable.
Pero es que a parte de estos, tenían dos procesadores para el display gráfico (VDP1 y 2) y cada uno estaba especializado en cosas distintas: VDP1 dibuja sprites y hace transformaciones geométricas simples sobre cuadrados como rotaciones y escalado (con antialiasing), puede aplicar sombreado sobre vectores (hace interpolación entre los colores de cada uno de los vértices del plano que define el sprite) y transparencia entre dos mapas de bits no opacos. Pero hablamos de planos "pequeños", para sprites, no es algo que pueda aplicarse al 3D en todo el escenario; es más una muestra de la potencia 2D de la máquina y se usaba tanto para los propios sprites como para el postprocesado porque dibujaba sobre el framebuffer. El VDP2 está enfocado al manejo de grandes superficies como fondos, también con capacidades de rotación y escala, pero dibuja sobre la pantalla, no sobre framebuffer, funcionaba como un motor de tiles o embaldosados clásico, en parte, uno de esos tiles era el propio framebuffer del VDP1, era capaz de componer planos (hasta cuatro planos 2D y uno 3D o dos planos 3D). Al tomar en consideración la profundidad a la hora de hacer rotaciones, el VDP2 era capaz de hacer corrección de perspectiva, necesaria para el mapeado de texturas en 3D. Otra cosa que podía hacer VDP2 era "traducir" los colores de paleta de sprites del VDP1 al color real de 24 bits que manejaba la máquina cuando se hacía el fundido de planos. Al final, el VDP2 era el encargado de dibujado 3D, con superposición de cosas del VDP1, apoyado por las dos CPUs SHA-2 y acelerado por las capacidades vectoriales del SCU, que entre los tres añadían elementos gráficos.
Para más inri, los dos megas de memoria tampoco eran lineales ni homogeneos. Un mega era de memoria bastante rápida y otro de una memoria memoria lenta, que tampoco ayudaba mucho a programar cosas a poco que se quisieran aprovechar todos los recursos del sistema, y el SCU sólo podía acceder al primero (que tiene sentido que tire de la memoria más rápida, pero te restringe la cantidad de texturas, modelos o recursos gráficos a los que puedes acceder sin tener que hacer copias de una memoria a otra). Luego ya vimos que en el VDP introducían una cosa muy buena que era un framebuffer (no dibujaba directamente a la pantalla, sino a un espacio de memoria designado y cuando ya estaba todo dibujado, lo presentaba en pantalla), que permitía todo tipo de efectos de postprocesado por software, pero que también implicaba que "perdías" parte de la memoria en ese buffer "invisible" (y más si lo hacías en alta resolución, que requiere más memoria).
Como vemos, la gestión de recursos de la máquina de SEGA para aprovechar sus características y potencia era una auténtica locura, lo normal era que a los juegos les costara hacerlo.
#2:
Al que diseñó el mando habría que explicarle un par de cosas, pero al que aprobó el diseño habría que expulsarlo del sector de por vida. Menudo horror!
Comentarios
Al que diseñó el mando habría que explicarle un par de cosas, pero al que aprobó el diseño habría que expulsarlo del sector de por vida. Menudo horror!
#2 Siendo además que Atari ya había hecho historia con su Joystick clásico para la 2600:
the Atari 2600 joystick has become an iconic symbol for the early era of video gaming, and is even recognizable by many gamers who never used them.
http://www.thealmightyguru.com/Wiki/index.php?title=Atari_2600_Joystick
En Atari a la altura de la Jaguar tomaron decisiones demasiado arriesgadas para volver a coger la iniciativa pero les salió mal. Tal vez una pena, porque como dicen el artículo quizá es una consola que mereció mejor suerte.
#2 Era parecido a los mandos de consolas Atari anteriores, con teclado numérico y pensados para ponerles cartulinas explicativas encima.
Quien sabe porqué, me he levantado hoy acordándome de esta consola. La probé al poco de su lanzamiento en una feria y me parceió impresionante, pero en el artículo cuentan muy bien la historia de su fracaso.
#1 "Quien sabe porqué, me he levantado hoy acordándome de esta consola..." Yo soy un abuelo cebolleta (generación finales de los 70) que se pega el día escuchando podcast retro como RM30, RetroHobby30, Arqueología Nintendo, Meripodcast retro, etc
Yo la Jaguar la vi por vez primera en El Corte Inglés si no recuerdo mal, creo que era uno de los principales distribuidores y me gustaba mucho de diseño. Yo fíjate que desde el anuncio, y era un crío, ya vaticinaba el desastre, en su historia reciente habían hecho el microordenador Atari ST, que era un buen bicho, pero cuando al poco salió el Amiga 500 se lo comía en todo, salvo en una cosa y que era el motivo por el que varios grupos musicales lo usaban antes que el Amiga que tenía mejor chip de sonido, que era que venía de serie con interfaz MIDI.
En portátil salió la LYNX, que impresionaba mucho pero era muy cara (30/35.000 pts), grande, devorapilas y con pocos juegos, luego salió una revisión pero ya era tarde.
Previamente habían hecho un "remake" de la Atari 2600, una castaña comparada con la NES o la Master System que se vendían entonces.
En fin, la historia de Atari es apasionante, pero creo que de haber sido algo menos codiciosos, les habría ido mejor.
#14 Lo más significativo de Atari es su primera quiebra por vengarse de Nintendo y no aceptar la oferta de convertirse en distribuidor de la NES en EEUU y por ende a todo Occidente. Eso fue su primera muerte. Así la NES, que había cosechado tanto éxito en Japón como Famicom, sería comerzializada directamente por Nintendo of America. Y Atari seguramente no rechazó sólo por venganza, sino también por miedo ante la nueva amenaza en un mercado, el de las sobremesa domésticas, que estaba en auge y donde Atari había estado dominando los primeros años de explosión de la industria.
La historia de venganza viene de unos pocos años antes, con la entrada en occidente (primero EEUU) de la arcade Donkey Kong. Tras el gran éxito que tuvo el juego, Nintendo quería introducirlo al mercado doméstico pero no tenía una consola propia para hacerlo, por lo que decidieron ofrecerle la expclusiva a Coleco en vez de a Atari, que para Atari fue un golpe bajo que dolió muchísimo, pues Donkey Kong era un fenómeno de masas en las recreativas y era un potencial vendeconsolas, de ahí los juicios por las semejanzas de Donkey Kong con King Kong (que Nintendo ganó sentando jurisprudencia de que la franquicia King Kong era de uso libre), y luego salieran versiones marca blanca del juego Donkey Kong. Pero el daño estaba hecho y Atari, después de estar a punto de aceptar el trato de distribuir la NES se echó atrás a última hora, en lo que se conoce como la venganza que enterró a Atari
#14 Creo que va a ser lo que dices, como escucho tantos programas de videojuegos, consolas, ordenatas y mundillo retro, se me mete Atari en el subconsciente
Gracias por tus recuerdos, yo "en vivo" no recuerdo haber visto ninguna LYNX, pero me llamaba la atención cuando salía (poco) por Micromanía
#12 Ningún programa de modelado, animación o diseño en 3D prima los cuadrados sobre los triángulos. Más que nada porque todo el hardware (y por supuesto el software, algoritmos de ordenación, de subdivisión de espacios tridimensionales, de cálculo de trazados, de dibujado, de...) que hay en la actualidad funciona con triángulos... es más eficiente y flexible.
No veo por qué la industria cinematográfica deba ser diferente cuando todo lo demás lo hace de una manera, ni sería viable en cuanto a costes, ni aporta ninguna ventaja significativa. Al fin y al cabo, un cuadrado son dos triángulos...
#13 Estoy hablando a nivel de técnica del modelador, no a nivel de programa de modelado. Independientemente de como trabaje el software o hardware, son preferibles los quads a los triángulos.
https://www.quora.com/Which-one-is-better-for-3D-modeling-Quads-or-Tris
#19 En modelado, si, se usan mallas de cuadrados de cara al artista, porque Internamente todo es procesado en base a triángulos. Y recalco esto porque es de lo que estábamos hablando, de cómo el hardware y el software gestionan la geometría. Si, antes en hardware habían tarjetas aceleradoras y engines que funcionaban a base de cuadrados. Y si, Tomb Raider se modeló usando cuadrados quizá porque artísticamente partieran de un software de modelado que de cara al artista usara cuadrados, pero es que internamente se iba a ejecutar en un engine diseñado para manejar geometrías como cuadrados porque el hardware en el que se iba a ejecutar tomaba las geometrías como cuadrados. En parte por eficiencia, porque definir un cuadrado usando cuadrados requiere 4 vértices, si definimos 2 triángulos requiere 6...
#10 Fíjate cómo es la cosa la próxima vez que juegues con él: el VDP1 (o motor de sprites) es el que dibuja los luchadores del virtua fighter, mientras que el VDP2 (o motor de fondos y planos) hace lo propio con los fondos y escenarios (se nota mucho cómo son dibujados de manera diferente, cómo unos son planos y apenas sombreados, cómo otros se dibujan un poco como bloques ensamblados, si tienen sombreado, etc. todo no sólo porque se usen dos chips diferentes para cada cosa, sino por las posibilidades y potencia de cada uno).
Otra cosa notable es que la saturn dibuja polígonos cuadrados y no triángulos. Y esto es así porque estaba pensada para renderizar sprites y todo tipo de planos. Como nota curiosa, tomb raider empezó desarrollándose en Saturn... ¿adivina cuántos triángulos tienen sus modelos?
https://64.media.tumblr.com/4ce53c86c5c3df62bee8ba1cf14dbffe/1c10270d0002a7d2-31/s540x810/169b68484dfabcd316703582d11b28e15bee194f.jpg
#11 en realidad en la industria cinematográfica prima el modelado con cuadrados
Da túnel carpiano sólo de ver ese mando.
Esta no la probé, pero la Atari Lynx sí cuando tenía unos 8-9 años y recuerdo que era como coger un ladrillo con una pantallita diminuta en la que apenas podías distinguir lo que sucedía en el juego. Luego probabas la Game Boy y caías rendido ante su pantalla "enorme" monocromática y que podías agarrar fácilmente con tus manitas diminutas sin temor a provocarte una hernia cervical
#8 doy fe. Un hamijo "pijo" la tenía (junto con un Atari ST y montones de juegos que intercambiaba por correo de un "club Atari", la leche....) y vaya decepción me llevé... ladrillazo con pantalla enana y resolución ínfima.... encima tenía un cajón lleno de pilas ahí al tun-tun que iba rotando de la velocidad a la que los gastaba.... pero estaba encantado oye, decía que la Gameboy era una mierda por ser monocroma...
Yo la tuve, sólo tenía dos juegos; Rayman y Alien Vs Predator.
Era super disfrutón el predator, guardo muy buenos recuerdos de esa consola
Es una máquina que me pilló de demasiado jovencillo y no tuve la oportunidad ni de probar porque nadie de mi entorno la llegó a tener. En un entorno en el que estaba copado por las Mega Drive fui el rarito del grupo que acabó teniendo una Super Nintendo imaginad una Jaguar.
Si que recuerdo de esa época todas las marcas dando sus palos de ciego con sus respectivas máquinas: Asocio siempre Jaguar con 3DO o el CD-I, fueron intentos que no supieron encontrar su camino, que estaban ofreciendo algo demasiado nuevo en pañales comparado con lo que había en el mercado 16 bits y que cuando llegaron las máquinas de siguiente generación de Nintendo / Sega y Sony estaban a años luz de ellas. Esas máquinas se quedaron un poco en tierra de nadie.
Hace tiempo investigué un poco sobre el tema, por los emuladores que han ido saliendo. Tenía un hardware complicado para la época, con dos GPUs que hacían de CPUs y una 68000 para otras tareas. Entre esto y la hegemonía de Sega y Nintendo no consiguieron interesar a muchos desarrolladores.
Y algunos directamente programaban para la 68000, porque ya la conocían de otras máquinas, desaprovechando la potencia de la máquina.
Así que quitando el AvP y algún otro los juegos son horribles.
Dios mio el mando es horrible, me recuerda a aquellos mandos de algunas clónicas de la primera magnavox.
Aquel intermedio generacional fue apasionante seguirlo desde las revistas, con tantas máquinas que aspiraban a llevarse el gato al agua con los nuevos juegos poligonales que iban a ser el futuro. Atari, SEGA, Sony, Panasonic, Apple, Nintendo, Casio, Commodore, salieron un porrón de casas conocidas que querian un cacho.
¿Tenían las consolas Atari alguna funcionalidad de teléfono incorporada?
Porque de lo contrario, no entiendo ese horror de mandos en el que no paraban de insistir.
Una pena. La Sega Saturn tambien tuvo fama de ser un engorro para programar por tener 2 CPUs, aunque fueron mejorando los dev kits para que los programadores no lo tuvieran tan difícil.
Creo que el mando tuvo mucho que ver en el fracaso para que la gente no comprara la consola, es un horror.
#6 En el caso de Saturn, añadir la segunda CPU fue una decisión de última hora en respuesta a la playstation de Sony, para poder competir con su potente apartado 3D. El caso es que se complicaron la vida porque además compartían bus, asi que aunque aprovecharas muy bien programando multiproceso (cosa que antes, sin kits de desarrollo adecuados y al más bajo nivel no era algo sencillo, que se lo digan por ejemplo a la ps2), luego no ibas a tener ancho de banda para aprovechar esa potencia.
Pero es que aparte de estos, tenían un procesador específico (el saturn control unit o SCU) con módulos para hacer DMA (acceso directo a memoria, con lo que puedes acceder a la misma liberando a la CPU) y un DSP (procesador de señales, básicamente un procesador vectorial para acelerar cálculos matriciales y demás para el 3D), que en principio está bien, pero que tenía más limitaciones de las que hubiera sido deseable.
Pero es que a parte de estos, tenían dos procesadores para el display gráfico (VDP1 y 2) y cada uno estaba especializado en cosas distintas: VDP1 dibuja sprites y hace transformaciones geométricas simples sobre cuadrados como rotaciones y escalado (con antialiasing), puede aplicar sombreado sobre vectores (hace interpolación entre los colores de cada uno de los vértices del plano que define el sprite) y transparencia entre dos mapas de bits no opacos. Pero hablamos de planos "pequeños", para sprites, no es algo que pueda aplicarse al 3D en todo el escenario; es más una muestra de la potencia 2D de la máquina y se usaba tanto para los propios sprites como para el postprocesado porque dibujaba sobre el framebuffer. El VDP2 está enfocado al manejo de grandes superficies como fondos, también con capacidades de rotación y escala, pero dibuja sobre la pantalla, no sobre framebuffer, funcionaba como un motor de tiles o embaldosados clásico, en parte, uno de esos tiles era el propio framebuffer del VDP1, era capaz de componer planos (hasta cuatro planos 2D y uno 3D o dos planos 3D). Al tomar en consideración la profundidad a la hora de hacer rotaciones, el VDP2 era capaz de hacer corrección de perspectiva, necesaria para el mapeado de texturas en 3D. Otra cosa que podía hacer VDP2 era "traducir" los colores de paleta de sprites del VDP1 al color real de 24 bits que manejaba la máquina cuando se hacía el fundido de planos. Al final, el VDP2 era el encargado de dibujado 3D, con superposición de cosas del VDP1, apoyado por las dos CPUs SHA-2 y acelerado por las capacidades vectoriales del SCU, que entre los tres añadían elementos gráficos.
Para más inri, los dos megas de memoria tampoco eran lineales ni homogeneos. Un mega era de memoria bastante rápida y otro de una memoria memoria lenta, que tampoco ayudaba mucho a programar cosas a poco que se quisieran aprovechar todos los recursos del sistema, y el SCU sólo podía acceder al primero (que tiene sentido que tire de la memoria más rápida, pero te restringe la cantidad de texturas, modelos o recursos gráficos a los que puedes acceder sin tener que hacer copias de una memoria a otra). Luego ya vimos que en el VDP introducían una cosa muy buena que era un framebuffer (no dibujaba directamente a la pantalla, sino a un espacio de memoria designado y cuando ya estaba todo dibujado, lo presentaba en pantalla), que permitía todo tipo de efectos de postprocesado por software, pero que también implicaba que "perdías" parte de la memoria en ese buffer "invisible" (y más si lo hacías en alta resolución, que requiere más memoria).
Como vemos, la gestión de recursos de la máquina de SEGA para aprovechar sus características y potencia era una auténtica locura, lo normal era que a los juegos les costara hacerlo.
#9 Gracias por la explicación, ha sido muy instructivo.
#9 Joder... he disfrutado más leyendo tu comentario que leyendo el artículo... por cosas como esta sigo entrando en meneame.