Si no se puede contestar a nivel técnico en el hilo de SNES para mostrar su funcionamiento y hacer ciertas comparativas mínimas para conocer los puntos fuertes/débiles de cada sistema, espero que en este hilo pueda hacerlo .
No te lo tomes como un ataque el que ahora te vaya a quotear, Ventura. Veo demasiado absolutismo quizás en varios puntos de tu comentario y otros puntos que sobre el papel parecen prometedores pero donde hay bastante más:
Señor Ventura escribió:Super pang con escenarios a 512x224 y una cantidad de bolas que amenaza con superar los 30 fragmentos por linea horizontalmente una vez iniciada su destrucción, parece casi diseñado para encajar especificamente en el hardware de la snes, porque además cualquier tamaño de bola requiere únicamente sprites cuadrados. Efectivamente, el cuanto se haya currado capcom el actual port no desmiente la capacidad del hardware.
Los escenarios de Super Pang de SNES no funcionan a 512x224 (pseudo Hi-res en Modo 1). Esta creencia viene dada por el flag activo de High Resolution Mode que se dejaron en la ROM
El registro $2133.3 está habilitado, pero eso no implica automáticamente que el juego esté emitiendo una señal de vídeo de 512×224.
Para comprender lo que sucede, podemos examinar el Visor de eventos de Mesen. Allí podemos verificar que, en la línea de exploración 225, el registro $2105 se establece en $09, configurando el Modo 1 estándar para todo el fotograma. No se realizan más escrituras en este registro durante la renderización, lo que nos permite descartar cualquier cambio dinámico de modo gráfico mientras se dibuja la pantalla.
En el mismo visor, así como en el visor de mapas de mosaicos, podemos ver que las capas 1 y 2 simplemente se superponen. No se combinan ni se utilizan para generar nuevos colores. Los registros de Matemáticas de Color ($2130 y $2131) permanecen en $00, lo que significa que esta funcionalidad no se está utilizando.
Además, los registros $212C y $212D muestran la misma configuración simultáneamente para la capa de pantalla principal (MSL) y la capa de subpantalla (SSL), con todas las capas habilitadas excepto BG4. Esto indica que tampoco se utilizan para aumentar la resolución, sino simplemente para superponer capas.
Para que el modo Pseudo Alta Resolución controlado por el registro $2133 proporcione una resolución horizontal real de 512 píxeles, la Pantalla Principal y la Pantalla Secundaria deben enviar información diferente a la PPU para que esta pueda intercalarlas píxel a píxel. Si quisiéramos que el Modo 1 se comportara como un modo de pseudo alta resolución, la Capa de Pantalla Principal y la Capa de Pantalla Secundaria necesitarían configuraciones diferentes:
Main: ACEGI
sub: BDFHJ
Pero lo que realmente tenemos es:
Main: AAAAA
Sub: AAAAA
Lo que significa que no se obtiene ni se amplía información adicional. Además, la posible ganancia de resolución sólo se ve afectada por el fondo. Los sprites siguen moviéndose sobre su propia capa de 256x224, tampoco obtienen ganancias de desplazamiento efectivo de área. Aquí sólo se ganaría detalle visual de fondo, aumentando el contraste para con los sprites en calidad de nitidez, cosa que se puede percibir rara por la diferencias de resoluciones de las diferentes capas.
Señor Ventura escribió:una cantidad de bolas que amenaza con superar los 30 fragmentos por linea horizontalmente una vez iniciada su destrucción
En el Super Pang de arcade no hay ningún momento en el que se lleguen alineare 30 objetos en una misma línea. Este es el punto donde verás el máximo de objetos alineados en una misma línea, y porque el mapa está diseñado para ello:
Parece que ocupe toda la pantalla pero "sólo" hay 20 bolas. En un sistema como MD donde la limitación se mantiene en 20 sprites por línea, aún poniendo 20 bolitas en este escenario concreto y, sabiendo de antemano con qué inercia y velocidad van, se puede agrupar 2 bolas en sprites de 16x8 teniendo cada uno de los tiles internos de ese sprite su propio hitbox en el que si una de estas bolas impacta, genera un sprite de 8x8 con una sóla bola a cambio.
El hecho de que puedas pensar que se puedan alinear 30 objetos en Super Pang es porque nos tragamos
el principio de proximidad, el principio de semejanza y el principio de continuidad del effecto GESTALTDe hecho, añado aquí un gameplay en el arcade de Super Pang para quien quiera que indique en qué momento se alinean 20 bolas en la misma línea lejos del ejemplo que he puesto:
https://youtu.be/cOKZ7RcsjlQ?si=nGejBJBECJ9TTkqySeñor Ventura escribió:Para empezar, todo juego de disparos encaja directamente mejor en la arquitectura de snes
En el hilo de FF2, concluías que la selección de tamaños de sprites de 16x16 y 32x32 no era algo tan eficiente como el uso de 8x8 y 32x32 basándote en puntuales momentos de "derroche" cuando usaba sprites de 16x16 para pintar 3 píxeles concluyendo que no estaba optimizado.
Aquí haces justo lo contrario: Justificas un punto concreto beneficioso para esta configuración para afirmar que el diseño global de un juego de disparos encaja mejor en SNES que en cualquier otro sistema.
Claro, tú pones en un papel al personaje al borde disparando una serie de proyectiles de izquierda a derecha y los 32 sprites por línea máximos, encajan.
Pero existen técnicas como las comentadas de Super Pang donde puedes añadir sprites horizontales donde cada tile dentro de ellos pudiera llevar su propio hitbox y que actuasen como objetos individuales:
Bastaría con cambiar cada tile interior de estos sprites de 32x8 las líneas que representan el Laser (−) por bolitas que encajen en tiles de 8x8 (◉).
*Como curiosidad, la imagen que he puesto se forma usando 21 sprites totales sin la necesidad de querer cubrir la línea a base del uso de 32 sprites de 8x8. La flexibilidad y eficiencia de diferentes tamaños de sprites simultáneos no es ninguna invención, sino una realidad objetiva.
Luego también sería posible realizar el clásico truco del parpadeo sincronizado para los proyectiles en caso de temer superar el máximo de sprites por línea:
O incluso combinar varios efectos como el parpadeo sincronizado y la búsqueda del desvío vertical de un "rayo" realizando "S" horizontalmente para evitar ese limitante concreto que mencionas:
Además de lo descrito, el uso de sobremanera de los 32 sprites por línea se dan en casos puntuales (en elq ue estás a un lado de la pantalla) y está bien tenerlo en cuenta, pero en un Run&Gun un personaje se mueve y desplaza el scroll mientras este está, generalmente en el centro de la pantalla. Un juego de disparos no sólo se compone tampoco de sprites de 8x8 en todos los aspectos, de hecho, hacerlo así hace que quemes demasiadas entradas OAM y recordemos que el máximo que puede dibujar 128 sprites de 8x8, que viene a ser poco más del 14% del total de la pantalla.
¿El límite de 32 sprites por línea sirve para evitar en la medida de lo posible el flickering cuando se dispara horizontalmente? Por supuesto.
¿Es más fácil a nivel de programación usar estos sprites de 8x8 para un juego de disparos y no tener que aplicar técnicas con variables para ahorrar tiempo de desarrollo y comerte menos la cabeza? Claro que sí.
¿Esto es un indicativo en el que podamos concluir que la arquitectura de la máquina fue diseñada para juegos de disparos? Ni mucho menos.
Es una capacidad a la que se le puede sacar provecho en diversas situaciones. Pero como dije antes, una ventaja concreta no convierte a un sistema en algo inherentemente más eficiente en un género sin ver ni estudiar todos los matices que el propio género demanda.
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
), abro este hilo para hablar de temas técnicos de consolas 2D (y arcades si hacen falta) y hacer las comparativas entre sistemas que hagan falta sin que nadie se ofenda ni acuse de off-topic 
![[plas]](/images/smilies/aplauso.gif "Aplausos")
![[jaja]](/images/smilies/nuevos2/otrasonrisa.gif "otra sonrisa")
