SCENE de sistemas clásicos: ¿Debemos esperar que algún producto exprima al máximo la consola?

Señor Ventura escribió:

gynion escribió:Es que decir que "no posteo porque esos hilos se pierden" es como decir "no posteo ahí porque no me va a leer nadie". Por tanto, claro que estoy seguro de ese es el motivo.

Las cosas no son como tu dices. Te dicen que no, e insistes por un lado, por otro, y sigues, y sigues.

Posteo donde cae, y si no es el sitio, muchas veces no te pones a buscar porque no te pones a buscar. Le estás dando una importancia exagerada con esas conclusiones tuyas.

Pero es que cuando caemos en los off-topics los hilos donde tocarían esos comentarios a lo mejor están tan solo 2 o 3 hilos más abajo, no perdidos. Además, tu mismo abres muchos hilos técnicos; el último muy reciente y activo (el de los planos). Entonces, la gente se satura, aunque no nos demos cuenta.

titorino escribió:

Manveru Ainu escribió:Como ya he comentado en otros hilos, en Mega drive no hay que esperar nada, ya existe un producto (la pregunta es producto, no juego) que no solo explota la consola sino que la sobreexplota, y no funciona bien en todos los modelos. De hecho los creadores de la demo Overdrive 2 han dicho que dan por finiquitada la Mega drive y quieren ir a por la Snes.

Que posibilidades hay de meter esos efectos en un juego manveru?
Se podria meter todos ?
O existen limitaciones a la hora de introducirlos?
Por cierto estoy dandole al chakan .
Que jodido es el cabron.
Me esta gustando pero solo para valientes.

Las demos técnicas son el mejor ejemplo de lo que puede hacer un hardware pero lo interesante sería que todos esos recursos técnicos fueran en beneficio de los juegos, como pregunta titorino... Yo no sé hasta que punto hay margen para implementarlos pero apostaría a que se podrían aprovechar para hacer cosas molonas, más allá de los géneros clásicos, como beat em ups, shooters... (y en éstos también)

P.D El Chakan es un poco castaña, no?

Señor Ventura escribió:La resolución de 512x224 también está por explorar, que con un plano de 16 colores por tile la definición puede ser una machada (mas luego un secundario de 4).

¿Pero en aventuras gráficas, juegos de escenario estático, o plataformas/run and guns patéticos?

gynion escribió:Pero es que cuando caemos en los off-topics los hilos donde tocarían esos comentarios a lo mejor están tan solo 2 o 3 hilos más abajo

A lo mejor están 2 o 3 hilos mas abajo, pero no ni siquiera normalmente.

robotnik16 escribió:Las demos técnicas son el mejor ejemplo de lo que puede hacer un hardware pero lo interesante sería que todos esos recursos técnicos fueran en beneficio de los juegos, como pregunta titorino... Yo no sé hasta que punto hay margen para implementarlos pero apostaría a que se podrían aprovechar para hacer cosas molonas, más allá de los géneros clásicos, como beat em ups, shooters... (y en éstos también)

Todo lo que pueda hacer con los planos, puede implementarse en cualquier juego sin ningún problema.

Otra cosa es que por ejemplo uses toda la cpu para calcular polígonos, y no dejes ni un ciclo para todo lo demás. Ahí obviamente no podrás conseguir hacer juegos 3D con la misma calidad gráfica.

Sexy MotherFucker escribió:¿Pero en aventuras gráficas, juegos de escenario estático, o plataformas/run and guns patéticos?

En juegos con los que conformas el escenario a base de las tiles que ya tienes preinstaladas en la vram, no vas a notar diferencia. Van a seguir teniendo el mismo aspecto de reutilizar los mismos elementos (solo que con el doble de definición.

Por otro lado, si quieres fondos planos complejos que no repiten tiles, y requieres de un flujo constante de DMA, se obligará al sistema a que un plano no se mueva tan rápido como a 256x224 porque a 512x224 las tiles ocupan mas.

Se puede calcular:

Mover horizontalmente un plano te obliga a actualizar las columnas verticales. Son 28 tiles por cada uno de los dos planos... uno de ellos es a razón de 64 bytes por tile, y el otro a razón de 32 bytes por tile.

Estamos hablando de 1792 bytes + 896 bytes= 2688 bytes por frame para dibujar la columna de tiles de los dos planos.
De esta forma el scroll avanza una pantalla entera cada 32 frames, que es apróximadamente cada medio segundo, y te sobran 3783 bytes para sprites (unos 3,69KB libres de 6,32KB aunque en realidad se queda en 6,14KB de ancho de banda total debido alas condiciones que impone físicamente la WRAM, obligando al sistema a pararse brevemente a mitad de cada line buffer para refrescar las direcciones de memoria ocupadas).


Para mover el plano verticalmente, son 32 tiles por cada uno de los dos planos. Esto hacen 3072 bytes por frame, y deja libres 3399 bytes (3,32KB).
De esta forma el scroll avanza una pantalla entera cada 28 frames, lo que es alrededor de medio segundo.


Y por último, un scroll multidireccional que avanza simultáneamente a la derecha y hacia arriba, está desplazando el scroll una columna vertical y otra horizontal por frame de los dos planos, lo que ocupa 5664 bytes (por frame), y deja libre 624 bytes para sprites por frame (0,61KB).
Eso si, la tasa de relleno aumenta que es un gusto, y actualiza una pantalla entera cada 15 frames. Es decir, el scroll ha movido una pantalla entera cada cuarto de segundo.

pregunto bajo mi ignoracia .
Hay algun juego que use esa resolución?
se notaria algo especial?
yo me conformo con la scene que saquen algun tipo de juego que no se prodige mucho en snes ,no se si me explico.

Como digo para mi esta todo visto ya , o por ejemplo ver cosas como un final fantasy 7 que comento gynion en otro hilo con los graficos de snes .
seria el tio mas feliz del mundo .
de todas formas la scene de snes esta muy parada en ese aspecto ,me conformo con que salgan nuevos juegos y habrá que tener paciencia,si watermelon se pone con la máquina y los de la demo esa tan guapa de megadrive se ponen tambien empezarán a salir cosillas ,se ve que es complicao trabajar con ella ,pero puede dar frutos interesantes .

@Señor Ventura ¡Puta mierda! ¡No me convences!

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

titorino escribió:pregunto bajo mi ignoracia .
Hay algun juego que use esa resolución?

Hubo uno a 512x448i (RPM racing), pero fué solo un experimento al que no le pusieron demasiado empeño, la verdad xD

No es un buen ejemplo, porque usa tiles muy simplificadas, y muy repetidas.

titorino escribió:se notaria algo especial?

Claro, doblas la densidad de pixels horizontales. Ganas definición en los contornos.

@Señor Ventura Vale lo acabo de ver y me quedo de lejos con rock and roll racing que aun teniendo menos resolucion se ve infinitamente mejor .

titorino escribió:@Señor Ventura Vale lo acabo de ver y me quedo de lejos con rock and roll racing que aun teniendo menos resolucion se ve infinitamente mejor .

No es un buen ejemplo, el rpm racing desaprovecha totalmente esa resolución.

titorino escribió:pregunto bajo mi ignoracia .
Hay algun juego que use esa resolución?

No como tú quieres.

Sexy MotherFucker escribió:@Señor Ventura ¡Puta mierda! ¡No me convences!

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

Te lo he puesto a huevo. A ver si sabes donde está la pega...

Señor Ventura escribió:

Sexy MotherFucker escribió:@Señor Ventura ¡Puta mierda! ¡No me convences!

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

Te lo he puesto a huevo. A ver si sabes donde está la pega...

Voy to ciego de pintas domingueras, no estoy pa acertijos xDDD

Mañana en mi resaca lo miro.

gynion escribió:

titorino escribió:pregunto bajo mi ignoracia .
Hay algun juego que use esa resolución?

No como tú quieres.

Por colores o algo?

titorino escribió:Por colores o algo?

No se aprovechan los colores por tile... el plano está conformado por los mismos tiles repetidos una y otra vez... el propio apartado artístico tiene unos dibujos demasiado simplificados...

No se aprovecha esa resolución.

Sexy MotherFucker escribió:Voy to ciego de pintas domingueras, no estoy pa acertijos xDDD

Mañana en mi resaca lo miro.

No hay espacio en la memoria designada en VRAM para meter todas las tiles que caben en la pantalla sin repetir, encima son dos planos.

A 512x224 habría que repetir algún que otro tile... aunque también hay que decir que es muy complicado que un plan no te permita repetir tiles por complejo que sea, o que necesites abarcar toda la pantalla, así que en realidad no hay problema (realmente no hace faltsa ocupar todo el ancho de banda que he indicado antes).

titorino escribió:

gynion escribió:

titorino escribió:pregunto bajo mi ignoracia .
Hay algun juego que use esa resolución?

No como tú quieres.

Por colores o algo?

Por el nivel general que tiene el juego que has comentado que te gusta, Rock and Roll Racing (por cierto, juegazo); ese es un juego juego. Si existiera otro comparable ya te lo habrían dicho.

O sea, básicamente, la respuesta es no como sería deseable, o no como tú quieres.

Gracias a los dos .
@gynion @Señor Ventura
Ha habido un momento que leyendo la explicación de ventura que era como si estuviese leyendo japones.
Desde luego intento captar algo pero que va.
Lo mio no es la parte tecnica.
Entre dma,tile y demás palabras me hago la pixa un lío.
En definitiva en papel la consola podría pero con muchisimas taras de ahi que nadie se haya tirao a la piscina.

@titorino se lo inventa todo, no le hagáis caso.


( )

@Señor Ventura

No entiendo lo de repetir tiles, no se si hablan de super o MD tampoco. En caso de ser la MD, eso es un problema de rom

Se repiten por falta de rom, si tenes suficiente espacio, da igual cuantos tiles repitas en vram, podras usar los maximos colores posibles dentro de lo q permita el arte

Sexy MotherFucker escribió:Discrepo bastante, a ver; evidentemente la Mega Drive no puede mucho más que lo que se ve en demos como Overdrive 2, bastante ha dado de sí la pobre a diferencia del otro pastel de 16 bits.

Sin embargo en juegos sí que podemos esperar cosas no vistas aun: Paprium sin ir más lejos ha llevado la calidad audiovisual del género de los beat em up tan al límite como nadie lo había hecho hasta el 2017 en el sistema. Me da igual que sea porque se han gastado un montón de memoria en gráficos, y porque tenga un chip de sonido/mapeador incorporado; ningún brawler de la MD muestra unos entornos con tal nivel de detalle, con 6 mastuerzos de ese tamaño a 320x224 60 fps, y vacilando tan alegremente el límite de sprites por scanlines gracias al inteligente diseño de Fonzie. Tiene pinta de que han reventado el DMA, y se han currado unas colisiones/IA todo locas para armonizar.

Yo por ejemplo ahora espero más bandas sonoras con ese chip nuevo, o un run and gun con 64 megabits de detalle gráfico, cosas así. No van a ir en lo técnico más allá de lo visto en Overdrive, pero si lo en lo audiovisual.

A ver en un juego AAA no vamos a ver ni de cerca algo que fuerce más la mega que en esa demo, porque un juego bueno digamos requiere mucha CPU para la lógica, y adiós a muchos de los extremos trucos de hardware. Sobre el Paprium aún queda mucho por saber, por no decir todo, para poder valorar el uso del DMA, las colisiones o las IAs. Seguro que técnicamente será el mejor beat'em up de la megadrive, y seguramente será un juego que explote la mega a tope, pero hay que verlo y jugarlo.

Visualmente es igual, sólo depende de lo "chetado" que esté la rom y del ingenio del diseñador, y eso no es exprimir la consola. Sonoramente tenemos en mega canciones de 2 minutos que ocupan 32 megas, qué más quieres jejeje. Además es lo mismo, sólo depende de la rom y del talento del compositor. Usar chips de apoyo no es exprimir la mega, es ir más allá.

Como poder se puede añadir al cartucho una cpu de 1ghz, 1gb de memoria y mil dopadas que quieras, pero eso no es explotar la consola, es experimentar con un híbrido.

Señor Ventura escribió:¿Comooooooor?.

No tiene sentido. Una demo técnica lo que mas necesita es microprocesador, y ancho de banda. Mas colores en un tile es algo que consigues sin exprimir nada.

Veo que no has observado bien esa demo y su doc jejeje.

Esa demo explota el 68k, incluyendo dma, trucos de rasters en los hints, etc. Añadir más de los 61 colores de la mega con rasters exige bastante a la consola. Además que el uso extremo de colores ya está más que forzado hace una década o más. Lo que es en juegos, de hecho hasta Sonic 3 no consiguieron hacerlo sin que glichease.

La demo explota a tope el vdp, forzando la máquina para dibujar un "tercer plano" y haciendo mil virguerías experimentando con los registros de configuración y el relativamente desconocido registro de debuggeo. El sonido estaba ya más que explotado hace mucho, por eso han añadido chip de apoyo.

Sea una demo o un juego, la mega es casi todo 68k. La mega drive es una consola bastante sencilla, sobre todo comparado con la Snes y por eso está bastante exprimida ya aunque queden bastantes interrogantes. Sobre diseños o sonido como digo ya es todo cuestión de rom, no de la potencia de la cpu, chip gráfico o de sonido.

@theelf @Manveru Ainu No se entiende porque está mal expresado, obviamente no puedes usar mas colores por tile del que está predefinido.

Me refería a que un tile de 32 bytes generalmente no estaba bien explotado, y que para llegar al límite de colores por tile prefijado no hace falta usar cpu extra.

No suena igual.

@Señor Ventura bueno no existe límite de colores por tile. El único límite teórico es que un tile son 8x8 píxeles = 64 píxels => 64 colores.

Para hacer eso tienes que cambiar los colores de las paletas con el raster y cambiar la paleta asignada al tile, todo perfectamente sincronizado en cada uno de los 8 hints que recorren el tile, lo cual no es tan fácil. El número de colores que puedes cambiar por scanline es limitado y normalmente no se recomienda cambiar más de 1 o 2 porque el tiempo de cpu es muy limitado. Seguramente los del Overdrive 2 cambiarán más colores, pero aún no han dado esa info.

Con todo esto, elevar el número de colores de un tile es bastante complicado y hay que exprimir bien cada ciclo del 68k. Creo recordar haber visto una demo con un tile de 64 colores, pero no la encuentro ahora mismo.

Manveru Ainu escribió:@Señor Ventura bueno no existe límite de colores por tile. El único límite teórico es que un tile son 8x8 píxeles = 64 píxels => 64 colores.

64 colores, pero no 64 tonos. No por las buenas, vamos.

Manveru Ainu escribió:Para hacer eso tienes que cambiar los colores de las paletas con el raster y cambiar la paleta asignada al tile, todo perfectamente sincronizado en cada uno de los 8 hints que recorren el tile, lo cual no es tan fácil. El número de colores que puedes cambiar por scanline es limitado y normalmente no se recomienda cambiar más de 1 o 2 porque el tiempo de cpu es muy limitado. Seguramente los del Overdrive 2 cambiarán más colores, pero aún no han dado esa info.

Con todo esto, elevar el número de colores de un tile es bastante complicado y hay que exprimir bien cada ciclo del 68k. Creo recordar haber visto una demo con un tile de 64 colores, pero no la encuentro ahora mismo.

A lo mejor por HDMA si se podría hacer algo así de forma mas automática, sin involucrar tanto a la cpu. Tal vez es de ahí de donde vienen las voces sobre la posibilidad de usar un plano con casi 500 tonos de color.

Cual es la diferencia entre color y tono?

Manveru Ainu escribió:@Señor Ventura bueno no existe límite de colores por tile. El único límite teórico es que un tile son 8x8 píxeles = 64 píxels => 64 colores.

Para hacer eso tienes que cambiar los colores de las paletas con el raster y cambiar la paleta asignada al tile, todo perfectamente sincronizado en cada uno de los 8 hints que recorren el tile, lo cual no es tan fácil. El número de colores que puedes cambiar por scanline es limitado y normalmente no se recomienda cambiar más de 1 o 2 porque el tiempo de cpu es muy limitado. Seguramente los del Overdrive 2 cambiarán más colores, pero aún no han dado esa info.

Con todo esto, elevar el número de colores de un tile es bastante complicado y hay que exprimir bien cada ciclo del 68k. Creo recordar haber visto una demo con un tile de 64 colores, pero no la encuentro ahora mismo.

Bueno, hacr un raster por linea es posible, poco util imagino, pero en ese caso, un tile podria tener 64 colores tecnicamente

La otra seria directamente cambiar los pixeles en la vram y chau, laborioso, pero podria resultar en una demo...

No se, algo asi en bex

theelf escribió:Cual es la diferencia entre color y tono?

Que con una paleta de 15 colores, no dejas de colorear 64 pixels (a menos que utilices el transparente, pero ya se enteinde).

Y lo diferencio porque mi comentario iba por el lado de no emplear trucos.

theelf escribió:Bueno, hacr un raster por linea es posible, poco util imagino, pero en ese caso, un tile podria tener 64 colores tecnicamente

La otra seria directamente cambiar los pixeles en la vram y chau, laborioso, pero podria resultar en una demo...

¿Veo un problema en hacer eso con sprites?, o solo me lo parece a mi...

theelf escribió:Bueno, hacr un raster por linea es posible, poco util imagino, pero en ese caso, un tile podria tener 64 colores tecnicamente

La otra seria directamente cambiar los pixeles en la vram y chau, laborioso, pero podria resultar en una demo...

No se, algo asi en bex

   loadtiles tile,1,1      
   drawtile 1,0,0         
   
   palette rgb(7,0,0),0,2   
        palette rgb(0,7,0),0,3      
      
      
   vdpramwrite 32,&h2111      
   vdpramwrite 32,&h3112
   
   
tile:
   datalong $11111111
   datalong $11111111
   datalong $11111111
   datalong $11111111
   datalong $11111111
   datalong $11111111
   datalong $11111111
   datalong $11111111

El raster por línea es útil para algunas cosas y para los colores también. El problema es que el tiempo por scanline es muy limitado y no se pueden cambiar muchos colores, entre otras cosas porque el VDP buguea (hay solución a eso pero ni idea). En cualquier caso eso ni en C ni en Basic, sino en Asm.

@Señor Ventura Con sprites es lo mismo. Un tile individual es un tile, da igual para lo que se use luego. La única diferencia es el órden en que lee los tiles un sprite y que todos los tiles de un sprite comparten paleta, pero para tiles sueltos da igual.

Señor Ventura escribió:Que con una paleta de 15 colores, no dejas de colorear 64 pixels (a menos que utilices el transparente, pero ya se enteinde).

Con una paleta de 15 colores, puedes meter 64 colores en un tile, sin problema, y no mas, xq nos faltan pixeles
El transparente, lo asignamos al fondo



@Manveru Ainu

sobre la funcion, vdpramwriten de bex, tengo el codigo asm x ahi, y esta bien escrita, asi q no deveria haber problema en hacerlo en bex. Al menos eso concreto

Hace tiempo atras, postie una demo con raster linea a linea, ni idea, no la encuentro ya. Esos hilos se pierden rapido

theelf escribió:Con una paleta de 15 colores, puedes meter 64 colores en un tile, sin problema, y no mas, xq nos faltan pixeles
El transparente, lo asignamos al fondo

Exacto, es lo que estaba diciendo. Colores, no tonos.

@Señor Ventura
Y cual es la diferencia entre color y tono?

theelf escribió:@Manveru Ainu

sobre la funcion, vdpramwriten de bex, tengo el codigo asm x ahi, y esta bien escrita, asi q no deveria haber problema en hacerlo en bex. Al menos eso concreto

Hace tiempo atras, postie una demo con raster linea a linea, ni idea, no la encuentro ya. Esos hilos se pierden rapido

Es lo que hay que hacer normalmente. Yo suelo mirar qué me genera el compilador al sacar el asm, porque en cosas críticas es mejor hacerlo a mano porque suele hacer cosas raras. Y en el hint hada ciclo cuenta porque tienes poquísimos.

El problema de eso es que sólo se puede probar en consolas porque ni el Exodus emula bien eso. El Blast'em está a saco haciendo compatible la demo Overdrive 2, a ver si me sirve para probar cosas de manera fiable

Típico ejemplo de raster cada línea es el efecto axelay. Se puede hacer cada 2, 4 u 8 líneas, pero por línea mola más jeje, aunque solo me gusta para efecto cascadas tipo jurassic park y creo que vectorman también.

@Manveru Ainu

En general siempre pruebo en kega, pero aun tengo conectada la megadrive al puerto serie del PC, asi q si el codigo es pequenio, lo pruebo automaticamente con el mismo bex, tiene la opcion, es util

Lo bueno del bex es q podes escribir codigo asm directo, asi q me es comodo como IDE incluso aunq no use basic jeje

No encuentro esa demo, una pena

Aunque se han visto maravillas en sistemas clásicos y se han aprovechado bastante bien, mi voto ha sido para el sí, me gustaría ver algo que aproveche (aunque sea un poquito ) al máximo las plataformas y además a poder ser que sean buenos productos y que diviertan como comenta algún compi atrás. Soñar es gratis .

theelf escribió:@Manveru Ainu

En general siempre pruebo en kega, pero aun tengo conectada la megadrive al puerto serie del PC, asi q si el codigo es pequenio, lo pruebo automaticamente con el mismo bex, tiene la opcion, es util

Lo bueno del bex es q podes escribir codigo asm directo, asi q me es comodo como IDE incluso aunq no use basic jeje

No encuentro esa demo, una pena

Es lo suyo, tener un everdrive de esos y probar en 0, pero cuestan un ojo de la cara xD. Si no, para rollos de rasters e hints y tal, el Exodus es el único que medio emula algo, los demás nada...

Sí, el gcc también permite mezclar C y Asm, embebido en el código C o compilando directamente archivos en asm para exportarlos a las sources en C.

Tres planos
https://youtu.be/5bbJLg0S2CI?t=29

La gran verdad es que Paprium tiene todo para ser el nuevo benchmark técnico cuando se trata de consolas de 16 bits.

Siento que los Nintenderos tienen grandes dificultades en aceptar, que el viejo Mega Drive es capaz de cosas que su plataforma de corazón no puede realizar.

La gente de WM tendrá que ser bastante creativos para mostrar algo realmente impactante en Proyect N, además en una plataforma que tiene medallones como Chrono Trigger y FFVI .

Señor Ventura escribió:Tres planos
https://youtu.be/5bbJLg0S2CI?t=29

jejeje eso tiene truco visual, y ya lo analizamos en el hilo de curiosidades de la mega creo. A 3 planos me refiero a esto https://youtu.be/gWVmPtr9O0g?t=1m28s

Manveru Ainu escribió:

Señor Ventura escribió:Tres planos
https://youtu.be/5bbJLg0S2CI?t=29

jejeje eso tiene truco visual, y ya lo analizamos en el hilo de curiosidades de la mega creo. A 3 planos me refiero a esto https://youtu.be/gWVmPtr9O0g?t=1m28s

Y tanto, las estalactitcas del primer plano deben ser sprites, porque si no es imposible que con solo dos planos ciertos fragmentos puedan ser superpuestos por otros (que como digo, en teoría no podrían).

Es así, ¿no?, tiene esa pinta.


Achievement: Following the thread even in your own thread!.

Señor Ventura escribió:Y tanto, las estalactitcas del primer plano deben ser sprites, porque si no es imposible que con solo dos planos ciertos fragmentos puedan ser superpuestos por otros (que como digo, en teoría no podrían).

Es así, ¿no?, tiene esa pinta.


Achievement: Following the thread even in your own thread!.

Hay 3 niveles de estalactitas: las marrones en primer plano (plano A), las difusas verdes al fondo del todo (plano B), y las verdes más nítidas que están entre ambas (plano B excepto la franja que está superpuesta a la de las estalactitas difusas del fondo, que son sprites).

Los juegos tienen trucos visuales para simular planos extra como el orden de superposición, animar tiles o usar propsprites para simular planos, pero sobre la secuencia del Overdrive 2 que te puse antes es algún truco de hardware que ahora mismo no acabo de ver