Hilo técnico de consolas 2D

Responder
1, 2, 3
cirote3 escribió:


Snes escribió:@cirote3 si por hay ronda entre un 10% y un 17% ,pero si se mejora el rendimiento general del juego eliminado casi todas las ralentizaciones .

Diría más bien entre un 2% y un 17% :)


He leido que ese agua en concreto de Sonic 3 no funciona correctamente en la Genesis 3 ya que es muy sensible al timming y esa consola es un ASIC no muy bien hecho por lo que no tiene los timmings perfectos pero nunca he visto un vídeo del problema que se produce.

Tampoco entiendo muy bien cual es la diferencia entre las 2 aguas ¿Que ponen un delay para que coincida con el Hblank y asi no salen los dots? ¿Y como saben cuanto tiempo tarda la línea en dibujarse?

Un Saludo.
naxeras escribió:Tampoco entiendo muy bien cual es la diferencia entre las 2 aguas ¿Que ponen un delay para que coincida con el Hblank y asi no salen los dots? ¿Y como saben cuanto tiempo tarda la línea en dibujarse?

Entiendo que la diferencia es que en una se actualiza toda la paleta del agua en un HBlank de golpe y en la otra se actualiza poco a poco, en varios HBlanks. Los HBlanks siempre duran lo mismo, la línea siempre tarda lo mismo en dibujarse.
¿Podría alguien explicarme lo de slow rom y fast rom? Se refiere al tipo de memoria rom (acceso a los datos y tal) en la que la original era más lenta que la fast rom y por eso provoca caídas? Al menos algo así he entendido.
Lázaro escribió:¿Podría alguien explicarme lo de slow rom y fast rom? Se refiere al tipo de memoria rom (acceso a los datos y tal) en la que la original era más lenta que la fast rom y por eso provoca caídas? Al menos algo así he entendido.

En el modo slow, la ROM tiene un tiempo de acceso de 200ns y en el fast de 120ns. Así que sí, la ROM en modo slow es más lenta y por eso provoca más ralentizaciones. Viendo los vídeos la diferencia entre los dos modos es menor de lo que me esperaba, la verdad.
@cirote3 ¿Pero es algo que se puede programar o es el hardware que lleva?
Hay momentos en los que se nota, si, pero si no hay mucha cosa en pantalla tampoco se nota tanto.
Lázaro escribió:@cirote3 ¿Pero es algo que se puede programar o es el hardware que lleva?
Hay momentos en los que se nota, si, pero si no hay mucha cosa en pantalla tampoco se nota tanto.

Los cartuchos que no soportaban modo fast eran más baratos. Si el cartucho soporta el modo fast, hay que activarlo con instrucciones dentro del juego.
@cirote3 Y si se comercializaban con soporte de modo fast, ¿por qué no lo activaban de serie? ¿Se sabía de antes todo esto?
Los cartuchos slow también provocan que la snes se configure para trabajar a una velocidad menor. El reloj de la CPU de quedaba en 2,68 mhz en lugar de los 3,58 MHz del modo fast.
Producir cartuchos con slow ROMs era mass barato y las empresas solían optar por ese camino de ahorrar dinero.
sgonzalez escribió:Los cartuchos slow también provocan que la snes se configure para trabajar a una velocidad menor. El reloj de la CPU de quedaba en 2,68 mhz en lugar de los 3,58 MHz del modo fast.
Producir cartuchos con slow ROMs era mass barato y las empresas solían optar por ese camino de ahorrar dinero.


Realmente era porque Nintendo es la que les vendia los cartuchos a las empresas a un precio de todo menos barato jajajajaja, menudas regalias les pedía por su cuasi monopolio de marca, eso si merecia la pena porque al final vendían mas con Nintendo que con la competencia.
Lázaro escribió:@cirote3 Y si se comercializaban con soporte de modo fast, ¿por qué no lo activaban de serie?

La SNES siempre arranca por defecto en modo slow, es el programador quien tiene que activar el modo fast cuando arranca el juego si sabe o cree que el cartucho lo va a soportar.

Lázaro escribió:¿Se sabía de antes todo esto?

Claro que se sabía, ¿por qué no se iba a saber? XD
cirote3 escribió:
Lázaro escribió:¿Se sabía de antes todo esto?

Claro que se sabía, ¿por qué no se iba a saber? XD

bueno ,se sabia ...
lo del fast rom es relativamente nuevo ,anda que no se ha escrito nada en este foro acerca de las ralentizaciones del castlevania 4 .
que si la consola no da para mas ,que las ralentizaciones eran por la cpu ect ,todo eso hace dos dias como quien dice .

como este juego otros que se arreglaron con el cambio a fast rom
Lázaro escribió:¿Podría alguien explicarme lo de slow rom y fast rom? Se refiere al tipo de memoria rom (acceso a los datos y tal) en la que la original era más lenta que la fast rom y por eso provoca caídas? Al menos algo así he entendido.


De hecho esto es buen momento para desmitificar ciertos funcionamientos de Fast/Slow-ROM.

Tal y como te indican Fast-Rom es un cartucho que permite a la CPU leer la ROM a 3,58 MHz en lugar de 2,68 MHz, en los bancos altos del mapa de memoria.

¿Es un mejora del 33%? ¿O es una mejora del 25%?
- Se dice que es una mejora del 33% porque el aumento de 2,68 MHz a 3,58 MHz es del 33,5%
- En cambio si calculamos la pérdida de eficiencia de entre 3,58MHz a 2,68 MHz es del 25,14%

La gente suele utilizar el número más grande. No es equívoco pero "suena mejor" pudiendo parecer que el rendimiento real y la diferencia de rendimiento es más exagerada de lo que realmente es... ¿Pero es realmente un aumento de rendimiento tan bestia? (hablando de ese 33%)

El acceso de CPU a ROM funciona a 3,58MHz con Fast-ROM pero esto no cambia el tiempo de acceso al resto de componentes sigue siendo el mismo: CPU a RAM/WRAM 2,68MHz, CPU a SRAM 2,68MHz, DMA a VRAM 2,68MHz, CPU a joypad 1,79MHz...

Además hay que tener en cuenta que tampoco evita los propios cuellos de botella del propio sistema, como cuando durante una transferencia DMA, la CPU se pausa mientras el controlador DMA toma el control del bus, lo que significa que Fast-ROM tampoco acelera ese proceso, o cuando para comunicarse con el SPC700, la CPU tiene que esperar a que este responda por los puertos, y el ritmo de esa transferencia lo marca el propio SPC700, no la velocidad de lectura de la ROM.

Con lo que aquí entraríamos en Ley de Amdahl la que describe que el rendimiento de un sistema está limitado por aquellas partes que no se puede cambiar. Te pongo un ejemplo simple:

Imagina que te lleva 1 hora escribir e imprimir un documento: dedicas 40 minutos a escribirlo y la impresora tarda 20 minutos en imprimirlo.

Ahora, decides comprar una impresora de última generación que imprime el mismo documento en 5 minutos. ¿Cuánto tardas ahora en tener el documento físico en tus manos? 45 minutos. Aunque hayas mejorado la impresora, sigues escribiendo a un ritmo que te lleva 40 minutos terminar el texto. En este caso, tú eres quien no ha mejorado, lo que hace que esos 40 minutos sean inevitables.

La mejora entre la impresora antigua y la nueva es del 75 % (de 20 minutos a 5 minutos), pero la mejora total para la tarea completa es solo del 25 % (de 1 hora a 45 minutos).


Luego ¿Cómo se compara esto con lo que hemos visto con Fast/Slow-ROM?
A pesar de que el acceso a ROM aumente ese 33%, a nivel general y dependiendo de las exigencias de acceso a ROM que requiera un juego u otro, la mejora variará según el escenario, pero a nivel general, un máximo de mejora de rendimiento de alrededor del 15% es lo que se logra con Fast-ROM.

Es por ello que aunque hay una mejora notable, juegos en Fast-ROM que antes no lo eran llegan a presentar aún ralentizaciones (Contra III, Thunder Spirits,SCIV...) por eso hackers como Vitor Vilela son más conservadores al declarar "casi todo".


Como dice @cirote3 la SNES arranca en modo SLOW, pero aunque vea el flag marcado de FAST-ROM, hay que verificar que también se esté accediendo a la zona de la memoria rápida de la ROM:
Imagen
Hay que mirar que el código se esté ejecutando entre los bancos $80 y $FF (los Bancos 83D... se encuentran en esa zona):
Imagen

Luego existen muchos juegos de SNES a Slow-ROM que funcionan perfectamente a 60FPS (como el nombreado F-Zero) donde poner Fast-ROM no tendría demasiado sentido ya ya mantiene una estabilidad perfecta. Gracias a que la PPU se encarga de lo más pesado (el modo 7), la CPU tiene que encargarse de las posiciones relativas de un máximo de 4 naves en pantalla respecto al jugador, el HUD, marcadores... El coste para la CPU en esta parte es pequeño; lo que sí consume es tiempo de bus por el HDMA.

A partir de aquí podríamos teorizar en F-Zero funcionase con Fast-ROM cuántos elementos más podríamos añadirle o no pero la realidad es que no existe de momento tal ROM para realizar comprobaciones y cómo se viese afectado el rendimiento según el número y la razón de esos elementos.
En el apartado de las ralentizaciones fue Nintendo la que realmente metió lo pata dando le a las empresas (capcom etc) la oportunidad de escoger entre fast rom y lowrom . Si Nintendo solo hubiera dado a las empresas la confirmación de fastrom la SNES hubiera tenido ralentizaciones en sus juegos? Te aseguro que sí pero no hubiera sido tan crítico como lo que tú vimos en la época, pero este problema de las ralentizaciones no era exclusivamente de la snes la MD, Neo Geo todas las 16 bit lo presentaban en mayor o menor medida que otras pero todas los tenían, la snes en este apartado era la que más sufría por la política de Nintendo. En cuanto a F zero por ejemplo la snes no necesita el fastrom para mover esas cuatro naves como antes dicho , pero una MD tiene que reducir distancia de dibujado ir a 30 FPS reducir resolución y la CPU a full para mover esas cuatro naves, eso es por diferencia de arquitectura entre ambas consolas pero aquí la snes sale ganando . Quizás si la snes no hubiera tenido la configuración de slowrom en los cartuchos hubiera estado más parejas con su competencia directa la MD.
Editó

Traducción:
Optimicé los códigos de *Thunder Spirits* para SNES!

Fue mi mayor desafío hasta la fecha, ya que el juego está pésimamente optimizado (es una brutalidad).
kandowontu había realizado una conversión a FastROM y, aun así, el juego sufría de un *lag* tremendo.
¡Ahora va mucho más fluido
Los cartuchos hubieran sido más caros todavía. ¿Hubieran vendido más para compensar el sobreprecio?
Seguramente no.
Creo que los cartuchos de la Mega Drive más rápidos eran igual de lentos que los más lentos de la SNES (200ns de latencia). Nunca he entendido por qué a Nintendo se le critica tanto el tema de la velocidad de los cartuchos y Sega tiene carta blanca XD

En ese tema yo no estoy muy puesto, seguro que @M68K sabe más :)
@M68K ¡Muchísimas gracias por la explicación! Vaya currada jaja
Más o menos me imaginaba que sería algo de eso pero en temas técnicos soy un pez de cuidao.
cirote3 escribió:Creo que los cartuchos de la Mega Drive más rápidos eran igual de lentos que los más lentos de la SNES (200ns de latencia). Nunca he entendido por qué a Nintendo se le critica tanto el tema de la velocidad de los cartuchos y Sega tiene carta blanca XD

En ese tema yo no estoy muy puesto, seguro que @M68K sabe más :)


Realmente que una ROM tenga 200ns no significa directamente que ambas CPUs puedan completar una lectura en 200ns, sino que la memoria necesita ese tiempo para preparar los datos válidos.

Luego cada CPU funciona a diferentes frecuencias con sus tiempo por ciclo (esto dependiente de los MHz), el número de ciclos por instrucción y la cantidad de datos transferibles cada vez (bus de 16bits vs bus de 8bits)

Lo que pasa es que era más determinante o más bien afecta más al rendimiento el tiempo de acceso a ROM de SNES que el de MD. Slow-ROM/Fast-ROM está directamente ligada al tiempo de los ciclos del 5A22 y, por tanto, puede afectar directamente a cuánto tarda la CPU en ejecutar código que depende de accesos a ROM.

Lázaro escribió:@M68K ¡Muchísimas gracias por la explicación! Vaya currada jaja
Más o menos me imaginaba que sería algo de eso pero en temas técnicos soy un pez de cuidao.


Nada hombre, si algo no te queda claro avisa que a base de símiles podemos llegar muy lejos.
M68K escribió:
cirote3 escribió:Creo que los cartuchos de la Mega Drive más rápidos eran igual de lentos que los más lentos de la SNES (200ns de latencia). Nunca he entendido por qué a Nintendo se le critica tanto el tema de la velocidad de los cartuchos y Sega tiene carta blanca XD

En ese tema yo no estoy muy puesto, seguro que @M68K sabe más :)


Realmente que una ROM tenga 200ns no significa directamente que ambas CPUs puedan completar una lectura en 200ns, sino que la memoria necesita ese tiempo para preparar los datos válidos.

Luego cada CPU funciona a diferentes frecuencias con sus tiempo por ciclo (esto dependiente de los MHz), el número de ciclos por instrucción y la cantidad de datos transferibles cada vez (bus de 16bits vs bus de 8bits)

Lo que pasa es que era más determinante o más bien afecta más al rendimiento el tiempo de acceso a ROM de SNES que el de MD. Slow-ROM/Fast-ROM está directamente ligada al tiempo de los ciclos del 5A22 y, por tanto, puede afectar directamente a cuánto tarda la CPU en ejecutar código que depende de accesos a ROM.

Todo eso lo tenía más o menos claro, lo que no tengo claro es si en los juegos comerciales de la Mega Drive se configuraba el tiempo de lectura con una latencia similar a la del modo FastROM de la SNES. Por lo que he leído, la latencia mínima que se usó era 200ns, la misma que los cartuchos SlowROM de la SNES, y había juegos comerciales con mayor latencia. Por eso no entiendo que se le eche tanto en cara la velocidad de los cartuchos a Nintendo y a Sega no. Supongo que los cartuchos de Mega Drive permitían transmitir más datos por segundo a costa de tener mayor latencia.
cirote3 escribió:Todo eso lo tenía más o menos claro, lo que no tengo claro es si en los juegos comerciales de la Mega Drive se configuraba el tiempo de lectura con una latencia similar a la del modo FastROM de la SNES. Por lo que he leído, la latencia mínima que se usó era 200ns, la misma que los cartuchos SlowROM de la SNES, y había juegos comerciales con mayor latencia. Por eso no entiendo que se le eche tanto en cara la velocidad de los cartuchos a Nintendo y a Sega no. Supongo que los cartuchos de Mega Drive permitían transmitir más datos por segundo a costa de tener mayor latencia.


Además de la mayor transferencia que comentas, en MD podías tener tranquilamente una ROM de 250ns o incluso 300ns de latencia que no iba a cambiar la frecuencia de reloj ni la velocidad de la CPU (Tiene un margen de hasta 520ns: 130ns por ciclo con, como mínimo 4 ciclos y luego puede transferir hasta 16 bits "en un viaje"), mientras que en SNES aumenta/reduce el número de ciclos necesarios para acceder a esa lectura de 6 a 8 ciclos del reloj maestro (funcionando a 3,58MHz o a 2,68MHz en acceso) limitando transferencias a un bus de 8bits.

La recriminación entonces creo que viene del hecho de "capar" su propia CPU para abaratar costes a cambio de rendimiento. Y que es notorio cuando pasan un juego con slowdowns constantes a Fast-ROM y se eliminan la mayoría o reducen esos tiempos. Por eso la gente se queja de ello o llama más la atención.

Ya sabes, se va a recriminar a cada sistema el punto débil del mismo: "Ojalá MD tuviera más colores, ojalá la CPU de SNES fuese más rápida, deberían haberle puesto a Dreamcast que pueda leer DvDs, Saturn es difícil de programar.." etc etc
Que maravilla poder leer mensajes TAN trabajados e interesantes [plas]
Pussykitty escribió:
cirote3 escribió:¿Eso no va demasiado rápido para ser de 32X? El Virtua Fighter también va a 30FPS pero usa solo polígonos planos y llena menos área de la pantalla con ellos. ¿Hay ROM?

Ya, la verdad es que es un poco mosqueante que, usando el motor de Virtua Racing (unos 20 fps), esté funcionando así de bien.



Ahora que se han reducido los parpadeos más molestos, esto está a un paso de juego comercial que nos habría flipado en su día.

En la 32X es mucho más eficiente mostrar polígonos planos que con texturas, ya que para los planos hay hardware dedicado: con el fill engine/function se puede pintar líneas de la pantalla con un color más rápido que con los SH2.

Por eso me extraña tanto que con polígonos con texturas vaya a 30FPS, más rápido que el Virtua Racing original con polígonos planos (a 20FPS). Dicen en los comentarios que aún nadie lo ha probado en HW real, a ver si alguien se anima.
Si me pasan el link de la rom la puedo probar yo
ChepoXX escribió:Si me pasan el link de la rom la puedo probar yo

Creía que las ROMs eran públicas pero no las encuentro.
M68K escribió:
cirote3 escribió:Todo eso lo tenía más o menos claro, lo que no tengo claro es si en los juegos comerciales de la Mega Drive se configuraba el tiempo de lectura con una latencia similar a la del modo FastROM de la SNES. Por lo que he leído, la latencia mínima que se usó era 200ns, la misma que los cartuchos SlowROM de la SNES, y había juegos comerciales con mayor latencia. Por eso no entiendo que se le eche tanto en cara la velocidad de los cartuchos a Nintendo y a Sega no. Supongo que los cartuchos de Mega Drive permitían transmitir más datos por segundo a costa de tener mayor latencia.


Además de la mayor transferencia que comentas, en MD podías tener tranquilamente una ROM de 250ns o incluso 300ns de latencia que no iba a cambiar la frecuencia de reloj ni la velocidad de la CPU (Tiene un margen de hasta 520ns: 130ns por ciclo con, como mínimo 4 ciclos y luego puede transferir hasta 16 bits "en un viaje"), mientras que en SNES aumenta/reduce el número de ciclos necesarios para acceder a esa lectura de 6 a 8 ciclos del reloj maestro (funcionando a 3,58MHz o a 2,68MHz en acceso) limitando transferencias a un bus de 8bits.

La recriminación entonces creo que viene del hecho de "capar" su propia CPU para abaratar costes a cambio de rendimiento. Y que es notorio cuando pasan un juego con slowdowns constantes a Fast-ROM y se eliminan la mayoría o reducen esos tiempos. Por eso la gente se queja de ello o llama más la atención.

Ya sabes, se va a recriminar a cada sistema el punto débil del mismo: "Ojalá MD tuviera más colores, ojalá la CPU de SNES fuese más rápida, deberían haberle puesto a Dreamcast que pueda leer DvDs, Saturn es difícil de programar.." etc etc


Vamos que realmente la culpa es la arquitectura de la SNES y no de que las compañias ahorraran en costes, es que SNES necesita ROMS más rapidas para que la CPU vaya a la frecuencia maxima que soporte y ese problema no lo tiene la megadrive.

Leí que Nintendo cobraba a los desarrolladores de juegos una fortuna por los cartuchos, tenía una posición muy dominante y lógicamente la aprovechó.
Básicamente ofreció dos alternativas a desarrolladores, empresas... La barata y la cara con la esperanza de que en un futuro bajara el precio de las ROMs y poco a poco se fueran adoptando las rápidas. La realidad fue que por ahorrar un poco (en cada cartucho) muy muy pocos desarrollos se hicieron en FastROM 😂.
sgonzalez escribió:Básicamente ofreció dos alternativas a desarrolladores, empresas... La barata y la cara con la esperanza de que en un futuro bajara el precio de las ROMs y poco a poco se fueran adoptando las rápidas. La realidad fue que por ahorrar un poco (en cada cartucho) muy muy pocos desarrollos se hicieron en FastROM 😂.


Exacto para ahorrar 4 perras todos pagamos jugar con los personajes debajo del agua... pero bueno, la pela es la pela podría haber sacado SNES sin modo 7 y hubiera triunfado igual.
@naxeras Nintendo era una hija de puta de cuidado en su día. Limitaba las copias, se permitía no distribuir juegos a ciertas tiendas importantes si no pasaban por su aro, se dice que tenían hasta a la yakuza en diferentes lugares manejando el cotarro (hay que cogerlo con pinzas y no literal), no dejaban que las marcas editaran más de X juegos (creo que eran 5) al año lo que provocaba que algunas empresas tuvieran que crear otras "marcas" para poder seguir licenciando sus juegos. A Namco por ejemplo la trataban bien pero llegó un momento en el que Nintendo dijo que nanai de la china, privilegios ninguno, y aunque Namco intentó dejar a Nintendo de lado, al final pasó por el aro. Controlaban la fabricación de cartuchos, se quedaban con derechos, impuestos, ventas, distribución... De no ser por Sony no se qué panorama tendríamos ahora, que fue la que empezó en el mundillo ofreciendo mejores condiciones para todas las desarrolladoras.
Lázaro escribió:@naxeras Nintendo era una hija de puta de cuidado en su día. Limitaba las copias, se permitía no distribuir juegos a ciertas tiendas importantes si no pasaban por su aro, se dice que tenían hasta a la yakuza en diferentes lugares manejando el cotarro, no dejaban que las marcas editaran más de X juegos (creo que eran 5) al año lo que provocaba que algunas empresas tuvieran que crear otras "marcas" para poder seguir licenciando sus juegos. A Namco por ejemplo la trataban bien pero llegó un momento en el que Nintendo dijo que nanai de la china, privilegios ninguno, y aunque Konami intentó dejar a Nintendo de lado, al final pasó por el aro. Controlaban la fabricación de cartuchos, se quedaban con derechos, impuestos, ventas, distribución... De no ser por Sony no se qué panorama tendríamos ahora, que fue la que empezó en el mundillo ofreciendo mejores condiciones para todas las desarrolladoras.


Bueno y no lo hace ahora porque la multa que le caería sera astronomica.

Pero vamos todas las empresas hacen lo mismo hoy en día cuando se ven sin competencia, abusan todo lo que la legislación vigente las deja.
Lázaro escribió:.. De no ser por Sony no se qué panorama tendríamos ahora, que fue la que empezó en el mundillo ofreciendo mejores condiciones para todas las desarrolladoras.

Y mira en lo que se ha convertido jeje
@yamauchi Touché jajajaja
¿Esto no era un hilo técnico?
M68K escribió:
cirote3 escribió:Todo eso lo tenía más o menos claro, lo que no tengo claro es si en los juegos comerciales de la Mega Drive se configuraba el tiempo de lectura con una latencia similar a la del modo FastROM de la SNES. Por lo que he leído, la latencia mínima que se usó era 200ns, la misma que los cartuchos SlowROM de la SNES, y había juegos comerciales con mayor latencia. Por eso no entiendo que se le eche tanto en cara la velocidad de los cartuchos a Nintendo y a Sega no. Supongo que los cartuchos de Mega Drive permitían transmitir más datos por segundo a costa de tener mayor latencia.


Además de la mayor transferencia que comentas, en MD podías tener tranquilamente una ROM de 250ns o incluso 300ns de latencia que no iba a cambiar la frecuencia de reloj ni la velocidad de la CPU (Tiene un margen de hasta 520ns: 130ns por ciclo con, como mínimo 4 ciclos y luego puede transferir hasta 16 bits "en un viaje"), mientras que en SNES aumenta/reduce el número de ciclos necesarios para acceder a esa lectura de 6 a 8 ciclos del reloj maestro (funcionando a 3,58MHz o a 2,68MHz en acceso) limitando transferencias a un bus de 8bits.

La recriminación entonces creo que viene del hecho de "capar" su propia CPU para abaratar costes a cambio de rendimiento. Y que es notorio cuando pasan un juego con slowdowns constantes a Fast-ROM y se eliminan la mayoría o reducen esos tiempos. Por eso la gente se queja de ello o llama más la atención.

Ya sabes, se va a recriminar a cada sistema el punto débil del mismo: "Ojalá MD tuviera más colores, ojalá la CPU de SNES fuese más rápida, deberían haberle puesto a Dreamcast que pueda leer DvDs, Saturn es difícil de programar.." etc etc

Lo de que usar el modo SlowROM cambia la velocidad de la CPU no lo sabía. En la GBA supongo que funciona igual que en la Mega Drive o en otros sistemas: usar una configuración de ROM con más ciclos de espera no afecta en nada a la CPU. De hecho lo normal con ella es ejecutar el código "caliente" (el que más CPU chupa) en la IWRAM en vez de en la ROM, para que la ROM no frene a la CPU.
cirote3 escribió:Lo de que usar el modo SlowROM cambia la velocidad de la CPU no lo sabía. En la GBA supongo que funciona igual que en la Mega Drive o en otros sistemas: usar una configuración de ROM con más ciclos de espera no afecta en nada a la CPU. De hecho lo normal con ella es ejecutar el código "caliente" (el que más CPU chupa) en la IWRAM en vez de en la ROM, para que la ROM no frene a la CPU.


Desconozco mucho de la GBA, creo que es de los sistemas caseros que más partido le han sacado al pixelart en cuanto a colores, efectos etc y todo en una consola portátil. Ya que estás, quería preguntarte respecto a ella:

Leí si mal no recuerdo que es capaz de tener 2 planos rotando simultáneamente y que es incluso capaz de rotar sprites (no me refiero a rotaciones mediante cambio dinámico de tiles frame a frame para simularlo) pero de verdad... ¿Puedes poner todo ello simultáneamente en marcha sin problema? Las 2 BG, con los sprites rotando etc ¿sin tener que hacer demasiado sacrificio si es que lo hay?

El movimiento de perspectivas de Golden Sun al entrar en combate, las invocaciones y efectos de luz estaban a un nivel altísimo e iba todo genial, es como si si no tuviera mucho que sacrificar para hacerlo.
M68K escribió:
cirote3 escribió:Lo de que usar el modo SlowROM cambia la velocidad de la CPU no lo sabía. En la GBA supongo que funciona igual que en la Mega Drive o en otros sistemas: usar una configuración de ROM con más ciclos de espera no afecta en nada a la CPU. De hecho lo normal con ella es ejecutar el código "caliente" (el que más CPU chupa) en la IWRAM en vez de en la ROM, para que la ROM no frene a la CPU.


Desconozco mucho de la GBA, creo que es de los sistemas caseros que más partido le han sacado al pixelart en cuanto a colores, efectos etc y todo en una consola portátil. Ya que estás, quería preguntarte respecto a ella:

Leí si mal no recuerdo que es capaz de tener 2 planos rotando simultáneamente y que es incluso capaz de rotar sprites (no me refiero a rotaciones mediante cambio dinámico de tiles frame a frame para simularlo) pero de verdad... ¿Puedes poner todo ello simultáneamente en marcha sin problema? Las 2 BG, con los sprites rotando etc ¿sin tener que hacer demasiado sacrificio si es que lo hay?

El movimiento de perspectivas de Golden Sun al entrar en combate, las invocaciones y efectos de luz estaban a un nivel altísimo e iba todo genial, es como si si no tuviera mucho que sacrificar para hacerlo.


Ni idea xd

Pero en Gunstar Super Heroes, el jefe del primer nivel pinta a ser un plano+ sprites (puños y cabeza), y rota y zomea al completo.
El nivel donde vas volando encima de un artefacto, los helicópteros gigantes pintan a ser otro plano, y en ocasiones se ven dos a la vez con zoom, mientras rotan las bolas que te tiran. Luego hay otro boss en un octágono, pinta a que es como el primer jefe. O el nivel donde manejas una nave puedes rotar el escenario con L/R y los spirtes también rotan. Ese juego tiene de todo xD

Tampoco se si es lo que buscas (rotaciones y zooms "puros") o usan trucos de software o lo que sea. Pero ahí lo dejo.



Minutos: 05:57 / 09:32 / 37:01 / 44:09
M68K escribió:Leí si mal no recuerdo que es capaz de tener 2 planos rotando simultáneamente y que es incluso capaz de rotar sprites (no me refiero a rotaciones mediante cambio dinámico de tiles frame a frame para simularlo) pero de verdad... ¿Puedes poner todo ello simultáneamente en marcha sin problema? Las 2 BG, con los sprites rotando etc ¿sin tener que hacer demasiado sacrificio si es que lo hay?

La GBA tiene dos grupos de modos de vídeo:
  • Los "tiled": los que muestran fondos con tiles, como la SNES y la Mega Drive.
  • Los "bitmap": los que muestran fondos de tipo frame buffer, como la 32X.
La única diferencia entre los dos grupos en cuanto a sprites es que los modos "tiled" dejan 32KB para sprites y los modos "bitmap" dejan 16KB. Como la GBA usa bancos de memoria y paletas diferentes para sprites y para fondos, no afecta en nada el número o el tipo de fondos activos a la hora de mostrar sprites o de escribir en sus tiles o en sus paletas.

@7Force el Gunstar Heroes es junto con los Golden Sun el juego que mejor aprovecha la PPU de la GBA. En este jefe hay dos fondos y varios sprites rotando a la vez sin problemas:

@7Force @cirote3 ¡Gracias por los ejemplos! Es una burrada lo que hace en bosses de Gunstar Super Heroes. La escena del boss que parece After Burner mientras te siguen avionetas girando son una pasada.
M68K escribió:@7Force @cirote3 ¡Gracias por los ejemplos! Es una burrada lo que hace en bosses de Gunstar Super Heroes. La escena del boss que parece After Burner mientras te siguen avionetas girando son una pasada.

El "homenaje" al After Burner es lo mismo, dos fondos rotando (avión y nubes) y el resto sprites rotando. Se habla mucho de lo desaprovechadas que estuvieron otras consolas, pero lo de la GBA tiene delito XD
136 respuestas
Responder
1, 2, 3
Volver a Consolas clásicas