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.
Venimos de aquí y de aquí.

Conker64 escribió:que sabes de la capacidades 2D de las 3 consolas? No se te ve muy contento con las de N64.

Que conste que las únicas con las que he trasteado lo suficiente son la GBA y la N64, con la PSX y la Saturn no he hecho nada aunque me gustaría algún día:
  • Con la GBA puedes mostrar 4 capas de fondos y otras 4/5 a base de sprites a 60FPS, sin frenar a la CPU ya que tiene VRAM dedicada.
  • Con la Saturn puedes mostrar 5? capas de fondos a 60FPS, sin frenar a la CPU ya que tiene VRAM dedicada. El número de capas que se pueden mostrar con sprites a 60FPS dependerá del número de sprites, de su tamaño y de otros factores.
  • Con la PSX el número de capas que se pueden mostrar con sprites a 60FPS dependerá del número de sprites, de su tamaño y de otros factores, pero sin frenar a la CPU ya que tiene VRAM dedicada.

Y llegamos a la N64, con la que por culpa de la memoria unificada todo frena a todo. Con la GBA da igual que programes como el culo, que mientras llegues a tiempo al V-Blank la PPU va a mostrar un chorro de fondos y sprites a 60FPS sin problema. Con la N64, programar mal implica bajonazos de FPS por culpa del aumento de las esperas a la memoria. Eso no se suele ver en demos técnicas porque el código al ser pequeño no tiene muchas oportunidades de ahogar a la memoria, pero en juegos de verdad se nota y mucho. Igual en una demo técnica la N64 puede mostrar muchas capas a 60FPS, pero en un juego de verdad que use la CPU y el RSP para más cosas no va a poder hacer lo mismo.

Y aunque intentes hacer las cosas bien, subir texturas a la TMEM es lento, haciendo que mostrar una capa con muchos tiles únicos cueste mucho más que una capa con pocos tiles. A la GBA y a la Saturn se la pela el número de tiles únicos que tenga un fondo, siempre rinden igual. Con los sprites de la PSX y la Saturn me imagino que importará menos que con la N64 al tener VRAM dedicada.

Por lo que no, no estoy muy contento con la N64 en cuanto a 2D XD

Ahora estoy haciendo un juego 3D para la N64 y las dos cosas que más me están ayudando a mantener los FPS, mucho más que desactivar efectos como el antialias, es evitar usar el Z-Buffer en la medida de lo posible para no ahogar a la RAM y minimizar el número de texture swaps para tocar la TMEM lo menos posible y no ahogar a la RAM. La historia de siempre. También me toca las narices un poco el no poder usar el additive blending sin miedo ni trucos, pero bastante menos que lo de la RAM XD
@cirote3
Ah entiendo, sí, N64 puede ser un poco la maquina de los horrores y hace falta programar bien.

Tenía curiosidad, porque más allá de las cosas que hay que hacer bien, no la vi tan difícil para programar un juego completo en 2D, bueno, no nos engañemos, en 2016 era MUY difícil sacar un juego completo de calidad con otra cosa que no fuera libultra, en cuanto a rendimiento hay que guardar siempre un margen como comentas, porque según añades cosas se va saturando cada vez más al sistema, o dejando menos margen, eso incluye el audio.

Usas la IA como asistente? Es decir, no que te escupa el código o te programe ella sola, sino para preguntarle que es más acertado o que te revise código en busca de mejoras a nivel de ciclos?

Porque es fascinante la cantidad de rendimiento que puedes sacarle a esta consola en particular, es un no parar, desde caer en el error de usar siempre loadtile en lugar de loadblock, a más bajo nivel mantener atomic prim en set other modes (que igual el micro código moderno ya mete pausas entre primitivas, omitiendo esto), y bueno lo del Z-Buffer es un clásico.

O pensar en omitir la CPU, cuando puede hacer desplazamientos de línea, como efectos clásicos de raster 2D leyendo directamente del framebuffer, es rápida con bloques alineados, en según que casos más que el chip gráfico, como para dibujar pequeñas partículas de pocos pixels, para otras cosas no.
Conker64 escribió:@cirote3
Ah entiendo, sí, N64 puede ser un poco la maquina de los horrores y hace falta programar bien.

Tenía curiosidad, porque más allá de las cosas que hay que hacer bien, no la vi tan difícil para programar un juego completo en 2D, bueno, no nos engañemos, en 2016 era MUY difícil sacar un juego completo de calidad con otra cosa que no fuera libultra, en cuanto a rendimiento hay que guardar siempre un margen como comentas, porque según añades cosas se va saturando cada vez más al sistema, o dejando menos margen, eso incluye el audio.

Hoy en día hacer un juego 2D con libdragon es muy fácil, otra cosa es que rinda como debe XD

Conker64 escribió:Usas la IA como asistente? Es decir, no que te escupa el código o te programe ella sola, sino para preguntarle que es más acertado o que te revise código en busca de mejoras a nivel de ciclos?

No me gusta usar la IA para hacer homebrew. Para mejorar el rendimiento la herramienta que más me ha ayudado ha sido el Ares 64, un fork del Ares del autor del Tiny3D que entre cosas cosas te muestra los comandos del RDP en cada fotograma, los fallos de la caché, etc:
@cirote3
Hay mucho manazas o que? [sonrisa] En su día hice cosas funcionales, assets con copyright que no publiqué, ahora veo un viva la pepa todo el mundo subiendo ports con patreon y aquí no pasa nada, no vi problema para mantener los 60fps, lo que más destruía el rendimiento de todo lo que hice es un port de la libogg, por como trabajaba el mixer de audio de aquella libdragon, y que vamos, tampoco creo que sea el formato ideal para reproducir en tiempo real, pero se llevaba tranquilamente un 40% del rendimiento total.

Me apunto el emu, me quedé desactualizado con CEN64.

Usas Tiny3D conjuntamente con libdragon?
Conker64 escribió:En su día hice cosas funcionales, assets con copyright que no publiqué, ahora veo un viva la pepa todo el mundo subiendo ports con patreon y aquí no pasa nada

Ya ves XD

Conker64 escribió:no vi problema para mantener los 60fps, lo que más destruía el rendimiento de todo lo que hice es un port de la libogg, por como trabajaba el mixer de audio de aquella libdragon, y que vamos, tampoco creo que sea el formato ideal para reproducir en tiempo real, pero se llevaba tranquilamente un 40% del rendimiento total.

Yo estoy usando ULC para reproducir música y VADPCM para sonidos. El ULC te comprime una canción de 3 minutos a 44100Hz a menos de medio mega y reproducirla baja solo un par de FPS, va genial.

Conker64 escribió:Me apunto el emu, me quedé desactualizado con CEN64.

Sigue haciendo falta una N64 de verdad para medir los FPS, ahora mismo hay unos 10FPS de diferencia en lo que estoy haciendo entre el Ares y la N64. Aparte de eso está genial, emula muy bien el RDP con los fallos gráficos y eso.

Conker64 escribió:Usas Tiny3D conjuntamente con libdragon?

Sí, yo creo que casi todo el mundo que usa Libdragon usa Tiny3D para el 3D. Las dos librerías lo ponen todo muy fácil.
181 respuestas
Responder
1, 2, 3, 4
Volver a Consolas clásicas