Binary Hack Research & Development
Research Font color depends on overworld sprite
Started by Sierraffinity December 18th, 2010 4:15 PM- 7739 views
- 8 replies
Age 24
Female
Somewhere the rains of Africa can be blessed
Seen 15 Hours Ago
Posted January 5th, 2021
1,067
posts
13.4
Years
Exactly what the title says.
There's nothing in the overworld data itself to specify text color, and I was wondering if anybody knows a table or something that tells the sprite which color font to use.
There's nothing in the overworld data itself to specify text color, and I was wondering if anybody knows a table or something that tells the sprite which color font to use.
Restarted and revamped.
Public alpha out now!
Public alpha out now!
Different sprites have different colors when producing textboxes?! In which game?
In FireRed, if you apply a simple text script to, say, a Youngster overworld, the text will be blue, and if you apply a simple text script to a Lass overworld, the text will be red by default.
The table you're looking for is at 08464300. It has 4-bit entries. (Firered)
EDIT: How I found this out:
As you probably know the C7-Script-Commands overwrites the color to use for the next textbox. This commands writes its argument to 020370DA. Now I put a writing breakpoint on 020370DA. 0xFF is written to this position in every frame by 080CBDF0 so I turn the writing breakpoint off and replace it with a reading breakpoint. This one triggers at 080CBE04. The code shows: If 080CBDF0 isn't 0xFF it is used as the color. Otherwise a function (0813CD24) is called to read the color out of the table mentioned above.
EDIT: How I found this out:
As you probably know the C7-Script-Commands overwrites the color to use for the next textbox. This commands writes its argument to 020370DA. Now I put a writing breakpoint on 020370DA. 0xFF is written to this position in every frame by 080CBDF0 so I turn the writing breakpoint off and replace it with a reading breakpoint. This one triggers at 080CBE04. The code shows: If 080CBDF0 isn't 0xFF it is used as the color. Otherwise a function (0813CD24) is called to read the color out of the table mentioned above.
Age 24
Female
Somewhere the rains of Africa can be blessed
Seen 15 Hours Ago
Posted January 5th, 2021
1,067
posts
13.4
Years
The table you're looking for is at 08464300. It has 4-bit entries. (Firered)
EDIT: How I found this out:
As you probably know the C7-Script-Commands overwrites the color to use for the next textbox. This commands writes its argument to 020370DA. Now I put a writing breakpoint on 020370DA. 0xFF is written to this position in every frame by 080CBDF0 so I turn the writing breakpoint off and replace it with a reading breakpoint. This one triggers at 080CBE04. The code shows: If 080CBDF0 isn't 0xFF it is used as the color. Otherwise a function (0813CD24) is called to read the color out of the table mentioned above.
Awesome! Exactly what I wanted/needed.EDIT: How I found this out:
As you probably know the C7-Script-Commands overwrites the color to use for the next textbox. This commands writes its argument to 020370DA. Now I put a writing breakpoint on 020370DA. 0xFF is written to this position in every frame by 080CBDF0 so I turn the writing breakpoint off and replace it with a reading breakpoint. This one triggers at 080CBE04. The code shows: If 080CBDF0 isn't 0xFF it is used as the color. Otherwise a function (0813CD24) is called to read the color out of the table mentioned above.
I thought about doing that, but decided it wasn't as MUCH of a priority as other things.
Also, I'm guessing that each 4 bits are flipped? (Ex. Sprite 1= Male; Sprite 2 = Female, = 10)
Restarted and revamped.
Public alpha out now!
Public alpha out now!
Thanks to knizz's post, I'm gonna try to get rid of this table altogether! What i'm gonna attempt is to place this "sex" byte within the actual sprite data and then rewrite the routine to make it read from the sprite data instead, thus removing the need for a table of values, and making the routine compatible with JPAN's hack or a simple extended table.
EDIT: Here we go! This routine makes the first "alignment" byte in the Overworld data into the male/female byte, getting rid of the need for this space using table altogether.
The main reason I developed this routine was to add support for extended Overworld tables and JPAN's Overworld hack. With the routine as is, it won't work with JPAN's hack, but it'll immediately support any extended table or normal table. It goes without saying that you'll need to modify the bytes to match the given sprite (EG, for Misty, change the relevant byte to 0x01 instead of 0x00), but it won't crash if you don't, just print blue text instead of red.
This code is smaller than the code it replaces, so you can safely overwrite the original routine at 0x0813CD24 without any issues.
I will look to release a patch with all the bytes corrected in the future, and then develop a version which supports JPAN's hack (shouldn't be overly difficult tbh) so that we can have "proper" male and female sprites.
Hopefully, when a newer version of Overworld Editor is released, it will support this option as it will make it much easier to designate which sprites you wish to be male and female.
EDIT: Here we go! This routine makes the first "alignment" byte in the Overworld data into the male/female byte, getting rid of the need for this space using table altogether.
.text
.align 2
.thumb
.thumb_func
.global OWsexbytechange
main:
push {lr}
ldr r2, table
mov r1, #0x4
mul r0, r1
add r0, r0, r2
ldr r0, [r0, #0x0]
ldrb r0, [r0, #0xE]
cmp r0, #0x2
bge black
back: pop {r1}
bx r1
black: mov r0, #0x3
b back
.align
table: .word 0x0839FDB0So, for the swimmer male sprite:FFFF0611FF110001100020001501000010373A089C373A0868333A08780D3A08FC1C2308The byte in bold becomes the male/female byte. 00 - Male, 01 - Female and anything above this is set to neutral (Black).
The main reason I developed this routine was to add support for extended Overworld tables and JPAN's Overworld hack. With the routine as is, it won't work with JPAN's hack, but it'll immediately support any extended table or normal table. It goes without saying that you'll need to modify the bytes to match the given sprite (EG, for Misty, change the relevant byte to 0x01 instead of 0x00), but it won't crash if you don't, just print blue text instead of red.
This code is smaller than the code it replaces, so you can safely overwrite the original routine at 0x0813CD24 without any issues.
I will look to release a patch with all the bytes corrected in the future, and then develop a version which supports JPAN's hack (shouldn't be overly difficult tbh) so that we can have "proper" male and female sprites.
Hopefully, when a newer version of Overworld Editor is released, it will support this option as it will make it much easier to designate which sprites you wish to be male and female.
Hey guys, please check out my recreations of the gen 1 and 2 music on my custom engine at my SoundCloud! - Here!
I'm impressed! In my opinion the table is the better way but now everyone can choose.
I'm impressed! In my opinion the table is the better way but now everyone can choose.
As I said, it's more built to add compatibility with JPAN's Overworld Hack, as that still uses exactly the same table, but doesn't take into account that it's an entirely different Overworld table. The table is, with this hack, made entirely unrequired, giving us free space to use. However, arguably, the table would be easier to edit from a hex editing point of view.Thanks for the opinion. I always appreciate comments and such, it's how I improve as a hacker. :D
Hey guys, please check out my recreations of the gen 1 and 2 music on my custom engine at my SoundCloud! - Here!
Disabling on FireRed and LeafGreen
I hate to revive this after so long, but I figured out a pretty easy way to disable this.
Basically, I just replace an instruction in the table reader (0813CD24) found by knizz which makes it jump to the fail-safe it has and forces it to choose grey.
To remove it on FireRed, at 0x13CD24 replace 00 B5 00 04 with 00 B5 0F E0.
To remove it on LeafGreen, do the same only at 0x13CCFC.
Also, to change the color that it will always use, mess around with the byte at 0813CD48 (0813CD0E on LeafGreen). The 03 there is the default grey. Changing it to 00 will make it blue and 01 makes it red. All other values make it grey. Of course, this is because it works like the "textcolor" script command. :)
I hate to revive this after so long, but I figured out a pretty easy way to disable this.
Basically, I just replace an instruction in the table reader (0813CD24) found by knizz which makes it jump to the fail-safe it has and forces it to choose grey.
To remove it on FireRed, at 0x13CD24 replace 00 B5 00 04 with 00 B5 0F E0.
To remove it on LeafGreen, do the same only at 0x13CCFC.
Also, to change the color that it will always use, mess around with the byte at 0813CD48 (0813CD0E on LeafGreen). The 03 there is the default grey. Changing it to 00 will make it blue and 01 makes it red. All other values make it grey. Of course, this is because it works like the "textcolor" script command. :)
What are you so afraid of?