[TRADUCCIÓN] Star Ocean de SNES en castellano

Llevo un buen tiempo volcando código para mejorar algunos aspectos del juego; de momento he podido arreglar un bug de la versión japonesa e inglesa y "medio solucionar" otro, el que hacía referencia @gadesx.

El que está arreglado ocurría porque las rutinas de colisiones entre objetos no tenían en cuenta que ambos objetos estuvieran en diferentes alturas en el escenario. La altura se obtiene de los bits de prioridad del sprite, por lo que haciendo la comprobación pertinente se pasa de esto:



a esto:




El otro bug tiene que ver con las colisiones a diferente nivel también, pero además interviene el orden de dibujado de los sprites; en la SNES, los sprites con más prioridad son los que están más arriba en el stack de capas visibles, pero no necesariamente son los que se dibujan. Esto debe de ser algú bug de la SNES, puesto que el sprite que siempre se dibuja primero es el sprite 0 de la tabla OAM, independientemente de su prioridad. Por tanto, pasamos de esto en la versión japonesa/inglesa:



a esto raro en la versión española:

Haces lo que quieres con la pobre consola. Qué abuso.

No he jugado al juego, pero me imagino que si hay niveles/pisos será porque puedes pasar por debajo de uno superior, ¿no? por ejemplo por la parte de la sombra en las dos primeras capturas.

EDIT: ¿No hay un parpadeo raro justo tras bajar las escaleras en la segunda captura? por otra parte, en ese mismo momento.. ¿es normal que el personaje pise el deposito circular ese de las lucecitas parpadeantes?

gynion escribió:
No he jugado al juego, pero me imagino que si hay niveles/pisos será porque puedes pasar por debajo de uno superior, ¿no? por ejemplo por la parte de la sombra en las dos primeras capturas.

Sí, así es. DE hecho, puedes estar debajo del puente verde, que es semitransparente, y el personaje se ve translúcido. También hay sombras en las que puedes "meterte" y el personaje se sombrea. Todo esto es muy parecido a cómo está hecho en Tales of Phantasia, y se basa en hacer BG3 semitransparente usando la suma de color por píxel.

gynion escribió:EDIT: ¿No hay un parpadeo raro justo tras bajar las escaleras en la segunda captura? por otra parte, en ese mismo momento.. ¿es normal que el personaje pise el deposito circular ese de las lucecitas parpadeantes?

No, el parpadeo es porque el personaje ha pasado justo por la sombra y sale de ella muy rápido, pero es culpa de los pocos frames por segundo que tienen los GIFs para que ocupen poco. Faltan unos frames en los que verías entrar al personaje en la zona de sombra, oscurecerse una parte y luego salir de ella y volver a aclarar.
Y sí, el personaje puede andar por encima de los depósitos, que son parte del suelo.

magno escribió:

gynion escribió:
No he jugado al juego, pero me imagino que si hay niveles/pisos será porque puedes pasar por debajo de uno superior, ¿no? por ejemplo por la parte de la sombra en las dos primeras capturas.

Sí, así es. DE hecho, puedes estar debajo del puente verde, que es semitransparente, y el personaje se ve translúcido. También hay sombras en las que puedes "meterte" y el personaje se sombrea. Todo esto es muy parecido a cómo está hecho en Tales of Phantasia, y se basa en hacer BG3 semitransparente usando la suma de color por píxel.

Ah, es verdad; se ve transparente el suelo; en eso no me había fijado (pensaba que simplemente desaparecía el personaje bajo el puente, y luego volvía a aparecer). Me molan esos detallitos.

Este era el cofre que decía que andando por el puente chocabas con él en la versión de dejap y supongo que en la japonesa igual.
Hacer esto a la inversa para algo concreto es muy complicado,
yo he cambiado cosas en juegos de snes como el lufia pero han sido a RAM,
en la rom tiene que ser un martirio.

Si tienes localizado la dirección del objeto
y puedes saberlo en ram me podrías decir el código y pasarme un save state
para usar en la versión de dejap por ejemplo para trastear.
Normalmente un evento como un cofre tienen valores y los codigos
cercanos son mas propiedades de ese evento.

(Trasteando esas cosas en el lufia por ejemplo pude hacer desaparecer
a los npcs de la cueva antigua )

Es curioso porque esto en el rpg maker (el 2003, que es el que más "imita" rpgs de snes)
que es lo unico que yo entiendo de estas cosas
sería algo así:
Cosas como los cofres son "eventos" con prioridades como capa/pasabilidad
y son independientes de los tiles que tienen sus prioridades aparte también de capa/pasabilidad.

Antes como chocabas, el cofre sería un evento con prioridad "como el personaje"
Ahora como se ve en el gif, el cofre sería como un evento con prioridad "sobre el personaje" pero
en una capa mas alta que interfiere con el plano del puente o algo así.
Eso mismo que pasa me ha pasado a mí cuando estaba haciendo el Lufia SDK en el maker
al tener dos cosas la misma prioridad.

No sé cuantos planos puede usar la snes o el juego concretamente a cuanto esta limitado,
aún así ahora por lo menos no chocas y es un bug menor que el de antes.



EDIT:
He intentado replicarlo en el maker, si el cofre es atravesable y esta en la misma prioridad que el personaje
pasa de forma parecida.


Y si la prioridad es mas alta...

gadesx escribió:Este era el cofre que decía que andando por el puente chocabas con él en la versión de dejap y supongo que en la japonesa igual.
Hacer esto a la inversa para algo concreto es muy complicado,
yo he cambiado cosas en juegos de snes como el lufia pero han sido a RAM,
en la rom tiene que ser un martirio.

Si tienes localizado la dirección del objeto
y puedes saberlo en ram me podrías decir el código y pasarme un save state
para usar en la versión de dejap por ejemplo para trastear.
Normalmente un evento como un cofre tienen valores y los codigos
cercanos son mas propiedades de ese evento.

(Trasteando esas cosas en el lufia por ejemplo pude hacer desaparecer
a los npcs de la cueva antigua )

Es curioso porque esto en el rpg maker (el 2003, que es el que más "imita" rpgs de snes)
que es lo unico que yo entiendo de estas cosas
sería algo así:
Cosas como los cofres son "eventos" con prioridades como capa/pasabilidad
y son independientes de los tiles que tienen sus prioridades aparte también de capa/pasabilidad.

Antes como chocabas, el cofre sería un evento con prioridad "como el personaje"
Ahora como se ve en el gif, el cofre sería como un evento con prioridad "sobre el personaje" pero
en una capa mas alta que interfiere con el plano del puente o algo así.
Eso mismo que pasa me ha pasado a mí cuando estaba haciendo el Lufia SDK en el maker
al tener dos cosas la misma prioridad.

No sé cuantos planos puede usar la snes o el juego concretamente a cuanto esta limitado,
aún así ahora por lo menos no chocas y es un bug menor que el de antes.



EDIT:
He intentado replicarlo en el maker, si el cofre es atravesable y esta en la misma prioridad que el personaje
pasa de forma parecida.

Es más o menos lo que estás comentando, en resumidas cuentas, funciona así:

1) Según la escena que se está dibujando, se descomprime un bloque de parámetros de 48 bytes que contienen punteros a gráficos, tilemaps, eventos, texto y configuración de modos de video
2) Al descomprimir los eventos, se ejecutan una serie de comandos que crean cada objeto de la escena; entre ellos, el cofre con el comando $0E (rutina $C21A07) y los parámetros vienen a continuación. Estos datos se almacenan en un array de 64 elementos de 64 bytes cada uno en $7E:2000 (el primer slot es para Ratix, los cofres suelen ir en $7E:2C00 y siguientes).
3) Una vez terminada de ejecutar la configuración de la escena, el bucle principal va leyendo los objetos en el array $7E:2000 y va creando los metadatos de los sprites correspondientes en $7E:67E1, que es una lista ligada de 64 elementos de 32 bytes cada uno, que contienen información de la paleta, la acción que está animándose, los frames en cada postura de la animación, el puntero a ROM con los datos de layout de sub-sprites, etc.... y el puntero al siguiente objeto que se crea.
4) Lo curioso es que a pesar de ser una lista ligada, al dibujar los sprites en pantalla (es decir, escribir en OAM) no se recorre desde el top al bottom, sino que hay un array en $7E:18E0 con punteros a cada uno de esos structs con metadatos que indica la prioridad. Es decir, el puntero en $7E:18E0 apunta a los metadatos del primer sprite que se dibuja (más prioritario en pantalla), el puntero en $7E:18E2 apunta a los metadatos del segundo sprite más prioritario, y así sucesivamente.
5) Mis indagaciones sobre la lista ligada es que lleva los metadatos de todos los sprites en movimiento (por ejemplo, personajes en un pueblo), pero se van ligando unos structs con otros según los que están en pantalla, de modo que a lo mejor en un momento están en pantalla los que ocupan las posiciones $7E:67E1 (elemento 0), $7E:6821 (elemento 2) y $7E:6881 (elemento 5) y la lista ligada refleja solo esos 3, pero el resto de personajes siguen en memoria pero "desligados".
6) Cuando Ratix se va moviendo por pantalla, el juego calcula en cada instante si hay un objeto colisionando, y en caso de que lo haya, determina si está por delante o detrás de Ratix para tapar la parte que corresponda de cada uno de ellos. La forma de hacerlo es cambiando los punteros en $7E:18E0, y eso es lo que pasa EXACTAMENTE en el caso que he mostrado: Ratix siempre está en la posición 0 de ese array, pero cuando sobrepasa la posición del cofre, el cofre pasa a la posición 0 y Ratix a la 1, por lo que el cofre tiene más prioridad y se dibuja tapando a Ratix.


Tengo 2 formas de solucionarlo:

1) Tengo lo datos en ROM del cofre, porque estos se crean con un comando del script de eventos que va comprimido LZ y que mi utilidad ya recomprime; entre todos esos, a parte de los dos bits de prioridad del sprite (considerando el sprite como los datos que residen en OAM), creo que hay un byte que determina la prioridad del sprite en la cola (en este caso, sprite se refiere al muñecote entero, formado por varios sprites de OAM), es decir, su posición en $7E:18E0 respecto al resto de objetos. Según este byte, cuando Ratix pasa por detrás de él, el objeto tapa a Ratix, y eso se hace cambiando la lista ligada de metadatos de los sprites ("muñecotes")

2) Los dos bits de prioridad del sprite (en OAM) los usa el juego para determinar la "altura" a la que está el objeto y comparando con los de Ratix sabría si colisionan o no. Esto ha funcionado en la solución del bug primero que he puesto y ha solucionado parcialmente este segundo caso, por lo que también debería de funcionar en el caso del orden de dibujado de los sprites

El problema de usar la primera solución es que cambiar la prioridad en la cola de ese objeto puede tener efectos raros a la hora de que Ratix se acerque, aunque lo bueno de esta solución es que el problema solo estaría localizado en este cofre, no en los demás del juego.
El problema de la segunda solución es que afecta a la rutina que determina la prioridad de dibujado de cada uno de los structs que forman la lista ligada de metadatos, y aquí no entran solo cofres, sino cualquier elemento animado del juego, lo cual puede producir efectos indeseados en vete tú a saber qué parte del juego. La otra cosa mala es que en la rutina donde tengo que actua no tengo los punteros a los objetos, sino a los metadatos de ese objeto, por lo que no tengo acceso a los bits de prioridad.
Lo bueno de la segunda solución es que está comprobada que para otros usos, funciona bien.

Yo creo que la forma más sencilla sería para no complicarte mucho,
localizar las coordenadas X e Y del objeto y cambiarlas.

Bueno realmente solo sería la coordenada Y de altura, no sé como trata esto
la snes internamente, quizás vaya por pixeles o a saber

Con cuadros me refiero a esto por si las dudas, los espacios para tiles y demás
que en el maker empiezan desde arriba a la izquierda son coordenadas x e y 0 en cada caso


Habría que subir el cofre 5 cuadros digamos para estar fuera del puente, aunque pasaría lo mismo
que con el bug del otro cofre que cogerlo sobre el puente, con 6 de distancia no
Al menos en el maker subir algo es restar a la coordenada Y
así que a la coordenada Y restandole 5 o 6

Pero este juego es "especialito" y usa como "semi-pasos" entre cuadros, que el personaje se puede mover
no a los cuadros de 16x16 sino a 8x8. No se si afectara a todo, creo que los tiles si tienen permisos de paso
usando esos 8x8 (en el mismo puente si te puedes mover hasta el borde si tendrán, si es hasta donde estan las
las rejillas de la imagen que he puesto son 16x16)

gadesx escribió:Yo creo que la forma más sencilla sería para no complicarte mucho,
localizar las coordenadas X e Y del objeto y cambiarlas.

Bueno realmente solo sería la coordenada Y de altura, no sé como trata esto
la snes internamente, quizás vaya por pixeles o a saber

Va por píxeles, sí, la resolución de los sprites de SNES es de 1 píxel y el cofre es un sprite; pero esa es la solución fácil, hombreeee No va mucho conmigo hacerlo fácil, aunque si llego a la desesperación, igual tiro por ahí.

gadesx escribió:Habría que subir el cofre 5 cuadros digamos para estar fuera del puente, aunque pasaría lo mismo
que con el bug del otro cofre que cogerlo sobre el puente, con 6 de distancia no
Al menos en el maker subir algo es restar a la coordenada Y
así que a la coordenada Y restandole 5 o 6

No, hombre, el otro bug está solucionado ya, es el primero que he puesto en mi post anterior.

gadesx escribió:Pero este juego es "especialito" y usa como "semi-pasos" entre cuadros, que el personaje se puede mover
no a los cuadros de 16x16 sino a 8x8. No se si afectara a todo, creo que los tiles si tienen permisos de paso
usando esos 8x8 (en el mismo puente si te puedes mover hasta el borde si tendrán, si es hasta donde estan las
las rejillas de la imagen que he puesto son 16x16)

Sí, el tilemap es 16x16 pero el tiletype es de 8x8, es decir, el mapa de acciones/colisiones se determina sobre tiles 16x16, pero el byte de tipo que va asociado a esa tile 16x16 tiene flags para controlar qué tile 8x8 de las 4 que la forman es atravesable.

Me referia a que si movieses el cofre (el de la ultima imagen) arriba quizás tambien pasaría lo del otro bug que ya has solucionado en el otro, que podías cogerlo estando sobre el puente, esta vez mirando arriba. Parece generalizado que en esa zona no separaron las acciones en cada altura y por eso pasa todo.

Tengo que encontrar la zona de desierto que te comenté que podías atravesar las paredes,
si quieres arreglar esos bugs ahí vas a tener hasta noche buena.

Creo que tengo una partida en la zona final, si puedo volver atrás te comento.
No descarto volver a poner ejemplos desde mi punto de vista que son como
desde un telescopio al revés.

wow... me he perdido un poco. Que crack

gadesx escribió:Me referia a que si movieses el cofre (el de la ultima imagen) arriba quizás tambien pasaría lo del otro bug que ya has solucionado en el otro, que podías cogerlo estando sobre el puente, esta vez mirando arriba. Parece generalizado que en esa zona no separaron las acciones en cada altura y por eso pasa todo.

Ah, ok, pero es que la solución del primer bug implica la solución para TODOS los casos que se den similares, es decir, no he solucionado el bug en sí mismo, sino que he añadido a la rutina de colisión de sprites además la comprobación de altura; por tanto en cualquier sitio que pudiera ocurrir esto, ya estaría solucionado.

gadesx escribió:Tengo que encontrar la zona de desierto que te comenté que podías atravesar las paredes,
si quieres arreglar esos bugs ahí vas a tener hasta noche buena.

Lo del desierto lo estuve buscando, porque supongo que será en la zona entre Tataroy y Parj, y no encontré lo que decías. Pero si la encuentras no será difícil cambiarlo ya que tengo todo el juego extraído: 30000 bloques de gráficos S-DD1, 1240 bloques LZ (entre ellos los eventos, texto y configuración de las 607 localizaciones diferentes del juego), rutinas de colisión, de scroll, etc...

Las configuraciones para cada escena son así:

Señor Ventura escribió:wow... me he perdido un poco. Que crack

madre mía, y sin pedir likes ni me gustas. Lo tuyo si que es para ponerte una estatua.

Es que magno está farmeando experiencia con la que podrá hacer un pedazo de juego algún día

Ostras como me había perdido este hilo, me subo al carro.

@magno Tengo que darte millones de gracias por la traducción del FFVI de snes

Aficionado...

Anoche estuve probando de madrugada volver atrás en el save que tenia en el snes9x de wii
y llegué al sitio de los tiles mal puestos, no es en el desierto, fallo de memoria mia,
es en la zona nevada, al oeste de sylvalant.
Tampoco fui a la busqueda de fallos, sino encontraría muchos mas porque no parece bien
testeado.

Tile inferior de bordeado de montaña que está puesto como sobre el personaje y con pasabilidad


Mas de lo mismo, tiles superiores que se pueden atravesar




Falta que encuentre la ciudad a la que le faltaba un plano de agua o algo así y me suena que se veia
negro, aunque por la forma de la ciudad esa parte solo se veia un poco desde un punto así que
era facil que pasase desapercibido.

EDITO;
Vale, la ciudad es justo la anterior, Van I II Castle Town
El plano de agua no está, pero están los tiles animados de bordeado de agua (layer 2 y 3 que añade el efecto de agua
en los bordeados)





En zonas anteriores con el tile de agua, si te fijas los bordeados son iguales pero hay agua azul, aqui es negro

Ya he terminado de arreglar el bug del cofre; he localizado la rutina que calcula el orden de prioridad de cada sprite en pantalla y en cada comprobación, también tengo en cuenta la altura a la que está el objeto respecto al personaje. Esto se hace para todos los objetos en $7E:2000, así que habrá que ver si tiene algún otro efecto colateral. Sería una putada que para solucionar un problema con un único cofre en todo el juego, fallara algo más.
También se ha solucionado con todo estos arreglos un tercer cofre que hay justo al empezar el laboratorio donde está Asmodeus, que estaba medio tapado debajo de un puente y podías abrirlo desde arriba.

gadesx escribió:Anoche estuve probando de madrugada volver atrás en el save que tenia en el snes9x de wii
y llegué al sitio de los tiles mal puestos, no es en el desierto, fallo de memoria mia,
es en la zona nevada, al oeste de sylvalant.
Tampoco fui a la busqueda de fallos, sino encontraría muchos mas porque no parece bien
testeado.

Tile inferior de bordeado de montaña que está puesto como sobre el personaje y con pasabilidad


Mas de lo mismo, tiles superiores que se pueden atravesar

Gracias, les echaré un vistazo porque nunca me había fijado en esos "problemillas".

gadesx escribió:Vale, la ciudad es justo la anterior, Van I II Castle Town
El plano de agua no está, pero están los tiles animados de bordeado de agua (layer 2 y 3 que añade el efecto de agua
en los bordeados)





En zonas anteriores con el tile de agua, si te fijas los bordeados son iguales pero hay agua azul, aqui es negro

El pueblo se llama "van i il" (lo pongo en un diálogo del juego para que quede claro ) y también me había fijado que el agua no era azul... lo que pasa es que siempre pensé que era porque las zonas de agua que se ven están en sombra, tanto la zona entre los dos edificios como el mini estanque donde está mirando la chica. Por eso pensé que la matemática de color daba como resultado en esa zona un color negro para el agua.
Lo miraré también a ver.

@magno

Esta gente... que genios, de verdad... llevo un rato rompiéndome el coco, y no consigo imaginar como puede salir algo así de una snes.

Se que no es precisamente del star ocean, pero, ¿hay algo similar a esto del chrono trigger en el?:
https://youtu.be/2Ja3TdujlDg?t=566

En el remake hay agua, supongo que querían hacer agua más oscura que no "desentone"
pero es que se ve negro

En el remake
https://youtu.be/RYWBlTXwLrE?t=2m12s

Señor Ventura escribió:Se que no es precisamente del star ocean, pero, ¿hay algo similar a esto del chrono trigger en el?:
https://youtu.be/2Ja3TdujlDg?t=566

No, realmente SO no se caracteriza por efectos realmente sorprendentes; a cambio los gráficos, su variedad y colorido son impresionantes. También resaltaría ese acabado tan cuidado en muchas cosas, como el objeto obtenido en los cofres que se va escalando de tamaño, las ventanas semitransparentes...
Ese efecto del Chrono Trigger se consigue modificando el registro mosaico por hardware con HDMA, de modo que en cada línea de pantalla se hace el mosaico en un tramo diferente para dar ese efecto de espiral y en cada frame se va girando dicha espiral. El resto de elementos son sprites que no se ven afectados por el mosaico de los BG.

gadesx escribió:En el remake hay agua, supongo que querían hacer agua más oscura que no "desentone"
pero es que se ve negro

En el remake
https://youtu.be/RYWBlTXwLrE?t=2m12s

Uf... se me ha ocurrido la idea de meter esos escenarios tan currados en un juego de SNES....

¿prerenderizados en un juego de snes? creo que solo se ha hecho en partes
divididos en tiles o sprites para cosas como los donkey kong country.

En psx eran como fondos con algunas capas para lo que estaba encima,
todo bajo un engine 3D que escala el tamaño de los personajes según las
perspectivas y con lineas pone las colisiones,
todo eso se puede ver como funciona por ejemplo con el programa makou
reactor para modificar el final fantasy 7.

En 2D es una locura, por debajo habria que hacer un zoom a los sprites en tiempo real
basado en tablas con valores que tengas para una perspectiva, en otra perspectiva habría que
cambiar todo. Al menos es lo que me he encontrado yo cuando he hecho prerenderizados
e intentado hacerlo en plan 2D.

gadesx escribió:¿prerenderizados en un juego de snes? creo que solo se ha hecho en partes
divididos en tiles o sprites para cosas como los donkey kong country.

En psx eran como fondos con algunas capas para lo que estaba encima,
todo bajo un engine 3D que escala el tamaño de los personajes según las
perspectivas y con lineas pone las colisiones,
todo eso se puede ver como funciona por ejemplo con el programa makou
reactor para modificar el final fantasy 7.

En 2D es una locura, por debajo habria que hacer un zoom a los sprites en tiempo real
basado en tablas con valores que tengas para una perspectiva, en otra perspectiva habría que
cambiar todo. Al menos es lo que me he encontrado yo cuando he hecho prerenderizados
e intentado hacerlo en plan 2D.

No hay que hacer tanto lío: fíjate que en el video del remake, los escenarios no rotan ni se escalan, y el personaje se escala solo en ciertos escenarios y en ciertos movimientos. Lo que proponía era hacer algo así:

Chiptune Rocker homebrew

Los escenarios van tal cual prerenderizados y sin escalados ni rotaciones (vendría a ser como un escenario 2D), las zonas de sombra serían igual que ahora, en BG3, y el personaje no se escalaría, aunque el StarOcean de SNES tiene una rutina de escalado por software para sprites que se podría usar.
Lo que pasa es que para hacer algo así habría que extraer los gráficos del remake para PSP y ahí ya me pierdo.

Que bestia xd Yo es que de hacer algo interesante con SO, lo que molaría
sería una versión tipo remake del Star Ocean 2 Blue Sphere de game boy color
que es el unico que sigue en japones y estaría bien verlo en plan o snes o como el 2/First Departure.
Pero fuera de lo que es mapeado con tiles, los prerenderizados requieren de saber
bastante de diseño y tener un pc en condiciones

En 2011-2012 si que me dio por hacer paridas y experimentar... hasta que se me jodió la tarjeta grafica.

magno escribió:Ese efecto del Chrono Trigger se consigue modificando el registro mosaico por hardware con HDMA, de modo que en cada línea de pantalla se hace el mosaico en un tramo diferente para dar ese efecto de espiral y en cada frame se va girando dicha espiral. El resto de elementos son sprites que no se ven afectados por el mosaico de los BG.

Ahí es a donde quería llegar, ¿girarlo no implica un doble plano?, ¿se podría hacer algo con el modo 7 extendido? (plano de 128 colores debajo, plano de 256 colores arriba rotando y haciendo uso del color math).

Poner un plano por debajo no entraría dentro de las limitaciones, aunque ahora mismo hablo solo de memoria (y no de la buena xD).

...es que no se me ocurre otra forma de rotarlo. Si es por hdma, mas por hardware imposible, y pienso en el modo 7 ext.


Vale, te lo voy a decir... es que llevo viendo desde que salió el f-zero de la game boy advance, un doble plano haciendo uso de las rotaciones, y se me ha ocurridoque tal vez podría hacerse algo parecido en snes a base de animar las tiles del plano inferior.

magno escribió:y el personaje no se escalaría, aunque el StarOcean de SNES tiene una rutina de escalado por software para sprites que se podría usar.

¿Has podido ver íntegra esa parte del código?, ¿es muy extensa?.

El efecto del escalado me ha parecido bastante legal (viendo otros como el del art of fighting 2, que se sirve del offset y la manipulación precalculada de los pixeles para simularlo), ¿cúantas tiles puede alterar a la vez?.

Señor Ventura escribió:Ahí es a donde quería llegar, ¿girarlo no implica un doble plano?

No estás girando un plano, estás creando el efecto óptico de que se está girando. Eso lo haces como he comentado: pixelas (es decir, usas el registro mosaico) las zonas del BG con diferentes intensidades para dar una sensación de círculo, ya que el registro mosaico permite "pixelar" la imagen con diferentes grados de intensidad. Luego en cada frame cambias la forma de la distorsión para que parezca una espiral. Pero el plano está quieto, sólo usas el HDMA para ir modificando cada línea de pantalla con diferentes pixelaciones.

Señor Ventura escribió:, ¿se podría hacer algo con el modo 7 extendido? (plano de 128 colores debajo, plano de 256 colores arriba rotando y haciendo uso del color math).

Poner un plano por debajo no entraría dentro de las limitaciones, aunque ahora mismo hablo solo de memoria (y no de la buena xD).

...es que no se me ocurre otra forma de rotarlo. Si es por hdma, mas por hardware imposible, y pienso en el modo 7 ext.

Eso no existe, hombre El Modo 7 Extendido no es más que desdoblar el único plano que existe en modo 7 (BG1) en dos planos diferentes de 128 colores cada uno (en vez de 1 plano de 256 colores) para que el plano BG2 pueda ser colocado encima de los sprites y el BG1 debajo. En el modo 7 extendido, realmente no existe un plano más, puesto que BG2 tiene el mismo tilemap y chardata que el BG1, lo que pasa es que los 8 bits para definir un color se convierten en 7 bits, siendo el de más peso el que controlará en qué posición respecto a los sprites se coloca cada tile de BG2; al usar el mismo chardata y el MSBit de cada byte para controlar la prioridad, a todos los efectos estás perdiendo ese bit también en BG1 y por tanto ya no puedes usar 256 colores libremente. Así que son dos planos idénticos, pero colocados a diferentes posiciones de altura en el stack de capas, pero que sí se pueden hacer scroll por separado, pero creo que no rotar porque eso depende de los registros $211B/1C/1D/1E, que parece que solo valen para un plano.

Señor Ventura escribió:Vale, te lo voy a decir... es que llevo viendo desde que salió el f-zero de la game boy advance, un doble plano haciendo uso de las rotaciones, y se me ha ocurridoque tal vez podría hacerse algo parecido en snes a base de animar las tiles del plano inferior.

Nop, eso en SNES creo que no se puede.

Señor Ventura escribió:¿Has podido ver íntegra esa parte del código?, ¿es muy extensa?.

El efecto del escalado me ha parecido bastante legal (viendo otros como el del art of fighting 2, que se sirve del offset y la manipulación precalculada de los pixeles para simularlo), ¿cúantas tiles puede alterar a la vez?.

Sí, la tengo extraída por ahí aunque no la he analizado en profundidad; no se basa en alterar tiles, sino que coge el sprite a resolución máxima y lo reduce por el factor deseado, independiente en horizontal y en vertical. El sprite puede estar formado por tiles de diferentes tamaños, aunque creo recordar que se aplicaba nada más en tiles 16x16 (o 4 tiles 8x8, no recuerdo exactamente).


En cuanto al bug del cofre, aquí está la prueba que demuestra que está solucionado

magno escribió:No estás girando un plano, estás creando el efecto óptico de que se está girando. Eso lo haces como he comentado: pixelas (es decir, usas el registro mosaico) las zonas del BG con diferentes intensidades para dar una sensación de círculo, ya que el registro mosaico permite "pixelar" la imagen con diferentes grados de intensidad. Luego en cada frame cambias la forma de la distorsión para que parezca una espiral. Pero el plano está quieto, sólo usas el HDMA para ir modificando cada línea de pantalla con diferentes pixelaciones.

Madre mía, que control del hardware hay que tener para poder idear algo así.

Lo que estoy entendiendo es que coges uno o varios pixels de cada tiles, los pixelas, y modificas cada scanline para que de la sensación de que esos pixels elegidos parezca que salen de su tile.

Eso en horizontal creo que lo entiendo... pero en vertical... joder, que es muy fuerte esto del hdma...

magno escribió:Eso no existe, hombre El Modo 7 Extendido no es más que desdoblar el único plano que existe en modo 7 (BG1) en dos planos diferentes de 128 colores cada uno (en vez de 1 plano de 256 colores) para que el plano BG2 pueda ser colocado encima de los sprites y el BG1 debajo. En el modo 7 extendido, realmente no existe un plano más, puesto que BG2 tiene el mismo tilemap y chardata que el BG1, lo que pasa es que los 8 bits para definir un color se convierten en 7 bits, siendo el de más peso el que controlará en qué posición respecto a los sprites se coloca cada tile de BG2; al usar el mismo chardata y el MSBit de cada byte para controlar la prioridad, a todos los efectos estás perdiendo ese bit también en BG1 y por tanto ya no puedes usar 256 colores libremente. Así que son dos planos idénticos, pero colocados a diferentes posiciones de altura en el stack de capas, pero que sí se pueden hacer scroll por separado, pero creo que no rotar porque eso depende de los registros $211B/1C/1D/1E, que parece que solo valen para un plano.

Si, hay que tener cuidado con la documentación que se encuentra uno por ahí, porque al final luego nunca se sabe...

Tenía entendido que resultaban en un plano de 256 colores, y otro de 128 haciendo uso de la mitad de las paletas del plano de 256, y que realmente podían solaparse, solo que el segundo plano nunca por encima del primero, pues por encima del plano que rota solo pueden haber sprites.

Gracias por la explicación

magno escribió:

Señor Ventura escribió:Vale, te lo voy a decir... es que llevo viendo desde que salió el f-zero de la game boy advance, un doble plano haciendo uso de las rotaciones, y se me ha ocurridoque tal vez podría hacerse algo parecido en snes a base de animar las tiles del plano inferior.

Nop, eso en SNES creo que no se puede.

Lo se, lo se, es solo que a veces ves efectos chulos, y te dices, ¡¡esto hay que conseguirlo!! (con el puño en alto, si no no vale xD).

¿Con el uso del hdma para el plano en modo 7, queda algo de sus 4 bytes para añadir algún efecto chulillo por scanline?.

Igual, por inventiva que no sea... lo que hacen algunos juegos (tímidamente), es actualizar tiles según te acercas para que de la sensación de que puedes ver a mas profundidad (aunque en este caso no parece ser actualización de tiles, sino cambio de color de los pixels para que dejen de ser oscuros, y pueda verse el terraplen):


Con la misma técnica (actualizando tiles externo a una pista de un circuíto, por ejemplo), tal vez se pueda simular una doble profundidad a diferentes velocidades, al estilo del f-zero de gba, con realmente solo un plano.

magno escribió:Sí, la tengo extraída por ahí aunque no la he analizado en profundidad; no se basa en alterar tiles, sino que coge el sprite a resolución máxima y lo reduce por el factor deseado, independiente en horizontal y en vertical. El sprite puede estar formado por tiles de diferentes tamaños, aunque creo recordar que se aplicaba nada más en tiles 16x16 (o 4 tiles 8x8, no recuerdo exactamente).

Tienes un tesoro, pues.

Pensando en como lo haría yo, también concluí que lo suyo es no cambiar tamaños de tiles para evitar conflictos. De hecho sería bastante similar a la famosa bola del super aleste.

Copias las tiles necesarias en WRAM, calculas el tamaño mínimo hasta estar formado por uno, o varios pixels, y a partir de ahí vas copiando el resultado a la VRAM, que actualizará las tiles del objeto. La clave es que la rutina no lleve mucho tiempo calcular la operación, claro

Una forma curiosa de implementar esa reducción/ampliación de información, es fijarse en el algoritmo que usa el propio efecto de pixelación por hardware de la snes, en el que básicamente coges un pixel como referencia, y haces una división entre los pixels inmediatamente cercanos para convertirlos en varios iguales de un color intermedio. Hablo un poco de memoria, y aprovecho para soltarlo por si hay que corregir cosillas, ya sabes (siento el abuso, pero es que eres mi principal referencia ^^u).

Para escalar uno o varios tiles tal vez sea mejor para una cpu de estas ese nivel de simplificación (que admeás se asimila mucho al resultado de mas fidelidad), al menos siempre será mejor que agrupar tiles para que parezca que hay un escalado, como en el art of fighting.


P.D: Perdón, y hablando de offsets. En un plano de con tiles de 3 colores (por ejemplo), ¿puedes agrupar algunos de ellos para que en algunas zonas puedan acumularse algunos colores mas? (vendría de lujo para algunas intersecciones).
Se que en algunos modos gráficos puedes escoger un grupo de tiles para moverlos verticalmente, superponiendose al resto, pero no se cual sería la limitación.

magno escribió:En cuanto al bug del cofre, aquí está la prueba que demuestra que está solucionado

¿Ha dejado de ser un sprite?.

Señor Ventura escribió:Madre mía, que control del hardware hay que tener para poder idear algo así.

Lo que estoy entendiendo es que coges uno o varios pixels de cada tiles, los pixelas, y modificas cada scanline para que de la sensación de que esos pixels elegidos parezca que salen de su tile.

Eso en horizontal creo que lo entiendo... pero en vertical... joder, que es muy fuerte esto del hdma...

Control del hardware e imaginación. El HDMA es muy potente pero hay que saberlo usar, su objetivo es poder modificar algún registro de PPU para que su efecto se vea en la siguiente línea, por lo que tiene casi todo el control de la visualización en cada línea de pantalla.
Ahora, saber usar esas herramientas eficazmente para crear el efecto que tienes en mente no es tan fácil.

Señor Ventura escribió:¿Con el uso del hdma para el plano en modo 7, queda algo de sus 4 bytes para añadir algún efecto chulillo por scanline?.

Igual, por inventiva que no sea... lo que hacen algunos juegos (tímidamente), es actualizar tiles según te acercas para que de la sensación de que puedes ver a mas profundidad (aunque en este caso no parece ser actualización de tiles, sino cambio de color de los pixels para que dejen de ser oscuros, y pueda verse el terraplen):

Con la misma técnica (actualizando tiles externo a una pista de un circuíto, por ejemplo), tal vez se pueda simular una doble profundidad a diferentes velocidades, al estilo del f-zero de gba, con realmente solo un plano.

A ver, eso que cuentas YA lo hace el Modo 7. Básicamente el modo 7 es un plano de 256 colores como un BG normal y corriente pero de 1024x1024 píxeles. Tú actualizas tiles y tilemaps en él como un BG normal, la única diferencia es que ese plano lo puedes tumbar y girar respecto del punto de vista de la pantalla. Así que lo que no sé exactamente es si el HDMA se aplica al plano considerandolo ya girado o sin girar. Es decir, piensa en la pista del Mario Kart... si yo hago HDMA para cambiar el color de la línea 1 de pantalla... ¿afecta al horizonte del plano o no?

Señor Ventura escribió:Pensando en como lo haría yo, también concluí que lo suyo es no cambiar tamaños de tiles para evitar conflictos. De hecho sería bastante similar a la famosa bola del super aleste.

Copias las tiles necesarias en WRAM, calculas el tamaño mínimo hasta estar formado por uno, o varios pixels, y a partir de ahí vas copiando el resultado a la VRAM, que actualizará las tiles del objeto. La clave es que la rutina no lleve mucho tiempo calcular la operación, claro

Eso lo tienes que hacer obligatoriamente siempre que quieres modificar las tiles de un objeto representado en pantalla. La VRAM solo es la memoria de video, no se debería de intentar hacer transformaciones en ella porque no está pensado para ello; y esto es así porque la VRAM no debería de modificarse fuera del VBlank.
Así que la única otra forma es copiar las tiles a RAM, transformarlas y luego enviarlas por DMA a VRAM (o copiándolas byte a byte, pero eso es más lento).

Señor Ventura escribió:Una forma curiosa de implementar esa reducción/ampliación de información, es fijarse en el algoritmo que usa el propio efecto de pixelación por hardware de la snes, en el que básicamente coges un pixel como referencia, y haces una división entre los pixels inmediatamente cercanos para convertirlos en varios iguales de un color intermedio. Hablo un poco de memoria, y aprovecho para soltarlo por si hay que corregir cosillas, ya sabes (siento el abuso, pero es que eres mi principal referencia ^^u).

En cuanto tienes que dividir algo, olvídate de ser un algoritmo rápido... a menos de que dividas por 2^n y entonces es un algoritmo muy limitado. Hay mucha literatura de procesado de señal de video que habla de cómo hacer el escalado. El más rápido y menos preciso es "nearest neighborhood" y los mejores son los que aplican polinomios de 3 o 5 orden. Uno rápido y adecuado para algo como SNES es el bilinieal, que suma dos píxeles cercanos, los promedia (haciendo un LSR) y obtiene el píxel. Pero esto sólo te permite hacer reducciones x2, x4, x8 y StarOcean permite más libertad que eso.

Señor Ventura escribió:P.D: Perdón, y hablando de offsets. En un plano de con tiles de 3 colores (por ejemplo), ¿puedes agrupar algunos de ellos para que en algunas zonas puedan acumularse algunos colores mas? (vendría de lujo para algunas intersecciones).
Se que en algunos modos gráficos puedes escoger un grupo de tiles para moverlos verticalmente, superponiendose al resto, pero no se cual sería la limitación.

Aquí ya no sé de qué hablas... ¿Planos de 3 colores? O son de 2 colores (1BPP), de 4 (2BPP) o de 16 (4BPP), o el modo 7 con 256. Y tampoco entiendo qué es "agrupar colores". Tampoco había oído eso de mover un grupo de tiles... Habia oído el Offeset per Tile, pero no tiene que ver con los colores...
No sé, ya me he perdido...

Señor Ventura escribió:¿Ha dejado de ser un sprite?.

No, sigue siendo un sprite pero colocado en el orden correcto de visualización respecto al sprite.

magno escribió:Control del hardware e imaginación. El HDMA es muy potente pero hay que saberlo usar, su objetivo es poder modificar algún registro de PPU para que su efecto se vea en la siguiente línea, por lo que tiene casi todo el control de la visualización en cada línea de pantalla.
Ahora, saber usar esas herramientas eficazmente para crear el efecto que tienes en mente no es tan fácil.

El resultado es algo así como manipular analógicamente la imagen para crear efectos gráficos. No que se haga analógicamente, sino que el coste no tiene ningún impacto en el rendimiento.

A mi me ha impresionado, desde luego...

Teniendo en cuenta de lo que es capaz, se podría decir que potencialmente podría replicar efectos como el de la silueta de alucard en el symphony of the night, por ejemplo (aunque este serían sprites, pero para un enemigo hecho con un plano... vía libre).

Por ejemplo drácula cuando se transforma en un monstruo, al principio del juego (en el prólogo):
https://youtu.be/RxRaLTpG2VI?t=175


¿Que te parece?.

magno escribió:A ver, eso que cuentas YA lo hace el Modo 7. Básicamente el modo 7 es un plano de 256 colores como un BG normal y corriente pero de 1024x1024 píxeles. Tú actualizas tiles y tilemaps en él como un BG normal, la única diferencia es que ese plano lo puedes tumbar y girar respecto del punto de vista de la pantalla. Así que lo que no sé exactamente es si el HDMA se aplica al plano considerandolo ya girado o sin girar. Es decir, piensa en la pista del Mario Kart... si yo hago HDMA para cambiar el color de la línea 1 de pantalla... ¿afecta al horizonte del plano o no?

Veamos...

Si tomo literalmente la premisa, cambiando el color de la línea 1 de la pantalla, estaría cambiando el color en el scanline correspondiente al segundo plano del modo 7 extendido, que es el que no recibe cálculos de rotación y escalado, y siendo que comparte paletas con el plano de la pista (el que si rota y escala, habría un conflicto de colores en este).

Si doy por hecho que te refieres al primer scanline del plano que si rota y escala, usando el hdma para cambiar sus colores, todo radicaría en si los cálculos de rotación y escalado ocupan enteramente los 4 Bytes por línea, y eso es algo que por descontado no se. Pero por contestar, intuyo que no puedes ocupar el hdma para esas dos tareas.

Y en el caso de que ambas instrucciones quepan en esos 4 Bytes, creo que volveríamos al conflicto de estar cambiando colores del otro plano descontroladamente, ya que comparten paleta.


Ahora, lo que tenía entendido es que el plano que si rota y escala tenía 256 colores con todas sus paletas, y el plano del modo 7 extendido tenía 128 colores usando la mitad de las paletas del plano a 256 colores. En este caso, todo dependería de si los colores cambiados pertenecerían a una paleta compartida, o no compartida.

magno escribió:Eso lo tienes que hacer obligatoriamente siempre que quieres modificar las tiles de un objeto representado en pantalla. La VRAM solo es la memoria de video, no se debería de intentar hacer transformaciones en ella porque no está pensado para ello; y esto es así porque la VRAM no debería de modificarse fuera del VBlank.
Así que la única otra forma es copiar las tiles a RAM, transformarlas y luego enviarlas por DMA a VRAM (o copiándolas byte a byte, pero eso es más lento).

Si, exacto, a eso me refería. Todo cambio al que aplicar una rutina por software que modifique un tiles (que luego podrá ser un sprite o un plano), deberá hacerse desde la WRAM, y enviar el resultado a la VRAM.

Si por ejemplo quisiese hacer un efecto de escalado de un objeto de 32x32 pixels que empieza siendo tan pequeño como un punto, y acaba volviendose tan grande como es en memoria (32x32):
-Primero copias los 16 tiles en la WRAM.
-Los duplicas, y a la copia le aplicas el cálculo de escalado hacia abajo (hacerlo mas pequeño). Esto conlleva andar borrando y duplicando el sprite de 16 tiles que ya está en la WRAM, por loque no requiere hacer DMA.
-Llevaría varios pasos dentro de un frame, y no pararía hasta que fuese un puntito.
-Ese sprite de 32x32 con el puntito lo copio a la VRAM, y el PPU1 lo manda a la pantalla a través del line buffer.
-Borro la copia de los 16 tiles
-En el siguiente frame la rutina empieza el proceso de nuevo, pero se queda en el paso anterior al resultado que da un puntito, siendo ahora 4 puntitos.
-Y así sucesivamente hasta que finalmente copias el sprite de 16 tiles íntegramente a la VRAM, ya en su tamaño total, para ser representado en pantalla.

La elección de la precisión del algoritmo del zoom dependerá de si tienes a la cpu muy ocupada, y no pudiese con ello, o de si por el contrario puede igualmente con ello.

A mejor precisión, la información será mas correcta con respecto al dibujo original cuando sea mas pequeño, y a menor precisión, será mas "deformado" (como el zoom out de neo geo, que aunque sea por hardware, parece bastante rudimentario... o al menos el zoom ou que aplica la snes a los planos es bastante mas fino).

magno escribió:En cuanto tienes que dividir algo, olvídate de ser un algoritmo rápido... a menos de que dividas por 2^n y entonces es un algoritmo muy limitado. Hay mucha literatura de procesado de señal de video que habla de cómo hacer el escalado. El más rápido y menos preciso es "nearest neighborhood" y los mejores son los que aplican polinomios de 3 o 5 orden. Uno rápido y adecuado para algo como SNES es el bilinieal, que suma dos píxeles cercanos, los promedia (haciendo un LSR) y obtiene el píxel. Pero esto sólo te permite hacer reducciones x2, x4, x8 y StarOcean permite más libertad que eso.

A mi me vale. Un algoritmo que permita ser rápido también te puede permitir aplicarlo a varios sprites a la vez, y eso lo compensa.

Pero vamos, todo dependerá del diseño que necesites aplicar, claro.

P.D: ¿Te refieres a que el algoritmo de escalado del star ocean permite escalar "anamórficamente"? (eso abriría las puertas a jugar con el diseño con muchos tipos de zoom diferente).

magno escribió:Aquí ya no sé de qué hablas... ¿Planos de 3 colores? O son de 2 colores (1BPP), de 4 (2BPP) o de 16 (4BPP), o el modo 7 con 256. Y tampoco entiendo qué es "agrupar colores". Tampoco había oído eso de mover un grupo de tiles... Habia oído el Offeset per Tile, pero no tiene que ver con los colores...
No sé, ya me he perdido...

Me refería a que hay modos gráficos en los que puedes coger filas verticales de tiles para moverlas verticalmente de su sitio, las cuales se situarían encima de otros tiles de otros planos, doblando el número de colores dentro de un tile gracias al transparente, pero es una tontería porque no hace falta hacer offset si le vas a cambiar la prioridad igualmente.

He dicho una chorrada, ignóralo

Señor Ventura escribió:El resultado es algo así como manipular analógicamente la imagen para crear efectos gráficos. No que se haga analógicamente, sino que el coste no tiene ningún impacto en el rendimiento.

A mi me ha impresionado, desde luego...

Eso es; no se hace analógicamente, pero es como si se hiciera, ya que cambias el efecto que tiene esa línea en pantalla haciendo HDMA. Pero sí impacta algo en el rendimiento: la CPU se para mientras se hace el HDMA. Esto es una necesidad por el diseño de los buses, y aunque el tiempo que se para es mínimo (creo recordar que el HDMA so unos 9 ciclos, por lo que vendrían a ser el equivalente de 3 o 4 instrucciones de CPU), sí hubiera sido una buena mejora que la SNES pudiera haber seguido usando la CPU mientras se hacía el DMA.

Señor Ventura escribió:Teniendo en cuenta de lo que es capaz, se podría decir que potencialmente podría replicar efectos como el de la silueta de alucard en el symphony of the night, por ejemplo (aunque este serían sprites, pero para un enemigo hecho con un plano... vía libre).

Por ejemplo drácula cuando se transforma en un monstruo, al principio del juego (en el prólogo):
https://youtu.be/RxRaLTpG2VI?t=175


¿Que te parece?.

Así a botepronto se me ocurre que se podría hacer por HDMA:

* Creas un enventanado que empiece y termine en cada línea formando la silueta de Drácula sin transformar; cambias la anchura de la ventana en cada línea con HDMA para que se cree esa sensación de siueta.
* Por HDMA, en otro canal, cambias el Direct Color de esa ventana para que cada línea de pantalla DENTRO DE LA SILUETA tenga un color. Esto implicará estar usando un BG completo sólo para hacer este efecto.
* Para cada frame siguiente vas cambiando la forma en la que se crea la silueta para hacer el morphing al Drácula transformado y cambias los colores con los que se rellena dicha silueta.

Señor Ventura escribió:Si tomo literalmente la premisa, cambiando el color de la línea 1 de la pantalla, estaría cambiando el color en el scanline correspondiente al segundo plano del modo 7 extendido, que es el que no recibe cálculos de rotación y escalado, y siendo que comparte paletas con el plano de la pista (el que si rota y escala, habría un conflicto de colores en este).

Pensando detenidamente la pregunta que me había hecho a mi mismo antes, cuando haces un HDMA en la primera línea de pantalla estás cambiando los registros de la PPU durante esa línea, por lo que no afecta al plano rotado si éste no tiene ningún píxel en la primera línea de pantalla.

Señor Ventura escribió:Si doy por hecho que te refieres al primer scanline del plano que si rota y escala, usando el hdma para cambiar sus colores, todo radicaría en si los cálculos de rotación y escalado ocupan enteramente los 4 Bytes por línea, y eso es algo que por descontado no se. Pero por contestar, intuyo que no puedes ocupar el hdma para esas dos tareas.

Y en el caso de que ambas instrucciones quepan en esos 4 Bytes, creo que volveríamos al conflicto de estar cambiando colores del otro plano descontroladamente, ya que comparten paleta.

El HDMA está pensado para cambiar la configuración de los registros de la PPU, no para hacer envío masivo de datos a VRAM, CGRAM o OAM. Pero si sólo tienes que cambiar un color de una paleta, puedes hacerlo enviando los 2 bytes de dicho color en cada línea. Pero ese color afecta a todas las tiles que caigan en ese scanline.

Señor Ventura escribió:Ahora, lo que tenía entendido es que el plano que si rota y escala tenía 256 colores con todas sus paletas, y el plano del modo 7 extendido tenía 128 colores usando la mitad de las paletas del plano a 256 colores. En este caso, todo dependería de si los colores cambiados pertenecerían a una paleta compartida, o no compartida.

Como te comenté, ambos planos comparten tilechar y tilemap. Teniendo en cuenta que los 8 bits del tilechar dicen directamente el color del píxel, quiere decir que ambos planos usan exactamente los mismos colores. Como el plano extendido entiende el bit 7 como bit de transparencia, entonces limita el uso de este bit para la capa de 256 colores.

Señor Ventura escribió:Si por ejemplo quisiese hacer un efecto de escalado de un objeto de 32x32 pixels que empieza siendo tan pequeño como un punto, y acaba volviendose tan grande como es en memoria (32x32):
-Primero copias los 16 tiles en la WRAM.
-Los duplicas, y a la copia le aplicas el cálculo de escalado hacia abajo (hacerlo mas pequeño). Esto conlleva andar borrando y duplicando el sprite de 16 tiles que ya está en la WRAM, por loque no requiere hacer DMA.
-Llevaría varios pasos dentro de un frame, y no pararía hasta que fuese un puntito.
-Ese sprite de 32x32 con el puntito lo copio a la VRAM, y el PPU1 lo manda a la pantalla a través del line buffer.
-Borro la copia de los 16 tiles
-En el siguiente frame la rutina empieza el proceso de nuevo, pero se queda en el paso anterior al resultado que da un puntito, siendo ahora 4 puntitos.
-Y así sucesivamente hasta que finalmente copias el sprite de 16 tiles íntegramente a la VRAM, ya en su tamaño total, para ser representado en pantalla.

La elección de la precisión del algoritmo del zoom dependerá de si tienes a la cpu muy ocupada, y no pudiese con ello, o de si por el contrario puede igualmente con ello.

A mejor precisión, la información será mas correcta con respecto al dibujo original cuando sea mas pequeño, y a menor precisión, será mas "deformado" (como el zoom out de neo geo, que aunque sea por hardware, parece bastante rudimentario... o al menos el zoom ou que aplica la snes a los planos es bastante mas fino).

Puedes hacerlo así, aunque no suele ser ése el procedimiento: la rutina de escalado siempre parte del sprite completo 32x32 y escala el ratio que tú le pases como parámetro, por eso te decía que una rutina que escale por 2 aplicando bilinear no es válida, ya que pasarías de un sprite 32x32 abruptamente a uno 16x16.
Así, a la rutina le pasas por ejemplo los parámetros 27 y 22, y eso quiere decir que escale las tiles 32x32 a 27x22. Para hacerlo, piensa en una línea el sprite 32x32: de 32 píxeles te tienes que quedar con 27 y "tirar" 5; pero no te puedes quedar con los 27 píxeles originales salteados, porque si no, distorsionas la imagen. Lo que puedes hacer es tener en ROM una tabla que te diga con qué píxeles te quedas cuando tienes que sacar 27 píxeles en horizontal:
11111011_11011110_11111011_11011111

Los bits a 0 indican que el bit en esa misma posición de la tile original 32x32 se tira y no se copia en la tile escalada 27x22. Quedaría aplicar el filtrado bilineal para retener algo de información de esos píxeles que has tirado, así que puedes tener otra tabla en ROM que te diga en qué píxeles aplicas bilineal (con el pixel actual y el anterior ) y al no aplicarlos en todos los píxeles, ahorras tiempo de procesado con un resultado visual muy parecido:
00000110_00110001_10000110_00110000

Lo mismo podrías hacer en vertical, aunque es un poco más complejo, la idea es la misma.

Eso sí, siempre se suele partir de las tiles 32x32 originales, no se va "acumulando el escalado" entre frames porque si aplicas un escalado cuando ya tienes las tiles de tamaño 10x10, por ejemplo, el gurruño que te sale es legendario.

Señor Ventura escribió:P.D: ¿Te refieres a que el algoritmo de escalado del star ocean permite escalar "anamórficamente"? (eso abriría las puertas a jugar con el diseño con muchos tipos de zoom diferente).

Claro, si has jugado al juego verás que cuando llegas a un punto de salvado, el sprite de Ratix se deforma verticalmente a diferente tamaño que horizontalmente.

Ese efecto de transformación de Drácula me parece haberlo visto en sparkter,en el primer nivel hay unos enemigos que hacen como un transformación de piedras a monstruos.
Corregidme si me equivoco

Pero este juego, resumiendo, ya esta en castellano pero no se puede jugar?
Porque leo que esta al 100%, me meto en la web y pone que no se puede jugar. Eso si, varios videos y capturas del juego con los textos en español.

mollar escribió:Pero este juego, resumiendo, ya esta en castellano pero no se puede jugar?
Porque leo que esta al 100%, me meto en la web y pone que no se puede jugar. Eso si, varios videos y capturas del juego con los textos en español.

Poderse jugar se puede, lo que no hay es parche para la versión de 48 megas que corre en los emuladores "estándares": SNES9x, ZSNES, bsnes (al menos en las versiones antiguas, en las nuevas Higan no he probado).

Ocupa como el tales of phantasia?

mollar escribió:Ocupa como el tales of phantasia?

Pero son 48 megas que están comprimidos, que al descomprimir todos los gráficos viene a ocupar unos 60~70 megabits; ahora mismo estoy en proceso de ver cómo montar un cartucho con todos los gráficos descomprimidos para no necesitar el chip S-DD1.

@magno ufff que lio! Pero se agradece el esfuerzo!

Tales? no querrás decir star?

magno tiooo, que tengo esto esperando tu tradu!!!!

gadesx escribió:Vale, la ciudad es justo la anterior, Van I II Castle Town
El plano de agua no está, pero están los tiles animados de bordeado de agua (layer 2 y 3 que añade el efecto de agua
en los bordeados)





En zonas anteriores con el tile de agua, si te fijas los bordeados son iguales pero hay agua azul, aqui es negro

¡SOLUCIONADO!





Se les había olvidado incluir BG3 en el MainScreen y por tanto no se hacía correctamente la matemática de color sobre el azul.

@magno Eres un crack!
Por cierto, ese Chiptune Rocker es tremendo! Cambias esos fondos por los del FF VII por ejemplo y daría el pego bastante bien. ¿No se puede descargar esa rom inacabada?

bluedark escribió:@magno Eres un crack!
Por cierto, ese Chiptune Rocker es tremendo! Cambias esos fondos por los del FF VII por ejemplo y daría el pego bastante bien. ¿No se puede descargar esa rom inacabada?

Gracias

He estado preguntando por foros pero nadie sabe dónde encontrar esa demo; tiene buena pinta, yo creo que sin límite de espacio en la ROM se podría hacer un juego así de vistoso.

Qué maquina , ya me imaginaba que faltaba, en tema de gráficos y betatesting pillo tela.
el agua queda genial, viendo el sombreado de los bordeados ya me imaginaba
que sería algo mas que un color plano como el agua del primer pueblo,
con el agua con pixeles en lineas que harán un ligero movimiento, el bordeado tiene una
animación que ya es así, aunque hay una ligera variación de color porque es un tile+reflejo de agua,
seguramente si no llegaron ni a ver el fallo, no verían esto que te voy a poner ampliado.

Podría ser un bug dentro de un bug,
aunque es bastante pasable si juegas en CRT,
difícil de notar, lo he visto en muchos juegos.

Me refiero a esto:

gadesx escribió:Podría ser un bug dentro de un bug,
aunque es bastante pasable si juegas en CRT,
difícil de notar, lo he visto en muchos juegos.

Me refiero a esto:

Sí, yo también me he dado cuenta, pero no es un bug: es el efecto de la matemática de color de la sombra de los árboles junto con el agua azul: la capa BG3 contiene las formas de las sombras y ese efecto que dices se supone que es la luz que pasa através de los árboles.

@magno, tengo una duda ¿Crees que funcionaría en la SNES mini? Se supone que va en un emulador y este bicho los es. Aún no la he toqueteado y no estaría mal empezar por este juego.

Un saludo.

legionpsm escribió:@magno, tengo una duda ¿Crees que funcionaría en la SNES mini? Se supone que va en un emulador y este bicho los es. Aún no la he toqueteado y no estaría mal empezar por este juego.

Un saludo.

El juego lleva chip S-DD1 y no está emulado en el emulador oficial de la SNES Mini; si consigo hacer una versión de 64 megas, entonces sí que dbeerñia funcionar sin problemas, pero aún no sé de qué tamaño me saldrá la ROM final con los gráficos descomprimidos (y por tanto sin necesidad de chip S-DD1).

Ok @magno, a la espera de tus notícias. Gracias.

Un saludo.

Sería magnífico poder cargarlo en la Mini SNES, así que estaré atento a las noticias. Disfruté mucho de la segunda entrega que apareció en PSX y me encantaría disfrutar de la primera

magno escribió:

lito69 escribió:No, yo espero tener 50 años y decirle a mi hijo mira, a esto jugaba papa, lo tradujo un tio de este foro y ahora puedes jugarlo tú igual que yo, aunque a lo mejor el niño sabe inglés y se la sopla.

Entonces lo estarías haciendo de puta madre como padre No solo por lo del inglés, sino porque le enseñes a tu hijo estas joyas
Yo aprendí el 90% de vocabulario en inglés entre los 13 y los 15 años jugando a Secret of Mana, Zelda, Breath of Fire...

Será niña Pero da igual, se lo pienso enchufar esto
A ver, te voy leyendo, pero es como que sufro un poco de pensar que no vas a compartir el parche, tengo esperanza de que te lo replantees y poderlo jugar, lo estoy dejando para cuando pueda jugar con la pequeña, es la excusa para que la madre no se queje sabes......

gadesx escribió:Anoche estuve probando de madrugada volver atrás en el save que tenia en el snes9x de wii
y llegué al sitio de los tiles mal puestos, no es en el desierto, fallo de memoria mia,
es en la zona nevada, al oeste de sylvalant.
Tampoco fui a la busqueda de fallos, sino encontraría muchos mas porque no parece bien
testeado.

Tile inferior de bordeado de montaña que está puesto como sobre el personaje y con pasabilidad


Mas de lo mismo, tiles superiores que se pueden atravesar




Falta que encuentre la ciudad a la que le faltaba un plano de agua o algo así y me suena que se veia
negro, aunque por la forma de la ciudad esa parte solo se veia un poco desde un punto así que
era facil que pasase desapercibido.

Ok, ya he encontrado esos fallos de tiles que dices... Son todos en la zona de Dulce tras ser arrasada y aquí puedes ver su tiletype:



Puedes ver que las tiles en rojo, de tipo 0x40, son zonas sólidas que no se pueden atravesar, las de tipo 0x00 son suelo normal y corriente, que en las capturas que has puesto, corresponden con los trozos de suelo sin nieve; las tiles 0x1A son las tiles con nieve donde el personaje deja sus huellas. Luego otros tipos de tile son para identificar las entradas y salidas de la zona.
Si miras bien, la zona ésa donde te metes en la roca no está bien delimitada con tiles 0x40, por eso el personaje puede entrar. También hay una tile 0x40 sólida en medio de la nada, al lado de la zona de color verde donde hay suelo sin nieve.
Y luego, la tile que tapa al personaje pero no debería está en la parte inferior izquierda, pero el tipo de tiles parece estar bien (0x1A), y lo que está mal es que hay una tile en el tilemap que tiene la prioridad mal puesta y por tanto queda por encima del sprite.

Lo primero está solucionado ya, pero lo del tilemap con prioridad incorrecta aún no.
Si vieras la cantidad de mapas que me he encontrado ya con fallos tontos.........

lito69 escribió:Será niña Pero da igual, se lo pienso enchufar esto
A ver, te voy leyendo, pero es como que sufro un poco de pensar que no vas a compartir el parche, tengo esperanza de que te lo replantees y poderlo jugar, lo estoy dejando para cuando pueda jugar con la pequeña, es la excusa para que la madre no se queje sabes......

¡Enhorabuena, hombre! El mundo necesita más gamers femeninas, así que harás viendo enchufándole esto por los ojos.

Curioso como ves los tiles en hex
Se parece a los tipos de terreno del rpg maker aunque no es lo mismo aqui, que se pueden
marcar tiles con un valor y según ese valor cambia el terreno que definas (pero para el fondo de combate al estar en ese tile, si es bosque, desierto, etc)

Hay otras cosas que tiene el maker que no se si es aplicable a esto,
los tiles tienen algunas caracteristicas mas,

Paso - 0 o X que es si puede pasar el personaje.
Dirección - Se ven flechas en el tile, segun pongas unas u otras puede o no puede entrar-salir
a ese tile el personaje, por ejemplo si hay una escalera pones que solo sea subir y bajar.
Terreno - Lo que decía arriba, segun el valor, cambia el fondo de batalla y otras cosas
mas como en rpgs que hay vehiculos para indicar que es mar y tierra al llevar un barco y poder bajar.

Hay mas cosas que son comunes en Rpgs como darle a un tile la propiedad de que
no interfiera entre personaje y npc, por ejemplo al hablar con alguien en una tienda,
personaje - mostrador que se omite su tile - npc vendedor.

El tema aqui en el Star ocean es que pueden entrar en conflicto tiles en diferentes capas con diferentes propiedades,
si el tile inferior es pared y es impasable y tiene encima un tile superior que es pasable, puede hacerle
caso a uno en vez de a otro. Con el snes9x mire la zona y vi dos capas de tiles me parece.

gadesx escribió:Curioso como ves los tiles en hex
Se parece a los tipos de terreno del rpg maker aunque no es lo mismo aqui, que se pueden
marcar tiles con un valor y según ese valor cambia el terreno que definas (pero para el fondo de combate al estar en ese tile, si es bosque, desierto, etc)

Hay otras cosas que tiene el maker que no se si es aplicable a esto,
los tiles tienen algunas caracteristicas mas,

Paso - 0 o X que es si puede pasar el personaje.
Dirección - Se ven flechas en el tile, segun pongas unas u otras puede o no puede entrar-salir
a ese tile el personaje, por ejemplo si hay una escalera pones que solo sea subir y bajar.
Terreno - Lo que decía arriba, segun el valor, cambia el fondo de batalla y otras cosas
mas como en rpgs que hay vehiculos para indicar que es mar y tierra al llevar un barco y poder bajar.

Hay mas cosas que son comunes en Rpgs como darle a un tile la propiedad de que
no interfiera entre personaje y npc, por ejemplo al hablar con alguien en una tienda,
personaje - mostrador que se omite su tile - npc vendedor.

El tema aqui en el Star ocean es que pueden entrar en conflicto tiles en diferentes capas con diferentes propiedades,
si el tile inferior es pared y es impasable y tiene encima un tile superior que es pasable, puede hacerle
caso a uno en vez de a otro. Con el snes9x mire la zona y vi dos capas de tiles me parece.

StarOcean es un poco especial para lo de la gestión de los mapas: hay tres tilemaps comprimidos con RLE para cada una de las capas, más tres tiletypes para cada una de las capas de donde se calcula el tiletype definitivo que va en $7E:EE73. Luego, los tilemaps que realmente se envían a VRAM están derivados de los comprimidos, y es de estos de donde se envían solo los tilemaps a actualizar en horizontal y vertical cada vez que hay scroll. No hacen como en otros juegos donde en RAM tienes una copia del tilemap de VRAM y en cada NMI lo envías ya modificado, sino que sacan provecho de los modos de escritura de VRAM que proporciona la SNES y actualizan una fila o una columna de tiles nada más cada 8 píxeles de scroll.


He corregido otro fallo que se producía en el Laboratorio del Tiempo y el Espacio, muy cerca del cofre ése con el que tropiezas a pesar de estar debajo del puente:



Como veis, el personaje baja la escalera muy raro, haciendo un zigzag como si realmente fuera un suelo plano y hubiera un obstáculo. Ha sido dificilísimo de corregir porque me ha costado darme cuenta de qué pasaba: el problema está en que se crea un evento en las tiles de la escalera para cambiar un bit de Ratix que le permite aparecer sombreado por debajo del puente y con colores sólidos por encima; así, cuando bajas las escaleras el bit se pone a '1' para hacer la matemática de color con el sprite al ir a por el cofre, y cuando las subes, se pone a '0' para que el sprite aparezca con colores sólidos y parezca que está encima del puente.
Pues el problema estaba que en la tiles con eventos (tiletype con MSBit a '1') no se tiene en cuenta el tipo de tile (que está en los 6 LSBits), ya que lo de los eventos lo usan principalmente en el juego para cambiar entre zonas o para lanzar alguna "cut-scene". Los programadores se olvidaron de hacerlo a pesar de que el código para hacerlo está presente en el banco $C6, así que simplemente enmascarando el MSBit del byte de tipo de tile ya funciona:

Vaya lío todo a la inversa
Normalmente en las escaleras yo pongo eventos de mover personaje abajo-izquierda por ejemplo
y se hace sólo, si no, no se tratan como escaleras, solo como suelo y no hace el efecto de subir-bajar.

Prueba pasar corriendo tambien por las escaleras a ver que tal.

Por cierto otra cosa que es generalizada en este juego es que al correr a veces
como el personaje tiene mas de 16x32px que andando, normalmente al correr de izquierda-derecha en algunos
sitios si hay un tile superior de 16x16px, como el personaje ocupa más pues se pasa
de largo la cola del personaje y se ve cortada fuera de los tiles