gasega68k escribió:@Señor Ventura ¡en donde puedo encontrar esa demo del bad apple a 512x448!
?? Tienes algun link?
Por mas que busco no la he encontrado. Yo recuerdo alguien mencionar (en nesdev? )sobre hacer una version a 512 pero nunca vi que la sacaran.
La demo surgió
de aquí, y hasta llegó a completarse con audio a 16 bits 32khz:
https://forums.nesdev.com/viewtopic.php?f=12&t=10696No he revisado todo el hilo, pero creo recordar que dijeron que lo limitaron a 15fps hasta que solventaran un contratiempo con la descompresión. Hablo muy
de memoria, pero la demo si que fué real, y hasta colgaron la rom, y hubieron vídeos en youtube.
Ahora ha desaparecido todo
EDITADO: ahora que lo menciona
@balónybalín, es posible que la versión msu-1 funcionara a 30fps debido a que la pega con la descompresión del audio desaparecía (añadiendo audio a 44khz), pero en la versión con audio a 32khz mediante el spc700, la demo funcionaba provisionalmente a 15fps (eso si, a 512x448i).
Realmente no recuerdo los detalles, pero vamos, que la resolución se alcanzó, y también renderizar a la máxima resolución horizontal.
balónybalín escribió:Fatal Fury 2 y World Heroes (en especial el primero), me sorprendió mucho hace pocos meses, se muestra superior al de Snes en varios detalles y no me lo esperaba,.
Creo que me gusta mas el fatal fury 2
de megadrive, aunque no le he echado un vistazo a fondo, pero da la impresión
de que en snes se comen planos y tamaño
de personajes, en comparación con megadrive, que anda mas equilibrada en general.
Aunque también hay que mencionar que he encontrado algunas discrepacias que son mas exactas en snes, como el propio aspecto
de algunos escenarios. El
de big bear por ejemplo, la versión snes se parece mas a la versión neo geo (está todo mas colocado en su sitio, un ejemplo es el horizonte con el sol partido por la mitad en la
de sega, o que el camión no está en la misma posición con la pantalla centrada, al empezar cada round).
Luego la versión snes tiene bandas negras, y la versión megadrive tiene un "modo ventana" que también arruina bastante el resultado final.
Sobre el world heroes no puedo estar
de acuerdo. Los gráficos son mas limpios en snes, la jugabilidad se parece mucho mas a la
de neo geo, y además sin los fallos
de colisiones que tiene la versión megadrive:
https://youtu.be/E1wJbWdrtAk?t=60darksch escribió:@Señor Ventura cuando son pocos sprites grandes sin problema, en ninguna 16-bit los encontrarás. El problema está cuando hay que mezclar tamaños, o poner muchos. El problema está en la cantidad, que te cae rápidamente, por eso no pueden poner tantos en sus beat'em up, por poner ejemplo.
El problema está en la cantidad
de ancho
de banda que estés dispuesto a gastar, para todo lo demás está la tabla
de atributos
de los sprites, que deja la tarea
de "unir" los sprites al sistema
de vídeo sin que suponga un coste extra para la cpu, salvo por el hecho
de tener que transmitirlo (que cuantos mas slots, mas tarea, y mas ancho
de banda se come).
El batman returns
de snes pone 128 sprites en pantalla a base
de sprites
de 8x8. Si malgastas sprites es porque quieres, porque a base
de sprites
de 32x32 ahorras muchos sin ningún problema.
darksch escribió:Y pues claro que puede hacer efectos
de ese tipo, también cuenta con interrupciones
de línea. Pero fíjate que es apareciendo un enemigo, zona con poca acción, y un efecto más simple que los que se ven en MD.
Mira (minuto 2:48)
https://youtu.be/EmO8WGx1hcE?t=2m48s
No,
de alterar los scanlines
de un plano, o todos los que el sistema
de vídeo pueda representar, se encarga el propio sistema
de vídeo, no la cpu, así que "rasterizar" planos durante una escena
de acción compleja, supone lo mismo que no "rasterizarlo".
darksch escribió:La diferencia de lo que se puede hacer es muy notable, dada la diferencia de CPU, ya que la interrupción se lleva sus ciclos y el M68k la gestiona mucho más rápido.
No, el 65816 es muy superior ejecutando interrupciones que el 68000 incluso funcionando a la mitad
de la frecuencia que el motorola.
darksch escribió:4 colores por plano son inusables, o nos vamos ahora a buscar el caso concretísimo en que por diseño del juego específico si le vale, como un juego donde meten 4 grises y ale, venga va. El Yoshi's usa el chip FX 2, mejor no usarlo mucho como ejemplo.
Son 4 colores por tile, no por plano.
Y además la snes dispone
de 8 paletas
de 4 colores por cada uno
de los cuatro planos. Es decir, que cada plano puede representar 32 colores, y cada uno
de los tres planos puede representar otros 32 colores diferentes al
de los demás planos.
Hablamos
de 128 colores entre los cuatro planos,
de una paleta
de 32768. ¿Y cual es la limitación?, pues que solo pueden hacer cuatro colores diferentes en cada grupo
de 8x8 pixels.
Pero vamos, que te estás imaginando una cosa muy diferente a la que es en realidad, y ya te puse dos ejemplos con 4 planos en los que no se veía nada mal.
En megadrive la cosa está en 2 o 4 paletas
de 4 colores para su plano
de 4 colores por tile,
de una paleta
de 512 colores.
darksch escribió:Por cierto, hablas de una demo, eso no sirve para nada. Las demos corren en unas condiciones y hacen uso de recursos que en un juego no puedes usar.
La MD también puede usar modo entrelazado para 320x448, pero también era inusable en juegos. Porque en algún caso muy concreto quizás se pudiera meter, no se puede usar como estandarte de que fuera su modo estándar precisamente.
No mezclemos la resolución horizontal con la resolución vertical.
Los 512 pixels horizontales para los planos son cosa del ppu1, sin pérdida
de rendimiento para la cpu, y por lo tanto tiene
de usable tanto como tu ambición para representar muchos tiles diferentes sea coherente con el ancho
de banda, pero eso es solo cuesitión
de dibujado. Para el rendimiento no hay impacto.
Otra cosa es doblar la resolución vertical. Pasar
de 224 a 448 si es potencialmente costoso para la cpu.
darksch escribió:@balónybalín fíjate que los ejemplos que pones todos usan o personajes muy grandes, o cabezones. Ahí claro que hay "sitio" para poner caras. Lo que es innegable, a ver quien puede decir que no, es que un 25% más
de resolución (256 -> 320) da para poner más detalles en el mismo espacio, que parece es lo que todo el mundo está obviando. Es que es algo
de cajón, venga ponemos algo más grande y ya tiene el mismo detalle, um, pues coges en la otra, lo agrandas al mismo tamaño, y en ese mismo tamaño puedes poner más detalles no?
No.
Un gráfico que haces con 6x2 tiles, va a seguir conteniendo todos los pixels que lo conforman tanto a 256x224, como a 320x224, y la proporción con respecto a la pantalla que queda libre no es tan drámatico como planteas, a menos que hablemos
de objetos super gigantes.
darksch escribió:Recordemos que SNES era más cara, con una CPU recortada. Lo cual al mismo tiempo introducía otra tara, y era el bus de datos 8-bit, para acceso al cartucho. Probablemente por eso se metieron 256KB de RAM, para volcar los datos de la ROM a la RAM y poder usar los address bus, o eso pienso al menos.
Todo depende
de como lo quieras mirar.
Con un bus
de datos
de 8 bits, una cpu que funciona a la mitad
de frencuencia que el 68000
de la megadrive, y un DMA que rebaja aún mas ese pico máximo
de frecuencia (2,68mhz), consigue alcanzar 6,32KB por frame (6,14KB debido a que la WRAM obliga a parar a todo el sistema durante 40 master cycles por cada scanline para "realimentar" todas sus celdas).
Si lo comparas con los 7,22KB por frame que consigue megadrive, te das cuenta que la lacra no es tal cosa, sino mas bien una eficiencia tan grande, que incluso capando por todos lados todavía es capaz
de ir pisándole los talones.
Y con respecto a la SRAM, se usa para grabar partidas en un cartucho, no para ayudar a volcar datos (que además sería una inutilidad volcarlos a una ram del cartucho, para luego volcarlos a una ram del sistema en lugar
de hacerlo directamente, para empezar porque el DMA no requiere supervisión
de la cpu, y para terminar porque no te vas a saltar el ancho
de banda que impone esta).
Pero vamos, lo dicho, que la sram del cartucho es para guardar partidas. Lo que no es si realmente puedes tener 256KB
de golpe, o si en realidad solo son "segmentos"
de 8KB. Un día
de estos lo miro.
Por último, el decodificador
de direcciones es externo, pero eso te permite saltarte el límite
de 95 megabits impuesto por nintendo, y alcanzar hasta los 118,73 megabits con uno hecho por ti mismo. No está mal si lo comparamos con los 32 megas que la megadrive puede direccionar como máximo.
darksch escribió:SNES era bastante más difícil de programar, con ese mapeo de memoria y claro vosotros no lo véis, pero los programadores tuvieron que hacer bastante magia para que con esa CPU los juegos corrieran bien, basta ver los 1os juegos con bastantes ralentizaciones.
No, el problema no fué ese, sino mas bien el hecho
de caían en un error muy típico: el
de intentar que una cpu con una arquitectura, trabaje como una cpu con otra arquitectura.
Here are techniques to avoid having your game lag:
Using the direct page for object handling. For most computer systems, object handling is done by copying the object's variables to and from "local" memory to calculate the object's next onscreen position. On the SNES's 65816, on the other hand, the direct page register can point wherever you want, so you can set it to point at an object's variables. Sadly, because this feature wasn't on very many CPUs, most SNES programmers didn't use it, and did the slower block copying.
Semi-unrolled loops. These are loops where the job is done twice per repetition. When in a loop, the CPU uses up a number of cycles counting down and jumping. With semi-unrolled looping, the CPU takes half the time it normally takes to count down and jump. It is almost as efficient as a fully unrolled loop, but with much less effort.
Inlining a subroutine. If there is a subroutine that is called in a tight loop, you can gain performance by replacing the "jsr" with a copy of the subroutine code. Calling a subroutine takes 12 cycles: 6 to jump, 6 to return.darksch escribió:@titorino pues como siempre. También están los juegos vectoriales (como Flashback) que tiran mejor en MD, y etc.etc. No hace falta ir juego por juego, conociendo la base.
De nuevo no. Aquí tienes el another world del apple iigs tirando en un 65816 mas lento que el que lleva la snes.
https://youtu.be/k1LPehNkWD4?t=152El problema es el
de siempre: BAJA OPTIMIZACIÓN.
Erwin Kloibhofer y Henk Nieborg, según Wikipedia. Para mi Lomax fué una especie de secuela espiritual, pero al parecer lo fué más bien de Lemmings..el efecto que tiene esa fase es ireeproducible en una megadrive ,con trucos quizás ,pero no igual
![[angelito]](/images/smilies/nuevos/angelito.gif "angelito")
) o gente que no tiene estima ni por una ni por otra, pero le va la gresca. Los programadores serios sobráis, sinceramente. Solo como consejo, eh.. luego haz lo que consideres, si crees que vale la pena corregir algún dato. Eso sí, no dejes de participar en otros hilos. 
![[bye]](/images/smilies/nuevos2/adio.gif "adios")
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
![[facepalm]](/images/smilies/facepalm.gif "facepalm")
![[tomaaa]](/images/smilies/nuevos2/tomaa.gif "toma")
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
:
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
%20(M6).png)
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
![[sati]](/images/smilies/nuevos2/demonio.gif "demoniaco")
![[360º]](/images/smilies/nuevos/vueltas.gif "como la niña del exorcista")
.png)
