El techo técnico de cada sistema (8 y 16 bit)

Calculinho escribió:Según leí aquí en EOL de NES lo más bruto sería un Batman concretamente esta fase:

https://youtu.be/p1Ivxnpbd5Y?t=13m21s

Parece un juego de Mega Drive o Super Nes. Incluso se cepilla a varios juegos de 16 bits gráficamente hablando.
Viendo esto, es una pena que no se vieran más juegazos así en Nes.

Y en PSX, Saturn y N64 hay alguno que exprimiera al máximo la consola. Se dicen que Metal Gear Solid en psx y puedo creermelo porque cuando salió ya hacia 5 años que se programaba en psx y se conocía el sistema, pero no me creo que Ocarina fuera lo máximo de N64 saliendo dos años después, y RE2 es un ejemplo de como exprimir al máximo el cartucho y su limitado espacio, pero no creo que a nivel hardware fuera tampoco lo máximo no? De Saturn desconozco

amiga es que tiene titulos impresionantes ,para mi lo mas bruto de amiga es lionheart
https://www.youtube.com/watch?v=BoiHk_3siYg una delicia
para mi de psx :metal gear solid,vagrant story y soul reaver
de nintendo 64:jet force gemini,conker y turok 2

titorino escribió:amiga es que tiene titulos impresionantes ,para mi lo mas bruto de amiga es lionheart
https://www.youtube.com/watch?v=BoiHk_3siYg una delicia
para mi de psx :metal gear solid,vagrant story y soul reaver
de nintendo 64:jet force gemini,conker y turok 2

El Lionheart para mi jugablemente es un poco patatero, técnicamente muy bestia en planos y colorido, pero con 4 bichos pequeños en pantalla de vez en cuando.

Calculinho escribió:Según leí aquí en EOL de NES lo más bruto sería un Batman concretamente esta fase:

https://youtu.be/p1Ivxnpbd5Y?t=13m21s

Mi voto en NES va para el Recca:

https://youtu.be/EE5URFvZfHo

Y en Pc Engine para el Sapphire

A todas estas...NeoGeo se considera 16 bits no?

Si es así, me gustaría comentar el Last Blade 2, me parece un titulo soberbio.

Pongo algunos...

NES - Sword Master (scroll "paralax" monodireccional pero de varias capas y voces digitalizadas TODO EL JUEGO)

-Super Spy Hunter (decenas de sprites en pantalla a velocidades vertiginosas, efectos graficos a rolete y sonido espectacular)

MS - MK2 (Sprites digitalizados enormes y voz digitalizada de Figth!)

- Desert Speedtrap (Scroll paralax en 8 direcciones de varias capas TODO EL JUEGO y sonidos digitalizados)

SNES - DKC Country (efectos graficos a rolete, transparencias, deformaciones y musicas increibles)

- Batman y Robin (efectos graficos increibles y banda sonora espectacular)

MD - Lost World of Jurassic Park (mapeado hiper realista, rotaciones, escenas de Boss INCREIBLES

- Sonic 3D Blast (la mas espectacular intro de la generación 16 bits, graficos pre-renderizados y escenas Bonus INCREIBLES

SEGA CD - Silpheed (absolutamentre INCREIBLE)

PC Engine - SF2

Hola, una pregunta relacionada. Por ejemplo, la Master System se calienta más si estas jugando al Desert Speedtrap, Aladdin o MK2 que si estas jugando al Alf???.

Muchas gracias.

BUENDANI escribió:
MD - Lost World of Jurassic Park (mapeado hiper realista, rotaciones, escenas de Boss INCREIBLES

No lo conocia, WOW eso es Megadrive?? Que intro y que colorido de juego...

aranya escribió:Hola, una pregunta relacionada. Por ejemplo, la Master System se calienta más si estas jugando al Desert Speedtrap, Aladdin o MK2 que si estas jugando al Alf???.

Muchas gracias.

Que yo sepa los componentes tienen una velocidad fija, o sea, no

theelf escribió:

aranya escribió:Hola, una pregunta relacionada. Por ejemplo, la Master System se calienta más si estas jugando al Desert Speedtrap, Aladdin o MK2 que si estas jugando al Alf???.

Muchas gracias.

Que yo sepa los componentes tienen una velocidad fija, o sea, no

Correcto, una CPU con poca carga estaría ejecutando NOPs a piñón .

Hola, gracias por responder. Es muy interesante. Un NOPs es una "No operación" según he podido leer. Entonces la Master System y las otras consolas, siempre funcionan a tope. Lo que pasa es que hay operaciones que solo sirven para gastar recursos cuando el juego no necesita todos, ¿no?.

En la época de la Master System sabian mientras desarrollaban un juego los recursos que tenian disponibles?, o tenian que estar continuamente haciendo pruebas ensayo-error para ver como iban?.

Saludos.

aranya escribió:Hola, gracias por responder. Es muy interesante. Un NOPs es una "No operación" según he podido leer. Entonces la Master System y las otras consolas, siempre funcionan a tope. Lo que pasa es que hay operaciones que solo sirven para gastar recursos cuando el juego no necesita todos, ¿no?.

En la época de la Master System sabian mientras desarrollaban un juego los recursos que tenian disponibles?, o tenian que estar continuamente haciendo pruebas ensayo-error para ver como iban?.

Saludos.

Correcto, el NOP es cuando la CPU no hace nada, está "en reposo". Las técnicas de frecuencia dinámica son modernas, por entonces no existían.

Respecto a los recursos disponibles, ten por seguro que cada desarrollador aprovechaba al límite la máquina, lo que pasa es que no todos lo hacían con el mismo acierto. Por ejemplo, busca por internet comparativa entre algoritmos de ordenación (burbuja vs quicksort). Ambos ordenan una lista de elementos, pero el 2º es infinitamente más eficiente y necesita menos pasos.

Este vídeo está muy bien para entenderlo: https://www.youtube.com/watch?v=kPRA0W1kECg

En snes los NOP's los fuerza el DMA... o mejor dicho, cuando hay que transferir, se aprovecha para diseñar el juego de forma que no haya nada mas que hacer en ese momento.

Una duda para los que sabéis más, ayer probé en emulador el Star Ocean y me ha parecido una maravilla ver las físicas del viento en las vegetación del entorno, el agua moviéndose, el agua REFLEJA al personaje, voces en la intro y en combates, etc y a mayores traía opción de sonido surround que desconocía que ya existiera en 1996. No sé si exprime o no el potencial de Snes, pero me parece digno de ser nombrado lo poco que vi vamos.

Calculinho escribió:Y en PSX, Saturn y N64 hay alguno que exprimiera al máximo la consola. Se dicen que Metal Gear Solid en psx y puedo creermelo porque cuando salió ya hacia 5 años que se programaba en psx y se conocía el sistema, pero no me creo que Ocarina fuera lo máximo de N64 saliendo dos años después, y RE2 es un ejemplo de como exprimir al máximo el cartucho y su limitado espacio, pero no creo que a nivel hardware fuera tampoco lo máximo no? De Saturn desconozco

Teniendo en cuenta su ciclo de vida, no creo que haya algún juego que exprima Saturn al máximo.

Técnicamente lo más potente que he podido ver en la misma es:

- 3D: Panzer Dragoon Saga: gráficos de gran calidad con efectos difíciles de ver en la consola (vía software) y escenarios semi-abiertos (escenarios en los que nos podemos mover en libertad dentro de sus límites). La banda sonora en su mayor parte no está compuesta por pistas gravadas, sino que está generada por la consola, sacando un gran partido a su potente hard de sonido (uno de los puntos fuertes de la consola junto a sus capacidaddes 2D). Tema aparte son el gran diseño, ambientación y jugabilidad....

Hay quien quien opina que Burning Rangers está por encima en el aspecto técnico, pero yo me quedo con PDS.

- 2D: Hay mucha cosa a pesar del declive de las 2D en su tiempo. Si me ciño a lo que he probado y a juegos propios de la consola y no a conversiones de otros sistemas (por todo lo que entraña intentar hacer una conversión 1:1 de otro sistema con una arquitectura diferente) probablemente me quedaré con Guardian Heroes. Es increíble lo que llega a mover el juego en algunos momentos, con más de 20 enemigos en pantalla y efectos a tutiplén.

Por lo demás, hay juegos mixtos que son difíciles de catalogar como 2d o 3d y que son aútenticos portentos técnicos dentro de las posibilidades de la consola, como el archiconocido Radiant Silvergun.

Tengo que pedir perdón porque cuando lancé mi pregunta creía que era sistemas retro en general, me acabo de enterar que el debate se ciñe a 8 y 16 bits.

spectrum3 escribió:Lo ideal sería sin chips de apoyos o addons tipo chip FX o 32X, sino fuerza bruta de la consola u ordenador.

El chip fx estaba dentro del cartucho con lo que si cuenta perfectamente otra cosa es un accesorio o consola adicional como es el mega cd o 32x con sus propios juegos no compatibles con la consola original.

Para mi Donkey Kong Country fue lo máximo tanto en 8 como en 16 bits

En juegos de plataformas de 16 bits? Pues si. En 8bits, no se cual es el mérito de las versiones de GB... No los veo nada espectaculares comparados tecnicamente con algunos juegos de MS...

Señor Ventura escribió:En snes los NOP's los fuerza el DMA... o mejor dicho, cuando hay que transferir, se aprovecha para diseñar el juego de forma que no haya nada mas que hacer en ese momento.

Hombre técnicamente hablando una CPU que no hace nada está ejecutando NOPs, no puede inhibirse o de lo contrario el sistema se colgaría. Desconozco qué papel juega el DMA en la SNES pero ¿estás seguro que hay que esperar NOPs para transferir? Es que entonces no hablaríamos de DMA, la idea de los dispositivos DMA es poder acceder a la memoria sin pasar por la CPU (controlador de mandos, chip de sonido, chip de video...) y evitar el cuello de botella.

Calculinho escribió:Tengo que pedir perdón porque cuando lancé mi pregunta creía que era sistemas retro en general, me acabo de enterar que el debate se ciñe a 8 y 16 bits.

No pasa nada hombre, pero mejor no pasarnos de 16bit o se abre demasiado el abanico. Ten por seguro que en Saturn se quedó lejos de su techo: el ciclo corto de vida y la ausencia de herramientas adecuadas no permitieron exprimirla mucho. Ese Shenmue quizás hubiera tenido mucho que decir...

Por cierto señores, más fotos / videos en el hilo, ya que hablamos de techo técnico que se vea

AxelStone escribió:Hombre técnicamente hablando una CPU que no hace nada está ejecutando NOPs, no puede inhibirse o de lo contrario el sistema se colgaría. Desconozco qué papel juega el DMA en la SNES pero ¿estás seguro que hay que esperar NOPs para transferir? Es que entonces no hablaríamos de DMA, la idea de los dispositivos DMA es poder acceder a la memoria sin pasar por la CPU (controlador de mandos, chip de sonido, chip de video...) y evitar el cuello de botella.

Es que es probablemente la mayor pega que tiene la snes, que durante la transferencia, la cpu se fuma un cigarrito.

Se soluciona buscando el mejor momento para que eso... o mejor dicho, en aquellos momentos en que vayas a forzar un NOP, transfieres algo (total, el efecto es el mismo xD).

Señor Ventura escribió:Es que es probablemente la mayor pega que tiene la snes, que durante la transferencia, la cpu se fuma un cigarrito.

Se soluciona buscando el mejor momento para que eso... o mejor dicho, en aquellos momentos en que vayas a forzar un NOP, transfieres algo (total, el efecto es el mismo xD).

Pues es para pegarles un palo en la cabeza , el DMA resulta especialmente práctico para disponer de toda la CPU. Incluso en sistemas de 8bit, como el MSX, se usaba justamente para aliviar al Z80. No obstante es cierto que sistemas de cierto renombre e incluso cierta potencia obviaron el DMA, así el Atari ST o el propio PC no lo tenían, lo cuál era un consumo innesario de CPU.

AxelStone escribió:Pues es para pegarles un palo en la cabeza , el DMA resulta especialmente práctico para disponer de toda la CPU. Incluso en sistemas de 8bit, como el MSX, se usaba justamente para aliviar al Z80. No obstante es cierto que sistemas de cierto renombre e incluso cierta potencia obviaron el DMA, así el Atari ST o el propio PC no lo tenían, lo cuál era un consumo innesario de CPU.

Pero es que la cosa no se acaba ahí. Tampoco es posible transferir durante la pantalla activa (excepto el HDMA, pero digamos que no transfiere datos, sino "órdenes" al sistema de vídeo).

En snes, despropósitos hay mil... por eso se dice que la "verdadera" snes estaba destinada a ser una auténtica bestia parda de consola.

Señor Ventura escribió:En snes, despropósitos hay mil... por eso se dice que la "verdadera" snes estaba destinada a ser una auténtica bestia parda de consola.

Ya leí la entrevista a Miyamoto en la que se quejaba con la boca pequeña del diseño final. Cuando le preguntaban por el FX respondía cosas tales como "es un chip maravilloso, debimos incluirlo desde un primer momento". De todos modos es la eterna historia del hardware: pudo ser y no fue. Sea por costes, por plazos o incluso por racanería del fabricante, la mayoría de los sistemas de los 80 se dejaron cosas en el tintero y vieron la luz por debajo de sus especificaciones iniciales.

Game boy. Los webos al suelo al ver por primera vez.
donkey kong land. Todo el juego es un prodigio inexplicable para el hard de game boy pero la fase acuatica es la polla.

Minuto 34.20 fase acuatica

https://youtu.be/cgSVNxDruO8

AxelStone escribió:

Señor Ventura escribió:En snes, despropósitos hay mil... por eso se dice que la "verdadera" snes estaba destinada a ser una auténtica bestia parda de consola.

Ya leí la entrevista a Miyamoto en la que se quejaba con la boca pequeña del diseño final. Cuando le preguntaban por el FX respondía cosas tales como "es un chip maravilloso, debimos incluirlo desde un primer momento". De todos modos es la eterna historia del hardware: pudo ser y no fue. Sea por costes, por plazos o incluso por racanería del fabricante, la mayoría de los sistemas de los 80 se dejaron cosas en el tintero y vieron la luz por debajo de sus especificaciones iniciales.

Es mas que eso, realmente el chip SFX estuvo planificado para ser el PPU 3 de la consola, lo que ocurre es que el lanzamiento ya se estaba demorando demasiado, y decidieron cerrarlo así. Pero vamos, que no fué un "y si", realmente querían el chip para la máquina, y no para los cartuchos.

Eso puede tener una cierta disculpa, pero lo que si que no se entiende, es como es posible que a la hora decidirse por un 65c816 (que me parece una muy buena idea viendo sus virtudes, mira el SA-1), lo hagan a una frecuencia de reloj tan baja, y lo que es peor, lo mal conjuntado que está con el DMA... es que de primero de "básico de manual", cpu y DMA ahí son como el agua y el aceite. Que locura.

Luego están las memorias, que tienen una latencia bastante "discreta", o los bus de 8 bits... la VRAM que se queda corta para la cantidad de información que ocupan tantos colores (con 256 colores hacen falta 128K, o si no no puedes emplear esa profundidad de color en todos los tiles)... o por ejemplo no unificar la ram principal y la ram del spc700 (porque muchísimos juegos infrautilizan la memoria ram principal, y ese excedente le vendría muy bien al hardware de sonido).


No se, son muchas cosas. Y de haberse hecho como dios manda, la snes hubiera sido un maquinón impresionante incluso sin el SFX.
Pero de haber llevado el SFX, imagina un chip de semejante potencia que puede trabajar en conjunción con un 65c816 a 10mhz, y los PPU 1 y 2. Todo a la vez, y sin la limitación de direccionamiento de memoria que tiene el SFX cuando ejecuta juegos desde el cartucho (SFX 8 megas, SFX2 16 megas... aunque lo cierto es que el SFX2 es el SFX original, y no una revisión mas potente del chip, como mucha gente cree. El SFX1 es en realidad el SFX funcionando al 50% de su capacidad).

Uno se para a pensar lo que hubiese supuesto una máquina así, y el efecto playstation con las recreativas se hubiese adelantado una generación.

Señor Ventura escribió:En snes los NOP's los fuerza el DMA... o mejor dicho, cuando hay que transferir, se aprovecha para diseñar el juego de forma que no haya nada mas que hacer en ese momento.

Señor ventura, los NOP's y el DMA no tienen que ver el uno con el otro.

Un NOP es una instrucción de CPU que no hace nada mas que "perder tiempo", y es precisamente para eso que se usa. Voy a poner varios ejemplos: en el Snes existe multiplicación y división en el hardware (en el CPU no hay multiplicación o división), cuando se introducen los valores a multiplicar o dividir, hay que esperar una cierta cantidad de tiempo(ciclos) antes de leer el resultado, en el caso de la multiplicación son 8 ciclos y la división 16, y eso se puede hacer usando NOP's.

Aqui hay otro ejemplo, en el sega Genesis/Megadrive para leer el control generalmente se usa una rutina como esta:

aqui se pueden ver varios NOP's, esto se debe a que el control no puede responder tan rápido y por eso se usan NOP's.


Ahora sobre el DMA (Acceso Directo a Memoria), el DMA se usa para transferir datos mas rápido de lo que puede hacer el CPU. Cuando se usa DMA en el snes o Genesis/MD usualmente se hace para transferir un bloque de datos desde rom o ram hacia la Vram. Generalmente cuando se inicia el DMA el CPU se detiene (Y digo "generalmente" porque no es así en todos los casos, mas abajo lo explico), y para que entonces el PPU o VDP pueda leer los datos directamente desde rom(o ram) para transferir a la VRAM. Para que quede claro, durante el tiempo que dure el DMA el CPU estará detenido, esto significa que el CPU no podrá ejecutar ninguna instrucción, porque el PPU o VDP tendrá el control de los buses de datos y direcciones(que normalmente lo controla el CPU).

Aunque en el caso del Genesis/MD existe dos modos de DMA llamados "Vram fill"(que es para escribir un mismo valor a un determinado bloque en VRAM, se usa generalmente para borrar un espacio en VRAM) y "Vram copy"(que se usa para copiar un bloque de datos de VRAM a otro espacio en VRAM), en donde el CPU no estará detenido, es decir que puede seguir ejecutando instrucciones, pero no puedes acceder al VDP mientras dure el DMA.

Señor Ventura escribió:...

Uno se para a pensar lo que hubiese supuesto una máquina así, y el efecto playstation con las recreativas se hubiese adelantado una generación.

En general creo que Nintendo cometía errores infantiles en los diseños. La N64 tiene errores más evidentes y aún así salió, no entiendo de verdad en qué pensaban sus diseñadores... . Y para una que diseñan a conciencia, la GameCube, no responde en ventas.

gasega68k escribió:Aunque en el caso del Genesis/MD existe dos modos de DMA llamados "Vram fill"(que es para escribir un mismo valor a un determinado bloque en VRAM, se usa generalmente para borrar un espacio en VRAM) y "Vram copy"(que se usa para copiar un bloque de datos de VRAM a otro espacio en VRAM), en donde el CPU no estará detenido, es decir que puede seguir ejecutando instrucciones, pero no puedes acceder al VDP mientras dure el DMA.

Eso me cuadra más con el concepto de DMA. Hasta donde yo sé las operaciones de tipo fill VRAM las introdujo ya el primigenio Texas Instrument de los MSX, que como se ha comentado en algún hilo sentó las bases de arquitecturas posteriories. Sobre ocupar el bus depende, si el VDP está accediendo a VRAM entiendo que tiene su propio bus y no bloquea el acceso de la CPU a RAM, después de todo es el propósito de las memorias dedicadas ¿correcto?

Imagino que con ese problema tuvieron que lidiar sistemas con shared memory como el Amiga, pero con esos pepinos de bus de 32bit el problema quedó resuelto.

Para mi en la NES de lo mas tocho que hay es el Bucky o'hare
https://www.youtube.com/watch?v=GHHM7_pBjUw
Utiliza casi todos los trucos de la nes, en cada pantalla uno.

gasega68k escribió:Señor ventura, los NOP's y el DMA no tienen que ver el uno con el otro.

Es que no he dicho que tengan que ver. Lo que he dicho es que el DMA entra en juego para transferir en momentos en que a la cpu no se le exige un funcionamiento.

De hecho, dices lo mismo que he dicho yo, que la cpu de la snes se para totalmente, cosa que no sucede con el 68000, y por lo tanto una manera de paliar eso es hacer entrar en juego el DMA.


Conozco el dato de los ciclos de "ausencia" cuando se usa la multiplicacion o la division. Lo que no he dicho es que usando el DMA para transferir provoca el mismo efecto en la cpu que forzar un NOP.
La cuestion es que si te puedes permitir forzar un NOP, puedes aprovechar para extender la situación transfiriendo algo.

Es complicado de explicar desde el movil, pero en definitiva, lo que digo es que en snes tienes que planificar el momento de usar el DMA mas que en megadrive, y aprovechar inteligentemente cada momento en el que transferir.


Una cosa que quiero aprovechar para comentar, es precisamente sobre ese detalle. Comunmente veo transferencia de datos a ram y vram mientras juego, sin provocar parones, y eso me desconcierta, porque se supone que el juego deberia congelarse... que estoy pasando por alto?.

Señor Ventura... Tienes mucha suerte de que ésto sea EOL y no assembler.

wave escribió:Para mi en la NES de lo mas tocho que hay es el Bucky o'hare
https://www.youtube.com/watch?v=GHHM7_pBjUw
Utiliza casi todos los trucos de la nes, en cada pantalla uno.

Pues no me parece muy bruto ¿no? O igual no estoy viendo las zonas de video adecuadas. El Batman que ponen poco más arriba es bastante más bestia a mi juicio.

AxelStone escribió:

wave escribió:Para mi en la NES de lo mas tocho que hay es el Bucky o'hare
https://www.youtube.com/watch?v=GHHM7_pBjUw
Utiliza casi todos los trucos de la nes, en cada pantalla uno.

Pues no me parece muy bruto ¿no? O igual no estoy viendo las zonas de video adecuadas. El Batman que ponen poco más arriba es bastante más bestia a mi juicio.

Hay que verlo entero digamos, hay zonas con cosas muy interesantes, si eso un dia con tiempo hago un resumen xD

Baek escribió:Señor Ventura... Tienes mucha suerte de que ésto sea EOL y no assembler.

En snes el DMA no puede entrar en juego en cualquier momento. Tal vez en megadrive si, pero en snes hay que planificar muy bien cuando lo hace.

En un bonus stage del donkey kong country, al ganar se cambia la musica, y la pantalla se queda congelada un segundo.

Me sigue llamando la atención como lo hacen otros juegos para transferir datos sin que se pare la accion.

En snes a pelo creo que DKC la pone a tope.
En MD a pelo dynamite heady es brutal.
En MS Sonic 2
En NES mario 3 aunque cre q llevaba chip de apoyo

Señor Ventura escribió:Es que no he dicho que tengan que ver. Lo que he dicho es que el DMA entra en juego para transferir en momentos en que a la cpu no se le exige un funcionamiento.

De hecho, dices lo mismo que he dicho yo, que la cpu de la snes se para totalmente, cosa que no sucede con el 68000, y por lo tanto una manera de paliar eso es hacer entrar en juego el DMA.

Conozco el dato de los ciclos de "ausencia" cuando se usa la multiplicacion o la division. Lo que no he dicho es que usando el DMA para transferir provoca el mismo efecto en la cpu que forzar un NOP.
La cuestion es que si te puedes permitir forzar un NOP, puedes aprovechar para extender la situación transfiriendo algo.

Es complicado de explicar desde el movil, pero en definitiva, lo que digo es que en snes tienes que planificar el momento de usar el DMA mas que en megadrive, y aprovechar inteligentemente cada momento en el que transferir.

No sé, pero me parece que aun no entiendes como funciona el DMA(al menos en snes). Para "activar" un DMA se ejecuta un conjunto de instrucciones en donde se dice hacia donde se hara la transferencia (usualmente hacia Vram), la direccion desde donde se hara la transferencia (Rom o Ram), numero de bytes a transferir, y despues se inicia el DMA a traves de un registro. En el instante que el CPU da inicio al DMA, el PPU detiene al CPU para luego comenzar la transferencia, y cuando haya terminado el PPU reactiva al CPU de nuevo para continuar ejecutando las instrucciones donde se habia quedado.

Señor Ventura escribió:Una cosa que quiero aprovechar para comentar, es precisamente sobre ese detalle. Comunmente veo transferencia de datos a ram y vram mientras juego, sin provocar parones, y eso me desconcierta, porque se supone que el juego deberia congelarse... que estoy pasando por alto?.

La transferencia a Vram se debe hacer solo durante Vblank, y no puede producir "parones" porque solo es en un "pequeño" bloque de datos por frame, unos 6KB maximo, la mayoría de los casos nunca llega a esta cantidad.

Señor Ventura escribió:En un bonus stage del donkey kong country, al ganar se cambia la musica, y la pantalla se queda congelada un segundo.

Me sigue llamando la atención como lo hacen otros juegos para transferir datos sin que se pare la accion.

Esto se debe al sonido. Es porque cargar datos a la ram del chip de sonido es extremadamente lento, debido al (ridículo) protocolo de transferencia que fue diseñado en el snes, que puede tardar hasta unos 2 segundos en cargar toda la ram de sonido(64kBytes).
Este es un ejemplo de como se hace la transferencia: primero existen 4 registros en los que el CPU se puede comunicar con el APU(cpu de sonido), al principio el CPU debe esperar a que el APU este listo para poder recibir datos(leyendo uno de los 4 registros), cuando esté listo el CPU envia un cero(este sería el contador de bytes) a uno de los registros y también envía el primer dato a otro registro, en este momento queda esperando la confirmación de que el APU recibió el dato leyendo uno de los registros hasta que sea cero (en el lado del APU se lee el dato y se envía un cero para que el CPU sepa que ya recibió el dato), luego se envia el siguiente dato a un registro y ahora se envia un uno al otro registro(el "contador") indicando que es el siguiente dato,... se repetirá todo este proceso hasta completar todos datos que se enviaran(que pudiera ser hasta 64KB), la lentitud también se debe a que el APU funciona a 1MHZ y el CPU debe esperar mucho tiempo entre bytes que envía.

Me es difícil pensar un techo técnico, porque siempre pienso en juegos que me parecen muy buenos, pero eso no significa que alcancen el límite del sistema.

En 8 bits, alguien ha comentado Sonic 2, creo que este si que puede ser, y el Sonic Chaos también, ya que por ejemplo este último a 60 Hz se ralentiza cuando te empiezas a mover rápido ¿Puede ser esto síntomas de que es un techo técnico?

En 16 bits, no se no se, solo pienso en juegos de MD, pero hay más mundo de 16 bits...

wave escribió:

AxelStone escribió:

wave escribió:Para mi en la NES de lo mas tocho que hay es el Bucky o'hare
https://www.youtube.com/watch?v=GHHM7_pBjUw
Utiliza casi todos los trucos de la nes, en cada pantalla uno.

Pues no me parece muy bruto ¿no? O igual no estoy viendo las zonas de video adecuadas. El Batman que ponen poco más arriba es bastante más bestia a mi juicio.

Hay que verlo entero digamos, hay zonas con cosas muy interesantes, si eso un dia con tiempo hago un resumen xD

Voy a poner links a partes interesantes.
De este video:
https://www.youtube.com/watch?v=dWHPNnrTmKs
4:20 esas naves/scroll parallax estan muy logradas.
4:50 el uso que se hace del background para representar la piedra (va a haber muchos efectos del estilo)
5:45 el efecto del agua es muy curioso
9:40 otra vez mucho uso del background para la lucha, muy logrado
12:23 esas llamaradas
13:50 el efecto del fondo
28:00 el clasico ascensor
32:30/34:02 los movimientos de los pinchos tan grandes
34:30 el efecto de luz de las luciernagas
36:26 movimiento de casi todo el escenario
41:32 "rotacion" del fondo
42:35 las serpientes del battletoads xD
44:27 la ultima fase en nave esta muy conseguida tambien

Hay alguna cosilla mas, pero es que diria que este juego hace uso de todo lo que se puede hacer en NES xD

AxelStone escribió:De todos modos es la eterna historia del hardware: pudo ser y no fue. Sea por costes, por plazos o incluso por racanería del fabricante, la mayoría de los sistemas de los 80 se dejaron cosas en el tintero y vieron la luz por debajo de sus especificaciones iniciales.

Exactamente, estoy seguro de que ninguna máquina fue construida tal y como se definió en su primer "boceto", siempre se estudian posibles mejoras, etc... lo que pasa es que hay que adaptarlas en función del objetivo comercial que se busca, no creo que a Sega le hubiera costado mucho mejorar ciertos aspectos de la MD, o directamente consolizar la System 16 u otras de sus placas, pero eso ya sería otra historia y conllevaría un aumento considerable del precio, y esa no era la cuestión. Quien dice Sega dice cualquier otra compañía.

Y por poner un ejemplo sobre el hilo, además del ya comentado Batman, a mí me impresionan mucho el Battletoads de la NES y el R-Type de la Master.

robotnik16 escribió:

AxelStone escribió:De todos modos es la eterna historia del hardware: pudo ser y no fue. Sea por costes, por plazos o incluso por racanería del fabricante, la mayoría de los sistemas de los 80 se dejaron cosas en el tintero y vieron la luz por debajo de sus especificaciones iniciales.

Exactamente, estoy seguro de que ninguna máquina fue construida tal y como se definió en su primer "boceto", siempre se estudian posibles mejoras, etc... lo que pasa es que hay que adaptarlas en función del objetivo comercial que se busca, no creo que a Sega le hubiera costado mucho mejorar ciertos aspectos de la MD, o directamente consolizar la System 16 u otras de sus placas, pero eso ya sería otra historia y conllevaría un aumento considerable del precio, y esa no era la cuestión. Quien dice Sega dice cualquier otra compañía.

Y por poner un ejemplo sobre el hilo, además del ya comentado Batman, a mí me impresionan mucho el Battletoads de la NES y el R-Type de la Master.

Tu mismo lo has dicho: ¿qué ganaba Sega con reprogramar versiones reducidas de Golden Axe, Altered Beast...? Si ya los tengo hechos, vendo la consola System 16 y salgo del paso. Obviamente para el hogar hay que pensar de otra forma y creo que acertada, ya que los sistemas caros son elitistas, lo que obstaculiza su difusión y se nota la falta de juegos. Un ejemplo tangible es la NeoGeo, que saltó directa de los salones al hogar con un precio prohibitivo en máquina y juegos, creo que todos coincidimos que MD/SNES eran mucho mejores sistemas domésticos.

El R-Type de MS es una bestia parda.

comprador escribió:Hola, me uno al tema y apuesto como techo técnico en Mega Drive16 bit, el impresionante Panorama Cotton.



Es increíble el efecto de scaling con más mérito aun al ser por software....

*** el 68000 de Motorola
mueve, escala, y rota sprites por hardware. La Megadrive nunca mostró nada
'acojonante' de lo ke podía hacer un M68000 realmente.

Sí hubo juegos notorios en ese sistema, pero no estaba realmente nada aprobechado.
También es cierto ke poseía una memoria de mierda, y eso lastraba bastante a todo
el conjunto, pero programándose en asm [como se programaba] se podía tener un
control absoluto sobre todo el conjunto.

Aprovecho para preguntar por si alguien lo sabe, siempre tuve curiosidad: ¿cómo demonios hicieron Wrath of the Demon de Atari ST? Un ordenador que no tiene ningún hardware gráfico de apoyo y se sacan de la manga un juego con un paralaje impresionante y múltiples planos de scroll. ¿Dónde está el truco?

Es un port del juego de Amiga. Con una paleta bastante mala por cierto, y la calidad musical
ke daba el ST [bastante penosa].

Los múltiples planos de scroll salen del sistema de raster de vídeo ke poseían [planar].
Se hace scroll++ de cada bit-plane ke aparece en pantalla. Simple y efectivo.

- Desert Speedtrap (Scroll paralax en 8 direcciones de varias capas TODO EL JUEGO y sonidos digitalizados)

Jaaaaaaaaaaaaaaaa jaa ja !!
Scroll con dos semiplanos y vas ke chutas. Paralax en 8 direcciones ?!¿ ..de varias capas?¿
Dónde los ves tú... ! [dejad de creer en las chorraditas de las 'revistillas' y las contraportadas de las cajas]

@Xputo , al igual que todos los usuarios, puedes dar tu opinión, pero sin usar comentarios despectivos y descalificando las de los demás usuarios.

Se puede opinar, debatir y discutir sobre cualquier tema que tenga cabida en los foros, pero con el respeto a los demás usuarios como regla principal. No se tolerarán insultos, salidas de tono, faltas de respeto, actitudes discriminatorias o, en general, cualquier tipo de comentario que contribuya a un mal ambiente.

Creo ke lo dices por: "....no tienes ni puta idea de lo ke dices..."
No insulto a la persona en sí...[ni es mi intención] ya sé ke en un escrito, todo
parece más rudo de lo ke realmente uno desea reflejar.