Super nes sufre bastante al mostrar varios elementos

Señor Ventura escribió:Entendido... entonces, si quieres añadir "un conjunto de tiles" para obtener un plano por software, no sale a cuenta porque este se desplazaría de 8 pixels en 8 pixels, y no hay otra forma de hacerlo por las buenas.

Sí, eso es, aunque hay que tener en cuenta lo que también comenta ThElf en el caso que quieras hace el scroll de uns parte de un plano por software: si ninguna tile del gráfico que quieremos mover independientemente tiene transparencia, se puede hacer más fácil.
Ejemplo chorra: una nube cuadrada que todos sus bordes se ciñen a los bordes de tiles 16x16 y de fondo tienen unas montañas. Si todo pertenece a un mismo BG no puedes mover independientemente por hardware la nube por delante de las montañas, y tendrías que hacerlo por software. ¿Cómo hacerlo? Pues teniendo en ROM almacenada 4 versiones de esa nube cuadrada desplazada 2 píxeles en cada posición dibujando en esos dos píxeles desplazados la parte de la montaña que se destapa por el movimiento de la nube.
Como ves es algo costoso de hacer.

Señor Ventura escribió:Obligaría a idear una rutina que encargue a la cpu la tarea de desplazar los tiles de pixel a pixel, pero intuyo que sería bastante costoso, mas que nada porque el código debería empezar por ahí cada vez que comienza un frame, y eso podría ser conflictivo en los momentos en que un programa demande rutinas con total prioridad, pudiendo causar ralentizaciones, etc... ¿no?.

Sí, ésa es la otra alternativa a tener en ROM ya dibujadas las tiles con ese desplazamiento.
Lo cierto es que acabo de caer en un modo de la SNES que se llama Offset por Tile que no sé si se podría usar para hacer ese efecto que dices, ya que no lo he usado nunca ni he visto usarlo para hacer scroll. Lo he visto para desplazar la ventana de diálogo de un juego de RPG (no recuerdo si el Chrono o el FF6) de modo que la ventana de diálogo la tienes en VRAM en una posición fija y el tilemap es fijo también, por lo que debería de salir siempre en la misma posición de la pantalla, pero pulsando el botón X la ventana cambia de posición en la pantalla usando el modo Offset per Tile.

Diskover escribió:

Gammenon escribió:
El truco del Battletoads es mover bloques de píxeles a diferentes velocidades. El caso más extremo de esta técnica es el suelo con perspectiva de SF2 y similares.

Ya, eso es lo que he dicho.

Es el,ejemplo más primitivo de scroll paralax.

Luego, si se mezcla con diferentes background de profundidad se consiguen cosas como los gif de ejemplo de SNES

Ummm, puede ser, pero yo veo una laguna en eso que decís: estas consolas antiguas no mueven píxeles, mueven tiles. Eso quiere decir que cada vez que desplaces una tile, el movimiento es brusco de 8 píxeles a la vez (si la tile es 8x8).
No sé si me explico: el scroll implementado por hardware implica mover una cámara con 1 píxel de precisión por una rejilla de tiles de 8x8; cuando te has desplazado 8 píxeles, ya has llegado al límite de una tile que está en el borde de la pantalla y antes de desplazar el siguiente píxel, te da tiempo a actualizar la siguiente tile 8x8 a mostrar. Así el efecto es suave.
Pero si tú quieres mover una tile 1 píxel, no puedes hacerlo, porque o cae en la posición de la reijlla -8 o en la posición +8.
No sé si alguien sabe exactamente cómo se hace esto, porque yo no caigo ahora mismo...

magno escribió:Ummm, puede ser, pero yo veo una laguna en eso que decís: estas consolas antiguas no mueven píxeles, mueven tiles. Eso quiere decir que cada vez que desplaces una tile, el movimiento es brusco de 8 píxeles a la vez (si la tile es 8x8).
No sé si me explico: el scroll implementado por hardware implica mover una cámara con 1 píxel de precisión por una rejilla de tiles de 8x8; cuando te has desplazado 8 píxeles, ya has llegado al límite de una tile que está en el borde de la pantalla y antes de desplazar el siguiente píxel, te da tiempo a actualizar la siguiente tile 8x8 a mostrar. Así el efecto es suave.
Pero si tú quieres mover una tile 1 píxel, no puedes hacerlo, porque o cae en la posición de la reijlla -8 o en la posición +8.
No sé si alguien sabe exactamente cómo se hace esto, porque yo no caigo ahora mismo...

Se puede hacer perfectamente mediante software. En NES no, pero en SNES o Mega Drive si me creo que se pueda hacer por pixel y no por tile con algún registro de memoria que permita ese acceso.

En NES está Battletoad VS. Double Dragon, en la fase 2 el efecto del suelo es parecido, pero este si, lo que hace es mover los tiles a diferente velocidad.

https://youtu.be/bukusPiWTmU?t=7m17s

En la nes, recuerdo que pasaba en el Faxanadu, en una pantalla, por lo demás no suele pasar muchas veces, de aquella los juegos estaban bien optimizados, no como ahora que nos venden betas en desarrollo.

Leugrim escribió:En la nes, recuerdo que pasaba en el Faxanadu, en una pantalla, por lo demás no suele pasar muchas veces, de aquella los juegos estaban bien optimizados, no como ahora que nos venden betas en desarrollo.

Vaya, en NES si que solía pasar y bastante: ralentizaciones y parpadeos eran muy comunes en muchos juegos.

Como ejemplo, la horrible conversión de Parodius.

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

Y es que, si me pongo a pensar... Castlevania 2, Megaman 3 (batalla final contra Dr. Wily), Blaster Master, Super Spy Hunter (los juegos de Sunsoft ponian la NES casi siempre al límite), Probotector, Contra Force, etc...

Diskover escribió:Se puede hacer perfectamente mediante software. En NES no, pero en SNES o Mega Drive si me creo que se pueda hacer por pixel y no por tile con algún registro de memoria que permita ese acceso.

Es que si se hace con algún registro de la SNEs o Megadrive, entonces es por hardware, no por software. Y en la SNES al menos es seguro 100% que no hay ningún registro que permita modificar un pixel solo, se hace todo por tiles. Es una de las cosas que pone justo al principio del libro del programador de SNES (que ya linké aquí en el foro hace tiempo): es un sistema orientado a caracter.
De hecho, las grandes ventajas que aportaron tanto el Super FX como el SA-1 (especialmente éste último) fue la posibilidad de tratar la pantalla como un bitmap y modificar píxeles sueltos.

Pero mi duda está en cómo hacerlo por software, cómo desplazar píxel a pixel la pantalla; la única forma que se me ocurre es como decía @Señor Ventura, tener las tiles en RAM, desplazarlas con un algoritmo y enviarlas a VRAM.
Esto es factible pero consume bastante tiempo de procesado.

que hubiese sido de SNES si mejor hubiese optado por usar un cpu motorola 68000

¿De verdad nadie sabe o se le ocurre cómo se puede hacer el scroll por software? Muchos comentásteis que sabíais que se hacía así en algunos juegos... ¿no tenéis ningún código ensamblador o pseudo-código para saber cómo está implementado?

magno escribió:¿De verdad nadie sabe o se le ocurre cómo se puede hacer el scroll por software? Muchos comentásteis que sabíais que se hacía así en algunos juegos... ¿no tenéis ningún código ensamblador o pseudo-código para saber cómo está implementado?

Me pillas que me voy al gimnasio ya mismo.

El parodius usa tiles por software para hacer el laser (como puedes ver, no hay ni rastro de semejante cosa en la table OAM, y ningún plano hace cosas raras para usar los suyos).


¿Tu pregunta es de que forma decirle a la cpu que coja ciertas tiles de la ROM, y sean mostradas en pantalla?, o a como implementar en forma de código una solución que ya sepas que puede funcionar.
Así a bote pronto, lo que se me ocurriría a mi es que fuese una especie de post procesado, una vez ya conformado el buffer, pero no se si funcionaría.


Creo que he dicho una tontería, si esperas al siguiente v-blank te cargas el invento. Voy a pensar en ello, a ver que se me ocurre.

magno escribió:¿De verdad nadie sabe o se le ocurre cómo se puede hacer el scroll por software? Muchos comentásteis que sabíais que se hacía así en algunos juegos... ¿no tenéis ningún código ensamblador o pseudo-código para saber cómo está implementado?

A que te refieres? a un falso segundo plano como el del Batman Returns de Nes? O a un scroll real por software como el del Golden Axe de master?

Si es el primer caso, simplemente tienes una parte del fondo formada por tiles con una textura repetitiva. Dichos tiles los vas recargando cada frame por versiones con un pixel desplazado. En el caso del Batman Returns creo recordar que son 4 tiles diferentes que se van recargando con las diferentes versiones (8 en total, tantas como pixeles de ancho tiene el tile)

En el caso del Golden Axe de master, simplemente parece que se hace scroll al tile, o sea el scroll se mueve 8px cada vez que avanzas (y necesitas regenerar todo el tilemap de lo que se muestra en pantalla).

Que quede constancia que en la pagina 8 de este hilo, postie un ejemplo con scroll por software

theelf escribió:Que quede constancia que en la pagina 8 de este hilo, postie un ejemplo con scroll por software

¿Te refieres a la pequeña demo que hiciste? Es que para mi el hilo tiene 3 páginas, no 8, ya que yo tengo configurado el foro para que me muestre el máximo de posts por página. Si es el BIN que colgaste, no tengo emulador de Megadrive y no pude mirarlo, pero además yo entendí que esa demo tenía 1 plano de scroll por hardware, no por software.

kusfo79 escribió:A que te refieres? a un falso segundo plano como el del Batman Returns de Nes? O a un scroll real por software como el del Golden Axe de master?

Si es el primer caso, simplemente tienes una parte del fondo formada por tiles con una textura repetitiva. Dichos tiles los vas recargando cada frame por versiones con un pixel desplazado. En el caso del Batman Returns creo recordar que son 4 tiles diferentes que se van recargando con las diferentes versiones (8 en total, tantas como pixeles de ancho tiene el tile)

En el caso del Golden Axe de master, simplemente parece que se hace scroll al tile, o sea el scroll se mueve 8px cada vez que avanzas (y necesitas regenerar todo el tilemap de lo que se muestra en pantalla).

Pues me refiero a las dos cosas Por lo que dices, me confirmas que el scroll por software se implementa haciendo un desplazamiento de 1 píxel en cada frame a cada tile 8x8 para conseguir el efecto de scroll suave. Ésa era la forma de implementarlo que me imaginaba como única posible, pero me parece una carga brutal para el micro tener que desplazar 8 veces por tile (es decir, un LSR o ASL por cada línea de una tile 8x8) las 32x32 tiles (1024 tiles) que forman la pantalla de una SNES.
El caso del Golden Axe de Master que comentas me parece increíble, ya que mover la pantalla 8 píxeles cada vez que avanzas tiene que dar sensación de brusquedad en el movimiento, ¿no?

Ralentizadas parece mentira, la gente descubriendo la sopa de ajo 25 años despues.

El.twin bee de super como ejemplo? Perdon? El de pcengine se lo folla de manera total, en cambio nadie habla del.aleste, el juego mejor programado de super, curioso al menos

Y por soft se puede hacer todo si tiene una maquina equilibrada, y la super con su supermierda de cpu no vale para eso, por cierto que aun no se tiene claro si es mas 8 bits que 16, pero da igual es un lastre y una autentica porqueria que lastro a la consola en el 98% de sus juegos.

Y lo pal funciona un 20% mas lento, por eso relentiza menos, algunas vacas sagradas de super con su velocidad original dan autentica pena, el dracula verlo ralentizarse con dos miseros esqueletos en pantalla y sus graficos guarros no tiene precio.

@magno

Es esa
Los ladrillos son scroll por software, ya que por hardware solo hay 1 plano


Si ves la demo en un emulador, podras notar que el scroll de los ladrillos es cada 1 tile, mientras lo demas que es por hardware es cada 1 pixel


Si queres hacer scroll por software pixel a pixel, tenes que tirar o de trucos, o si no queres usar trucos,un metodo podria ser leer la vram, y actualizarla cada frame

Por ejemplo, leemos una linea vertical



Modificamos esos datos, y volvemos a escribirlos




que se yo, por decir algo... escribi lo primero q me vino a la cabeza

magno escribió:

kusfo79 escribió:A que te refieres? a un falso segundo plano como el del Batman Returns de Nes? O a un scroll real por software como el del Golden Axe de master?

Si es el primer caso, simplemente tienes una parte del fondo formada por tiles con una textura repetitiva. Dichos tiles los vas recargando cada frame por versiones con un pixel desplazado. En el caso del Batman Returns creo recordar que son 4 tiles diferentes que se van recargando con las diferentes versiones (8 en total, tantas como pixeles de ancho tiene el tile)

En el caso del Golden Axe de master, simplemente parece que se hace scroll al tile, o sea el scroll se mueve 8px cada vez que avanzas (y necesitas regenerar todo el tilemap de lo que se muestra en pantalla).

Pues me refiero a las dos cosas Por lo que dices, me confirmas que el scroll por software se implementa haciendo un desplazamiento de 1 píxel en cada frame a cada tile 8x8 para conseguir el efecto de scroll suave. Ésa era la forma de implementarlo que me imaginaba como única posible, pero me parece una carga brutal para el micro tener que desplazar 8 veces por tile (es decir, un LSR o ASL por cada línea de una tile 8x8) las 32x32 tiles (1024 tiles) que forman la pantalla de una SNES.
El caso del Golden Axe de Master que comentas me parece increíble, ya que mover la pantalla 8 píxeles cada vez que avanzas tiene que dar sensación de brusquedad en el movimiento, ¿no?

No, a ver, lo de hacer desplazamientos de bits de todos los tiles no funcionaria (ademas que no queremos hacer eso, querríamos desplazar el contenido de un tile a otro, no solo 8 pixeles). El truco que me refiero es tener esos 4 tiles del Shadow of the Beast guardados en la rom en sus 8 variantes. Es mas, diria que en realidad, esos 4 tiles diferentes son diversos estado de "desplazamiento" de los pixeles, así que realmente lo que tienes son 4 huecos en la VRAM, en los que vas cargando las 8 variantes de ese tile en el que se desplazan los bits.

Y si, en el caso del Golden Axe o del Altered Beast, hay scroll brusco como pocos

kusfo79 escribió:Y si, en el caso del Golden Axe o del Altered Beast, hay scroll brusco como pocos

¿Alguna idea de por qué se hicieron así? No lo entiendo, la Master hace scroll por hardware.

Otro hilo desprestigiando a la snes. Illo de verdad que esto es para hacerselo mirar eh?
Aún hay gente que cree que va a reescribir la historia .

binario22 escribió:Otro hilo desprestigiando a la snes. Illo de verdad que esto es para hacerselo mirar eh?
Aún hay gente que cree que va a reescribir la historia .

Tenia sus defectos igual que los tenia la mega. Fue una de las mejores consolas de la historia igual que su compañera de guerras, pero no el Santo Grial flotando en los cielos.

Xaradius escribió:

binario22 escribió:Otro hilo desprestigiando a la snes. Illo de verdad que esto es para hacerselo mirar eh?
Aún hay gente que cree que va a reescribir la historia .

Tenia sus defectos igual que los tenia la mega. Fue una de las mejores consolas de la historia igual que su compañera de guerras, pero no el Santo Grial flotando en los cielos.

Pero aquí lo que parece es que la queréis hundir en el fango y eso amigos es querer reescribir la historia.

kusfo79 escribió:No, a ver, lo de hacer desplazamientos de bits de todos los tiles no funcionaria (ademas que no queremos hacer eso, querríamos desplazar el contenido de un tile a otro, no solo 8 pixeles). El truco que me refiero es tener esos 4 tiles del Shadow of the Beast guardados en la rom en sus 8 variantes. Es mas, diria que en realidad, esos 4 tiles diferentes son diversos estado de "desplazamiento" de los pixeles, así que realmente lo que tienes son 4 huecos en la VRAM, en los que vas cargando las 8 variantes de ese tile en el que se desplazan los bits.

Y si, en el caso del Golden Axe o del Altered Beast, hay scroll brusco como pocos

Eso es lo que había entendido.

Pero, ¿como se desplaza al pixel entonces el rayo del parodius da!?, porque hay un desplazamiento, no sustitución de tiles.

AxelStone escribió:

kusfo79 escribió:Y si, en el caso del Golden Axe o del Altered Beast, hay scroll brusco como pocos

¿Alguna idea de por qué se hicieron así? No lo entiendo, la Master hace scroll por hardware.

Yo solo conocía que hubieran hecho esto en el Popolous, ya que necesitaban "dibujar" el mapa en medio de los iconos, en una perspectiva isométrica. En el Mortal Kombat 2 un luchador se dibuja con sprites y el otro en el fondo, para saltarse las limitaciones de sprite por linea...entiendo que en Golden Axe y Altered Beast es también para saltarse esa limitación, pero no me parece que tengan tampoco tantos sprites...

Señor Ventura escribió:

kusfo79 escribió:No, a ver, lo de hacer desplazamientos de bits de todos los tiles no funcionaria (ademas que no queremos hacer eso, querríamos desplazar el contenido de un tile a otro, no solo 8 pixeles). El truco que me refiero es tener esos 4 tiles del Shadow of the Beast guardados en la rom en sus 8 variantes. Es mas, diria que en realidad, esos 4 tiles diferentes son diversos estado de "desplazamiento" de los pixeles, así que realmente lo que tienes son 4 huecos en la VRAM, en los que vas cargando las 8 variantes de ese tile en el que se desplazan los bits.

Y si, en el caso del Golden Axe o del Altered Beast, hay scroll brusco como pocos

Eso es lo que había entendido.

Pero, ¿como se desplaza al pixel entonces el rayo del parodius da!?, porque hay un desplazamiento, no sustitución de tiles.

Siendo un rayo, supongo que simplemente se aseguran que todos los tiles son únicos en esa parte del fondo, y dibujan por software una linea en los tiles involucrados

kusfo79 escribió:Siendo un rayo, supongo que simplemente se aseguran que todos los tiles son únicos en esa parte del fondo, y dibujan por software una linea en los tiles involucrados

Esa es la clave, pero es que los tiles se desplazan pixel a pixel, no "interiormente".

kusfo79 escribió:Yo solo conocía que hubieran hecho esto en el Popolous, ya que necesitaban "dibujar" el mapa en medio de los iconos, en una perspectiva isométrica. En el Mortal Kombat 2 un luchador se dibuja con sprites y el otro en el fondo, para saltarse las limitaciones de sprite por linea...entiendo que en Golden Axe y Altered Beast es también para saltarse esa limitación, pero no me parece que tengan tampoco tantos sprites...

En Populous tiene sentido justamente por eso, no puedes hacer scroll de pantalla ya que solo mueves una parte, pero en Golden Axe tiene pinta de decisión incorrecta. Vale que usando sprites te quedan más pequeños y simples, pero te sale un Streets of Rage por ejemplo que es mucho más jugable.

Sobre tiles no creas, en Master System a nada que querían mostrar bloques grandes tiraban de ellos: Altered Beast, Golden Axe, Mortal Kombat, After Burner, Street Fighter 2, ...

theelf escribió:Si ves la demo en un emulador, podras notar que el scroll de los ladrillos es cada 1 tile, mientras lo demas que es por hardware es cada 1 pixel

Sí, eso tiene sentido.
Lo que propones de leer la VRAM, al menos en la SNES es un poco lento aunque se puede hacer por DMA. El problema es que aún así necesitas un espacio de RAM reservado para todas esas tiles y poder desplazarlas pixel a pixel.

kusfo79 escribió:No, a ver, lo de hacer desplazamientos de bits de todos los tiles no funcionaria (ademas que no queremos hacer eso, querríamos desplazar el contenido de un tile a otro, no solo 8 pixeles).

Sí claro, me refería a eso, lo de pasar un pixel de un tile a otro, por eso puse la instrucción ROL/ROR como ejemplo porque usa el CARRY para pasar ese pixel al siguiente byte (es decir, siguiente tile).

kusfo79 escribió:El truco que me refiero es tener esos 4 tiles del Shadow of the Beast guardados en la rom en sus 8 variantes. Es mas, diria que en realidad, esos 4 tiles diferentes son diversos estado de "desplazamiento" de los pixeles, así que realmente lo que tienes son 4 huecos en la VRAM, en los que vas cargando las 8 variantes de ese tile en el que se desplazan los bits.

Ésa era la otra opción de la que hablé más arriba acerca de cómo se puede hacer un scroll por software, en relación a lo que proponía SeñorVentura de la bola ésa del Super Aleste.
Sin embargo, para estos juegos donde el espacio en ROM es tan limitado, poner 8 versiones del mismo fondo en algún lugar de la ROM (tiles + tilemap) es comerse demasiado espacio útil, por lo que supongo que esto funcionará si el scroll solo implica unos cuantos tiles de una parte pequeña del escenario.

Resumiendo entonces, el scroll por software realmente se hace:
* A lo burro moviendo tiles completas y por tanto, sin sensación de "suavidad"
* Suavemente teniendo en ROM cada una de las copias de esas tiles desplazadas la cantidad de píxeles correcta

La opción de desplazar por software (haciendo ROL o ROR) las tiles para mí queda descartada a menos de que hay un caso muy concreto donde se muevan muy pocas tiles. En el RS3, cuando reprogramé la parte del menú programé una rutina de fuente de ancho variable con un par de bucles anidados que desplazaban unos cuántos píxeles nada más cada letra y el resultado era insoportable, así que no quiero pensar lo que puede suponer para la CPU desplazar todas las tiles de un fondo.

La bola del super aleste nos ha dejado con el culo torcido a todos.

Si no es rotación, se me ocurre que debería poder salirse de dudas ripeando sprites de la rom, ¿no?... es mas fácil que intentar echar un vistazo al código (extraerlo, y revisarlo enterito).

Señor Ventura escribió:Si no es rotación, se me ocurre que debería poder salirse de dudas ripeando sprites de la rom, ¿no?... es mas fácil que intentar echar un vistazo al código (extraerlo, y revisarlo enterito).

Apoyo la moción, le regalo todos los Pokemon que he capturado de vacaciones en París al que nos saque de dudas

En serio, es que si es rotaciòn vìa PPu, va a ver que ir reordenando nuestras percepciones acerca de las posibilidades de SNES en dicho campo.

@Sexy MotherFucker

Yo solo dejo caer que sería la única animación del juego tic a tic, y con muchísima diferencia.

Por lo que he podido concluir, todo indica que se trata de una rotación.

Pero ojo, que podría ser a base de cpu (que también hay instrucciones que te sacan de ese apuro, aunque no sean tan eficientes).


Y en teoría, acceder a las instrucciones de multiplicación del ppu1 debería facilitar muchísimo no solo rotar sprites, sino también escalarlos. Esto se puede dar por hecho, pero lo que me resulta una incognita es cuántos se podrían manejar con esa rutina simultáneamente (de momento la bola del super aleste son 4 sprites de 32x32 pixels).

La bola son dos sprites de 32x32

theelf escribió:La bola son dos sprites de 32x32

4.

2 sprites de 32x32 es un rectángulo.

Señor Ventura escribió:

theelf escribió:La bola son dos sprites de 32x32

4.

2 sprites de 32x32 es un rectángulo.

¿No tienes ningún savestate del juego cerca de la bola? Mándamelo al correo y salimos de dudas.

magno escribió:¿No tienes ningún savestate del juego cerca de la bola? Mándamelo al correo y salimos de dudas.

Estoy en el trabajo ahora, luego cuando llegue a casa me echo una partidilla rápida antes de ponerme a estudiar, y te lo paso


Editado: De todos modos, si es para mirar el número de sprites de la bola, ya confirmo yo que son 4 de 32x32, porque lo miré con el debugger hace ya semanas (como minimo).

Señor Ventura escribió:Editado: De todos modos, si es para mirar el número de sprites de la bola, ya confirmo yo que son 4 de 32x32, porque lo miré con el debugger hace ya semanas (como minimo).

No, es para mirar cómo se hace la rotación del sprite completo, si copiando las tiles de cada posición de la rotación desde ROM, o haciendo la rotación con alguna rutina software.

Señor Ventura escribió:2 sprites de 32x32 es un rectángulo.

No necesariamente

2 sprites de 32x32 son solo dos sprites de 32x32



aca tenes como 2 sprites de 32x32 pueden formar un cuadrado de 64x64. Programado en bex, y pon tus propios sprites

magno escribió:No, es para mirar cómo se hace la rotación del sprite completo, si copiando las tiles de cada posición de la rotación desde ROM, o haciendo la rotación con alguna rutina software.

Hecho. He guardado la partida usando el snes9x, si tiene que ser desde otro emulador, házmelo saber.
download/file.php?id=91572

theelf escribió:No necesariamente

2 sprites de 32x32 son solo dos sprites de 32x32



aca tenes como 2 sprites de 32x32 pueden formar un cuadrado de 64x64. Programado en bex, y pon tus propios sprites

Entiendo, duplicas los dos sprites, y los colocas en otras coordenadas, y con su posición "flipeada".

Me suena que la megadrive tenía algún tipo de ventaja con esto frente a snes, pero ahora mismo no recuerdo...


Sobre la bola del super aleste, a lo que me refería, aunque realmente en rom solo existan 2 sprites, es que duplicándolas, al final la máquina está manejando 4, y en el caso de ser rotación, se aplica a 4.

@Señor Ventura

Pues, no estas entendiendo el ejemplo que puse. En mi codigo, solo 2 hay sprites definidos, bloque y bloque1


En caso de haber rotacion por software, para una bola de 64x64 simetrica, lo mas logico es definir dos conjuntos de tiles, 2 o 4 sprites depende como se decida programar, pero se aplicaria el proceso de rotacion a solo 2 sprites

Señor Ventura escribió:Hecho. He guardado la partida usando el snes9x, si tiene que ser desde otro emulador, házmelo saber.
download/file.php?id=91572

Me vale en formato SNES9x, preferiblemente 1.51, pero lo que has compartido tú está en ZST de ZSNES

magno escribió:

Señor Ventura escribió:Hecho. He guardado la partida usando el snes9x, si tiene que ser desde otro emulador, házmelo saber.
download/file.php?id=91572

Me vale en formato SNES9x, preferiblemente 1.51, pero lo que has compartido tú está en ZST de ZSNES

Imposibol (xD), juro por dios, y por los cigarrillos de chocolate que usé el snes9x

Mañana compruebo que esté todo bien, y te lo pongo por aquí.


P.D: Ya decía yo que se me olvidaba algo importante, ahora que veo el mensaje de theelf ^^

Malditos, en cuanto tengáis una certeza respecto a la PUTA BOLA exponedla por aquì de una santa vez!

@magno

Ahora si, aquí está la partida con snes9x v1.51, perdón por el lapsus (almacenan los saves en diferentes carpetas).

Señor Ventura escribió:@magno

Ahora si, aquí está la partida con snes9x v1.51, perdón por el lapsus (almacenan los saves en diferentes carpetas).

El savestate que has subido no me vale: carga en el 1.51 pero se cuelga nada más cargar la partida con la pantalla en la que se ve la nave, un par de disparos, unos cuantos misiles y parpadea el fondo. He probado con varias versiones de SNES9x y varias versiones de la ROM, pero en ninguna me funciona.

A ver si se resuelve el misterio de la bola

binario22 escribió:

Xaradius escribió:

binario22 escribió:Otro hilo desprestigiando a la snes. Illo de verdad que esto es para hacerselo mirar eh?
Aún hay gente que cree que va a reescribir la historia .

Tenia sus defectos igual que los tenia la mega. Fue una de las mejores consolas de la historia igual que su compañera de guerras, pero no el Santo Grial flotando en los cielos.

Pero aquí lo que parece es que la queréis hundir en el fango y eso amigos es querer reescribir la historia.

Es más, yo hasta ahora no he visto a nadie abriendo posts flamers del tipo "¿Qué motivos tendría un nintendero para comprarse una Mega Drive?" o "Mega Drive sin el velo de la nostalgia". De la Super, unos cuantos.

Que se le tiene inquina en este subforo al Cerebro de la Bestia es un hecho más que contrastado. Ya ni lo disimulan un poquito.

Eso lo llevo yo pensando desde hace algun tiempo y esta mas que comprobado que es cierto.
Ultimamente la megadrive es una neogeo y la snes caquita y tiene que ser que mi megadrive este estropeada o se le ha ido el chip gordo porque no se yo ...
algunos estan empeñados en hacer ver que la super esta tan bien considerada por amor al arte o no se ...
a mi a estas alturas no me tiene que demostrar nadie nada ,tenemos un catalogo brutal lleno de joyas y mil ejemplos de todo .
que un juego tenga ralentizaciones? quien este libre de pecado que tire la primera piedra ,hay juegos de megadrive que las tienen a montones y no se le ocurre a ningun supernintendero abrir un hilo por ello .
anda que si nos ponemos a brir hilos por cada juego de mega que no de el tipo vamos listos...
en fin que a ver si se resuelve el misterio de la bola

Si han chapao el otro hilo por lo mismo no veo correcto recuperar sus debates para traerlos aquí, que se está hablando de temas técnicos seriamente; pero bueno, vosotros veréis..

llevas razón gynion ,por mi parte dejo zanjado el tema ,solo queria expresar mi opinion de lo que se ve ultimamente por el foro.
edito:
cuando se resuelva el misterio de la bola ,por favor resolverme este
bola macross
¿como esta hecha esa rotacion? parece modo 7 pero el fondo me confunde .
gracias
edito 2 : llevas razón pero cansa un poco. pero en fin que le vamos a hacer

titorino escribió:llevas razón gynion ,por mi parte dejo zanjado el tema ,solo queria expresar mi opinion de lo que se ve ultimamente por el foro.

Joe, pues que te quiten lo jugao, que es lo que pienso yo ¿o lo que te digan va a influir en tu experiencia con Super Metroid?

También me cabreaba antes de que despotricaban contra FF7, pero la cierto es que la experiencia ahí queda.

Es un plano en modo 7, si.

gracias señor ventura ,me habia confundido el fondo con las estrellas moviendose
este juego es brutal ,os recomiendo que le echeis unos vicios ,tiene algunas cosillas muy interesantes y aprovecha muy bien las virtudes graficas de la maquina .

titorino escribió:gracias señor ventura ,me habia confundido el fondo con las estrellas moviendose
este juego es brutal ,os recomiendo que le echeis unos vicios ,tiene algunas cosillas muy interesantes y aprovecha muy bien las virtudes graficas de la maquina .

Acabo de ver un video y esta parte me parece preciosa

https://youtu.be/LticFKw1EqA?t=30m24s

muy chula con jupiter de fondo
y esta fase 7
el juego sorprende viniendo de una compañia no muy conocida y no muy prolifica en la consola

titorino escribió:gracias señor ventura ,me habia confundido el fondo con las estrellas moviendose
este juego es brutal

Podrían ser sprites perfectamente, a la snes le sobran slots en la tabla OAM.

De todos modos, en modo 7 la configuración es un plano de 256 colores, y otro de 16... la única condición es que el plano de 16 no se superponga al de 256.