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.
Code:
.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 0x0839FDB0
So, for the swimmer male sprite:
Code:
FFFF0611FF110001100020001501[B]00[/B]0010373A089C373A0868333A08780D3A08FC1C2308
The 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.