Completo dossier técnico/comparativo entre Megadrive y Super Nintendo

Hoy es un buen día para los cuenta-pixeles. Enhorabuena.

SNES; Lacra de resolución de confort, y que le cuesta mover a 60 fps el campo de los sprites.

MD; lacra de paleta y falta de puto blitter para escalados y hostias. Porque vale que el M68k es el puto mejor micro de su gen, pero si le tienes asfixiado de CPU a una INFRAfrecuencia, pues demasiado que te Rota un par de sprites vía DMA joder. Si estuviese a pleno potencial como en la Recre de Out Run otro gallo cantaría.

Neo Geo lacra de catálogo monotemático, pero Bendito fillrate * _*

Una pena no se haya explotado el uso de la posible retrocompatibilidad con el 6502 para el uso de juegos de NES en Super.
(Sin tener en cuenta los periféricos extraoficiales, licenciados o de 3ºs, que me veo ya al pato poniendome un Super 8, Tri-Star, Retro Port & Cía ).

grandes esos supern nintenderos!!! yo me considero un fanatico de los 8 y 16 bits, coleccionista de nes y snes.

@Sexy MotherFucker , sobre la MD, una pregunta, lo que comentas que la lastra, en 1988 cuando sale al mercado, si hubiera salido con las correcciones que hablas, ¿hubiera encarecido el precio?, ¿Si, no?, ¿Tanto como para hacerse inviable en la época?.

Creo que no hay que perder de vista que sale en 1988, imagino que la paleta de colores no tiene lógica, ya que si no estoy equivocado la de la Pc Engine es superior, y no se hasta que punto encarece o no el producto.

Saludos.

DonVeneno escribió:grandes esos supern nintenderos!!! yo me considero un fanatico de los 8 y 16 bits, coleccionista de nes y snes.

Aquí otro. Y también Game Boy!

aranya escribió:@Sexy MotherFucker , sobre la MD, una pregunta, lo que comentas que la lastra, en 1988 cuando sale al mercado, si hubiera salido con las correcciones que hablas, ¿hubiera encarecido el precio?, ¿Si, no?, ¿Tanto como para hacerse inviable en la época?.

Creo que no hay que perder de vista que sale en 1988, imagino que la paleta de colores no tiene lógica, ya que si no estoy equivocado la de la Pc Engine es superior, y no se hasta que punto encarece o no el producto.

Saludos.

La PC engine tiene la misma paleta de 9 bits que la Mega (512 colores), pero tiene la ventaja de que tiene 16 paletas para fondos, y 16 paletas para sprites, lo que en teoría te permite hasta 480 colores simultáneos. A cambio, tiene menos sprites, solo una capa de fondo, y los tiles del fondo no tienen capacidad de mirroring.

Las dos máquinas tienen la misma cantidad de VRAM, solo que la Mega aprovecha la ram para guardar las nametables de dos planos enteros, mientras que la PCEngine solo guarda uno, pero puede guardar 32 paletas de 16 en lugar de 4 (Y las nametables de pcengine codifican la paleta con 4 bits, mientras que la mega solo en dos)

Sexy MotherFucker escribió:SNES; Lacra de resolución de confort, y que le cuesta mover a 60 fps el campo de los sprites.

Meeeec xD

Inténtalo otra vez.

yuragalo escribió:Una pena no se haya explotado el uso de la posible retrocompatibilidad con el 6502 para el uso de juegos de NES en Super.
(Sin tener en cuenta los periféricos extraoficiales, licenciados o de 3ºs, que me veo ya al pato poniendome un Super 8, Tri-Star, Retro Port & Cía ).

Es por el sistema de vídeo, que no son ni siquiera equivalentes.

Señor Ventura escribió:Es por el sistema de vídeo, que no son ni siquiera equivalentes.

Me imagino que las PPU de ambas máquinas diferirán bastante, además del sistema de ranuran/pines, pueden que habrá también diferencias en los bus de datos, puede incluso voltajes... (suposiciones mías).
Pero a lo que voy es sigue siendo una pena no haber buscado una manera de posibilitar y haber hecho realidad la retrocompatibilidad entre ambas .
No recuerdo ningún un periférico oficial de Nintendo que lo permitiera al estilo Super GB (al menos desconozco si existe, a excepción de los mencionados antes).

@kusfo79 , gracias por la info.

Un saludo.

Pero la parte de la SNES tiene el velo de la nostalgia o no?

Gammenon escribió:Pero la parte de la SNES tiene el velo de la nostalgia o no?

Hay cosas incorrectas.

No tiene un ancho de banda de 5,72KB, ni son 256 pixels de sprites por scanline, ni direcciona solo 4MB... y en general hay muchos detalles de ese harware que nunca se comentan, ni aparecen fácilmente en ninguna publicación, como por ejemplo el hecho de que puedes acceder a instrucciones de multiplicación de hasta 24 bits del PPU1 gracias a una instrucción de la cpu específicamente creada para acceder a partes externas de la misma... o a que las tiles de 2BPP pesan solo 16 bytes, duplicando así el ancho de banda efectivo... o a que es una bestia haciendo interrupciones, o accediendo/leyendo/escribiendo en memoria dentro de un mismo ciclo (ciertas instrucciones llevan hasta 5, 6, o incluso 8 ciclos ser ejecutadas, pero no son los 32, o incluso mas ciclos que necesitan otras cpu's).

@Señor Ventura

Lo de los 256 pixels de sprites como máximo por línea, hasta donde yo se, si que es correcto (ojo que no soy un experto en super). Al menos en las documentaciones que he visto por ahí hay:

Maximum colors per layer per scanline: 256.
Maximum colors on-screen: 32,768 (using color arithmetic for transparency effects).
Resolution: between 256x224 and 512x448.
Maximum onscreen objects (sprites): 128 (32 per line, up to 34 8x8 tiles per line).
Maximum number of sprite pixels on one scanline: 256.

Por otro lado, los tiles de 2bpp se limitan a un plano en los modos 4 y 5, o a 4 planos en modo 0. Creo que pocos juegos usan el modo 0, y en los otros casos, esa ventaja en el ancho de banda lo tienes solo en un plano.

Y sobre la multiplicación que comentas, yo conocía una rutina en assembler que permitía una multiplicación mucho más rápida usando los registros de la PPU, pero no se puede usar si en ese momento estas usando algunos efectos de la PPU, como por ejemplo el modo 7.

Señor Ventura escribió:No tiene un ancho de banda de 5,72KB, ni son 256 pixels de sprites por scanline, ni direcciona solo 4MB...

No he leído el artículo, pero efectivamente, puede direccionar hasta 128 Megabits, lo que pasa es que sólo 95Mbit de ROM, el resto es shadow RAM, registros y demás... Hay una manera de direccionar 127Megabits de ROM, pero tienes que diseñar tus propias placas para eso con el decodificador de direcciones apropiado.

Lo del ancho de banda depende de si se refiere entre ROM a RAM, RAM a RAM, ROM a VRAM o RAM a VRAM.
Pero lo de 256 píxeles de sprites por scanline claro que es cierto, ya que la resolución máxima horizontal es 256 píxeles en modo normal, y en el modo Hi-Res, no puedes poner más de esos 32 sprites de 8x8 en un scanline.

Señor Ventura escribió:puedes acceder a instrucciones de multiplicación de hasta 24 bits del PPU1 gracias a una instrucción de la cpu específicamente creada para acceder a partes externas de la misma...

What the fuck????

Señor Ventura escribió:o a que las tiles de 2BPP pesan solo 16 bytes, duplicando así el ancho de banda efectivo...

¿Duplicar con respecto a qué? Una tile 8x8 de 2BPP pesa 16 bytes ya que en 1 byte tienes una línea de 8 pixeles de un BPP, y en el siguiente byte tienes la misma línea de 8 píxeles pero para el otro BPP... ¿Qué es lo que duplicas exactamente?

Señor Ventura escribió: pero no son los 32, o incluso mas ciclos que necesitan otras cpu's).

¿Qué CPU necesita 32 ciclos de acceso a memoria? ¿No te estarás liando por los accesos a DRAM o SDRAM, que son diferentes, no?

kusfo79 escribió:Por otro lado, los tiles de 2bpp se limitan a un plano en los modos 4 y 5, o a 4 planos en modo 0. Creo que pocos juegos usan el modo 0, y en los otros casos, esa ventaja en el ancho de banda lo tienes solo en un plano.

Y en el modo 1 también se usan planos 2BPP. Este tipo de planos es útil para hacer sombreados, transparencias o meter texto así que no es una limitación que sólo haya un plano 2BPP; además, aunque se usa en pocos modos, son precisamente los modos gráficos más usados y extendidos de la SNES.

kusfo79 escribió:Y sobre la multiplicación que comentas, yo conocía una rutina en assembler que permitía una multiplicación mucho más rápida usando los registros de la PPU, pero no se puede usar si en ese momento estas usando algunos efectos de la PPU, como por ejemplo el modo 7.

No, cualquier multiplicación arbitraria (no 2^n) tarda más en ensamblador que en hardware. Lo que comentas es que se puede usar el registro de multiplicación de matrices para hacer multiplicaciones de 16bits * 8 bits (es decir, multiplicaciones de 24 bits), pero si lo estás usando para girar una matriz de perspectiva del modo 7, entonces tienes que multiplexar el acceso a dicho multiplicador, unas veces para girar el plano, otra para hacer la multiplicación arbitraria...

kusfo79 escribió:@Señor Ventura

Lo de los 256 pixels de sprites como máximo por línea, hasta donde yo se, si que es correcto (ojo que no soy un experto en super). Al menos en las documentaciones que he visto por ahí hay:

Por eso digo que son datos que no te encuentras fácilmente, y que siempre aparecen mal.

Son 272 pixels por scanline, y en el modo de alta resolución son 304 pixels por scanline (que como el plano de los sprites sigue funcionando a 256x224/239, aumenta mas aún el fill rate efectivo).

kusfo79 escribió:Por otro lado, los tiles de 2bpp se limitan a un plano en los modos 4 y 5, o a 4 planos en modo 0. Creo que pocos juegos usan el modo 0, y en los otros casos, esa ventaja en el ancho de banda lo tienes solo en un plano.

No, tu puedes usar tiles de 2bpp en cualquier plano, en cualquier momento. La única limitación que tienes es que si usas una tile de 2bpp en un plano habilitado para 4bpp, u 8bpp, ya no podrás poner tiles de esa profundidad (4bpp u 8bpp), en ese plano.

Lo que si puedes hacer es usar un plano de 4bpp, u 8bpp, y usar un plano en el que estes dibujando tiles de 2bpp para cambiar su prioridad, y ponerlo junto a los tiles de 4bb y 8bpp (nota que ahora no digo "u", sino "y", porque puedes mezclarlos usando este truco, pero estaría bien que magno confirmara todo esto si tiene algo de tiempo).

Es decir, tu tienes un plano de 4bpp para dibujar una montaña, y luego un plano de 2bpp detrás para dibujar unas nubes. Detrás de las montañas hay un montón de espacio que no vas a ver nunca lo que hay detrás, y puedes usar a modo de "buffer" con tiles que vas a cambiar de prioridad para ponerlo en el plano de 4bpp de las montañas, porque puedes coger cualquier tile, y cambiarla de plano, de altura, y de longitud

Una pasada, vamos.

kusfo79 escribió:Y sobre la multiplicación que comentas, yo conocía una rutina en assembler que permitía una multiplicación mucho más rápida usando los registros de la PPU, pero no se puede usar si en ese momento estas usando algunos efectos de la PPU, como por ejemplo el modo 7.

Te lleva 8 ciclos de reloj ejecutar esa instrucción, y aún así es mas rápido ejecutarla que en el 68000, y encima luego tienes unas ventajas tremendas con el ppu de apoyo.

Solo hay que tener dos consideraciones. La primera, como bien dices, es que no puedes usar el ppu para tareas de multiplicación si te encuentras en el modo 7, porque ya se están reservando para calcular el plano de ese modo gráfico... pero con el resto de modos si puede usarse perfectamente.

Y la segunda, que por lo visto te sale mas a cuenta usar instrucciones de multiplicación del ppu de 16 bits, que las instrucciones de 24 bits. Esto se lo leí a magno, y no quise preguntar porque ya le tenemos estallado al pobre, y no quise molestar, pero algún día indagaré en los "porqueses", y tal xD

P.D: ¡¡¡Quiero esa rutina, por dios!!!!... ¿la tienes a mano? (estoy intentando hacerme una librería para cuando pueda volcarme a tope con esto).



editado: aprovecho que ya estás aquí.

magno escribió:Lo del ancho de banda depende de si se refiere entre ROM a RAM, RAM a RAM, ROM a VRAM o RAM a VRAM.
Pero lo de 256 píxeles de sprites por scanline claro que es cierto, ya que la resolución máxima horizontal es 256 píxeles en modo normal, y en el modo Hi-Res, no puedes poner más de esos 32 sprites de 8x8 en un scanline.

Son 272 pixels, pero ahora mismo dudo si puedes dibujar hasta 272 si intercalas sprites de 8x8, con sprites de otro tamaño.

34 sprites de 8x8 son 272 pixels.

magno escribió:

Señor Ventura escribió:puedes acceder a instrucciones de multiplicación de hasta 24 bits del PPU1 gracias a una instrucción de la cpu específicamente creada para acceder a partes externas de la misma...

What the fuck????

El 65816 tiene una instrucción para acceder al modo de multiplicación externo del ppu de la consola, y te leí decir que son de hasta 24 bits, pero que no merece la pena usar palabras de mas de 16.

magno escribió:

Señor Ventura escribió:o a que las tiles de 2BPP pesan solo 16 bytes, duplicando así el ancho de banda efectivo...

¿Duplicar con respecto a qué? Una tile 8x8 de 2BPP pesa 16 bytes ya que en 1 byte tienes una línea de 8 pixeles de un BPP, y en el siguiente byte tienes la misma línea de 8 píxeles pero para el otro BPP... ¿Qué es lo que duplicas exactamente?

Perdón... duplicas el número de tiles a transferir que con respecto al modo normal. Es como si tuvieses el doble de ancho de banda.

xD

magno escribió:

Señor Ventura escribió: pero no son los 32, o incluso mas ciclos que necesitan otras cpu's).

¿Qué CPU necesita 32 ciclos de acceso a memoria? ¿No te estarás liando por los accesos a DRAM o SDRAM, que son diferentes, no?

No tengo ni papa del 68000, pero si necesita 4 veces mas ciclos de reloj que el 65816... me juego 5 céntimos a que tiene cifras de ese estilo leyendo/escribiendo/ejecutando instrucciones.

Hola @magno , gracias por los aportes, como he comentado, no soy un experto en SNES, así que nos ayuda mucho que aportes tu granito de arena

magno escribió:

kusfo79 escribió:Por otro lado, los tiles de 2bpp se limitan a un plano en los modos 4 y 5, o a 4 planos en modo 0. Creo que pocos juegos usan el modo 0, y en los otros casos, esa ventaja en el ancho de banda lo tienes solo en un plano.

Y en el modo 1 también se usan planos 2BPP. Este tipo de planos es útil para hacer sombreados, transparencias o meter texto así que no es una limitación que sólo haya un plano 2BPP; además, aunque se usa en pocos modos, son precisamente los modos gráficos más usados y extendidos de la SNES.
.

Pensaba que el modo 1 era todo a 3bpp, por eso pensaba que los de 2bpp se aplicaban a los otros modos que he comentado.

magno escribió:

kusfo79 escribió:Y sobre la multiplicación que comentas, yo conocía una rutina en assembler que permitía una multiplicación mucho más rápida usando los registros de la PPU, pero no se puede usar si en ese momento estas usando algunos efectos de la PPU, como por ejemplo el modo 7.

No, cualquier multiplicación arbitraria (no 2^n) tarda más en ensamblador que en hardware. Lo que comentas es que se puede usar el registro de multiplicación de matrices para hacer multiplicaciones de 16bits * 8 bits (es decir, multiplicaciones de 24 bits), pero si lo estás usando para girar una matriz de perspectiva del modo 7, entonces tienes que multiplexar el acceso a dicho multiplicador, unas veces para girar el plano, otra para hacer la multiplicación arbitraria...

Vale, sabía que era usar de forma "creativa" registros de la PPU, pero no tenía claro exactamente la manera

Ahora me ha salito tu mensaje @Señor Ventura , contesto lo tuyo:

Señor Ventura escribió:

kusfo79 escribió:@Señor Ventura

Lo de los 256 pixels de sprites como máximo por línea, hasta donde yo se, si que es correcto (ojo que no soy un experto en super). Al menos en las documentaciones que he visto por ahí hay:

Por eso digo que son datos que no te encuentras fácilmente, y que siempre aparecen mal.

Son 272 pixels por scanline, y en el modo de alta resolución son 304 pixels por scanline (que como el plano de los sprites sigue funcionando a 256x224/239, aumenta mas aún el fill rate efectivo).

Lo de los sprites es lo que había leído, pero claro, a veces esto no se corresponde con la realidad. Ojo que magno ha dicho que el valor correcto si es 256.

Señor Ventura escribió:

kusfo79 escribió:Por otro lado, los tiles de 2bpp se limitan a un plano en los modos 4 y 5, o a 4 planos en modo 0. Creo que pocos juegos usan el modo 0, y en los otros casos, esa ventaja en el ancho de banda lo tienes solo en un plano.

No, tu puedes usar tiles de 2bpp en cualquier plano, en cualquier momento. La única limitación que tienes es que si usas una tile de 2bpp en un plano habilitado para 4bpp, u 8bpp, ya no podrás poner tiles de esa profundidad (4bpp u 8bpp), en ese plano.

Entiendo que esto que dices, es cambiar el modo del plano "al vuelo"? por que de fábrica no creo que el Hardware sea capaz de eso.

Señor Ventura escribió:

kusfo79 escribió:Y sobre la multiplicación que comentas, yo conocía una rutina en assembler que permitía una multiplicación mucho más rápida usando los registros de la PPU, pero no se puede usar si en ese momento estas usando algunos efectos de la PPU, como por ejemplo el modo 7.

Te lleva 8 ciclos de reloj ejecutar esa instrucción, y aún así es mas rápido ejecutarla que en el 68000, y encima luego tienes unas ventajas tremendas con el ppu de apoyo.

Solo hay que tener dos consideraciones. La primera, como bien dices, es que no puedes usar el ppu para tareas de multiplicación si te encuentras en el modo 7, porque ya se están reservando para calcular el plano de ese modo gráfico... pero con el resto de modos si puede usarse perfectamente.

Y la segunda, que por lo visto te sale mas a cuenta usar instrucciones de multiplicación del ppu de 16 bits, que las instrucciones de 24 bits. Esto se lo leí a magno, y no quise preguntar porque ya le tenemos estallado al pobre, y no quise molestar, pero algún día indagaré en los "porqueses", y tal xD

P.D: ¡¡¡Quiero esa rutina, por dios!!!!... ¿la tienes a mano? (estoy intentando hacerme una librería para cuando pueda volcarme a tope con esto).

La rutina de multiplicación la vi aquí: https://en.wikibooks.org/wiki/Super_NES_Programming/multiplication

Señor Ventura escribió:Son 272 pixels por scanline, y en el modo de alta resolución son 304 pixels por scanline (que como el plano de los sprites sigue funcionando a 256x224/239, aumenta mas aún el fill rate efectivo).

No, ya te he contestado antes, son 256 píxeles de resolución horizontal. Super Nintendo no tiene ningún modo de 304 píxeles horizontales, no sé de dónde sacas esos datos

Señor Ventura escribió:No, tu puedes usar tiles de 2bpp en cualquier plano, en cualquier momento. La única limitación que tienes es que si usas una tile de 2bpp en un plano habilitado para 4bpp, u 8bpp, ya no podrás poner tiles de esa profundidad (4bpp u 8bpp), en ese plano.

Que va, tampoco sé de dónde sacas eso.... Si tienes un plano 4BPP, por supuesto que puedes usar una tile que solo tenga 2 colores, o 4, o 5, pero la tile seguirá ocupando en VRAM el tamaño de una tile 4BPP y tu paleta en CGRAM tendrá el tamaño de 16 colores. PEro claro que puedes seguir usando en ese plano tiles de 4BPP... Creo que no tienes el concepto de BPP bien pillado; 2BPP indica que para ese plano todas las tiles tienen 2 bits para cada píxel de la tile, por lo que las paletas de CGRAM se "reconfiguran" para que tengan 4 colores cada una (realmente lo que pasa es que se direcciona una parte de CGRAM a saltos de 4 colores según el valor en el tilemap).

Señor Ventura escribió:Es decir, tu tienes un plano de 4bpp para dibujar una montaña, y luego un plano de 2bpp detrás para dibujar unas nubes. Detrás de las montañas hay un montón de espacio que no vas a ver nunca lo que hay detrás, y puedes usar a modo de "buffer" con tiles que vas a cambiar de prioridad para ponerlo en el plano de 4bpp de las montañas, porque puedes coger cualquier tile, y cambiarla de plano, de altura, y de longitud

Una pasada, vamos.

Si la tile es 2BPP no puedes "pasarla" a un plano 4BPP por las buenas. No sé de dónde sacas esa información tan errónea. Si tienes una tile 4BPP la puedes "poner" en cualquier plano 4BPP, pero ojo porque depende del Tile Base Address de cada plano: si un plano tiene el Tile Address en $0000 de VRAM y otro en $6000 de VRAM, o tienes duplicado el tileset (es decir, las tiles) o no podrás cambiar una tile de plano sólo cambiando su tilemap.

Señor Ventura escribió:Y la segunda, que por lo visto te sale mas a cuenta usar instrucciones de multiplicación del ppu de 16 bits, que las instrucciones de 24 bits. Esto se lo leí a magno, y no quise preguntar porque ya le tenemos estallado al pobre, y no quise molestar, pero algún día indagaré en los "porqueses", y tal xD

Te sale más a cuenta usar la del multiplicador primero porque normalmente las multiplicaciones no son de 24 bits, sino de 16bits, y segundo porque para usar el registro de matrices del Modo 7 tienes que esperar al HBlank, creo que para evitar que se interfiera con los cálculos del modo 7; por eso decía antes lo de usarlo multiplexado.

Sexy MotherFucker escribió:SNES; Lacra de resolución de confort, y que le cuesta mover a 60 fps el campo de los sprites.

Eso de que no puede mover sprits a 60fps es una cosa que desde hace unos meses la gente de este foro se está inventando y no sé cuál es su fundamento. Si me dibujas una animación de un personaje a 60 fps, me comprometo a meterlo en una ROM de demo de SNES y te lo muevo a 60fps si quieres.

También he leído el artículo que la MEgadrive puede mover independientemente 2-3 planos de scrolll.... Y la SNES 4, pero eso no lo dice... Me parece que ese artículo ni es objetivo ni presenta datos técnicos basados en pruebas. Es más de lo mismo, fanboyismo al máximo nivel.

@magno

Gracias magno, me cuadran más tus respuestas, que me parecía un hardware muy raro que hiciera lo que @Señor Ventura comentaba....

kusfo79 escribió:@magno

Gracias magno, me cuadran más tus respuestas, que me parecía un hardware muy raro que hiciera lo que @Señor Ventura comentaba....

A mi me parece raro todo lo que comenta @Señor Ventura... ¿de dónde saca esa información? Me tiene intrigadísimo!!!

Hay gente que no se cansa de pasar vergüenza

Ya llegó el cansino.

Vergüenza me daría a mi comportarme como vosotros.

No contamineis el hilo, y sed constructivos.

@Señor Ventura
Intenta buscar fuentes fiables, y si ya te va el tema técnico, bichear un poco a programar algo. Te dará una mejor comprensión de como funcionan las cosas. Por ejemplo, el tema de los tiles de 2BBP mezclados con tiles de otras profundidades es algo que técnicamente me parecía muy raro (por como tendría que ser un chip que permitiera eso)

Señor Ventura escribió:Son 272 pixels, pero ahora mismo dudo si puedes dibujar hasta 272 si intercalas sprites de 8x8, con sprites de otro tamaño.

34 sprites de 8x8 son 272 pixels.

No son 272 píxeles, nunca lo ha sido, di de dónde sacas esa información, de verdad que quiero saberlo...
En cualquier documento técnico de SNES verás que la resolución horizontal estándar es 256, y la Hi-Res, 512 píxeles.

34 sprites de 8x8 NO son 272 píxeles, ya que los sprites no tienen por qué estar consecutivos uno al lado de otro. Si todos están en la coordenada (0, 0) de pantalla, ocuparían 8 píxeles de alto y 8 de ancho.

Y no le des más vueltas, son 256 píxeles de resolución horizontal

Señor Ventura escribió:El 65816 tiene una instrucción para acceder al modo de multiplicación externo del ppu de la consola, y te leí decir que son de hasta 24 bits, pero que no merece la pena usar palabras de mas de 16.

No es cierto. Dime qué instrucción es si lo tienes tan claro. A los multiplicadores se accede a través de los registros de la PPU $4202 y $4203. A los del modo 7 en los registros $211b/1C/1D/1E. No hay ninguna instrucción para acceder a ellos, es simplemente un acceso de escritura a una dirección del mapa de memoria como cualquier otra, pero ha de ser dentro del banco $00, o en una zona "shadow" de ese banco.

Te he linkado mil veces esta página, y lo vuelvo a hacer:

https://wiki.superfamicom.org/

Aquí podrás confirmar lo que te digo.

Señor Ventura escribió:No tengo ni papa del 68000, pero si necesita 4 veces mas ciclos de reloj que el 65816... me juego 5 céntimos a que tiene cifras de ese estilo leyendo/escribiendo/ejecutando instrucciones.

Lo dudaba horrores cuando te he escrito antes, pero con uns simple búsqueda de google te confirmo que no es verdad lo que decías:

https://retrocomputing.stackexchange.com/questions/2905/68000-and-memory-access-speed

Hablan de 8 ciclos típicamente de acceso a DRAM.

@magno Estoy en el trabajo, y no me puedo extender.

Decía que la resolución horizontal es de 256 pixels, pero que puedes dibujar 272 pixels de sprites.

Vamos, que no he dicho que la resolución sea de 272x224, ni nada por el estilo.

Y en el modo alta resolución, el campo de los sprites sigue siendo de 256x224, pero el fill rate aumenta hasta los 304 pixels.

Señor Ventura escribió:@magno Estoy en el trabajo, y no me puedo extender.

Decía que la resolución horizontal es de 256 pixels, pero que puedes dibujar 272 pixels de sprites.

Vamos, que no he dicho que la resolución sea de 272x224, ni nada por el estilo.

Y en el modo alta resolución, el campo de los sprites sigue siendo de 256x224, pero el fill rate aumenta hasta los 304 pixels.

Insisto en que quiero saber tus fuentes de información, porque no sé de dónde sacas eso...


Así se dibujan los sprites:

Drawing the Sprites

As with everything else on the SNES, sprites are drawn per-scanline. The process is basically as follows:

If any OBJ is at X=256 (or X=-256, same difference), consider it as being at X=0 when considering Range and Time. Note that this doesn't mean you actually draw it at X=0.

Range: Starting with the FirstSprite, determine the first 32 sprites on this scanline. Only those sprites with -size < X < 256 are considered in Range. If there are more than 32 sprites on the scanline, set bit 6 of register $213e.

Time: Starting with the last sprite in Range, load up to 34 8x8 tiles (from left-to-right, after flipping). If there are more than 34 tiles in Range, set bit 7 of $213e. Only those tiles with -8 < X < 256 are counted.

Associate with each tile in Range and Time its true X position (256/-256 should not be set to 0), palette, and priority for drawing.

Como ves en la última línea, sólo se dibujan las tiles en Rango y Tiempo, y en rango sólo puede haber 32 sprites.

Ahora, hay un giro enrevesado en el que igual estás pensando ¿Qué pasa si los primeros 31 sprites en una misma scanline son 8x8 (31 tiles por tanto) y el último es 16x16 (4 tiles más), es decir 35 tiles en total? Habrían 32 sprites cargados en memoria, todos dentro del intervalo Rango, y de las 35 tiles 8x8, las 34 primeras dentro del intervalo Tiempo corresponden a los 31 sprites 8x8, a la parte de arriba 8x8+8x8 del último sprite (el de tamaño 16x16) y la parte inferior izquierda 8x8 de éste ...
Entonces, como el último sprite es 16x16, realmente estarías dibujando 31 sprites * 8 + 1 sprite * 16 = 264 píxeles, y del último sprite NO estarías dibujando la tile 8x8 de abajo a la derecha.
Pero vamos, esto es muy enrevesado y tengo mis dudas de que se dibujaran los 264 pixeles; mi voto es que se dibujarían sólo 256 casi 100% seguro.

magno escribió:

Sexy MotherFucker escribió:SNES; Lacra de resolución de confort, y que le cuesta mover a 60 fps el campo de los sprites.

Eso de que no puede mover sprits a 60fps es una cosa que desde hace unos meses la gente de este foro se está inventando y no sé cuál es su fundamento. Si me dibujas una animación de un personaje a 60 fps, me comprometo a meterlo en una ROM de demo de SNES y te lo muevo a 60fps si quieres.

Debe ser porque asocián frames a fluidez, cuando no necesariamente es lo mismo, y como en muchos juegos de snes se puede apreciar esa falta de fluidez, pues claro.. Además, es que estamos en territorio PAL, y en el caso de snes las diferencias entre pal y ntsc suelen estar bastante marcadas. Es normal que muchos tengan esa impresión sobre sus juegos; no la veo desacertada, sino que simplemente no tiene por qué tener relación con los frames generales.

gynion escribió:Debe ser porque asocián frames a fluidez, cuando no necesariamente es lo mismo, y como en muchos juegos de snes se puede apreciar esa falta de fluidez, pues claro.. Además, es que estamos en territorio PAL, y en el caso de snes las diferencias entre pal y ntsc suelen estar bastante marcadas. Es normal que muchos tengan esa impresión sobre sus juegos; no la veo desacertada, sino que simplemente no tiene por qué tener relación con los frames generales.

Es posible que sea como dices, ya que al poner muchos sprites en pantalla hay que calcular muchas cosas y la CPU se convierte en un cuello de botella; pero eso depende de la cantidad de sprites, cómo se gestionen y demás.
Pero vamos, que he comprobado con una demo que hice hace un par de años que, sin detectar colisiones entre ellos, se podían mover unos 50 personajes (que prácticamente llenaban los 128 sprites de la tabla OAM) sin ningún problema por transferir las tiles a VRAM.

magno escribió:

gynion escribió:Debe ser porque asocián frames a fluidez, cuando no necesariamente es lo mismo, y como en muchos juegos de snes se puede apreciar esa falta de fluidez, pues claro.. Además, es que estamos en territorio PAL, y en el caso de snes las diferencias entre pal y ntsc suelen estar bastante marcadas. Es normal que muchos tengan esa impresión sobre sus juegos; no la veo desacertada, sino que simplemente no tiene por qué tener relación con los frames generales.

Es posible que sea como dices, ya que al poner muchos sprites en pantalla hay que calcular muchas cosas y la CPU se convierte en un cuello de botella; pero eso depende de la cantidad de sprites, cómo se gestionen y demás.
Pero vamos, que he comprobado con una demo que hice hace un par de años que, sin detectar colisiones entre ellos, se podían mover unos 50 personajes (que prácticamente llenaban los 128 sprites de la tabla OAM) sin ningún problema por transferir las tiles a VRAM.

Sí, ese tiene que ser el tipo de sprites que utilizan para escombros, fragmentos de explosiones, particulas u otros elementos meramente visuales, ¿no? Luego al querer meterle IA o hitbox igual es cuando la cosa se complica.

128 sprites =/= 128 objetos.

Quizá se debería utilizar éste hilo para tratar temas técnicos, aprovechando que tiene información y los aportes de magno.

Nunca voy a entender el porque la necesidad de tantos datos tecnicos, si luego la verdadera magia esta en la programacion

Obvio que el programador necesita estar enterado de cada detalle, pero da igual la CPU, el VDP, la ram o lo que sea, la magia sale del codigo

Si no es para programar, realmente los detalles tecnicos no son mas que unas cifras que no dicen nada de ninguna maquina


No he visto el link en profundidad, creo que de MD se le escapa alguna cosa y equivoca en otra, no habla de pal, ntsc, transferencias pasivas/activas, el plano window, que se yo, lo que si es bueno, es que da links a los doc de macdonald, que salvo algunas cosas q estan erroneas (creo q se hablo de eso en spritemind) son documentos que valen oro, exelentes, cualquiera q quiera aprender sobre la MD deve leerlos

theelf escribió:Nunca voy a entender el porque la necesidad de tantos datos tecnicos, si luego la verdadera magia esta en la programacion

Obvio que el programador necesita estar enterado de cada detalle, pero da igual la CPU, el VDP, la ram o lo que sea, la magia sale del codigo

Si no es para programar, realmente los detalles tecnicos no son mas que unas cifras que no dicen nada de ninguna maquina


No he visto el link en profundidad, creo que de MD se le escapa alguna cosa y equivoca en otra, no habla de pal, ntsc, transferencias pasivas/activas, el plano window, que se yo, lo que si es bueno, es que da links a los doc de macdonald, que salvo algunas cosas q estan erroneas (creo q se hablo de eso en spritemind) son documentos que valen oro, exelentes, cualquiera q quiera aprender sobre la MD deve leerlos

Los datos técnicos en sí de esa manera que hablas los usa un forero en especial (Señor Ventura) continuamente para refutar sus argumentos en su mayoría basados en datos erróneos sin contrastar, pero que presenta como irrefutables, en el caso de foreros como Magno, Gasega68k o Bmb64... se muestran para argumentar las preguntas que se les hacen o para explicar sus labores de programación.

Más de una vez estos foreros han corregido a algunos, pero en especial al que continuamente "saca" datos a relucir para darle peso a sus argumentos, este post es una muestra de ello.

Esa es la diferencia principal, todavía seguimos esperando que Señor Ventura deje de lanzar balones fuera que ayer tuvo toda la noche para joder otro hilo, perdón, para contestar a Magno que cuales son sus fuentes para refutar los disparates que dice sin los tiene bien puestos y entender su idiosincrasia de todos están contra mí. Aunque como es rutina, vendrán unas risitas falsas xD xD ante alguien que sabe como Magno, enfocar el tema solo en mi y no en Magno o darle un total enfoque de que todos estamos locos menos el verdadero loco al que todos señalan día tras día que va loco. Sin acritud.

Algo interesante entre la costra, gracias por el articulo (y sus enlaces)

CapcomRyu escribió:Los datos técnicos en sí de esa manera que hablas los usa un forero en especial (Señor Ventura) continuamente para refutar sus argumentos en su mayoría basados en datos erróneos sin contrastar, pero que presenta como irrefutables, en el caso de foreros como Magno, Gasega68k o Bmb64... se muestran para argumentar las preguntas que se les hacen o para explicar sus labores de programación.

Lo que me de la gana decir no es asunto tuyo.

Y que en su mayoría no estén contrastados lo dices tu.

CapcomRyu escribió:Más de una vez estos foreros han corregido a algunos, pero en especial al que continuamente "saca" datos a relucir para darle peso a sus argumentos, este post es una muestra de ello.

Que quede claro, a ver si así conseguimos que se una mas gente en esta cruzada.

CapcomRyu escribió:Esa es la diferencia principal, todavía seguimos esperando que Señor Ventura deje de lanzar balones fuera que ayer tuvo toda la noche para joder otro hilo, perdón, para contestar a Magno que cuales son sus fuentes para refutar los disparates que dice

Te has tenido que quedar a gusto.

Así que, según tu lógica tu propio mensaje no jode ningún hilo... hasta que por fín logreis que os conteste, y entonces ya si, señor ventura jode los hilos.

CapcomRyu escribió:sin los tiene bien puestos y entender su idiosincrasia de todos están contra mí. Aunque como es rutina, vendrán unas risitas falsas xD xD

Porque no hay motivos, claro.

CapcomRyu escribió:ante alguien que sabe como Magno, enfocar el tema solo en mi y no en Magno o darle un total enfoque de que todos estamos locos menos el verdadero loco al que todos señalan día tras día que va loco. Sin acritud.

Sin acritud, si.

Ni ganas, tampoco. Se nota.

xD

Aunque como es rutina, vendrán unas risitas falsas xD xD ante alguien que sabe como Magno, enfocar el tema solo en mi y no en Magno o darle un total enfoque de que todos estamos locos menos el verdadero loco al que todos señalan día tras día que va loco. Sin acritud.

ya estais otra vez enredaos....

Señor Ventura escribió:

CapcomRyu escribió:Los datos técnicos en sí de esa manera que hablas los usa un forero en especial (Señor Ventura) continuamente para refutar sus argumentos en su mayoría basados en datos erróneos sin contrastar, pero que presenta como irrefutables, en el caso de foreros como Magno, Gasega68k o Bmb64... se muestran para argumentar las preguntas que se les hacen o para explicar sus labores de programación.

Lo que me de la gana decir no es asunto tuyo.

Y que en su mayoría no estén contrastados lo dices tu.

A ver, no es cuestión de hacer leña del árbol caído, pero si que muchos de los datos que comentas en los hilos, no están contrastados.

kusfo79 escribió:A ver, no es cuestión de hacer leña del árbol caído, pero si que muchos de los datos que comentas en los hilos, no están contrastados.

Yo tampoco quiero cargar contra @Señor Ventura porque le pone ganas, pero creo que el 90% de las aportaciones suyas que leo son erróneas. E insisto que, o tiene unas fuentes incorrectas y debería de dejar de leerlas, o saca conclusiones precipitadas y no contrastadas de cómo funciona la SNES.
Y lo peor es que así le hace un flaco favor precisamente a la máquina de sus amores, ya que están quedando escritos muchos datos aportados por él que quien los lea en un futuro, podría terminar por aprender conceptos erróneos.

Yo tambien denuncie el tema hace tiempo y se me tildó de troll o hater, veo que a todo Ventura le llega su San Martín

Nada, tambien es verdad lo que dice magno, le pone muchas ganas y se nota que sabe un huevo, y si ahora le diera por pirarse clásicas decaeria bastante. Dicho de otro modo, su presencia es necesaria porque aunque la mayoria de veces aporte datos de manera inexacta, su mera aportacion ayuda a enriquecer y dar vidilla a este decadente subforo.

Yo a lo que voy con decir que los datos tecnicos sobran demasiado en casi todos los hilos que leo, es que simplemente, no son indicadores reales de lo que realmente da una maquina

No es que sobren los datos tecnicos, todo lo contrario, a mi me gusta leer y disfrutar de estos datos, porque los necesito para poder progresar en mis conocimientos de una plataforma

Pero llegado un punto, no son mas que indicadores sin mas trasfondo que los numeros, nada.

Podemos sentarnos a hablar de las paletas de la megadrive, y poner 10 paginas sobre ello, discutiendo lo que sea...

O tomar 20 minutos de nuestro tiempo, como hice recien, y por ejemplo, hacer un mapa usando los recursos de la megadrive, y postear algo que sobre el papel, es imposible de explicar




esto me llevo ni 20 minutos de hacer, y usa dos paletas, menos 3 colores reservados para barras.


Luego podemos discutir si gusta mas o menos, pero para mi... una imagen vale mas que mil palabras

@Remigio7

Nadie es indispensable, si se pira, que se pire, pena daría que se perdiera a Magno, Bmbx64, Gasega68k y muchos otros que aportan calidad. La persona que sabe, lo demuestra con datos, no con sarcasmos y datos sin contrastar cuando te los requieren, escribir es genial y te puedes volver loco hablando y juntando datos pero de ahi a demostrarlo va bastante. Se entiende que muchos callan por que defiende un gusto que otros comparten y lo dejan desvariar...o les apasiona las tanganas donde siempre está, pero esto no es sano para un foro con buenos datos, Magno lo dejo todo finiquitado.

@CapcomRyu

Todo el mundo que participe asiduamente es indispensable

Otra cosa.es luego q tratemos de revisar mas los datos que escribimos

@Señor Ventura
si una eminencia como magno te pregunta de dónde sacas esos datos tan detallados y al parecer erróneos, al menos podrías contestar y así salimos todos de dudas

theelf escribió:Yo a lo que voy con decir que los datos tecnicos sobran demasiado en casi todos los hilos que leo, es que simplemente, no son indicadores reales de lo que realmente da una maquina

No es que sobren los datos tecnicos, todo lo contrario, a mi me gusta leer y disfrutar de estos datos, porque los necesito para poder progresar en mis conocimientos de una plataforma

Pero llegado un punto, no son mas que indicadores sin mas trasfondo que los numeros, nada.

Podemos sentarnos a hablar de las paletas de la megadrive, y poner 10 paginas sobre ello, discutiendo lo que sea...

O tomar 20 minutos de nuestro tiempo, como hice recien, y por ejemplo, hacer un mapa usando los recursos de la megadrive, y postear algo que sobre el papel, es imposible de explicar




esto me llevo ni 20 minutos de hacer, y usa dos paletas, menos 3 colores reservados para barras.


Luego podemos discutir si gusta mas o menos, pero para mi... una imagen vale mas que mil palabras

Siento mi ignorancia pero, ¿de dónde es esa imagen?

Edit. Vale ya lo sé, ¿cuántos colores usa? Se ve bastante bien, en un crt se debe ver aun mejor.

Ese es un pedazo de ejemplo en el se ve como que limitando las tonalidades se pueden lograr cosas muy vistosas en Mega. Quizás el problema sería al meter a los luchadores, porque es posible que ese stage ya esté al límite de colores simultáneos, y deje muy poco margen para la variedad de tonos que pueden tener los sprites que se muevan por ahí.

CapcomRyu escribió:No hay más que decir. RIP.

Participar solo para reventar el foro.

Remigio7 escribió:Yo tambien denuncie el tema hace tiempo y se me tildó de troll o hater, veo que a todo Ventura le llega su San Martín

Será porque lo sois.

La opinión que me de la gana tener no debería quitaros tanto el sueño.

Remigio7 escribió:Nada, tambien es verdad lo que dice magno, le pone muchas ganas y se nota que sabe un huevo, y si ahora le diera por pirarse clásicas decaeria bastante. Dicho de otro modo, su presencia es necesaria porque aunque la mayoria de veces aporte datos de manera inexacta, su mera aportacion ayuda a enriquecer y dar vidilla a este decadente subforo.

Antes me arranco una oreja que compartir nada en este foro.

el terry escribió:@Señor Ventura
si una eminencia como magno te pregunta de dónde sacas esos datos tan detallados y al parecer erróneos, al menos podrías contestar y así salimos todos de dudas

Compartiré lo que me apetezca compartir, que es cero.

CapcomRyu escribió:@Remigio7

Nadie es indispensable, si se pira, que se pire, pena daría que se perdiera a Magno, Bmbx64, Gasega68k y muchos otros que aportan calidad. La persona que sabe, lo demuestra con datos, no con sarcasmos y datos sin contrastar cuando te los requieren, escribir es genial y te puedes volver loco hablando y juntando datos pero de ahi a demostrarlo va bastante. Se entiende que muchos callan por que defiende un gusto que otros comparten y lo dejan desvariar...o les apasiona las tanganas donde siempre está, pero esto no es sano para un foro con buenos datos, Magno lo dejo todo finiquitado.

Sano es aguantar a usuarios como tu que son capaces de seguir con la tontería de mostrar una animadversión por un usuario porque no se equivoca a favor de la consola que os gusta a vosotros.

No te olvides de seguir mencionándome en todo comentario que escribas.

theelf escribió:

Precioso

Manveru Ainu escribió:

theelf escribió:

Precioso

Pues en photoshop me sale que esa imagen usa 29 colores; o sea, todavía habría algo de margen para los sprites, ¿no?