Hilo técnico de consolas 2D

Responder
1, 2, 3, 4
Yo tuve el primer modelo de GBA y suerte que la pude vender a tiempo por que era estafa de campeonato. Prácticamente imposible de ver nada a la que te diera un mínimo de luz externa.

La Micro mil veces mejor. El Gunstar Se ve increíble en esa pantallita.
@7Force
Totalmente de acuerdo.
Solo un único pero a modo totalmente personal, cuando me compre mis micros podía jugar como un campeón, ahora no uso ninguna de ellas. Como mucho, solo tengo la vista suficiente para poder mirar la caja de la Micro 25 aniversario de Mario y admirarla [qmparto]
NAILIK escribió:@7Force
Totalmente de acuerdo.
Solo un único pero a modo totalmente personal, cuando me compre mis micros podía jugar como un campeón, ahora no uso ninguna de ellas. Como mucho, solo tengo la vista suficiente para poder mirar la caja de la Micro 25 aniversario de Mario y admirarla [qmparto]

La SP 101 tiene una pantalla lo suficientemente grande como para que los cuarentones como yo no nos perdamos nada :)
@cirote3
Es una de las pocas gameboys que no tengo, y 3,5", aunque también sea pequeña, si que se hace mucho más jugable que la pantalla de reloj inteligente que tiene la micro [qmparto]
Mientras llega el momento de completar la colección de GB, cuando me apetece jugar a mi cartuchada, uso la NDS Phat o Lite, aunque cada vez tiro más por la comodidad de las "consolas" emuladoras si es para una partida rápida. Lo sé, iré al infierno y con razón [hallow]
NAILIK escribió:@cirote3
Es una de las pocas gameboys que no tengo, y 3,5", aunque también sea pequeña, si que se hace mucho más jugable que la pantalla de reloj inteligente que tiene la micro [qmparto]
Mientras llega el momento de completar la colección de GB, cuando me apetece jugar a mi cartuchada, uso la NDS Phat o Lite, aunque cada vez tiro más por la comodidad de las "consolas" emuladoras si es para una partida rápida. Lo sé, iré al infierno y con razón [hallow]

Para mí la Micro y la SP 101 tienen pantallas mejores que la DS Phat y la Lite. Es una putada que las GBAs no se puedan dormir como las DSs, tienes que tenerlas enchufadas al cargador si no quieres perder la partida por la noche.
PHANTASIA escribió:Si la GBA era tan superior por qué apestaban tanto gráficamente la trilogía DKC por ejemplo?
La gente suele echarle flores al 3 de GBA pero aun ese era MUY inferior al de SNES, con los colores super quemados...


Eso es porque salió sin pantalla retroiluminada y para que se vieran mejor los colores los saturaban a morir y después al usarlos en pantallas retroiluminadas se veian mal. Hay parches para corregirlo: https://gbatemp.net/threads/donkey-kong ... on.508587/

Lo otro es que al ser portátil usa resolución 240x140 así que los ports tenian que rediseñar los gráficos. A la hora de valorar la GBA hay que mirar sus mejores juegos nativos o cosas como que es capaz de emular NES y SMS decentemente bien y la PCE la emula aunque no fluida.

Edit: Por lo visto también emula a la propia SNES aunque no fluidamente: https://www.youtube.com/watch?v=MHRwrSwhrKE
SuperPadLand escribió:
PHANTASIA escribió:Si la GBA era tan superior por qué apestaban tanto gráficamente la trilogía DKC por ejemplo?
La gente suele echarle flores al 3 de GBA pero aun ese era MUY inferior al de SNES, con los colores super quemados...


Eso es porque salió sin pantalla retroiluminada y para que se vieran mejor los colores los saturaban a morir y después al usarlos en pantallas retroiluminadas se veian mal. Hay parches para corregirlo: https://gbatemp.net/threads/donkey-kong ... on.508587/

Lo otro es que al ser portátil usa resolución 240x140 así que los ports tenian que rediseñar los gráficos. A la hora de valorar la GBA hay que mirar sus mejores juegos nativos o cosas como que es capaz de emular NES y SMS decentemente bien y la PCE la emula aunque no fluida.

Edit: Por lo visto también emula a la propia SNES aunque no fluidamente: https://www.youtube.com/watch?v=MHRwrSwhrKE

Yo jugué en la GBA a algunos juegos de la SNES sin problemas (y sin sonido) en su día, los que más me gustaban eran el Super Pang y el Aero Fighters.
Tiene buena pinta éste intento:
https://www.youtube.com/watch?v=UwDIsBemYnc

Obvio los colores y algunos efectos o detalles quizás se pierdan, pero puede ganar mucho con el aumento de resolución pues uno de los problemas del original es que el scroll puede ser brusco a veces; salvo eso el juego no es más que prerrenderizado no mueve muchas cosas, y la música está quedando sorprendentemente bien.

Hubo dos tech demos de Pyron intentando resolver algunos efectos como la niebla o la miel de abeja, bastante resultones:
https://www.youtube.com/watch?v=NGqG2QcrXq0
https://www.youtube.com/watch?v=1fW0EJUe3fk

Sin saber si avanzará o se terminará, quizás al menos sirva para enterrar el donkey kong 99 como intento canónico de replicarlo [tomaaa]
https://www.youtube.com/watch?v=Bc2cTjyX_dw
Venimos de aquí:

Kim Hwan escribió:;)

La Mesa No Es El Límite - Rompiendo el supuesto límite de "380 sprites" del #NeoGeo

Presentado en estilo demoscene

Capturado desde hardware real sin hardware extra acelerándolo.

Lo lanzaré como descarga para probar en tu flashcart pronto



Confirman que la Neo Geo puede multiplexar sprites, pasando de los 380:


EDIT

Venimos de aquí:

chinitosoccer escribió:
cirote3 escribió:Para que haya menos parpadeos en la Supergrafx que en la Mega Drive hay que repartir bien todos los sprites entre los dos VDPs. Si todos o casi todos los sprites se muestran con un solo VDP, va a haber más parpadeos.


Eso te lo hace el HuC6202 Video Priority Controller de forma automatizada programandolo con el Hu-SDK, segun turboxray, "sin desperdiciar practicamente nada de ambos VDPs, lo que permite directamente duplicar el rendimiento casi como si se tratara de 1 solo VDP el doble de potente", lo que si es una limitación insalvable es la VRAM que no es unificada ni accesible entre ambos, el VDP1 no puede leer ni escribir en la VRAM del otro y viceversa.

No, ese chip lo que hace principalmente es ordenar las cuatro capas de los dos VDPs (dos de fondo y dos de sprites). Es el programador quien tiene que repartir los sprites entre los dos VDPs, y si no lo hace bien y muestra todos o casi todos los sprites con el mismo VDP, va a haber más parpadeos que en la Mega Drive.

Hacer el reparto de sprites no es fácil porque:
  • Todos los sprites de un VDP se muestran antes o después que los del otro VDP, sus prioridades no se pueden entremezclar.
  • Cada VDP tiene su propia VRAM, por lo que si quieres mostrar el mismo sprite con los dos VDPs, tienes que tener los tiles del sprite duplicados en los dos VDPs.
Aquí hay más info: https://github.com/MiSTer-devel/TurboGr ... gxtech.txt
Yo estaba haciendo referencia a la hora portear assets de un VDP cualquiera, llamese NES, SNES, Megadrive, Neogeo, CPS1 etc al VDP o al VDC+dual VDP de PC Engine o Supergrafx usando el HUC-SDK pero bueno...
chinitosoccer escribió:Yo estaba haciendo referencia a la hora portear assets de un VDP cualquiera, llamese NES, SNES, Megadrive, Neogeo, CPS1 etc al VDP o al VDC+dual VDP de PC Engine o Supergrafx usando el HUC-SDK pero bueno...

Puede que el SDK que mencionas permita hacer el reparto de sprites de forma automática, pero el chip del que hablabas no tiene nada que ver con ello.

¿Puedes enlazar las funciones de ese SDK que permiten hacer el reparto de sprites de forma automática? ¿Algún ejemplo que las use?
cirote3 escribió:Puede que el SDK que mencionas permita hacer el reparto de sprites de forma automática, pero el chip del que hablabas no tiene nada que ver con ello.

¿Puedes enlazar las funciones de ese SDK que permiten hacer el reparto de sprites de forma automática? ¿Algún ejemplo que las use?


Lo leí de TurboXray , el tio que estaba con el Daimakaimura arcade edition de Supergrafx a 384x224, el autor de los Hacks SGX de R-Type y la demo del Hu-Zero, Axelay etc.
edito: Hasta donde se se trata de un fork del HUCC de autoría propia, el tio no responde mensajes ni comparte la mayoría de sus trabajos, aunque el Fork si lo ha leberado.
chinitosoccer escribió:
cirote3 escribió:Puede que el SDK que mencionas permita hacer el reparto de sprites de forma automática, pero el chip del que hablabas no tiene nada que ver con ello.

¿Puedes enlazar las funciones de ese SDK que permiten hacer el reparto de sprites de forma automática? ¿Algún ejemplo que las use?


Lo leí de TurboXray , el tio que estaba con el Daimakaimura arcade edition de Supergrafx a 384x224, el autor de los Hacks SGX de R-Type y la demo del Hu-Zero, Axelay etc.
edito: Hasta donde se se trata de un fork del HUCC de autoría propia, el tio no responde mensajes ni comparte la mayoría de sus trabajos, aunque el Fork si lo ha leberado.

¿Tienes el link del fork? Es por ver cómo funciona el reparto automático.
cirote3 escribió:¿Tienes el link del fork? Es por ver cómo funciona el reparto automático.


No, pero hasta donde sé debería ser el mismo que esta usando este tio con Master Linkuei para el hack SGX del Strider, y Master tiene cuenta en EOL si mal no recuerdo.

Snes escribió:

El creador del 65816 y el diseñador principal del Apple 2 con un 65816 como CPU puede que no fueran los más fiables con ese tema, ¿no? XD
@cirote3 me da gracia por qué yo pensé lo mismo 😂
La realidad es que la CPU de la SNES no es más rápida que la de la MD, ni equivalente.
Este video esta interesante habla de la familia deCPU 6502
Da el apaño.
stormlord escribió:La realidad es que la CPU de la SNES no es más rápida que la de la MD, ni equivalente.

Todos sabemos que la CPU de la SNES no es más rápida ni equivalente a la CPU de la MD, son de arquitecturas diferentes, pero tampoco hay una diferencia de la luna a la tierra como muchos quieren poner, al final son dos CPU de 16 bit con diferentes registros y formas de trabajar. Podrías aporta datos técnicos a tu comentario todos queremos aprender.
Snes escribió:


Un 65816 de 8MHZ puede ser tan rapido como un 68000 de la misma velocidad de reloj....en depende que situaciones, eso es sabido desde siempre, por supuesto, pero lo que cuesta creer es que un WDC 65C816 a 3.58mhz como el de SNES este a la altura de un 68000.
Snes escribió:
stormlord escribió:La realidad es que la CPU de la SNES no es más rápida que la de la MD, ni equivalente.

Todos sabemos que la CPU de la SNES no es más rápida ni equivalente a la CPU de la MD, son de arquitecturas diferentes, pero tampoco hay una diferencia de la luna a la tierra como muchos quieren poner, al final son dos CPU de 16 bit con diferentes registros y formas de trabajar. Podrías aporta datos técnicos a tu comentario todos queremos aprender.

Solo lo dije porque lo que remarcas en la imagen no se aplica entre SNES y MD, nada más.
@stormlord no , no se aplica a las consolas como tal se aplica a las CPU y sus forma de trabajo.
@chinitosoccer
Según es artículo: CPU snes 3.58Mhz x2= 7.16Mhz este es el equivalente en rendimiento si el procesador de la SNES fuera un Motorola, según el artículo. Claro hay otros factores que influyen no solo es la velocidad de CPU
MD: Motorola a 7.67Mhz , pero al final de el día la CPU de la MD es mejor ,de eso no hay dudas.
Snes escribió:
stormlord escribió:La realidad es que la CPU de la SNES no es más rápida que la de la MD, ni equivalente.

Todos sabemos que la CPU de la SNES no es más rápida ni equivalente a la CPU de la MD, son de arquitecturas diferentes, pero tampoco hay una diferencia de la luna a la tierra como muchos quieren poner, al final son dos CPU de 16 bit con diferentes registros y formas de trabajar. Podrías aporta datos técnicos a tu comentario todos queremos aprender.


Ya sólo en la diferencia de hz creo que no habría que mirar mucho más pero tomando sólo las CPU y nada más del sistema, la de MD soporta multiplicar y dividir negativos, ancho de registro de datos de 32bits con bus de 16bits (SNES de 16bits con bus de 8), desplazamiento multiple de hasta 8 bits (SNES sólo 1), etc.

SNES tiene alguna cosa propia que MD no como multiplicar y dividir de forma asíncrona.

Pero es que el punto fuerte de SNES no es la CPU sino sus PPU y el como la CPU se apoya en ellas, por ejemplo la CPU delega en el PPU las multiplicaciones de matrices que es lo que se usa para escalados y rotaciones y en MD no hay equivalmente a esto ni en CPU ni en VDP ni combinadas ambas.

Cada máquina tiene sus cosas y el software de ellas ya deja claro lo que pueden y no pueden hacer mejor que la otra.
@SuperPadLand efectivamente, muy buena tu explicación 👍🏻
En este aspecto, tienden a haber mediciones erróneas en la comparativa de estas CPUs. Unos miden los MHz, otros comparan los MIPS (Millones de Imprecisiones Penosas por Segundo) cuando ni las instrucciones son equiparables, ni los ciclos tienen la misma velocidad, ni el nº de instrucciones para una misma tarea poseen la necesidad de los mismos ciclos ni necesitan la misma cantidad de instrucciones para una tarea concreta.

En este aspecto se suele escuchar:
"La CPU de MD tiene más MHz pero la de SNES es más eficiente porque sus instrucciones requieren la mitad de ciclos"

Y entonces... ¡BOOM! Se comentan las métricas comentadas sin sentido en comparaciones varias donde no hay nada comparable si no empezamos a buscar una estadística común: El tiempo X Tarea.

Es aquí donde realicé una comparativa con cálculos sobre la velocidad de los ciclos en nanosegundos, el número de ellos necesario para cada instrucción y las instrucciones necesarias para cada tarea (una tarea como "mover un objeto A al punto B y realizar comparaciones de eficiencia en TIEMPO)
https://vrtay16bitgen.wordpress.com/2026/06/28/68000-vs-65c816-when-cycles-lie-and-nanoseconds-dont/

Puse algunos símiles que, ayuda bastante a entenderlo si se hace muy espeso. Dejo este ejemplo aquí que puse de manera escrita y visual para entender la diferencia entre una memoria lineal y una segmentada:
Imagen

Por supuesto hablo de los puntos fuertes de cada CPU como es la multiplicación de 8bits más rápida en SNES, pero matizo su uso ya que se limita a valores de 0 a 255 lo que en estos sistemas sin coma flotante, limita su uso cuando hay físicas avanzadas o cálculos que requieran valores de 16 bits o superiores donde los LUTs serían más aconsejables para según tarea y tiempo.

También nombro la capacidad del direct page del 65C816 para el acceso rápido a variables dentro de la RAM. MD no dispone de esta función pero tiene su sentido ya que al disponer de 16 registros de 32 bits no requiere tanto acceso a RAM para cálculos y punteros como lo hace el 65C816 al disponer de un acumulador de 16 bits y dos registros de índice.

Es una comparativa en crudo con declaraciones sobre eficiencia de devs como TiagoSC o Suganami que trabajaron con ambos sistemas. Aquí no entran los chips gráficos donde cada una tiene lo suyo en diferencia de resoluciones, modos, colores, manejo de planos, accesos a VRAM durante el renderizado... ese punto es otro mundo a parte.
176 respuestas
Responder
1, 2, 3, 4
Volver a Consolas clásicas