[ASM] [FR] Fadescreen con efecto de fundido

[Eaas]

Buenas q tal.
¿Alguna vez an querido q el fadescreen tenga efecto de fundido?
Buenos, los q han trabajado en Ruby sabrán q @eing hizo una rutina con este efecto en esa base.
A petición de un usuario quise editarla para FR y es lo q enseño hoy.

Primero necesitamos dos rutinas, una q haga q la pantalla se difumine en negro y otra para q vuelva a la normalidad.

Spoiler: DARK

.align 2
.thumb

main:
push {r0-r3,lr}
ldr r0,.04000048
mov r1,#0x3f
strb r1,[r0,#0x0]
ldr r0,.lastresult
ldrh r0,[r0,#0x0]
cmp r0,#0x0
beq negro
ldr r1,.04000050
mov r2,#0xbf
strb r2,[r1,#0x0]
ldr r1,.04000054
mov r2,#0x0
b bucle

negro:
ldr r1,.04000050
mov r2,#0xfe
strb r2,[r1,#0x0]
ldr r1,.04000054
mov r2,#0x0
b bucle

bucle:
mov r0,#0x0
add r2,#0x1
strb r2,[r1,#0x0]
cmp r2,#0x1f
bge fin
ldr r3,.r3
b pause

pause:
cmp r0,r3
beq bucle
add r0,#0x1
b pause

fin:
pop {r0-r3,pc}

.align 2
.lastresult: .word 0x020370d0
.04000048: .word 0x04000048
.04000050: .word 0x04000050
.04000054: .word 0x04000054
.02024EB5: .word 0x02024EB5
.r3: .word 0x0000ffff

Spoiler: LIGHT

.align 2
.thumb

main:
push {r0-r3,lr}
ldr r0,.04000054
mov r1,#0x1f
ldr r2,.r2
b bucle

bucle:
mov r3,#0x0
sub r1,#0x1
strb r1,[r0,#0x0]
cmp r1,#0x0
beq fin
b pause

pause:
cmp r3,r2
beq bucle
add r3,#0x1
b pause

fin:
pop {r0-r3,pc}

.align 2
.04000054: .word 0x04000054
.r2: .word 0x0000ffff

Simplemente llaman las rutinas respectivamente.

Un usuario el cual. La probó en su juego uso un script sencillo. Pará probarla.

#dynamic 0x800000
#org @start
callasm 0xDARK+1
pause 0x50
callasm 0xLIGHT+1
end

Pueden probar y ver el resultado

Creditos
@eing
Por la rutina original aportada a PRHE.

 

[Tohru]

Esta hermoso creo que lo voy a usar ;3

 

[Versekr Dark]

Grande esto, la verdad me encanto y aunque no lo vaya a usar me parece algo muy bueno.

 

[Vent]

:0000000000 OSTIA QUE CRACK!!!!!
Me lo quedo, y lo pondré en los ini de ModExe

 

[Azulado]

Buenas q tal.
¿Alguna vez an querido q el fadescreen tenga efecto de fundido?
Buenos, los q han trabajado en Ruby sabrán q @eing hizo una rutina con este efecto en esa base.
A petición de un usuario quise editarla para FR y es lo q enseño hoy.

Primero necesitamos dos rutinas, una q haga q la pantalla se difumine en negro y otra para q vuelva a la normalidad.

Spoiler: DARK

.align 2
.thumb

main:
push {r0-r3,lr}
ldr r0,.04000048
mov r1,#0x3f
strb r1,[r0,#0x0]
ldr r0,.lastresult
ldrh r0,[r0,#0x0]
cmp r0,#0x0
beq negro
ldr r1,.04000050
mov r2,#0xbf
strb r2,[r1,#0x0]
ldr r1,.04000054
mov r2,#0x0
b bucle

negro:
ldr r1,.04000050
mov r2,#0xfe
strb r2,[r1,#0x0]
ldr r1,.04000054
mov r2,#0x0
b bucle

bucle:
mov r0,#0x0
add r2,#0x1
strb r2,[r1,#0x0]
cmp r2,#0x1f
bge fin
ldr r3,.r3
b pause

pause:
cmp r0,r3
beq bucle
add r0,#0x1
b pause

fin:
pop {r0-r3,pc}

.align 2
.lastresult: .word 0x020370d0
.04000048: .word 0x04000048
.04000050: .word 0x04000050
.04000054: .word 0x04000054
.02024EB5: .word 0x02024EB5
.r3: .word 0x0000ffff

Spoiler: LIGHT

.align 2
.thumb

main:
push {r0-r3,lr}
ldr r0,.04000054
mov r1,#0x1f
ldr r2,.r2
b bucle

bucle:
mov r3,#0x0
sub r1,#0x1
strb r1,[r0,#0x0]
cmp r1,#0x0
beq fin
b pause

pause:
cmp r3,r2
beq bucle
add r3,#0x1
b pause

fin:
pop {r0-r3,pc}

.align 2
.04000054: .word 0x04000054
.r2: .word 0x0000ffff

Simplemente llaman las rutinas respectivamente.

Un usuario el cual. La probó en su juego uso un script sencillo. Pará probarla.

#dynamic 0x800000
#org @start
callasm 0xDARK+1
pause 0x50
callasm 0xLIGHT+1
end

Pueden probar y ver el resultado

Creditos
@eing
Por la rutina original aportada a PRHE.

Ver el archivo adjunto 5744

amigo la rutina esta buena para una escena de transformacion dentro de mi hackrom

 

[Azulado]

hay manera de que vaya un poco mas rapido

 

[Eaas]

hay manera de que vaya un poco mas rapido

Más rápido para q?
la sucecion no está lenta, solo q en el script hay un pause.

 

[Azulado]

Más rápido para q?
la sucecion no está lenta, solo q en el script hay un pause.

es que se ve lento

 

[Eaas]

es que se ve lento

La idea es esa, q la pantalla se difumine poco a poco, si quieres mas rápido ya esta el fadescreen original de la Rom.

 

[Azulado]

La idea es esa, q la pantalla se difumine poco a poco, si quieres mas rápido ya esta el fadescreen original de la Rom.

umm... ok

 

[Samu]

fadescreenspeed FADE_TO_BLACK, 8

O para los profanos

fadescreendelay 0x1 0x8

 

[Jaizu]

fadescreenspeed FADE_TO_BLACK, 8

O para los profanos

fadescreendelay 0x1 0x8

Buena rutina me ha gustado

 

[Eaas]

fadescreenspeed FADE_TO_BLACK, 8

O para los profanos

fadescreendelay 0x1 0x8

Deverías de saber q el resultado no es el mismo y q parpadea, por algo es la rutina.
Si fuera tan fácil con un script me hubiese ahorrado mi tiempo.

Lo q hace el script es cerrar la pantalla poco a poco, para después darte el fadescreen,por lo tanto después de cerrarla se vuelve a abrir y te da el fadescreen, eso está de cartón xd.

Muchas grax, la rutina queda más chula.

 

[X_TERRA]

Interesante, se me ocurren algunas ideas para insertarlo en mi hack, mis 10 puntos.

 

[Vent]

Guapo guapisimo, queda hermoso. Sinceramente, 100/10.

 

[Samu]

Deverías de saber q el resultado no es el mismo y q parpadea, por algo es la rutina.
Si fuera tan fácil con un script me hubiese ahorrado mi tiempo.

Lo q hace el script es cerrar la pantalla poco a poco, para después darte el fadescreen,por lo tanto después de cerrarla se vuelve a abrir y te da el fadescreen, eso está de cartón xd.

Muchas grax, la rutina queda más chula.

No sé a que parpadeo te refieres la verdad, no veo mucha diferencia, las dos terminan haciendo un blend a negro con los registros BLDCNT y BLDY.

Lo que sí te puedo decir, es que la rutina tal y como está programada me temo que solo funcionará en emuladores (y puede que no en todos). La rutina está accediendo directamente a los registros I/O (cosa que es en sí mismo unsafe), y lo está haciendo en el instante que llames al callnative. Ahora mismo no recuerdo si el callnative está restringido de alguna manera a ejecutarse en el VBlank/HBlank, pero diría que no. La cosa está en que los registros, al igual que la OAM, VRAM, etc solo pueden ser accedidos en ese momento.
Muchos emuladores son permisivos y pasan esto por alto, pero en hardware real el acceso está bloqueado físicamente fuera de los blanks.

Buena rutina, me gustó el aporte reciclado del rar de eing.

 

[Eaas]

No sé a que parpadeo te refieres la verdad, no veo mucha diferencia, las dos terminan haciendo un blend a negro con los registros BLDCNT y BLDY.

Ver el archivo adjunto 5808
Lo que sí te puedo decir, es que la rutina tal y como está programada me temo que solo funcionará en emuladores (y puede que no en todos). La rutina está accediendo directamente a los registros I/O (cosa que es en sí mismo unsafe), y lo está haciendo en el instante que llames al callnative. Ahora mismo no recuerdo si el callnative está restringido de alguna manera a ejecutarse en el VBlank/HBlank, pero diría que no. La cosa está en que los registros, al igual que la OAM, VRAM, etc solo pueden ser accedidos en ese momento.
Muchos emuladores son permisivos y pasan esto por alto, pero en hardware real el acceso está bloqueado físicamente fuera de los blanks.

Buena rutina, me gustó el aporte reciclado del rar de eing.

la única forma de saberlo es probando en hardware real, y hasta ahora lo más cercano es el Mgba, y si funsiona ahí q más puedo hacer, como único metiendo el Rom en un casete xd.
La verdad si la saque del baúl de Eing, para q hacerla de 0 si el ya lo había hecho?.

 

[Samu]

la única forma de saberlo es probando en hardware real, y hasta ahora lo más cercano es el Mgba, y si funsiona ahí q más puedo hacer, como único metiendo el Rom en un casete xd.
La verdad si la saque del baúl de Eing, para q hacerla de 0 si el ya lo había hecho?.

¿Ahora en serio, cual se supone que es la diferencia? Porque yo no lo veo. He mirado el código ASM y el relacionado con el comando, y la única diferencia que veo es que un código es "hacky" y unsafe, y el otro no.

 

[eing]

Buenas,

Solo vengo a decir que el aporte en si no esta mal, pero que deberias de dejar binario de lado y centrarte en decomp.
Las rutinas del PRHE, como la mayoría de rutinas creadas para el rom hacking binario, no están exentas de fallos, ya que cuando se hicieron, apenas habia documentacion.
Esta en principio funciona, pero si el emulador le da por hacer de las suyas, te va a putear. (De echo cuantos errores han habido en unos emuladores y en otros no?

Si ahora tienes la posibilidad de ver todo proceso del rom documentado (decomp) tira de ello y dejad de darle soporte al binario, que es seguir intentando hacer fuego con dos piedras cuando ya hay mecheros de gas para ello.

Pd. Y con esto no quiero decir que el rom hacking binario sea cancer, pero a dia de hoy, existiendo decomp es un absurdo enorme.
Otra cosa es que no exista decomp para dicho juego y no te queda otra que tirar de RH binario, como por ejemplo un hack de mario, zelda, metroid prime, yugioh.. etc. pero si no, NI DE BROMA.

 

[Vent]

la única forma de saberlo es probando en hardware real, y hasta ahora lo más cercano es el Mgba, y si funsiona ahí q más puedo hacer, como único metiendo el Rom en un casete xd.
La verdad si la saque del baúl de Eing, para q hacerla de 0 si el ya lo había hecho?.

Si quieres puedo hacer un Virtual Console de un ROM de FR con la rutina y probarlo. Y salimos de dudas.
En fin, digan no al fanatismo con decomp; cada post que veo cada ''discusión'' que miro sobre Decomp Vs Binario.