¿Podría la Super Nes con un port 1:1 de Street of Rage II?

Kasios escribió:Es algo inevitable. Y digo yo, mientras no se llegue al insulto y/o a las descalificaciones personales que problema ahi?, es una forma de mover el hilo y darle vidilla

En efecto, si no se producen no hay ninguna pega. De hecho, si se producen con aportes y desde el respeto, pueden dar lugar a debates muy interesantes.
El problema viene cuando vienen las cosas que comentas, como ha pasado en otro hilo.

En cualquier caso, tienes razón, el hilo va bastante bien, y salvo pequeñas excepciones el ambiente ha sido muy bueno este verano.

Señor Ventura escribió:
No. La snes puede tener sprites incluso el doble de grandes que la pc engine, y 4 veces mas grandes que los de megadrive.

Y sobre los colores, la pc engine puede poner 15 colores por sprite, mientras que la snes puede poner 16. La diferencia está en la paleta de colores, que en snes se nota demasiado ese toque.

Si, como dije, esos datos en papel no significan nada, y ya que inisistís una y otra vez en tirar datos tecnicos sin ni siquiera haber programado nunca nada para ninguno de estos sistemas no queda mas remedio que hechar mano al "archivo", por ejemplo se dice que SNES es la que mas sprites puede poner en pantalla, pues bien:

Esta comprobado Snes puede dibujar 34 celdas de 8x8 lo que da como resultad (272 sprites por scanline) , lo dicen los manuales de desarrollo Oficiales y numerosas pruebas que se han hecho en el sistema real (que es super fácil de probar).

Pero...Laresolución de pantalla es de sólo 256 píxeles máximo, pero el ancho de banda de píxeles por sprites (como con Génesis / TG16) también se compone de píxeles invisibles "transparentes" en el mapa de bits del sprite.

Por lo que en situaciones muy extremas / casos específicos, snes pueden mostrar mas celdas de sprites por pantalla que los otros dos sistemas;

eso sería utilizando el modo de sprites 8x8 / 16x16. Esto es porque la tabla OAM (SAT) es de 128 entradas, de lo contrario seria excesivo para el sistema, por eso en practica la SNES es el más débil cuando se trata de sprites - porque está limitado a sólo dos tamaños de sprites por trama.

Mostrar sprites pequeños significa mayor sobrecarga en la decodificación por sprite, en un procesador que ya es lento desde el vamos, resultado? La mayoría de los juegos no utilizan esa configuración. En la mayoría de los casos se usa 16x16 / 32x32 es la configuración común para la mayoría de los juegos.

Megadrive tiene la mejor configuración de sprites, seguido de la Pc Engine y SuperGrafx. Sobre todo porque el modo 320x240 reescala el ancho de banda de píxeles de sprites para que coincida con la resolución. Puede hacer una mejor optimización de ancho de banda de píxeles de sprites en ese modo. los sprites al ser más pequeños horizontalmente se pueden poner mas por línea.

Ese es el problema con el examen de las características que salen en el papel, Lo que se ve no siempre equivale a lo mismo aplicado en el mundo real. El diablo siempre está en los detalles.

Es igual, el siguiente argumento es....

"El Cerebro de La Bestia.."

chinitosoccer escribió:

Señor Ventura escribió:
No. La snes puede tener sprites incluso el doble de grandes que la pc engine, y 4 veces mas grandes que los de megadrive.

Y sobre los colores, la pc engine puede poner 15 colores por sprite, mientras que la snes puede poner 16. La diferencia está en la paleta de colores, que en snes se nota demasiado ese toque.

Si, como dije, esos datos en papel no significan nada, y ya que inisistís una y otra vez en tirar datos tecnicos sin ni siquiera haber programado nunca nada para ninguno de estos sistemas no queda mas remedio que hechar mano al "archivo", por ejemplo se dice que SNES es la que mas sprites puede poner en pantalla, pues bien:

Esta comprobado Snes puede dibujar 34 celdas de 8x8 lo que da como resultad (272 sprites por scanline) , lo dicen los manuales de desarrollo Oficiales y numerosas pruebas que se han hecho en el sistema real (que es super fácil de probar).

Pero...Laresolución de pantalla es de sólo 256 píxeles máximo, pero el ancho de banda de píxeles por sprites (como con Génesis / TG16) también se compone de píxeles invisibles "transparentes" en el mapa de bits del sprite.

Por lo que en situaciones muy extremas / casos específicos, snes pueden mostrar mas celdas de sprites por pantalla que los otros dos sistemas;

eso sería utilizando el modo de sprites 8x8 / 16x16. Esto es porque la tabla OAM (SAT) es de 128 entradas, de lo contrario seria excesivo para el sistema, por eso en practica la SNES es el más débil cuando se trata de sprites - porque está limitado a sólo dos tamaños de sprites por trama.

Mostrar sprites pequeños significa mayor sobrecarga en la decodificación por sprite, en un procesador que ya es lento desde el vamos, resultado? La mayoría de los juegos no utilizan esa configuración. En la mayoría de los casos se usa 16x16 / 32x32 es la configuración común para la mayoría de los juegos.

Megadrive tiene la mejor configuración de sprites, seguido de la Pc Engine y SuperGrafx. Sobre todo porque el modo 320x240 reescala el ancho de banda de píxeles de sprites para que coincida con la resolución. Puede hacer una mejor optimización de ancho de banda de píxeles de sprites en ese modo. los sprites al ser más pequeños horizontalmente se pueden poner mas por línea.

Ese es el problema con el examen de las características que salen en el papel, Lo que se ve no siempre equivale a lo mismo aplicado en el mundo real. El diablo siempre está en los detalles.

Hombre, si partimos de la premisa de que la snes no tiene cpu, pues ya el resto del argumento te viene rodado.

Pero lo cierto es que el 65c816 es una cpu mas eficiente con la gestion de los sprites que el 68000, y segun su configuracion en ambas maquinas, la cosa se equipara.

claro que podría ser un port 1:1 o superior.

Señor Ventura escribió:
Pero lo cierto es que el 65c816 es una cpu mas eficiente con la gestion de los sprites que el 68000,

De vuelta, de donde sale eso????? realmente lees lo que escribes? a ti te parece que si un cpu basado en 65cXXX fuese realmente mejor manejando "graficos" no hubiese sido usado en mas sistemas como placas arcade y mas ordenadores personales de la época?? asi a simple vista solo fue usado en SNES y en una computadora de Apple, encima la version que lleva la SNES se trata de una version recortada del chip;

La SNES solo lleva un 65c816 porque el plan inicial de Nintendo era hacer que la SNES fuera retrocompatible con NES ya que el 65c816 posee registros de 8 bits derivados del 6502, punto.

No hay nada mas que eso, y es que se te va la mano un mundo al decir que es "mejor para graficos"????WTF?? ..... tela;

sobre todo cuando es un hecho que el 68000 puede trabajar incluso en 32 bits...si, cuando se trata de tareas en 16 y 32 bits el 68000 le patea el culo al 65c816, en lo unico que gana al 68000 es en tareas de 8 bits, pero no porque sea mas rapido sino porque para el 68000 le da igual trabajar en 8 o 16 bits, es igual de rapido, el 65c816 puede trabajar en 16 bits pero es muchismo mas lento que el 68000 en ese sentido;

Incluso en tareas de 8bits, el 65c816 sale perdiendo contra otros cpus mas viejos como por ejemplo el Hu6280A de Pc engine con sus 7mhz vs los 2,68 mhz comunes del 65c816 de SNES, si!! 2,68 putos mhz!!! no fue hasta los ultimos años de vida de SNES que los juegos comenzaron a utilizar los 3,58 mhz, y solo un par de juegos lo hicieron, el 80% del catalogo de SNES utiliza 2,68 mhz debido al cuello de botella que existe entre el 65c816 y la RAM de trabajo;

No es nada personal, pero me parece que a veces a los fanboys de Nintendo se les va un poco la mano, en serio....

chinitosoccer escribió:De vuelta, de donde sale eso????? realmente lees lo que escribes? a ti te parece que si un cpu basado en 65cXXX fuese realmente mejor manejando "graficos" no hubiese sido usado en mas sistemas como placas arcade y mas ordenadores personales de la época?? asi a simple vista solo fue usado en SNES y en una computadora de Apple, encima la version que lleva la SNES se trata de una version recortada del chip;

La SNES solo lleva un 65c816 porque el plan inicial de Nintendo era hacer que la SNES fuera retrocompatible con NES ya que el 65c816 posee registros de 8 bits derivados del 6502, punto.

No hay nada mas que eso, y es que se te va la mano un mundo al decir que es "mejor para graficos"????WTF?? ..... tela;

sobre todo cuando es un hecho que el 68000 puede trabajar incluso en 32 bits...si, cuando se trata de tareas en 16 y 32 bits el 68000 le patea el culo al 65c816, en lo unico que gana al 68000 es en tareas de 8 bits, pero no porque sea mas rapido sino porque para el 68000 le da igual trabajar en 8 o 16 bits, es igual de rapido, el 65c816 puede trabajar en 16 bits pero es muchismo mas lento que el 68000 en ese sentido;

Incluso en tareas de 8bits, el 65c816 sale perdiendo contra otros cpus mas viejos como por ejemplo el Hu6280A de Pc engine con sus 7mhz vs los 2,68 mhz comunes del 65c816 de SNES, si!! 2,68 putos mhz!!! no fue hasta los ultimos años de vida de SNES que los juegos comenzaron a utilizar los 3,58 mhz, y solo un par de juegos lo hicieron, el 80% del catalogo de SNES utiliza 2,68 mhz debido al cuello de botella que existe entre el 65c816 y la RAM de trabajo;

No es nada personal, pero me parece que a veces a los fanboys de Nintendo se les va un poco la mano, en serio....

Wellcome to the jungle, hermano.

Acabas de abrir la caja de pandora. Pues ni diciendo esas verdades como puños te vas a librar de la reprimenda de algunos.

Salu2.

Como siempre, que bueno es leerlos, hay algunos aqui que dan catedra por Dios!
Ahora, siendo la cpu de snes tan pobre, como es posible que pueda con los donkey kongs country,?
a mi criterio, es lo mas bonito que existe en consolas de 16bits, ademas sin una ralentizacion.
es mas el adventure island de snes ralentiza!!!!
Acaso los de RARE sabian algo del hard que la propia nintendo u otras compañias no sabian?

releon escribió:

chinitosoccer escribió:De vuelta, de donde sale eso????? realmente lees lo que escribes? a ti te parece que si un cpu basado en 65cXXX fuese realmente mejor manejando "graficos" no hubiese sido usado en mas sistemas como placas arcade y mas ordenadores personales de la época?? asi a simple vista solo fue usado en SNES y en una computadora de Apple, encima la version que lleva la SNES se trata de una version recortada del chip;

La SNES solo lleva un 65c816 porque el plan inicial de Nintendo era hacer que la SNES fuera retrocompatible con NES ya que el 65c816 posee registros de 8 bits derivados del 6502, punto.

No hay nada mas que eso, y es que se te va la mano un mundo al decir que es "mejor para graficos"????WTF?? ..... tela;

sobre todo cuando es un hecho que el 68000 puede trabajar incluso en 32 bits...si, cuando se trata de tareas en 16 y 32 bits el 68000 le patea el culo al 65c816, en lo unico que gana al 68000 es en tareas de 8 bits, pero no porque sea mas rapido sino porque para el 68000 le da igual trabajar en 8 o 16 bits, es igual de rapido, el 65c816 puede trabajar en 16 bits pero es muchismo mas lento que el 68000 en ese sentido;

Incluso en tareas de 8bits, el 65c816 sale perdiendo contra otros cpus mas viejos como por ejemplo el Hu6280A de Pc engine con sus 7mhz vs los 2,68 mhz comunes del 65c816 de SNES, si!! 2,68 putos mhz!!! no fue hasta los ultimos años de vida de SNES que los juegos comenzaron a utilizar los 3,58 mhz, y solo un par de juegos lo hicieron, el 80% del catalogo de SNES utiliza 2,68 mhz debido al cuello de botella que existe entre el 65c816 y la RAM de trabajo;

No es nada personal, pero me parece que a veces a los fanboys de Nintendo se les va un poco la mano, en serio....

¿Y la fuente?,¿o nos tenemos que creer lo que llevan pregonando tal cual misioneros,segueros frustrados en muchos foros ?

@chinitosoccer
obvias la música y los FX,no sería lo mismo.

diego777 escribió:Como siempre, que bueno es leerlos, hay algunos aqui que dan catedra por Dios!
Ahora, siendo la cpu de snes tan pobre, como es posible que pueda con los donkey kongs country,?
a mi criterio, es lo mas bonito que existe en consolas de 16bits, ademas sin una ralentizacion.
es mas el adventure island de snes ralentiza!!!!
Acaso los de RARE sabian algo del hard que la propia nintendo u otras compañias no sabian?

Y que tiene de impresionante Donkey Kong Country?? es un juego mediocre con graficos pre renderizados, no hay efectos impresionantes fuera de lo común en cuanto a las capacidades del GPU de SNES, es un juego que Megadrive podria mover sin despeinarse si contara con una paleta de colores similar, Super Adventure Island me parece un juego mucho mas interesante tecnicamente que cualquiera de los DK de SNES.

Solieyu escribió:
¿Y la fuente?,¿o nos tenemos que creer lo que llevan pregonando tal cual misioneros,segueros frustrados en muchos foros ?

google, busca tu mismo los manuales, tanto los del 68000 como el del 65c816 estan disponibles desde hace tiempo en internet.

chinitosoccer escribió:

Señor Ventura escribió:Incluso en tareas de 8bits, el 65c816 sale perdiendo contra otros cpus mas viejos como por ejemplo el Hu6280A de Pc engine con sus 7mhz vs los 2,68 mhz comunes del 65c816 de SNES, si!! 2,68 putos mhz!!! no fue hasta los ultimos años de vida de SNES que los juegos comenzaron a utilizar los 3,58 mhz, y solo un par de juegos lo hicieron, el 80% del catalogo de SNES utiliza 2,68 mhz debido al cuello de botella que existe entre el 65c816 y la RAM de trabajo;

No es nada personal, pero me parece que a veces a los fanboys de Nintendo se les va un poco la mano, en serio....

No tenía ni idea de eso.
¿Por qué Nintendo no hizo nada al respecto? Creo que se acomodaron, se conformaron con la "pequeña" diferencia de potencia respecto a la Mega Drive. Pero Super Nes podría haber destacado mucho más, acercándose incluso a CPS1 o a Neo Geo.
Una Super Nes con una buena cpu podría haber dado mucho más de sí. La historia podría haber sido muy distinta. Pero claro, una máquina más potente hubiese hecho menguar mucho las ventas de la Mega Drive y el pique de por aquel entonces y la gran rivalidad se habría perdido, dejando a la grande de Sega muy atrás.

Creo que la historia está bien tal y como está.

En fin, Nintendo siempre cagándola con el hardware como hoy en día.

paco_man escribió: Pero Super Nes podría haber destacado mucho más, acercándose incluso a CPS1 o a Neo Geo.

, no, imposible, ni con un CPU mas rapido se podria haber acercado, CPS1 y Neogeo son sistemas arcade, diseñados para trabajar con grandes cantidades de espacio en ROM sin necesidad de Ram de trabajo o video, ambos con sistemas de sonido y graficos mucho mas avanzados que los de una consola o computadora domestica de la epoca.

Solo como dato comparativo una SNES en 1991 costaba en USA 199 dolares, mientras que una placa arcade CPS1 salia entre 500 y 1200 dolares dependiendo del titulo, solo el GPU Ricoh de CPS1 costaba el doble que una SNES.

Pues para cagarla en el hardware si que se hincharon a vender incluso hasta bien entrado 1996 se seguía vendiendo la SNES bastante bien aqui en USA...de la Genesis ya nadie se acordaba salvo los brasileños.

chinitosoccer escribió:De vuelta, de donde sale eso????? realmente lees lo que escribes? a ti te parece que si un cpu basado en 65cXXX fuese realmente mejor manejando "graficos" no hubiese sido usado en mas sistemas como placas arcade y mas ordenadores personales de la época?? asi a simple vista solo fue usado en SNES y en una computadora de Apple, encima la version que lleva la SNES se trata de una version recortada del chip;

Voy a intentarlo una vez mas.

El 65c816 trabaja con sprites a mas bajo nivel, y es una cpu que ciertamente es mas eficiente que el motorola en esa tarea (comunicar la tabla OAM con el sistema de video para que este los mueva). Luego ocurre que ambas cpu's a sus correspondientes velocidades de 3.58mhz, y 7.60mhz, finalmente quedan bastante equiparadas en esa cuestión.

Estamos hablando de lo concerniente a los sprites, no al poder de computación que te permite hacer otras muchas cosas. Confundes los conceptos llevando las cosas a un "todo".

chinitosoccer escribió:La SNES solo lleva un 65c816 porque el plan inicial de Nintendo era hacer que la SNES fuera retrocompatible con NES ya que el 65c816 posee registros de 8 bits derivados del 6502, punto.

El 65c816 no lleva registros derivados del 6502 para los juegos de 16 bits. Lleva los registros de 8 bits del 6502 para una retrocompatibilidad que ulteriormente no se usó en software alguno, y luego una actualización que hace del 65c816 un auténtico procesador de 16 bits.
Si lo que intentas decir es que la arquitectura y las instrucciones de 16 bits del chip derivan de un chip de 8 bits(6502), entonces estás muy equivocado, no entiendes lo que ha pasado ahí.

chinitosoccer escribió:No hay nada mas que eso, y es que se te va la mano un mundo al decir que es "mejor para graficos"????WTF?? ..... tela;

Sprites.

chinitosoccer escribió:sobre todo cuando es un hecho que el 68000 puede trabajar incluso en 32 bits...si, cuando se trata de tareas en 16 y 32 bits el 68000 le patea el culo al 65c816, en lo unico que gana al 68000 es en tareas de 8 bits, pero no porque sea mas rapido sino porque para el 68000 le da igual trabajar en 8 o 16 bits, es igual de rapido, el 65c816 puede trabajar en 16 bits pero es muchismo mas lento que el 68000 en ese sentido;

En megadrive me encuentro muy perdido, pero tengo entendido que todas las instrucciones del 68000 son de 32 bits, excepto una, que es de 16 bits.

Pero luego no todo es tan así:
"Aunque los registros de direcciones son de 32 bits, debe observarse que ya que el espacio de direccionamiento del 68000 es de 2(elevado a 24)bytes, solamente son significativos los 24 bits de menor peso de cada registro de direcciones."

Y luego, por cuestiones de direccionamiento del registro de estado, el bus está limitado a 16 bits. No quiero hablar mas sin saber.

Ahí va un link, para quien quiera echar un vistazo:
http://www.dia.eui.upm.es/asignatu/arq_ ... C68000.pdf


Luego tenemos la snes, que tiene un microprocesador de 16 bits, con algunas de sus intrucciones extendidas en el sistema de video (instrucciones para multiplicar y dividir tiran con la potencia de un procesador a 21Mhz (PPU1), aunque tambien tiene un coste utilizarlo, porque son externas a la cpu).
-Tiene un bus de datos de 8 bits (recalco DATOS, es decir, gráficos, programa, etc).
-Tiene otro bus de direcciones de 24 bits que se comunica directamente con la memoria ram principal, y conecta tambien con los conectores de los cartuchos.
-Y tiene otro bus de 8 bits que conecta los PPU 1 y 2, el SPC700, y la memoria ram principal.

El tema de los buses en snes es altamente complejo por todo el tema de prioridades, y desde luego que no es tan sencillo como reducir la cuestión a "tiene buses de 8 bits, entonces trabaja como un sistema de 8 bits". Es netamente un sistema de 16 bits, aunque es complejo de explicar.

chinitosoccer escribió:Incluso en tareas de 8bits, el 65c816 sale perdiendo contra otros cpus mas viejos como por ejemplo el Hu6280A de Pc engine con sus 7mhz vs los 2,68 mhz comunes del 65c816 de SNES, si!! 2,68 putos mhz!!! no fue hasta los ultimos años de vida de SNES que los juegos comenzaron a utilizar los 3,58 mhz, y solo un par de juegos lo hicieron, el 80% del catalogo de SNES utiliza 2,68 mhz debido al cuello de botella que existe entre el 65c816 y la RAM de trabajo;

Los juegos de snes no usan registros de 8 bits. Esos registros estaban destinados a correr los juegos de NES. Esa comparación no tiene sentido.

P.D: ¿Estás seguro de que solo 2 juegos de snes funcionan a 3.58mhz?. No son esos los datos que me están arrojando los debuggers.

chinitosoccer escribió:No es nada personal, pero me parece que a veces a los fanboys de Nintendo se les va un poco la mano, en serio....

Tanto como se te ha ido a ti, quienes decir, ¿no?.

La próxima vez, por favor, infórmate antes de negar las cosas de la forma en que lo has hecho.

https://www.youtube.com/watch?v=ek1w1V2vrf0

chinitosoccer escribió:

diego777 escribió:Como siempre, que bueno es leerlos, hay algunos aqui que dan catedra por Dios!
Ahora, siendo la cpu de snes tan pobre, como es posible que pueda con los donkey kongs country,?
a mi criterio, es lo mas bonito que existe en consolas de 16bits, ademas sin una ralentizacion.
es mas el adventure island de snes ralentiza!!!!
Acaso los de RARE sabian algo del hard que la propia nintendo u otras compañias no sabian?

Y que tiene de impresionante Donkey Kong Country?? es un juego mediocre con graficos pre renderizados, no hay efectos impresionantes fuera de lo común en cuanto a las capacidades del GPU de SNES, es un juego que Megadrive podria mover sin despeinarse si contara con una paleta de colores similar, Super Adventure Island me parece un juego mucho mas interesante tecnicamente que cualquiera de los DK de SNES.

tiene efectos que la megadrive no puede hacer ,como transparencias ,aparte de la calidad de sonido y por supuesto la gama de colores que pone en pantalla lo que ya querria una megadrive ,que un juego de 16 bits parezca de 32 bits pocos juegos lo consiguen.
ahora resulta que los donkey kongs son juegos mediocres
definicion de mediocre:
mediocre
Que es mediano o regular, tirando a malo, en cuanto a su calidad, valor, interés, etc.

precisamente es lo contrario,haced el favor de utilizar las palabras correctamente ,mediocre es el port de l mismo juego a la megadrive donkey kong 99.

chinitosoccer escribió:

diego777 escribió:Como siempre, que bueno es leerlos, hay algunos aqui que dan catedra por Dios!
Ahora, siendo la cpu de snes tan pobre, como es posible que pueda con los donkey kongs country,?
a mi criterio, es lo mas bonito que existe en consolas de 16bits, ademas sin una ralentizacion.
es mas el adventure island de snes ralentiza!!!!
Acaso los de RARE sabian algo del hard que la propia nintendo u otras compañias no sabian?

Y que tiene de impresionante Donkey Kong Country?? es un juego mediocre con graficos pre renderizados, no hay efectos impresionantes fuera de lo común en cuanto a las capacidades del GPU de SNES, es un juego que Megadrive podria mover sin despeinarse si contara con una paleta de colores similar, Super Adventure Island me parece un juego mucho mas interesante tecnicamente que cualquiera de los DK de SNES.

Con todo mi respeto, al ver que eres un conocedor del tema, donkey kong country 2 se caga en todo lo que adventure island puede hacer,
a menos que puedas explicarme en que es superior el adventure al donkey.
Como puedes comparar esto (el video no es mio)
https://www.youtube.com/watch?v=awjajRL7pk8
a esto:
https://www.youtube.com/watch?v=EHqjp-oQans
Sin animo de montar rollo, odias los juegos de rare?
O simplemente odias a la snes?
Gracias por compartir.

Que cada uno exponga sus razones o de su opinión, pero vamos a evitar denominar a nadie "Fanboy", " misionero seguero" así como descalificar a nadie o aprovechar para intentar avivar otro tipo de polémicas.

paco_man escribió:En fin, Nintendo siempre cagándola con el hardware como hoy en día.

Por ejemplo...

No se va a estar dado los mismos avisos en todos los hilos del foro, ......

Se puede opinar, debatir y discutir sobre cualquier tema que tenga cabida en los foros, pero con el respeto a los demás usuarios como regla principal. No se tolerarán insultos, salidas de tono, faltas de respeto, actitudes discriminatorias o, en general, cualquier tipo de comentario que contribuya a un mal ambiente.

Yo no he apuntado a nadie solo he dicho como les llamo.Cosas peores me han dicho y nunca pasó nada.

Solieyu escribió:Yo no he apuntado a nadie solo he dicho como les llamo.Cosas peores me han dicho y nunca pasó nada.

Por favor, vuelve a leer el aviso general que he dado.

Cuando se te digan ese tipo de cosas reporta, para que moderación pueda valorarlo y tomar las acciones oportunas (no siempre visibles a los usuarios)

Si quieres poner en duda la labor de moderación o si es necesaria alguna explicación, en Feedback.

vamos a seguir con el tema.

diego777 escribió:Con todo mi respeto, al ver que eres un conocedor del tema, donkey kong country 2 se caga en todo lo que adventure island puede hacer,
a menos que puedas explicarme en que es superior el adventure al donkey.
Como puedes comparar esto (el video no es mio)
https://www.youtube.com/watch?v=awjajRL7pk8
a esto:
https://www.youtube.com/watch?v=EHqjp-oQans
Sin animo de montar rollo, odias los juegos de rare?
O simplemente odias a la snes?
Gracias por compartir.

Lo que quiere decir, es que el donkey kong usa planos, sprites, y en general, exactamente la misma implicación del hardware tanto para un juego, como para otro.

Piensa en los planos y en los sprites como un lienzo en blanco que puedes rellenar de la forma que tu prefieras (cubismo, expresionismo, arte abstracto, o incluso fotografías a todo detalle). Los gráficos del donkey kong country tienen el aspecto de ser 3D porque sus gráficos en vez de haber sido dibujados a mano, han sido hechos por ordenador con ese aspecto... pero siguen siendo planos y sprites (qeu además no explotan el límite de la consola)... vamos, nada que suponga una diferencia con cualquier otro juego.

Bueno, que DKC no tiene efectos impresionantes o al menos muy buenos... Es muy relativo, estamos ignorando las luces de las lamparas en la fase de la mina que iluminan al mono y se mueven de un lado a otro, las tormentas de nieve, los efectos de iluminacion, la lluvia, luego en su segunda entrega el paralax de las vigas de la parte inundada del barco pirata del primer mundo, el grandiante de color del agua...

Pero bueno, como ya dije, de aqui a nada un "¿Podria Md con un port 1:1 del kirby de GB?"

Señor Ventura escribió:

diego777 escribió:Con todo mi respeto, al ver que eres un conocedor del tema, donkey kong country 2 se caga en todo lo que adventure island puede hacer,
a menos que puedas explicarme en que es superior el adventure al donkey.
Como puedes comparar esto (el video no es mio)
https://www.youtube.com/watch?v=awjajRL7pk8
a esto:
https://www.youtube.com/watch?v=EHqjp-oQans
Sin animo de montar rollo, odias los juegos de rare?
O simplemente odias a la snes?
Gracias por compartir.

Lo que quiere decir, es que el donkey kong usa planos, sprites, y en general, exactamente la misma implicación del hardware tanto para un juego, como para otro.

Piensa en los planos y en los sprites como un lienzo en blanco que puedes rellenar de la forma que tu prefieras (cubismo, expresionismo, arte abstracto, o incluso fotografías a todo detalle). Los gráficos del donkey kong country tienen el aspecto de ser 3D porque sus gráficos en vez de haber sido dibujados a mano, han sido hechos por ordenador con ese aspecto... pero siguen siendo planos y sprites (qeu además no explotan el límite de la consola)... vamos, nada que suponga una diferencia con cualquier otro juego.

Los muñecos de los Donkey Kongs son renderizaciones en 3D?

Pre-renderizaciones. Son sprites.

salvor70 escribió:Que cada uno exponga sus razones o de su opinión, pero vamos a evitar denominar a nadie "Fanboy", " misionero seguero" así como descalificar a nadie o aprovechar para intentar avivar otro tipo de polémicas.

paco_man escribió:En fin, Nintendo siempre cagándola con el hardware como hoy en día.

Por ejemplo...

No se va a estar dado los mismos avisos en todos los hilos del foro, ......

Se puede opinar, debatir y discutir sobre cualquier tema que tenga cabida en los foros, pero con el respeto a los demás usuarios como regla principal. No se tolerarán insultos, salidas de tono, faltas de respeto, actitudes discriminatorias o, en general, cualquier tipo de comentario que contribuya a un mal ambiente.

Lo siento, la verdad es que me he pasado con ese comentario.

paco_man escribió:Lo siento, la verdad es que me he pasado con ese comentario.

Gracias

Señor Ventura escribió:El ejemplo ese que pones no muestra 8 IAs totalmente independientes, y no, no es lo mismo sprites, que objetos.

Aunque sean 8 objetos iguales no significa que sea mas fácil de manejar, cada objeto estará ejecutando su propia rutina, es decir, sería lo mismo que fueran 8 objetos diferentes.

Ragnar Lodbrok escribió:Y sí, puede colocar sprites de 64x64, lo que significa que no podremos situar más de 4 de este tamaño a la vez por línea si utilizas esta opción.

El problema con los sprites de 64x64 es que no sirve para para ser usados en juegos, debido a que la posición "Y" de los sprites son en 8 bit , es decir varia de 0 a 255, y por esto cuando colocas un sprite por ejemplo en la posición "Y" en 208 veras la mitad del sprite arriba y la otra mitad abajo, para que se entienda, si un personaje con este tamaño salta hasta que se salga de la pantalla hacia arriba, lo veras asomándose por abajo.
Tambien está el problema de que un sprite de 64x64 usaría 64 tiles y puedes malgastar muchos tiles, al menos que sea un sprite casi cuadrado.
Hasta ahora, de todos los juegos que he probado, no he visto ningún juego que use este tamaño de sprites, la mayoría usa los tamaños de 8x8 y 16x16, y otros usan 16x16 y 32x32.

Señor Ventura escribió:Estás mezclando churras con merinas. Son 32 sprites por scanline, y 256 pixels por scanline.

Solo seran 32 sprites por scanline si son de 8x8 , por ejemplo si usas sprites de 16x16 solo pueden estar 17, ya estarías en el limite de 272 pixeles(no es 256).

Señor Ventura escribió:Los parpadeos que has llegado a ver en bastantes juegos de snes, se deben a un bug del generador de imágenes, no a una falta de capacidad para manejar sprites.

Yo no sé porque insistes en el "bug del generador de imágenes", no existe ningún bug. Los parpadeos que dices se debe a que se ha llegado al limite de sprites por scanline, o al limite de pixeles que son 272, o bien al limite de los 128 sprites. Yo dije en otro hilo que el juego de Batman Returns se llegaba al limite de los 128 sprites y por eso se desaparecían una parte de algún enemigo y se veía esos parpadeos que dices. Voy a tratar de sacar una captura de esto, con el emulador no$sns, en donde se pueden ver los sprites también.

Señor ventura escribió:Si tu en megadrive declaras un tamaño de sprite de 16x32 para conformar un objeto, y a la hora de hacer un port en snes la configuración en ese momento exacto de de 16x16 para sprites pequeños, y 32x32 para sprites grandes, lo que tu piensas es que no podría hacerse, o que tendría que forzar una configuración que joda la planificación del resto del juego, solo para equiparar el tamaño de ese sprite en megadrive... que además tendría que hacerse con sprites de 8x8, y supondría un gasto de sprites que no tendría la megadrive.

Lo que ocurre, es que si yo cojo un sprite de 32x32 pixels, centro el dibujo, y los pixels que no conforman el muñeco los pinto de color transparente (es decir, pixels nulos), entonces no se ha perdido nada. Lo que tu ves como una restricción, implica únicamente otra forma de trabajar... no hay impacto en el resultado.

Estas equivocado, el problema esta en que cuando usas un sprite de 32x32 estarías usando 16 tiles y en cambio un sprite de 16x32 usarías 8 tiles. Ahora si usas dos sprites de 16x16 asi si usarías solo 8 tiles. A la hora de programar un juego deberás decidir cual de las dos opciones sera la mejor, pero en ambos casos queda en desventaja con respecto a Genesis/MD.
Nota: para los que no lo saben, un tile es un espacio de 8x8 pixeles.

Señor ventura escribió:Y sobre los colores, la pc engine puede poner 15 colores por sprite, mientras que la snes puede poner 16. La diferencia está en la paleta de colores, que en snes se nota demasiado ese toque.

Snes Genesis/MD y Pc engine solo pueden mostrar 15 colores para los sprites, en las tres el color cero siempre sera la transparencia.

Señor Ventura escribió:La diferencia está en que no supone ningún problema de rendimiento... y esa es la gracia de poner sprites grandes, que no vas a necesitar tantos para representar lo mismo, por lo que así es mas sencillo evitar el bug.

Como dije anteriormente los sprites de 64x64 son "inservibles", no creo que haya ningún juego que los haya usado, y ademas no hay tal "bug".

Señor ventura escribió:El 65c816 trabaja con sprites a mas bajo nivel, y es una cpu que ciertamente es mas eficiente que el motorola en esa tarea (comunicar la tabla OAM con el sistema de video para que este los mueva). Luego ocurre que ambas cpu's a sus correspondientes velocidades de 3.58mhz, y 7.60mhz, finalmente quedan bastante equiparadas en esa cuestión.

Estamos hablando de lo concerniente a los sprites, no al poder de computación que te permite hacer otras muchas cosas. Confundes los conceptos llevando las cosas a un "todo".

No, en realidad el manejo de los sprites es ineficiente en el snes, debido a como fue diseñado los registros del OAM en donde se tienen que enmascarar bits para la coordenada "X" y "tile index", no tiene que ver con el CPU, para que me entiendas si ambas consolas tuvieran el 68000 o el 65c816 aun así sería mas eficiente el manejo de los sprites en el Genesis/MD.

Señor Ventura escribió:El 65c816 no lleva registros derivados del 6502 para los juegos de 16 bits. Lleva los registros de 8 bits del 6502 para una retrocompatibilidad que ulteriormente no se usó en software alguno, y luego una actualización que hace del 65c816 un auténtico procesador de 16 bits.
Si lo que intentas decir es que la arquitectura y las instrucciones de 16 bits del chip derivan de un chip de 8 bits(6502), entonces estás muy equivocado, no entiendes lo que ha pasado ahí.

Aquí si que estas muy equivocado, el 65c816 es derivado del 6502, se puede decir que es una ampliación del 6502, tiene un bus de datos externo de 8bits pero internamente puede funcionar en 16 bits, y un bus de dirección de 24 bit(el 6502 es de 16 bit).
El 65c816 tiene las mismas instrucciones del 6502 pero se agregaron otras nuevas, tiene los mismos registros del 6502: "A","X" y "Y" pero a diferencia del 6502 estos registros pueden ser de 8 o 16 bit, se agregaron varios registros mas, mas que todo para poder manejar los 24 bit de dirección, ya que el PC(contador de programa) sigue siendo de 16 bit como en el 6502. Ademas el 65c816 tiene un modo llamado "emulation mode" que funcionará exactamente como un 6502.
Si quieres saber un poco mas sobre como "nació" este CPU lee esto(está en ingles):
https://en.wikipedia.org/wiki/WDC_65816/65802

Señor Ventura escribió:En megadrive me encuentro muy perdido, pero tengo entendido que todas las instrucciones del 68000 son de 32 bits, excepto una, que es de 16 bits.

Pero luego no todo es tan así:
"Aunque los registros de direcciones son de 32 bits, debe observarse que ya que el espacio de direccionamiento del 68000 es de 2(elevado a 24)bytes, solamente son significativos los 24 bits de menor peso de cada registro de direcciones."

Y luego, por cuestiones de direccionamiento del registro de estado, el bus está limitado a 16 bits. No quiero hablar mas sin saber.

Bueno, de verdad si que estas perdido. ¿"toas las instrucciones del 68000 son de 32 bit"?, ¿"por cuestiones de direccionamiento del registro de estado, el bus está limitado a 16 bits"?, acaso sabes lo que es un registro de estado?, de verdad no se de donde sacas estas cosas que escribes, estas totalmente perdido.

Voy a dar una breve explicación sobre el 68000. Este CPU se dice que es un CPU de 16/32 bit porque aunque tiene un bus de datos de 16 bits puede realizar operaciones de 32 bit internamente, tiene 16 registros de 32 bit, 8 son llamados registros de datos y 8 son llamados registros de dirección, se pueden realizar operaciones lógicas y aritméticas en 8, 16 y 32 bit y operaciones en bits, y a diferencia del CPU 6502(y sus derivados) en donde la mayoría de las operaciones se deben hacer a través del registro "A"(llamado acumulador), en el 68000 se pueden realizar todas las operaciones lógicas y aritméticas en cualquier registro de datos y operaciones aritméticas en registros de dirección e incluso se pueden realizar operaciones lógicas y aritméticas sin intervención de registros, directamente en memoria. Tiene un amplio y variado conjunto de instrucciones que lo hacen muy versátil, ademas puedes realizar códigos usando solo registros en los casos en que la velocidad es importante y es allí en donde este cpu se destaca comparándolo con CPUs de la serie 6502, y ni hablar de operaciones de 32bits(que en el caso del 65c816 no tiene), que aunque mucha gente no crea, se usa mas frecuentemente de lo que parece.

Señor Ventura escribió:Luego tenemos la snes, que tiene un microprocesador de 16 bits, con algunas de sus intrucciones extendidas en el sistema de video (instrucciones para multiplicar y dividir tiran con la potencia de un procesador a 21Mhz (PPU1), aunque tambien tiene un coste utilizarlo, porque son externas a la cpu).
-Tiene un bus de datos de 8 bits (recalco DATOS, es decir, gráficos, programa, etc).
-Tiene otro bus de direcciones de 24 bits que se comunica directamente con la memoria ram principal, y conecta tambien con los conectores de los cartuchos.
-Y tiene otro bus de 8 bits que conecta los PPU 1 y 2, el SPC700, y la memoria ram principal.

El tema de los buses en snes es altamente complejo por todo el tema de prioridades, y desde luego que no es tan sencillo como reducir la cuestión a "tiene buses de 8 bits, entonces trabaja como un sistema de 8 bits". Es netamente un sistema de 16 bits, aunque es complejo de explicar.

El cpu del snes es un cpu con 8 bits de datos y 24 bits de dirección(por eso es que los cartuchos tienen roms de 8bits), la memoria ram, la rom (cartucho) y los PPUs se conectan a estos buses, no existen "otros buses".

Los juegos de snes no usan registros de 8 bits. Esos registros estaban destinados a correr los juegos de NES. Esa comparación no tiene sentido.

Aunque no lo creas es común que hayan operaciones en 8 bits, ademas que hay registros de los PPU que se deben hacer en 8 bits, como los registros para el modo 7, scroll de backgrounds y OAM(sprites).

Que hayan operaciones en 8 bits no hace que una consola sea de "8 bits", en el Genesis/Md también se hacen algunas operaciones en 8 bits, incluso en el GBA que tiene un CPU ARM7 también se pueden ver algunas cosas en 8 bits.

Señor ventura escribió:P.D: ¿Estás seguro de que solo 2 juegos de snes funcionan a 3.58mhz?. No son esos los datos que me están arrojando los debuggers.

Mas bien creo que pudiera ser cerca de la mitad los juegos a 3.58mhz (sobretodo los últimos), lo que sucede es que los juegos que corren a 3.58 requieren Memorias Roms mas rápidas, y al principio la mayoría de juegos usaban Roms "lentas" porque eran menos costosas, ya mas adelante era mas común que se usaran Roms mas rápidas. Aunque hayan juegos a 3.58mhz, el acceso a la Wram (ram del sistema) siempre sera a 2.68mhz, aquí está un "quote" sacado de la documentación del emulador no$sns:

Note that WRAM is accessed at 2.6MHz. Meaning that all variables, stack, and
program code in RAM will be slow. The SNES doesn't include any fast RAM.

Para los que no entienden ingles esto es lo que dice mas o menos: Nótese que el acceso a la Wram será a 2.6mhz. Esto significa que todas las variables, stack, y codigo en RAM será lento. El Snes no incluye ninguna Ram rápida.

Aunque hay una manera de acceder a la Wram a 3.58, a través de un registro para ese fin, pero solo será para leer o escribir datos secuenciales, no servirá para variables o código.

Todo lo que he escrito aquí no es algo que yo tenga en contra del Snes, son simplemente datos técnicos que cualquier persona puede verificar solo buscándolos.

Y sobre el tema de este hilo voy a expresar mi opinión al respecto mas adelante.

gasega68k escribió:

Señor Ventura escribió:El ejemplo ese que pones no muestra 8 IAs totalmente independientes, y no, no es lo mismo sprites, que objetos.

Aunque sean 8 objetos iguales no significa que sea mas fácil de manejar, cada objeto estará ejecutando su propia rutina, es decir, sería lo mismo que fueran 8 objetos diferentes.

Ragnar Lodbrok escribió:Y sí, puede colocar sprites de 64x64, lo que significa que no podremos situar más de 4 de este tamaño a la vez por línea si utilizas esta opción.

El problema con los sprites de 64x64 es que no sirve para para ser usados en juegos, debido a que la posición "Y" de los sprites son en 8 bit , es decir varia de 0 a 255, y por esto cuando colocas un sprite por ejemplo en la posición "Y" en 208 veras la mitad del sprite arriba y la otra mitad abajo, para que se entienda, si un personaje con este tamaño salta hasta que se salga de la pantalla hacia arriba, lo veras asomándose por abajo.
Tambien está el problema de que un sprite de 64x64 usaría 64 tiles y puedes malgastar muchos tiles, al menos que sea un sprite casi cuadrado.
Hasta ahora, de todos los juegos que he probado, no he visto ningún juego que use este tamaño de sprites, la mayoría usa los tamaños de 8x8 y 16x16, y otros usan 16x16 y 32x32.

Señor Ventura escribió:Estás mezclando churras con merinas. Son 32 sprites por scanline, y 256 pixels por scanline.

Solo seran 32 sprites por scanline si son de 8x8 , por ejemplo si usas sprites de 16x16 solo pueden estar 17, ya estarías en el limite de 272 pixeles(no es 256).

Señor Ventura escribió:Los parpadeos que has llegado a ver en bastantes juegos de snes, se deben a un bug del generador de imágenes, no a una falta de capacidad para manejar sprites.

Yo no sé porque insistes en el "bug del generador de imágenes", no existe ningún bug. Los parpadeos que dices se debe a que se ha llegado al limite de sprites por scanline, o al limite de pixeles que son 272, o bien al limite de los 128 sprites. Yo dije en otro hilo que el juego de Batman Returns se llegaba al limite de los 128 sprites y por eso se desaparecían una parte de algún enemigo y se veía esos parpadeos que dices. Voy a tratar de sacar una captura de esto, con el emulador no$sns, en donde se pueden ver los sprites también.

Señor ventura escribió:Si tu en megadrive declaras un tamaño de sprite de 16x32 para conformar un objeto, y a la hora de hacer un port en snes la configuración en ese momento exacto de de 16x16 para sprites pequeños, y 32x32 para sprites grandes, lo que tu piensas es que no podría hacerse, o que tendría que forzar una configuración que joda la planificación del resto del juego, solo para equiparar el tamaño de ese sprite en megadrive... que además tendría que hacerse con sprites de 8x8, y supondría un gasto de sprites que no tendría la megadrive.

Lo que ocurre, es que si yo cojo un sprite de 32x32 pixels, centro el dibujo, y los pixels que no conforman el muñeco los pinto de color transparente (es decir, pixels nulos), entonces no se ha perdido nada. Lo que tu ves como una restricción, implica únicamente otra forma de trabajar... no hay impacto en el resultado.

Estas equivocado, el problema esta en que cuando usas un sprite de 32x32 estarías usando 16 tiles y en cambio un sprite de 16x32 usarías 8 tiles. Ahora si usas dos sprites de 16x16 asi si usarías solo 8 tiles. A la hora de programar un juego deberás decidir cual de las dos opciones sera la mejor, pero en ambos casos queda en desventaja con respecto a Genesis/MD.
Nota: para los que no lo saben, un tile es un espacio de 8x8 pixeles.

Señor ventura escribió:Y sobre los colores, la pc engine puede poner 15 colores por sprite, mientras que la snes puede poner 16. La diferencia está en la paleta de colores, que en snes se nota demasiado ese toque.

Snes Genesis/MD y Pc engine solo pueden mostrar 15 colores para los sprites, en las tres el color cero siempre sera la transparencia.

Señor Ventura escribió:La diferencia está en que no supone ningún problema de rendimiento... y esa es la gracia de poner sprites grandes, que no vas a necesitar tantos para representar lo mismo, por lo que así es mas sencillo evitar el bug.

Como dije anteriormente los sprites de 64x64 son "inservibles", no creo que haya ningún juego que los haya usado, y ademas no hay tal "bug".

Señor ventura escribió:El 65c816 trabaja con sprites a mas bajo nivel, y es una cpu que ciertamente es mas eficiente que el motorola en esa tarea (comunicar la tabla OAM con el sistema de video para que este los mueva). Luego ocurre que ambas cpu's a sus correspondientes velocidades de 3.58mhz, y 7.60mhz, finalmente quedan bastante equiparadas en esa cuestión.

Estamos hablando de lo concerniente a los sprites, no al poder de computación que te permite hacer otras muchas cosas. Confundes los conceptos llevando las cosas a un "todo".

No, en realidad el manejo de los sprites es ineficiente en el snes, debido a como fue diseñado los registros del OAM en donde se tienen que enmascarar bits para la coordenada "X" y "tile index", no tiene que ver con el CPU, para que me entiendas si ambas consolas tuvieran el 68000 o el 65c816 aun así sería mas eficiente el manejo de los sprites en el Genesis/MD.

Señor Ventura escribió:El 65c816 no lleva registros derivados del 6502 para los juegos de 16 bits. Lleva los registros de 8 bits del 6502 para una retrocompatibilidad que ulteriormente no se usó en software alguno, y luego una actualización que hace del 65c816 un auténtico procesador de 16 bits.
Si lo que intentas decir es que la arquitectura y las instrucciones de 16 bits del chip derivan de un chip de 8 bits(6502), entonces estás muy equivocado, no entiendes lo que ha pasado ahí.

Aquí si que estas muy equivocado, el 65c816 es derivado del 6502, se puede decir que es una ampliación del 6502, tiene un bus de datos externo de 8bits pero internamente puede funcionar en 16 bits, y un bus de dirección de 24 bit(el 6502 es de 16 bit).
El 65c816 tiene las mismas instrucciones del 6502 pero se agregaron otras nuevas, tiene los mismos registros del 6502: "A","X" y "Y" pero a diferencia del 6502 estos registros pueden ser de 8 o 16 bit, se agregaron varios registros mas, mas que todo para poder manejar los 24 bit de dirección, ya que el PC(contador de programa) sigue siendo de 16 bit como en el 6502. Ademas el 65c816 tiene un modo llamado "emulation mode" que funcionará exactamente como un 6502.
Si quieres saber un poco mas sobre como "nació" este CPU lee esto(está en ingles):
https://en.wikipedia.org/wiki/WDC_65816/65802

Señor Ventura escribió:En megadrive me encuentro muy perdido, pero tengo entendido que todas las instrucciones del 68000 son de 32 bits, excepto una, que es de 16 bits.

Pero luego no todo es tan así:
"Aunque los registros de direcciones son de 32 bits, debe observarse que ya que el espacio de direccionamiento del 68000 es de 2(elevado a 24)bytes, solamente son significativos los 24 bits de menor peso de cada registro de direcciones."

Y luego, por cuestiones de direccionamiento del registro de estado, el bus está limitado a 16 bits. No quiero hablar mas sin saber.

Bueno, de verdad si que estas perdido. ¿"toas las instrucciones del 68000 son de 32 bit"?, ¿"por cuestiones de direccionamiento del registro de estado, el bus está limitado a 16 bits"?, acaso sabes lo que es un registro de estado?, de verdad no se de donde sacas estas cosas que escribes, estas totalmente perdido.

Voy a dar una breve explicación sobre el 68000. Este CPU se dice que es un CPU de 16/32 bit porque aunque tiene un bus de datos de 16 bits puede realizar operaciones de 32 bit internamente, tiene 16 registros de 32 bit, 8 son llamados registros de datos y 8 son llamados registros de dirección, se pueden realizar operaciones lógicas y aritméticas en 8, 16 y 32 bit y operaciones en bits, y a diferencia del CPU 6502(y sus derivados) en donde la mayoría de las operaciones se deben hacer a través del registro "A"(llamado acumulador), en el 68000 se pueden realizar todas las operaciones lógicas y aritméticas en cualquier registro de datos y operaciones aritméticas en registros de dirección e incluso se pueden realizar operaciones lógicas y aritméticas sin intervención de registros, directamente en memoria. Tiene un amplio y variado conjunto de instrucciones que lo hacen muy versátil, ademas puedes realizar códigos usando solo registros en los casos en que la velocidad es importante y es allí en donde este cpu se destaca comparándolo con CPUs de la serie 6502, y ni hablar de operaciones de 32bits(que en el caso del 65c816 no tiene), que aunque mucha gente no crea, se usa mas frecuentemente de lo que parece.

Señor Ventura escribió:Luego tenemos la snes, que tiene un microprocesador de 16 bits, con algunas de sus intrucciones extendidas en el sistema de video (instrucciones para multiplicar y dividir tiran con la potencia de un procesador a 21Mhz (PPU1), aunque tambien tiene un coste utilizarlo, porque son externas a la cpu).
-Tiene un bus de datos de 8 bits (recalco DATOS, es decir, gráficos, programa, etc).
-Tiene otro bus de direcciones de 24 bits que se comunica directamente con la memoria ram principal, y conecta tambien con los conectores de los cartuchos.
-Y tiene otro bus de 8 bits que conecta los PPU 1 y 2, el SPC700, y la memoria ram principal.

El tema de los buses en snes es altamente complejo por todo el tema de prioridades, y desde luego que no es tan sencillo como reducir la cuestión a "tiene buses de 8 bits, entonces trabaja como un sistema de 8 bits". Es netamente un sistema de 16 bits, aunque es complejo de explicar.

El cpu del snes es un cpu con 8 bits de datos y 24 bits de dirección(por eso es que los cartuchos tienen roms de 8bits), la memoria ram, la rom (cartucho) y los PPUs se conectan a estos buses, no existen "otros buses".

Los juegos de snes no usan registros de 8 bits. Esos registros estaban destinados a correr los juegos de NES. Esa comparación no tiene sentido.

Aunque no lo creas es común que hayan operaciones en 8 bits, ademas que hay registros de los PPU que se deben hacer en 8 bits, como los registros para el modo 7, scroll de backgrounds y OAM(sprites).

Que hayan operaciones en 8 bits no hace que una consola sea de "8 bits", en el Genesis/Md también se hacen algunas operaciones en 8 bits, incluso en el GBA que tiene un CPU ARM7 también se pueden ver algunas cosas en 8 bits.

Señor ventura escribió:P.D: ¿Estás seguro de que solo 2 juegos de snes funcionan a 3.58mhz?. No son esos los datos que me están arrojando los debuggers.

Mas bien creo que pudiera ser cerca de la mitad los juegos a 3.58mhz (sobretodo los últimos), lo que sucede es que los juegos que corren a 3.58 requieren Memorias Roms mas rápidas, y al principio la mayoría de juegos usaban Roms "lentas" porque eran menos costosas, ya mas adelante era mas común que se usaran Roms mas rápidas. Aunque hayan juegos a 3.58mhz, el acceso a la Wram (ram del sistema) siempre sera a 2.68mhz, aquí está un "quote" sacado de la documentación del emulador no$sns:

Note that WRAM is accessed at 2.6MHz. Meaning that all variables, stack, and
program code in RAM will be slow. The SNES doesn't include any fast RAM.

Para los que no entienden ingles esto es lo que dice mas o menos: Nótese que el acceso a la Wram será a 2.6mhz. Esto significa que todas las variables, stack, y codigo en RAM será lento. El Snes no incluye ninguna Ram rápida.

Aunque hay una manera de acceder a la Wram a 3.58, a través de un registro para ese fin, pero solo será para leer o escribir datos secuenciales, no servirá para variables o código.

Todo lo que he escrito aquí no es algo que yo tenga en contra del Snes, son simplemente datos técnicos que cualquier persona puede verificar solo buscándolos.

Y sobre el tema de este hilo voy a expresar mi opinión al respecto mas adelante.

Gasega, eres de lo más valioso en EOL, gracias por compartir tus conocimientos y además por hacerlo de forma legible para los no tan eruditos.

Estás preparando alguna cosilla para SNES???

Owned....

Y aún así con tales demostraciones de saber entender y expresar todavía alguno no se habrá enterado...

Ho!

PD: Pediría por favor, aunque la verdad ofenda, que no se me editaran más mensajes porque no digo nada del otro mundo y la verdad cansa, que esto aunque nos tiremos al cuello no quedaría en nada en la calle, probablemente con cañitas fresquitas de por medio. Si así de infantiles vamos a ser pues ale hop.

Salu2 y gracias por adelantado.

Hay que pensar que lo que para uno es una verdad absoluta, puede que para otros no lo sea, por lo que no tiene sentido situar el debate en términos de victoria/derrota así como para aprovecharlo para mofas o para reavivar disputas que se han producido en otros hilos.
Al igual que ha hecho el compañero gasega68k con su excelente exposición, cada uno que exponga su opinión y argumentos, y luego que cada usuario saque sus propias conclusiones. Situarlo en otros términos, hace imposible un debate sosegado.

releon escribió:PD: Pediría por favor, aunque la verdad ofenda, que no se me editaran más mensajes porque no digo nada del otro mundo y la verdad cansa, que esto aunque nos tiremos al cuello no quedaría en nada en la calle, probablemente con cañitas fresquitas de por medio. Si así de infantiles vamos a ser pues ale hop.

La mayoría de esas ediciones no se hubiesen producido si se hubiesen hecho caso de alguno de los avisos de moderación, los cuales parece que no han contado nada para algunos usuarios.
Y te aseguro que me hubiera gustado evitarme tanto ediciones como avisos....

En cualquier caso,tienes todo el derecho a dudar sobre la labor de moderación, pero al igual que todos los usuarios del foro, estas dudas han de realizarse en feedback, no aquí.

Y en efecto, seguro que con unas cañas sería diferente, creo no es pedir demasiado que el comportamiento en el foro no sea peor que en un bar.

gasega68k escribió:

Señor Ventura escribió:El ejemplo ese que pones no muestra 8 IAs totalmente independientes, y no, no es lo mismo sprites, que objetos.

Aunque sean 8 objetos iguales no significa que sea mas fácil de manejar, cada objeto estará ejecutando su propia rutina, es decir, sería lo mismo que fueran 8 objetos diferentes.

Hay rutinas, y rutinas. Y tambien hay maneras de hacer mas fácil la carga de gestionarlas. El comportamiento de los personajes es el que es, y ofrece dudas. Equivocado o no, es razonable, pero es algo que dificilmente se pueda saber sin echar un vistazo al código.

gasega68k escribió:El problema con los sprites de 64x64 es que no sirve para para ser usados en juegos, debido a que la posición "Y" de los sprites son en 8 bit , es decir varia de 0 a 255, y por esto cuando colocas un sprite por ejemplo en la posición "Y" en 208 veras la mitad del sprite arriba y la otra mitad abajo, para que se entienda, si un personaje con este tamaño salta hasta que se salga de la pantalla hacia arriba, lo veras asomándose por abajo.
Tambien está el problema de que un sprite de 64x64 usaría 64 tiles y puedes malgastar muchos tiles, al menos que sea un sprite casi cuadrado.
Hasta ahora, de todos los juegos que he probado, no he visto ningún juego que use este tamaño de sprites, la mayoría usa los tamaños de 8x8 y 16x16, y otros usan 16x16 y 32x32.

En realidad, la única pega que tiene un sprite de 64x64 pixels, es que en todo el dibujo solo puedes emplear 16 colores. Todas las demás posibles pegas dependerán del diseño del juego, creo yo.

Por ejemplo, una nave en un shooter no necesita saltar, ni salirse de la pantalla... y puede tener una forma lo suficientemente cuadriculada como para que tenga sentido meterlo ahí.
...o en su defecto, un sprite de 64x64 para la parte central de la nave, y otros de 16x16 a izquierda y derecha si se quieren añadir mas detalles (o arrriba y abajo... o en todas direcciones, vaya).

Tambien puedes hacer un beat'em up en el que los enemigos no saltan hasta el cielo. Todo depende del diseño. Obviamente su uso es algo mas limitado, pero no creo que se pueda decir que no tiene uso en juegos.

gasega68k escribió:Solo seran 32 sprites por scanline si son de 8x8 , por ejemplo si usas sprites de 16x16 solo pueden estar 17, ya estarías en el limite de 272 pixeles(no es 256).

¿Sería posible implementar una forma de hacer que los pixels de los sprites que queden tapados por otros sprites, no computen para el límite de pixels por scanline? (algo así como por ejemplo hacer desaparecer los sprites que quedan por detrás de otros sprites hasta que cualquiera de sus pixeles vuelvan a aparecer).

Y otra mas, que por mas que intento leer, no consigo encontrar nada. Cuando se establece la configuración del tamaño para sprites grandes y sprites pequeños, ¿es algo que permanece de forma rígida?, o permite una cierta flexibilidad para cambiarlo en mitad de una fase sin ningún tipo de reseteo (es decir, al vuelo).

gasega68k escribió:Yo no sé porque insistes en el "bug del generador de imágenes", no existe ningún bug. Los parpadeos que dices se debe a que se ha llegado al limite de sprites por scanline, o al limite de pixeles que son 272, o bien al limite de los 128 sprites. Yo dije en otro hilo que el juego de Batman Returns se llegaba al limite de los 128 sprites y por eso se desaparecían una parte de algún enemigo y se veía esos parpadeos que dices. Voy a tratar de sacar una captura de esto, con el emulador no$sns, en donde se pueden ver los sprites también.

En realidad lo que estaba diciendo era que el bug del generador de imágenes no es que cause las desapariciones de sprites, sino que mas bien prioriza al revés los que deben desaparecer cuando se excede el límite, y por lo tanto se hace mas evidente.

gasega68k escribió:Estas equivocado, el problema esta en que cuando usas un sprite de 32x32 estarías usando 16 tiles y en cambio un sprite de 16x32 usarías 8 tiles. Ahora si usas dos sprites de 16x16 asi si usarías solo 8 tiles. A la hora de programar un juego deberás decidir cual de las dos opciones sera la mejor, pero en ambos casos queda en desventaja con respecto a Genesis/MD.
Nota: para los que no lo saben, un tile es un espacio de 8x8 pixeles.

Cierto. No es el gasto de información (pixels usados, profundidad de color), sino el uso limitado de tiles.

gasega68k escribió:Como dije anteriormente los sprites de 64x64 son "inservibles", no creo que haya ningún juego que los haya usado, y ademas no hay tal "bug".

Ya queda aclarado mas arriba.

gasega68k escribió:No, en realidad el manejo de los sprites es ineficiente en el snes, debido a como fue diseñado los registros del OAM en donde se tienen que enmascarar bits para la coordenada "X" y "tile index", no tiene que ver con el CPU, para que me entiendas si ambas consolas tuvieran el 68000 o el 65c816 aun así sería mas eficiente el manejo de los sprites en el Genesis/MD.

Los registros del OAM no son eficientes, pero eso no significa que su rendimiento sea insuficiente, y menos aún ateniendo a las especificaciones que tiene su sistema de vídeo.

De todos modos es algo sobre lo que quiero profundizar, a ver si encuentro documentos interesantes al respecto.

gasega68k escribió:https://en.wikipedia.org/wiki/WDC_65816/65802Bueno, de verdad si que estas perdido. ¿"toas las instrucciones del 68000 son de 32 bit"?, ¿"por cuestiones de direccionamiento del registro de estado, el bus está limitado a 16 bits"?, acaso sabes lo que es un registro de estado?, de verdad no se de donde sacas estas cosas que escribes, estas totalmente perdido.

Si... como ya dije, estoy perdido con eso xD

Demasiado largo de explicar... pero no me refería al registro, sino al bus que utiliza. Es decir, no que ese bus sea de 16 bits porque el registro de estado lo imponga. Eso no tendría sentido... bueno, de hecho ninguna interpretación lo tiene, pero lo puse porqueyoquese

gasega68k escribió:Voy a dar una breve explicación sobre el 68000. Este CPU se dice que es un CPU de 16/32 bit porque aunque tiene un bus de datos de 16 bits puede realizar operaciones de 32 bit internamente, tiene 16 registros de 32 bit, 8 son llamados registros de datos y 8 son llamados registros de dirección, se pueden realizar operaciones lógicas y aritméticas en 8, 16 y 32 bit y operaciones en bits, y a diferencia del CPU 6502(y sus derivados) en donde la mayoría de las operaciones se deben hacer a través del registro "A"(llamado acumulador), en el 68000 se pueden realizar todas las operaciones lógicas y aritméticas en cualquier registro de datos y operaciones aritméticas en registros de dirección e incluso se pueden realizar operaciones lógicas y aritméticas sin intervención de registros, directamente en memoria. Tiene un amplio y variado conjunto de instrucciones que lo hacen muy versátil, ademas puedes realizar códigos usando solo registros en los casos en que la velocidad es importante y es allí en donde este cpu se destaca comparándolo con CPUs de la serie 6502, y ni hablar de operaciones de 32bits(que en el caso del 65c816 no tiene), que aunque mucha gente no crea, se usa mas frecuentemente de lo que parece.

Bastante cómodo en comparación, si. Luego están los datos sobre la eficiencia, pero igualmente se lo puede permitir.

gasega68k escribió:El cpu del snes es un cpu con 8 bits de datos y 24 bits de dirección(por eso es que los cartuchos tienen roms de 8bits), la memoria ram, la rom (cartucho) y los PPUs se conectan a estos buses, no existen "otros buses".

Exacto. Los datos viajan en un ancho de banda de 8 bits... aunque ya digo que el sistema es demasiado complejo como para reducirlo todo a ese punto.

gasega68k escribió:

Los juegos de snes no usan registros de 8 bits. Esos registros estaban destinados a correr los juegos de NES. Esa comparación no tiene sentido.

Aunque no lo creas es común que hayan operaciones en 8 bits, ademas que hay registros de los PPU que se deben hacer en 8 bits, como los registros para el modo 7, scroll de backgrounds y OAM(sprites).

Entiendo que quieres decir que se manda en bloques de 8 bits, o de que cierta información no ocupe mas de eso (porque el HDMA no necesita grandes volúmenes de información para lanzar la instrucción), y que por lo tanto el resto del registro (los siguientes 8 bits del registro de 16) no tenga uso, ¿no?.

Una cosa es operaciones en 8 bits, y otra usar los registros en 8 bits que implicarían estar funcionando en modo emulación. Es lo que estaba mencionando.

gasega68k escribió:Que hayan operaciones en 8 bits no hace que una consola sea de "8 bits", en el Genesis/Md también se hacen algunas operaciones en 8 bits, incluso en el GBA que tiene un CPU ARM7 también se pueden ver algunas cosas en 8 bits.

Es decir, que no toda la información/órdenes ocupan grandes extensiones de memoria.

gasega68k escribió:Mas bien creo que pudiera ser cerca de la mitad los juegos a 3.58mhz (sobretodo los últimos), lo que sucede es que los juegos que corren a 3.58 requieren Memorias Roms mas rápidas, y al principio la mayoría de juegos usaban Roms "lentas" porque eran menos costosas, ya mas adelante era mas común que se usaran Roms mas rápidas. Aunque hayan juegos a 3.58mhz, el acceso a la Wram (ram del sistema) siempre sera a 2.68mhz, aquí está un "quote" sacado de la documentación del emulador no$sns:

Note that WRAM is accessed at 2.6MHz. Meaning that all variables, stack, and
program code in RAM will be slow. The SNES doesn't include any fast RAM.

Para los que no entienden ingles esto es lo que dice mas o menos: Nótese que el acceso a la Wram será a 2.6mhz. Esto significa que todas las variables, stack, y codigo en RAM será lento. El Snes no incluye ninguna Ram rápida.

Aunque hay una manera de acceder a la Wram a 3.58, a través de un registro para ese fin, pero solo será para leer o escribir datos secuenciales, no servirá para variables o código.

Todo lo que he escrito aquí no es algo que yo tenga en contra del Snes, son simplemente datos técnicos que cualquier persona puede verificar solo buscándolos.

Y sobre el tema de este hilo voy a expresar mi opinión al respecto mas adelante.

Eso es lo que tenía entendido, que la cpu se adapta a las memorias, y que causa "step-down" cuando lee/escribe, pero que funciona a 3.58mhz cuando ejecuta procesos internamente.

De hecho ya lo mencioné en otro hilo hace poco, creo recordar. La poca frecuencia de las memorias, la latencia de estas, y el ancho de banda del bus de datos, son el mayor despropósito de la máquina (las mas inmediatas de las pegas, vamos).

En definitiva, snes no puede hacer un port 1:1 de sr2, y megadrive puede con un "mediocre" dkc sin despeinarse (si no fuese por la paleta de colores ,claro)

binario22 escribió:En definitiva, snes no puede hacer un port 1:1 de sr2, y megadrive puede con un "mediocre" dkc sin despeinarse (si no fuese por la paleta de colores ,claro)

Visto así ninguna consola puede hacer un port 1:1 devla otra,ni por colores,resolución,sonido,efectos......solo serían parecidos.Y eso lo puedes ver con cualquier juego multiplataforma.

mcfly escribió:

binario22 escribió:En definitiva, snes no puede hacer un port 1:1 de sr2, y megadrive puede con un "mediocre" dkc sin despeinarse (si no fuese por la paleta de colores ,claro)

Visto así ninguna consola puede hacer un port 1:1 devla otra,ni por colores,resolución,sonido,efectos......solo serían parecidos.Y eso lo puedes ver con cualquier juego multiplataforma.

Aleluya !!! Por fin os habeis dado cuenta de que por arquitecturas distintas, ninguna de las dos consolas (3 venga, incluyamos a la PcAnginas...) puede hacer un port 1:1 de la otra.

Exacto? ERROR !!!!

Parecido muy mucho ?? ACIERTO

releon escribió:Lo diré una vez solo.

Un título puede estar programado para exprimir, por ejemplo, el 90% de potencia y cálculo CPU. Suponiendo que SOR2 (u otro cualquiera) lo hiciese (solo por cpu) Snes no podría con un port 1:1 ni de coña porque es obvio.

Si Nintendo lo hiciese igual planteado con sus herramientas adaptado a Snes podrían sacarlo parecido explotando la potencia cpu al máximo, pero jamás sería port 1:1 por temas obvios.

¿Podrían ser ambos iguales gráficamente y sonoramente? Quizás similares al 80% pero 100% jamás, cada cual tiene su sello y su manera de desarrollar. Gráficamentre y sonoramente Snes podría hacerlo mejor (no lo dudo) pero tal cual está SOR2 ni de coña. En resumen, puede mejorar o empeorar pero port 1:1 JAMÁS.

Salu2.

Como dice Vareland y autocitándome lo que dije atrás sin dar tantísimos datos técnicos como el compañero gasega, seguramente sigan los mismos teniendo dudas. Creo que con esto y un bizcocho pondré fin al hilo porque ya está todo lo importante dicho y demostrado.

Condios!

Segueros contra Nintenderos, benditas guerras.

binario22 escribió:En definitiva, snes no puede hacer un port 1:1 de sr2, y megadrive puede con un "mediocre" dkc sin despeinarse (si no fuese por la paleta de colores ,claro)

Pues igual que la Game Boy y la Game Boy Color tuvieron sus Donkey Kongs o el juego pirata ese de NES que es un Donkey Kong Country con pandas.

Si los DKC son juegos de plataformas como han habido cientos, no hacen que la SNES "sude" a la hora de moverlos, ni nada por el estilo.

En lo único en lo que son exigentes es en su banda sonora y su preciosismo visual, no solo por su estilo gráfico renderizado, si no también por la calidad y cantidad de sus efectos (las luces de los focos, las nieblas) y es precisamente ahí donde los ports perderán más o menos según la máquina a la que vayan. Pero el juego en sí, no tiene ningún misterio para consolas que muevan con soltura juegos de plataformas.

Ummmm, y ya que estamos, cual creeis que es el juego que exprime lo maximo la snes?. Será el Donkey kong country?, o el street figther alpha 2?, o el famoso mario rpg?. Cual creeis?.

Y de megadrive?, cual creeis?

Kasios escribió:Ummmm, y ya que estamos, cual creeis que es el juego que exprime lo maximo la snes?. Será el Donkey kong country?, o el street figther alpha 2?, o el famoso mario rpg?. Cual creeis?.

Y de megadrive?, cual creeis?

Como ya he dicho antes, los DKC solo exprimen en aspecto visual, por los colores y los efectos tan chulos que usan (aun recuerdo la miel resbalando por la pantalla del televisor en DKC2, ese efecto me encantaba) pero a nivel jugable es otro juego de plataformas más, no creo que exija nada fuera de lo normal.

Ahora que si te refieres a cual es más bruto a nivel "visual" la trilogía de Donkey seguramente este entre los mejores, porque visualmente esta muy cuidada en todos los sentidos.

Kasios escribió:Ummmm, y ya que estamos, cual creeis que es el juego que exprime lo maximo la snes?. Será el Donkey kong country?, o el street figther alpha 2?, o el famoso mario rpg?. Cual creeis?.

Y de megadrive?, cual creeis?

A ver, que exprima lo máximo en cuanto a churruscar CPU, seguramente no sea en ninguna de las dos consolas uno de los mejores juegos.

Por ejemplo, en Megadrive, seguramente StarCruiser debe ser uno de los que mas gasto le dan a la CPU al usar 3D
https://www.youtube.com/watch?v=yND5V85iPHc

En Super, pues no estoy muy seguro, pero probablemente el Street Fighter Alpha 2 (su lógica de sistema de combate es la ostia )o quizá el Drakkhen II por el 3d
https://www.youtube.com/watch?v=pRQeMDwB5_4

kusfo79 escribió:

Kasios escribió:Ummmm, y ya que estamos, cual creeis que es el juego que exprime lo maximo la snes?. Será el Donkey kong country?, o el street figther alpha 2?, o el famoso mario rpg?. Cual creeis?.

Y de megadrive?, cual creeis?

A ver, que exprima lo máximo en cuanto a churruscar CPU, seguramente no sea en ninguna de las dos consolas uno de los mejores juegos.

Por ejemplo, en Megadrive, seguramente StarCruiser debe ser uno de los que mas gasto le dan a la CPU al usar 3D
https://www.youtube.com/watch?v=yND5V85iPHc

En Super, pues no estoy muy seguro, pero probablemente el Street Fighter Alpha 2 (su lógica de sistema de combate es la ostia )o quizá el Drakkhen II por el 3d
https://www.youtube.com/watch?v=pRQeMDwB5_4

Que wapo el drakken 2, no?, no hay traducción al español?

Muy grande Gasega con sus explicaciones, sencillas, yendo al grano sin enrevesar las cosas y "fáciles" de entender incluso para los que no sabemos de estos temas, es una suerte tener a gente así mezclada entre la plebe y que encima tire pa MegaDrive , dejaos de presionarle para que se pase a Nintendo, que es nuestro Yuji Naka/Yu Suzuki particular, buscaos a otro!!! (necesitáis a programadores de MD que os enseñen a entender la SNES, si es que... ).

Chistes aparte, en mi humilde opinión, insisto en lo que ya he dicho más veces, no hace falta tanto echar mano a datos técnicos ni a suposiciones, simplemente jugando uno se da cuenta los pros y contras de cada consola, lo de la vagancia de los programadores, años de lanzamiento, etc... no son más que "justificaciones" o excusas, es evidente que la paleta de MD se queda corta respecto a SNES, o que la Super sufre cuando mete velocidad y chicha en pantalla, el que no vea ésto es que no ha debido jugar mucho a ambas, o simplemente que no lo quiere ver.

Chistes aparte, eso de que el DKC no aprieta la SNES no sé yo, una cosa es que como dice Kusfo79, no lleve al límite el procesador y otra que no aproveche a tope las prestaciones de la consola...

@Kusfo79

El Star Criuser lo conservo original por el musicón de la intro (y del resto del juego), porque el estar en chinorri lo hace totalmente injugable, y es una putada porque es un juego muy interesante.

robotnik16 escribió:
Chistes aparte, eso de que el DKC no aprieta la SNES no sé yo, una cosa es que como dice Kusfo79, no lleve al límite el procesador y otra que no aproveche a tope las prestaciones de la consola...

Me refiero a que lo apreta tanto como puede apretarlo cualquier otro juego de plataformas similar, vamos que DKC no "rompe las reglas" en ningún sentido, técnicamente hablando. Tiene muchas virguerías, pero casi todas destinadas a efectos visuales, que es lo que suele perder en las conversiones, porque ahí sí, que han llegado a usar las capacidades de la consola (como las transparencias) con mucho acierto.

En cierto modo es normal que la gente se crea que son juegos extremadamente exigentes o incluso que llevan chips de apoyo (como muchos piensan) porque visualmente son tremendos, pero a nivel jugable no creo que veas nada que ponga la SNES contra las cuerdas. De hecho es muy posible que algunos juegos como la trilogia Magical Quest o incluso el Castlevania 4 hagan que la consola trabaje más en algunos puntos concretos.

Comparad el DKC de SNES con el de GB Color y veréis que para la diferencia técnica que hay en ambas máquinas, el juego de GBColor es muy fiel al de SNES en el desarrollo de los niveles. Obviamente, todas las virguerias visuales han desaparecido.

Y repito, soy muy ignorante en temas técnicos, puede que este equivocado, pero no lo creo. A la consola le cuesta lo mismo mover un sprite de DKC que un sprite del Super Mario World, siempre y cuando tengan las mismas caracteristicas (tamaño, colores...) de la misma manera que le costaría lo mismo mover un Ryu que un Liu Kang (si tuviesen las mismas caracteristicas), por mucho que el sprite de Liu Kang provenga de una foto real y el de Ryu un sprite dibujado.

Skullomartin escribió:

robotnik16 escribió:
Chistes aparte, eso de que el DKC no aprieta la SNES no sé yo, una cosa es que como dice Kusfo79, no lleve al límite el procesador y otra que no aproveche a tope las prestaciones de la consola...

Me refiero a que lo apreta tanto como puede apretarlo cualquier otro juego de plataformas similar, vamos que DKC no "rompe las reglas" en ningún sentido, técnicamente hablando. Tiene muchas virguerías, pero casi todas destinadas a efectos visuales, que es lo que suele perder en las conversiones, porque ahí sí, que han llegado a usar las capacidades de la consola (como las transparencias) con mucho acierto.

En cierto modo es normal que la gente se crea que son juegos extremadamente exigentes o incluso que llevan chips de apoyo (como muchos piensan) porque visualmente son tremendos, pero a nivel jugable no creo que veas nada que ponga la SNES contra las cuerdas. De hecho es muy posible que algunos juegos como la trilogia Magical Quest o incluso el Castlevania 4 hagan que la consola trabaje más en algunos puntos concretos.

Comparad el DKC de SNES con el de GB Color y veréis que para la diferencia técnica que hay en ambas máquinas, el juego de GBColor es muy fiel al de SNES en el desarrollo de los niveles. Obviamente, todas las virguerias visuales han desaparecido.

Y repito, soy muy ignorante en temas técnicos, puede que este equivocado, pero no lo creo. A la consola le cuesta lo mismo mover un sprite de DKC que un sprite del Super Mario World, siempre y cuando tengan las mismas caracteristicas (tamaño, colores...) de la misma manera que le costaría lo mismo mover un Ryu que un Liu Kang (si tuviesen las mismas caracteristicas), por mucho que el sprite de Liu Kang provenga de una foto real y el de Ryu un sprite dibujado.

Sabía que te referías a eso, lo que pasa es que cuando se habla de techo técnico hay quien sólo se centra en cuestiones muy puntuales. Quizás sea cosa mía, pero para mí lo técnico empieza por los propios grafistas, o simplemente por la idea o tipo de juego.

robotnik16 escribió:Sabía que te referías a eso, lo que pasa es que cuando se habla de techo técnico hay quien sólo se centra en cuestiones muy puntuales. Quizás sea cosa mía, pero para mí lo técnico empieza por los propios grafistas, o simplemente por la idea o tipo de juego.

Supongo que yo he separado lo visual de lo totalmente técnico, centrándome en que el desarrollo de los niveles de los DKC no es nada exageradamente complejo, ni mucho menos. Pero en caso que te refieras a ambas cosas, si que podía decir que los DKC ponen el listón muy alto, gracias al añadido visual.

En ese sentido, todas las virguerias visuales que usaron los de Rare para que el juego se viese como se ve, serían el principal problema para hacer un port a una consola anterior a la SNES, de hecho lo más seguro es que en caso de tener que hacer un port de los DKC a otra consola, todas esas cosas se eliminasen igual que se hizo en las versiones de GB Color.

Claro, yo al pararme a pensar en temas complejos, me he quedado mas con la idea de los juegos de plataformas que recurren a mil chorradas raras para hacer efectos raros como el Castlevania 4 o la trilogia Magical Quest, que son juegos mucho menos vistosos que los DKC, pero seguro que a la hora de hacer esas rotaciones en los niveles y en los enormes jefes finales, deformaciones y zooms, dan más trabajo a la SNES que un nivel cualquiera del DKC.

Señor Ventura escribió:Por ejemplo, una nave en un shooter no necesita saltar, ni salirse de la pantalla... y puede tener una forma lo suficientemente cuadriculada como para que tenga sentido meterlo ahí.
...o en su defecto, un sprite de 64x64 para la parte central de la nave, y otros de 16x16 a izquierda y derecha si se quieren añadir mas detalles (o arrriba y abajo... o en todas direcciones, vaya).

También puedes hacer un beat'em up en el que los enemigos no saltan hasta el cielo. Todo depende del diseño. Obviamente su uso es algo mas limitado, pero no creo que se pueda decir que no tiene uso en juegos.

Es cierto que se puede utilizar sprites de 64x64 en los ejemplos que das, pero si lo vemos desde este punto de vista:
cuando vas a usar sprites de 64x64 tendría que ser para objetos grandes, idealmente se usarían por ejemplo para los jefes de final de nivel, porque usarias 64 tiles y si hubieran varios de estos objetos utilizarías muchos tiles(y solo hay 512 disponibles), y como solo sería un sprite de 64x64 (para un jefe de final de nivel) se pudieran usar 4 sprites de 32x32 y no habría problemas.

No digo que no se puedan utilizar sprites de 64x64, lo que pasa es que esta muy limitado, y como dije antes hasta ahora no he visto juegos que use sprites de ese tamaño.

Señor ventura escribió:¿Sería posible implementar una forma de hacer que los pixels de los sprites que queden tapados por otros sprites, no computen para el límite de pixels por scanline? (algo así como por ejemplo hacer desaparecer los sprites que quedan por detrás de otros sprites hasta que cualquiera de sus pixeles vuelvan a aparecer).

Es difícil, porque tendrías que saber que los sprites que estén por encima de los que quieras "desaparecer" no tengan alguna parte con color transparente (color 0) que haga ver el sprite que esté detrás.

Señor ventura escribió:Y otra mas, que por mas que intento leer, no consigo encontrar nada. Cuando se establece la configuración del tamaño para sprites grandes y sprites pequeños, ¿es algo que permanece de forma rígida?, o permite una cierta flexibilidad para cambiarlo en mitad de una fase sin ningún tipo de reseteo (es decir, al vuelo).

Si se puede cambiara en cualquier momento, pero afectaría a todos los sprites.

Señor Ventura escribió:En realidad lo que estaba diciendo era que el bug del generador de imágenes no es que cause las desapariciones de sprites, sino que mas bien prioriza al revés los que deben desaparecer cuando se excede el límite, y por lo tanto se hace mas evidente.

Creo que ya se a que te refieres, es cuando por ejemplo hay 17 sprites en linea y luego agregas otro, y el que desaparece es el primero en vez de el ultimo que es lo que uno pensaría. Claro tambien depende del orden en que esten los sprites. El ejemplo que dí es en el caso de que los sprites que esten en linea sea los 17 primeros, es decir desde el sprites0 a sprite16 y cuando se agrega el sprite17 desaparece el sprite0. Pero igual no creo que eso se deba a algún bug sino a a la forma en que esta hecho.


Aquí están las imágenes del Batman Returns de snes que había prometido antes:
(en ambas imágenes se ve una linea con un recuadro rojo que es lo que se ve cuando se sitúa el puntero del ratón en uno de los sprites, y es para poder ver en donde está el sprite en la imagen del juego).


En esta imagen se pueden ver que se esta usando todos los sprites(a la izquierda) y se ve en una de las motocicletas desaparecer un pedazo de una de las ruedas.



En esta imagen no tienen todos los sprites usados, pero se ve a uno de los motociclistas (en la cabeza) desaparecer un pedazo, posiblemente por el limite de pixeles o sprites por linea.

gasega68k escribió:Es cierto que se puede utilizar sprites de 64x64 en los ejemplos que das, pero si lo vemos desde este punto de vista:
cuando vas a usar sprites de 64x64 tendría que ser para objetos grandes, idealmente se usarían por ejemplo para los jefes de final de nivel, porque usarias 64 tiles y si hubieran varios de estos objetos utilizarías muchos tiles(y solo hay 512 disponibles), y como solo sería un sprite de 64x64 (para un jefe de final de nivel) se pudieran usar 4 sprites de 32x32 y no habría problemas.

No digo que no se puedan utilizar sprites de 64x64, lo que pasa es que esta muy limitado, y como dije antes hasta ahora no he visto juegos que use sprites de ese tamaño.

La parte buena es que dependiendo de la escena, y del diseño del juego, no van a desaparecer sprites debido al límite por pixel a menos que llenes todo un scanline, pero justo me estaba preguntado si los pixels transparentes cuentan para el límite por scanline...

Y luego está el límite de que un sprite de 64x64 solo podría tener una profundidad de 16 colores, que tambien es importante si el resto de sprites están ideados para mostrar mas detalles de color.

gasega68k escribió:

Señor ventura escribió:¿Sería posible implementar una forma de hacer que los pixels de los sprites que queden tapados por otros sprites, no computen para el límite de pixels por scanline? (algo así como por ejemplo hacer desaparecer los sprites que quedan por detrás de otros sprites hasta que cualquiera de sus pixeles vuelvan a aparecer).

Es difícil, porque tendrías que saber que los sprites que estén por encima de los que quieras "desaparecer" no tengan alguna parte con color transparente (color 0) que haga ver el sprite que esté detrás.

En ese caso, si se vieran los pixels del sprite que tiene que desaparecer, no lo haría (no desaparecería). Aparte de conseguir la estabilidad para que la rutina funcione, habría que considerar mas condiciones todavía cuando está el color 0 por medio.

¿Realmente estaría dentro del alcance de estos procesadores? (no en una demo, sino en un juego que demande tambien su buena parte de tiempo de proceso, se entiende).

gasega68k escribió:Creo que ya se a que te refieres, es cuando por ejemplo hay 17 sprites en linea y luego agregas otro, y el que desaparece es el primero en vez de el ultimo que es lo que uno pensaría. Claro tambien depende del orden en que esten los sprites. El ejemplo que dí es en el caso de que los sprites que esten en linea sea los 17 primeros, es decir desde el sprites0 a sprite16 y cuando se agrega el sprite17 desaparece el sprite0. Pero igual no creo que eso se deba a algún bug sino a a la forma en que esta hecho.

Una cosa muy curiosa que siempre me había planteado, es que todo este tema de la desaparición de sprites jamás ha afectado al SFX (el chip), aunque teóricamente es algo que tambien le afecta, pues tanto el límite de 128 sprites, como el resto de imposición que implica el uso del hardware de vídeo, siguen teniendo vigencia.

Y resulta que esto es así porque funciona de una forma muy "especial".
Un ejemplo es el doom. Para sprites se usan únicamente los relativos a los marcadores, y poco mas... mientras que los enemigos -que pueden llegar a ser tan grandes como la pantalla-, pueden coincidir además en un buen número hasta llenar toda la pantalla si hace falta, y sin rastro de parpadeos.
La respuesta es que toda esa información se encuentra en el background 1 como si tudo fuese el plano principal. El movimiento del escenario, y el cambio de posición de los enemigos son enviados a la vram en forma de "pantallazo", y la snes lo muestra todo como "background 1".

Entonces he pensado que es cosa de las características del SFX, de que incluye por hardware a través de sus pines extras la posibilidad de transferir a la VRAM prescindiendo del DMA, y por lo tanto mas rápido...
...pero he recordado lo que comentaste del wolfenstein, y efectivamente, ocurre exactamente lo mismo que con el doom, usando el background 1 como plano en modo 7, y así reescalar sin problemas de rendimiento.
Es decir, que tener ese fotograma en la VRAM es lo realmente complicado, pero una vez con ese fotograma en memoria puede estar escalado con las coordenadas que se prefieran sin nigún problema (gracias a que es una característica del modo 7 manejar las coordenadas de un plano de forma independiente).

Se que es un cambio de tercio importante en la conversación, pero, ¿la dificultad de mostrar eso en pantalla hasta el punto de estar a una resolución tan pequeña (procesos lógicos de la cpu aparte), se debe en gran medida a que no se podría transferir un pantallazo a 256x224 por motivos de ancho de banda del bus?.

gasega68k escribió:

Señor Ventura escribió:Por ejemplo, una nave en un shooter no necesita saltar, ni salirse de la pantalla... y puede tener una forma lo suficientemente cuadriculada como para que tenga sentido meterlo ahí.
...o en su defecto, un sprite de 64x64 para la parte central de la nave, y otros de 16x16 a izquierda y derecha si se quieren añadir mas detalles (o arrriba y abajo... o en todas direcciones, vaya).

También puedes hacer un beat'em up en el que los enemigos no saltan hasta el cielo. Todo depende del diseño. Obviamente su uso es algo mas limitado, pero no creo que se pueda decir que no tiene uso en juegos.

Es cierto que se puede utilizar sprites de 64x64 en los ejemplos que das, pero si lo vemos desde este punto de vista:
cuando vas a usar sprites de 64x64 tendría que ser para
[...]

[...]

Aquí están las imágenes del Batman Returns de snes que había prometido antes:
(en ambas imágenes se ve una linea con un recuadro rojo que es lo que se ve cuando se sitúa el puntero del ratón en uno de los sprites, y es para poder ver en donde está el sprite en la imagen del juego).


En esta imagen se pueden ver que se esta usando todos los sprites(a la izquierda) y se ve en una de las motocicletas desaparecer un pedazo de una de las ruedas.



En esta imagen no tienen todos los sprites usados, pero se ve a uno de los motociclistas (en la cabeza) desaparecer un pedazo, posiblemente por el limite de pixeles o sprites por linea.

Una vez más perfectas explicaciones, desconocía que la SNES iba a full de sprites en este tipo de juegos.

Lo que pasa es que ....joer gasega YO PENSÉ que ibas a meterte a programar algo en SNES .

Saludos y mientras sigáis así, da gusto leer este tipo de hilos.