Welcome to Smashboards, the world's largest Super Smash Brothers community! Over 250,000 Smash Bros. fans from around the world have come to discuss these great games in over 19 million posts!
You are currently viewing our boards as a visitor. Click here to sign up right now and start on your path in the Smash community!
It appears that you are using ad block :'(
Hey, we get it. However this website is run by and for the community... and it needs ads in order to keep running.
Please disable your adblock on Smashboards, or go premium to hide all advertisements and this notice. Alternatively, this ad may have just failed to load. Woops!
4.) Open MCM v2.0 and open your ISO. In the "Injection Mods" tab scroll all the way down.
You should see "Marth Costume Dependent Sword Colors" in white. Click it, it should turn light green.
5.) Click "save changes" and you're done.
Creating your own colors:
Replace the following values indicated below, where XX is the opacity control (00 = transparent, FF = opaque), R1 is RR for Color 1, G1 is GG for Color 1, B1 is BB for Color 1, R2 is RR for Color 2, G2 is GG for Color 2, and B2 is BB for Color 2.
I'll leave this picture from the color effects thread for reference:
C2136510 00000020
3DC0FF00 61CEFFFF
7C007000 408200EC
39E5E181 89EF0000
2C0F0000 40820024 // Blue Marth
3C60B200 60630000
90650010 3C60FFXX
6063R1G1 3C00B100
6000R2G2 480000A0
2C0F0001 40820024 // Red Marth
3860B200 60630000
90650010 3C60FFXX
6063R1G1 3C00B100
6000R2G2 48000078
2C0F0002 40820024 // Green Marth
3C60B200 60630000
90650010 3C60FFXX
6063R1G1 3C00B100
6000R2G2 48000050
2C0F0003 40820024 // Black Marth
3860B200 60630000
90650010 3C60FFXX
6063R1G1 3C00B100
6000R2G2 48000028
2C0F0004 40820040 // White Marth
3C60B200 60630000
90650010 3C60FFXX
6063R1G1 3C00B100
6000R2G2 94650008
90050004 38840008
80040004 38A50008
90050004 48000008
94650008 00000000
Original Post with installation directions for 20XX v3.02 and v4.05:
I wasn't sure where to post this... it's related to 20XX, color effects, and gecko codes, so I just decided to make my own post. Preview below. It's a code that allows you to change both colors in Marth's sword swings for every costume. It works with the 20XX 'sword swing colors' switch in the debug menu.
To make your own colors, replace the following values indicated below, where XX is the opacity control (00 = transparent, FF = opaque), R1 is RR for Color 1, G1 is GG for Color 1, B1 is BB for Color 1, R2 is RR for Color 2, G2 is GG for Color 2, and B2 is BB for Color 2.
I'll leave this picture from the color effects thread for reference:
Starting with the first line, 3DC0FF00 is at offset 0x00426330 in start.dol. There are other changes that I made in start.dol, so be sure to make your changes on a copy of the start.dol that I linked above!
You are encouraged to post your color schemes, I'd love to see what you guys come up with
Could you tell me what are the exact color offsets for this start.dol
Im trying to customize it but i messed up in the green, black and white colors
thanks
because it seems this 4.05 dol is shorter from the 3.02
I worked on some color schemes. All should run cleanly with 4.05. Attached both the dol files and the code.
The first is all normal blue and white for every costume, but this is using the code from Decipio-Carmen
. Perhaps this could be useful for anyone writing a code to toggle between sword swing colors.
The second is the colors from this gif, created by achilles for 3.02 (or maybe earlier), but is now working with Decipio-Carmen's code for 4.05.
The third is the same as the second but with the colors inverted. That is color 1 becomes color 2, so for blue Marth, white is on the hilt of the sword and blue is on the tip. I thought this would give more emphasis on the tip, and I think it turned out pretty well. Some pics.
I worked on some color schemes. All should run cleanly with 4.05. Attached both the dol files and the code.
The first is all normal blue and white for every costume, but this is using the code from Decipio-Carmen
. Perhaps this could be useful for anyone writing a code to toggle between sword swing colors.
The second is the colors from this gif, created by achilles for 3.02 (or maybe earlier), but is now working with Decipio-Carmen's code for 4.05.
The third is the same as the second but with the colors inverted. That is color 1 becomes color 2, so for blue Marth, white is on the hilt of the sword and blue is on the tip. I thought this would give more emphasis on the tip, and I think it turned out pretty well. Some pics.
Could you help me -- I'm wondering how to get it just like 3.02 (so you can toggle in the debug menu between regular and hacked), but I'm kind of confused.
I worked on some color schemes. All should run cleanly with 4.05. Attached both the dol files and the code.
The first is all normal blue and white for every costume, but this is using the code from Decipio-Carmen
. Perhaps this could be useful for anyone writing a code to toggle between sword swing colors.
The second is the colors from this gif, created by achilles for 3.02 (or maybe earlier), but is now working with Decipio-Carmen's code for 4.05.
The third is the same as the second but with the colors inverted. That is color 1 becomes color 2, so for blue Marth, white is on the hilt of the sword and blue is on the tip. I thought this would give more emphasis on the tip, and I think it turned out pretty well. Some pics.
Could you help me -- I'm wondering how to get it just like 3.02 (so you can toggle in the debug menu between regular and hacked), but I'm kind of confused.
I'd really like that too, unfortunately I don't think I'll be a lot of help because I don't understand enough about how the debug menu works. I'll try to make some sense of it though. The good news is that this is a somewhat highly requested feature so achilles may be working to include it again.
I also think it would be neat if there were costume dependent colors for firefox, shine, illusion and lasers for fox and falco and maybe a different up-b poof color for sheik, but maybe that wouldn't be as cool.
I'd really like that too, unfortunately I don't think I'll be a lot of help because I don't understand enough about how the debug menu works. I'll try to make some sense of it though. The good news is that this is a somewhat highly requested feature so achilles may be working to include it again.
I also think it would be neat if there were costume dependent colors for firefox, shine, illusion and lasers for fox and falco and maybe a different up-b poof color for sheik, but maybe that wouldn't be as cool.
Just rewrote and optimized the code. The color changing guide is pretty much the same. Optimizations could be made on a case-by-case basis, but you'd need to know ASM.
Code:
lis r14,-256
ori r14,r14,65535
cmpw r0,r14
bne- Hook
subi r15,r5,7807
lbz r15,0(r15)
cmpwi r15,0
bne- Red
Blue:
lis r3,-13312
ori r3,r3,0
stw r3,16(r5)
lis r3,-256
ori r3,r3,102
lis r0,-256
ori r0,r0,255
b Put
Red:
cmpwi r15,1
bne- Green
li r3,0
ori r3,r3,0
stw r3,16(r5)
lis r3,-256
ori r3,r3,0
lis r0,0
ori r0,r0,35584
b Put
Green:
cmpwi r15,2
bne- Black
lis r3,-256
ori r3,r3,0
stw r3,16(r5)
lis r3,-256
ori r3,r3,33023
lis r0,-22016
ori r0,r0,65535
b Put
Black:
cmpwi r15,3
bne- White
li r3,0
ori r3,r3,0
stw r3,16(r5)
lis r3,-256
ori r3,r3,0
lis r0,0
ori r0,r0,35584
b Put
White:
cmpwi r15,4
bne- Exit
lis r3,-256
ori r3,r3,0
stw r3,16(r5)
lis r3,-193
ori r3,r3,65382
lis r0,-256
ori r0,r0,26316
Put:
stwu r3,8(r5)
stw r0,4(r5)
addi r4,r4,8
lwz r0,4(r4)
addi r5,r5,8
stw r0,4(r5)
b Exit
Hook:
stwu r3,8(r5)
Exit:
Just rewrote and optimized the code. The color changing guide is pretty much the same. Optimizations could be made on a case-by-case basis, but you'd need to know ASM.
Code:
lis r14,-256
ori r14,r14,65535
cmpw r0,r14
bne- Hook
subi r15,r5,7807
lbz r15,0(r15)
cmpwi r15,0
bne- Red
Blue:
lis r3,-13312
ori r3,r3,0
stw r3,16(r5)
lis r3,-256
ori r3,r3,102
lis r0,-256
ori r0,r0,255
b Put
Red:
cmpwi r15,1
bne- Green
li r3,0
ori r3,r3,0
stw r3,16(r5)
lis r3,-256
ori r3,r3,0
lis r0,0
ori r0,r0,35584
b Put
Green:
cmpwi r15,2
bne- Black
lis r3,-256
ori r3,r3,0
stw r3,16(r5)
lis r3,-256
ori r3,r3,33023
lis r0,-22016
ori r0,r0,65535
b Put
Black:
cmpwi r15,3
bne- White
li r3,0
ori r3,r3,0
stw r3,16(r5)
lis r3,-256
ori r3,r3,0
lis r0,0
ori r0,r0,35584
b Put
White:
cmpwi r15,4
bne- Exit
lis r3,-256
ori r3,r3,0
stw r3,16(r5)
lis r3,-193
ori r3,r3,65382
lis r0,-256
ori r0,r0,26316
Put:
stwu r3,8(r5)
stw r0,4(r5)
addi r4,r4,8
lwz r0,4(r4)
addi r5,r5,8
stw r0,4(r5)
b Exit
Hook:
stwu r3,8(r5)
Exit:
Thank you Decipio-Carmen
for the original code and SinsOfApathy
for optimizing it. I really enjoy using this script you have created. However, when I play Black Marth, I like to use the purple skin(R Trigger). How could I go about changing the above script in order to make Black Marth have a Black+Purple sword rather than a Black+Red sword. I could very easily follow Decipio's instructions for changing the colors, but in this optimized script I am having some trouble.
Many thanks,
HoDANG
I’ve been working on a code that conditionally overhauls the sword trail draw and keyframe updates with custom, volatile data--allowing for any character to use sword trails. It’s all meant to take advantage of some advanced features in MCM in order to create a reusable core library--such that additional codes can later be written from it, like custom subaction event syntaxes, or programmable trail states.
In other words, it’s got some big moving parts and is a little… thick. I'm still pulling it apart and putting it back together.
---
I really admire this project you guys have continued to develop. It works entirely inside of the existing allocated player entity for Marth, and so it works cleanly without needing much care.
After staring at sword trails for so long, I wanted to look into simpler options and ended up using some of what I’ve learned to revise this evolving code.
(To make it clear, this is separate from the library I'm writing.)
The resulting optimization was so effective that I scaled it up to include all sword using characters. Krusteaz
Because of the way the data has been formatted, it's also now quite a bit easier to copy/paste hex-colors. Let me know if there are any bugs.
New Code -Costume Dependent Sword Trails (all sword users)
Code:
-==-
Costume Dependent Sword Trail Colors
For all sword users
[Achilles1515, Decipio-Carme, Sins of Apathy, Punkline]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0xE7E74 --- FC000800 -> Branch
7CCB3378 8865E129
8085DB14 38A5FF9C
7D4802A6
bl <CDSC_storeColors>
7D4803A6 7D665B78
FC000800 00000000
----------- 0x1330FC --- 4E800020 -> Branch
8865E169 8085DB54
38A5FFF0 7D4802A6
bl <CDSC_storeColors>
7D4803A6 4E800020
1.01 ----- 0xE7C00 --- FC000800 -> Branch
7CCB3378 8865E129
8085DB14 38A5FF9C
7D4802A6
bl <CDSC_storeColors>
7D4803A6 7D665B78
FC000800 00000000
----------- 0x132E20 --- 4E800020 -> Branch
8865E169 8085DB54
38A5FFF0 7D4802A6
bl <CDSC_storeColors>
7D4803A6 4E800020
1.00 ----- 0xE79CC --- FC000800 -> Branch
7CCB3378 8865E129
8085DB14 38A5FF9C
7D4802A6
bl <CDSC_storeColors>
7D4803A6 7D665B78
FC000800 00000000
----------- 0x132A84 --- 4E800020 -> Branch
8865E169 8085DB54
38A5FFF0 7D4802A6
bl <CDSC_storeColors>
7D4803A6 4E800020
PAL ------- 0xE8628 --- FC000800 -> Branch
7CCB3378 8865E129
8085DB14 38A5FF9C
7D4802A6
bl <CDSC_storeColors>
7D4803A6 7D665B78
FC000800 00000000
----------- 0x1338A0 --- 4E800020 -> Branch
8865E169 8085DB54
38A5FFF0 7D4802A6
bl <CDSC_storeColors>
7D4803A6 4E800020
<CDSC_getData> ALL
4E800021 # blrl
#0x0
# toggle
0000000F # this line stores 4 bits that toggle custom trails by character
# 4 bits = +8=Link, +4=Marth, +2=YLink, +1=Roy
# 0x4
#Ln Mr Yl Ry -- these are CHIDs for the toggles above
06 12 14 1A # this line defines 4 character IDs for the code to allow
# 0x8 - Ln
#Ae As R1G1B1 R2G2B2
FF 00 FFFFFF FFFFFF # 0 - Link NR - Hylian Swordsman
FF 11 ffbf81 ff8000 # 1 - Link Red - Charged Spin Slash
FF 00 d0ffc0 a6f4ee # 2 - Link Blue - Mikau Fins
CC 00 e89393 9e1067 # 3 - Link Black - Poe Wisps
FF 00 f6baba e81d60 # 4 - Link Pink - Lovely Link
# 0x30 - Mr
CC 22 FF40FF 0040FF # 0 - Marth NR - Shield Breaker
FF 00 e48e48 ffdf5d # 1 - Marth Red - Mango Marth
FF 11 c89a50 d8eba5 # 2 - Marth Green - Kiwi Slash
FF 00 F7E183 FFFFFF # 3 - Marth Black - Golden Sting
CC 00 7D77C8 FFFFFF # 4 - Marth White - Pale Lavender
# 0x58 - Yl
FF 00 73c478 daf4c7 # 0 - YLink NR - Kokiri Gale
FF 00 FF0000 FF5010 # 1 - YLink Red - Orange Rupee
FF 11 81ffec 00ffff # 2 - YLink Blue - Spin Slash
FF 11 ede2b8 c9edf2 # 3 - YLink Pink - Pastel Sword
CC 00 430549 c72f19 # 4 - YLink Black - Lense of Truth
# 0x80 - Ry
CC 22 fa4100 f5dd89 # 0 - Roy NR - Fire Blade
FF 00 ae1a2b fdecaa # 1 - Roy Red - Grapefruit Roy
FF 00 f4e9c7 119aa6 # 2 - Roy Blue - Lamplight
FF 00 80FFAA FFFFFF # 3 - Roy Green - Emerald Edge
FF 22 f7f29a FFFFFF # 4 - Roy Yellow - Radiant Swing
# 0xA8
<CDSC_storeColors> ALL
7C0802A6
bl <CDSC_getData>
7CC802A6 7C0803A6
38E00000 39000004
81260000 5D293F39
41820014 7D283A14
7D2930AE 7C092000
41820014 38E70001
2C070004 41810038
4BFFFFD8 1C870028
38840008 54631838
7C841A14 7C843214
88640000 98650000
80640001 90650001
80640005 5463C23E
90650005 4E800020
Code:
-==-
Costume Dependent Sword Trail Colors
For all sword users
[Achilles1515, Decipio-Carme, Sins of Apathy, Punkline]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0x800eb294 --- FC000800 -> Branch
# @ 800eb294 : fcmpu cr0,f0,f1
# r6 holds important data that gets saved in unused r11
# r10 saves LR
# r5 = internal player data offset 0x24F0
# Link/Ylink
mr r11, r6
lbz r3, -0x1ed7(r5) # load costume ID
lwz r4, -0x24EC(r5) # load CHID
subi r5, r5, 0x64 # location of sword trail data start
mflr r10 # save LR
bl <CDSC_storeColors>
mtlr r10
mr r6, r11
fcmpu cr0,f0,f1
.long 0x00000000
----------- 0x8013651c --- 4E800020 -> Branch
# @ 8013651C : blr
# r10 saves LR
# r5 = internal player data offset 0x24B0
# Marth/Roy
lbz r3, -0x1e97(r5) # load costume ID
lwz r4, -0x24AC(r5) # load CHID
subi r5, r5, 0x10 # location of sword trail data start
mflr r10 # save LR
bl <CDSC_storeColors>
mtlr r10
blr
<CDSC_getData> ALL
4E800021 # blrl
#0x0
# toggle
0000000F # this line stores 4 bits that toggle custom trails by character
# 4 bits = +8=Link, +4=Marth, +2=YLink, +1=Roy
# 0x4
#Ln Mr Yl Ry -- these are CHIDs for the toggles above
06 12 14 1A # this line defines 4 character IDs for the code to allow
# 0x8 - Ln
#Ae As R1G1B1 R2G2B2
FF 00 FFFFFF FFFFFF # 0 - Link NR - Hylian Swordsman
FF 11 ffbf81 ff8000 # 1 - Link Red - Charged Spin Slash
FF 00 d0ffc0 a6f4ee # 2 - Link Blue - Mikau Fins
CC 00 e89393 9e1067 # 3 - Link Black - Poe Wisps
FF 00 f6baba e81d60 # 4 - Link Pink - Lovely Link
# 0x30 - Mr
CC 22 FF40FF 0040FF # 0 - Marth NR - Shield Breaker
FF 00 e48e48 ffdf5d # 1 - Marth Red - Mango Marth
FF 11 c89a50 d8eba5 # 2 - Marth Green - Kiwi Slash
FF 00 F7E183 FFFFFF # 3 - Marth Black - Golden Sting
CC 00 7D77C8 FFFFFF # 4 - Marth White - Pale Lavender
# 0x58 - Yl
FF 00 73c478 daf4c7 # 0 - YLink NR - Kokiri Gale
FF 00 FF0000 FF5010 # 1 - YLink Red - Orange Rupee
FF 11 81ffec 00ffff # 2 - YLink Blue - Spin Slash
FF 11 ede2b8 c9edf2 # 3 - YLink Pink - Pastel Sword
CC 00 430549 c72f19 # 4 - YLink Black - Lense of Truth
# 0x80 - Ry
CC 22 fa4100 f5dd89 # 0 - Roy NR - Fire Blade
FF 00 ae1a2b fdecaa # 1 - Roy Red - Grapefruit Roy
FF 00 f4e9c7 119aa6 # 2 - Roy Blue - Lamplight
FF 00 80FFAA FFFFFF # 3 - Roy Green - Emerald Edge
FF 22 f7f29a FFFFFF # 4 - Roy Yellow - Radiant Swing
# 0xA8
<CDSC_storeColors> ALL
# r3 = CSID (costume)
# r4 = CHID (character)
# r5 = location to dump color info
# r10 is deliberately untouched so that it may be used like a saved register by the calling function
mflr r0 # back up lr in r0
bl <CDSC_getData> # this just clobbers the LR with a pointer to our data
mflr r6 # r6 = location of custom color data start
mtlr r0 # restore LR for return
li r7, 0 # loop increment var (becomes ID for CHID if toggle bit is active)
li r8, 4 # start of CHID bytes from r6
#start loop
CHIDindexLoop:
lwz r9, 0(r6) # load toggle bit flags
rlwnm. r9, r9, r7, 28, 28 # check nth flag
beq- nextCHID # if toggle is off, don't load this character
add r9, r8, r7
lbzx r9, r9, r6 # else, load the associated CHID specification
cmpw r9, r4 # compare to passed r4
beq- writeColors # if match, then write corresponding colors
nextCHID:
addi r7, r7, 1
cmpwi r7, 4
bgt- return #if this isn't any of the specified characters, then just return
b CHIDindexLoop # else, try next CHID (there are 4)
#end loop
writeColors:
mulli r4, r7, 0x28 # create a character alignment out of loop count
addi r4, r4, 8 # add 8 to account for toggle and CHID data
slwi r3, r3, 3 # CSID << 3 == 8-byte alignment
add r4, r4, r3 # r4 = final displacement
add r4, r4, r6 # r4 = final pointer
lbz r3, 0(r4) # r3 = 1st byte
stb r3, 0(r5) # store As
lwz r3, 1(r4)
stw r3, 1(r5) # store Ae R1G1B1
lwz r3, 5(r4)
srwi r3, r3, 8
stw r3, 5(r5) # store 00 R2G2B2
return:
blr
I’d also like to offer some notes about creating and using portable data to summarize redundancies in codes without having to rely on static overwrites. Achilles1515Decipio-CarmenSinsOfApathyDRGN
Notes for developers:
Immediate values like those hard-coded into PPC instructions are extremely useful, but on a large enough scale there comes an opportunity to minimize a code by simply representing the hard data as a separate body to be parsed.
5 separate handles that deliver different sets of similarly formatted color information is a perfect example in which the difference between repetitions could be represented by pure data; allowing for a single routine to handle it all in just a handful of instructions.
For example, here's my take on the 2 previous iterations of this code:
And you don't need a static overwrite. I think there might be a common misconception that static overwrites are the only way to store your custom variables outside of the stack. Static overwrites are very useful, especially for creating modular gecko codes; but they are rigid and you may have better options available to you that can be more easily organized.
When it comes to modular codes (meant to coexist alongside other codes in a potentially arbitrary codespace) I think that avoiding static overwrites is a valuable design decision to make if it can be afforded. In many cases (especially where data only needs to be local to your injection code) there are alternatives to programming explicit, static locations of data into your code, and they can be exploited by both gecko codes and MCM DOL mods.
In the ASM I captioned above, I’ve written the handle for designating costume-keyed data to load from a BA that comes from the blrl at the bottom, labeled “getData:”
The “bl” that calls the “getData” label saves its location so that it can be returned to. It immediately hits the blrl we've told it to branch to; which turns it back around to where it came from with a present in the link register that tells us where our data is.
From this little dance, you can retrieve an address local to your code meaning you can store data alongside your instructions. In the case of gecko codes, you can create a table of data local to multiple injections by manually branching to the "blrl + data" table contained within another injection--so long as the injections are submitted together as a single code.
---
With MCM however, there’s an even fancier trick you can do with the “standalone function” feature. Basically, you stuff the “blrl + data” portion of this exploit into a named function, and then any code compiled with MCM can reference it by simply calling it with the special branching syntax:
bl <getData> # this works between ports
This layer of abstraction allows us to encapsulate data in a callable function that MCM then compiles into available code space behind the scenes as needed. Now, at no point do we need to know where this data is located; only that it is named "getData"
If we add handles to another function that use this data in order to work for each sword user (IDs 06=Link, 12=Marth, 14=YLink, 1A=Roy) then all that’s left to port are some tiny injections. The total code size is now ~half data, and almost totally portable:
I think several popular codes would benefit from using portable data like this. I have my eye on Frame Speed Modifiers @Ampers@Tater@Zadamanim
I’ve been working on a code that conditionally overhauls the sword trail draw and keyframe updates with custom, volatile data--allowing for any character to use sword trails. It’s all meant to take advantage of some advanced features in MCM in order to create a reusable core library--such that additional codes can later be written from it, like custom subaction event syntaxes, or programmable trail states.
In other words, it’s got some big moving parts and is a little… thick. I'm still pulling it apart and putting it back together.
---
I really admire this project you guys have continued to develop. It works entirely inside of the existing allocated player entity for Marth, and so it works cleanly without needing much care.
After staring at sword trails for so long, I wanted to look into simpler options and ended up using some of what I’ve learned to revise this evolving code.
(To make it clear, this is separate from the library I'm writing.)
The resulting optimization was so effective that I scaled it up to include all sword using characters. Krusteaz
Because of the way the data has been formatted, it's also now quite a bit easier to copy/paste hex-colors. Let me know if there are any bugs.
New Code -Costume Dependent Sword Trails (all sword users)
Code:
-==-
Costume Dependent Sword Trail Colors
For all sword users
[Achilles1515, Decipio-Carme, Sins of Apathy, Punkline]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0xE7E74 --- FC000800 -> Branch
7CCB3378 8865E129
8085DB14 38A5FF9C
7D4802A6
bl <CDSC_storeColors>
7D4803A6 7D665B78
FC000800 00000000
----------- 0x1330FC --- 4E800020 -> Branch
8865E169 8085DB54
38A5FFF0 7D4802A6
bl <CDSC_storeColors>
7D4803A6 4E800020
1.01 ----- 0xE7C00 --- FC000800 -> Branch
7CCB3378 8865E129
8085DB14 38A5FF9C
7D4802A6
bl <CDSC_storeColors>
7D4803A6 7D665B78
FC000800 00000000
----------- 0x132E20 --- 4E800020 -> Branch
8865E169 8085DB54
38A5FFF0 7D4802A6
bl <CDSC_storeColors>
7D4803A6 4E800020
1.00 ----- 0xE79CC --- FC000800 -> Branch
7CCB3378 8865E129
8085DB14 38A5FF9C
7D4802A6
bl <CDSC_storeColors>
7D4803A6 7D665B78
FC000800 00000000
----------- 0x132A84 --- 4E800020 -> Branch
8865E169 8085DB54
38A5FFF0 7D4802A6
bl <CDSC_storeColors>
7D4803A6 4E800020
PAL ------- 0xE8628 --- FC000800 -> Branch
7CCB3378 8865E129
8085DB14 38A5FF9C
7D4802A6
bl <CDSC_storeColors>
7D4803A6 7D665B78
FC000800 00000000
----------- 0x1338A0 --- 4E800020 -> Branch
8865E169 8085DB54
38A5FFF0 7D4802A6
bl <CDSC_storeColors>
7D4803A6 4E800020
<CDSC_getData> ALL
4E800021 # blrl
#0x0
# toggle
0000000F # this line stores 4 bits that toggle custom trails by character
# 4 bits = +8=Link, +4=Marth, +2=YLink, +1=Roy
# 0x4
#Ln Mr Yl Ry -- these are CHIDs for the toggles above
06 12 14 1A # this line defines 4 character IDs for the code to allow
# 0x8 - Ln
#Ae As R1G1B1 R2G2B2
FF 00 FFFFFF FFFFFF # 0 - Link NR - Hylian Swordsman
FF 11 ffbf81 ff8000 # 1 - Link Red - Charged Spin Slash
FF 00 d0ffc0 a6f4ee # 2 - Link Blue - Mikau Fins
CC 00 e89393 9e1067 # 3 - Link Black - Poe Wisps
FF 00 f6baba e81d60 # 4 - Link Pink - Lovely Link
# 0x30 - Mr
CC 22 FF40FF 0040FF # 0 - Marth NR - Shield Breaker
FF 00 e48e48 ffdf5d # 1 - Marth Red - Mango Marth
FF 11 c89a50 d8eba5 # 2 - Marth Green - Kiwi Slash
FF 00 F7E183 FFFFFF # 3 - Marth Black - Golden Sting
CC 00 7D77C8 FFFFFF # 4 - Marth White - Pale Lavender
# 0x58 - Yl
FF 00 73c478 daf4c7 # 0 - YLink NR - Kokiri Gale
FF 00 FF0000 FF5010 # 1 - YLink Red - Orange Rupee
FF 11 81ffec 00ffff # 2 - YLink Blue - Spin Slash
FF 11 ede2b8 c9edf2 # 3 - YLink Pink - Pastel Sword
CC 00 430549 c72f19 # 4 - YLink Black - Lense of Truth
# 0x80 - Ry
CC 22 fa4100 f5dd89 # 0 - Roy NR - Fire Blade
FF 00 ae1a2b fdecaa # 1 - Roy Red - Grapefruit Roy
FF 00 f4e9c7 119aa6 # 2 - Roy Blue - Lamplight
FF 00 80FFAA FFFFFF # 3 - Roy Green - Emerald Edge
FF 22 f7f29a FFFFFF # 4 - Roy Yellow - Radiant Swing
# 0xA8
<CDSC_storeColors> ALL
7C0802A6
bl <CDSC_getData>
7CC802A6 7C0803A6
38E00000 39000004
81260000 5D293F39
41820014 7D283A14
7D2930AE 7C092000
41820014 38E70001
2C070004 41810038
4BFFFFD8 1C870028
38840008 54631838
7C841A14 7C843214
88640000 98650000
80640001 90650001
80640005 5463C23E
90650005 4E800020
Code:
-==-
Costume Dependent Sword Trail Colors
For all sword users
[Achilles1515, Decipio-Carme, Sins of Apathy, Punkline]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0x800eb294 --- FC000800 -> Branch
# @ 800eb294 : fcmpu cr0,f0,f1
# r6 holds important data that gets saved in unused r11
# r10 saves LR
# r5 = internal player data offset 0x24F0
# Link/Ylink
mr r11, r6
lbz r3, -0x1ed7(r5) # load costume ID
lwz r4, -0x24EC(r5) # load CHID
subi r5, r5, 0x64 # location of sword trail data start
mflr r10 # save LR
bl <CDSC_storeColors>
mtlr r10
mr r6, r11
fcmpu cr0,f0,f1
.long 0x00000000
----------- 0x8013651c --- 4E800020 -> Branch
# @ 8013651C : blr
# r10 saves LR
# r5 = internal player data offset 0x24B0
# Marth/Roy
lbz r3, -0x1e97(r5) # load costume ID
lwz r4, -0x24AC(r5) # load CHID
subi r5, r5, 0x10 # location of sword trail data start
mflr r10 # save LR
bl <CDSC_storeColors>
mtlr r10
blr
<CDSC_getData> ALL
4E800021 # blrl
#0x0
# toggle
0000000F # this line stores 4 bits that toggle custom trails by character
# 4 bits = +8=Link, +4=Marth, +2=YLink, +1=Roy
# 0x4
#Ln Mr Yl Ry -- these are CHIDs for the toggles above
06 12 14 1A # this line defines 4 character IDs for the code to allow
# 0x8 - Ln
#Ae As R1G1B1 R2G2B2
FF 00 FFFFFF FFFFFF # 0 - Link NR - Hylian Swordsman
FF 11 ffbf81 ff8000 # 1 - Link Red - Charged Spin Slash
FF 00 d0ffc0 a6f4ee # 2 - Link Blue - Mikau Fins
CC 00 e89393 9e1067 # 3 - Link Black - Poe Wisps
FF 00 f6baba e81d60 # 4 - Link Pink - Lovely Link
# 0x30 - Mr
CC 22 FF40FF 0040FF # 0 - Marth NR - Shield Breaker
FF 00 e48e48 ffdf5d # 1 - Marth Red - Mango Marth
FF 11 c89a50 d8eba5 # 2 - Marth Green - Kiwi Slash
FF 00 F7E183 FFFFFF # 3 - Marth Black - Golden Sting
CC 00 7D77C8 FFFFFF # 4 - Marth White - Pale Lavender
# 0x58 - Yl
FF 00 73c478 daf4c7 # 0 - YLink NR - Kokiri Gale
FF 00 FF0000 FF5010 # 1 - YLink Red - Orange Rupee
FF 11 81ffec 00ffff # 2 - YLink Blue - Spin Slash
FF 11 ede2b8 c9edf2 # 3 - YLink Pink - Pastel Sword
CC 00 430549 c72f19 # 4 - YLink Black - Lense of Truth
# 0x80 - Ry
CC 22 fa4100 f5dd89 # 0 - Roy NR - Fire Blade
FF 00 ae1a2b fdecaa # 1 - Roy Red - Grapefruit Roy
FF 00 f4e9c7 119aa6 # 2 - Roy Blue - Lamplight
FF 00 80FFAA FFFFFF # 3 - Roy Green - Emerald Edge
FF 22 f7f29a FFFFFF # 4 - Roy Yellow - Radiant Swing
# 0xA8
<CDSC_storeColors> ALL
# r3 = CSID (costume)
# r4 = CHID (character)
# r5 = location to dump color info
# r10 is deliberately untouched so that it may be used like a saved register by the calling function
mflr r0 # back up lr in r0
bl <CDSC_getData> # this just clobbers the LR with a pointer to our data
mflr r6 # r6 = location of custom color data start
mtlr r0 # restore LR for return
li r7, 0 # loop increment var (becomes ID for CHID if toggle bit is active)
li r8, 4 # start of CHID bytes from r6
#start loop
CHIDindexLoop:
lwz r9, 0(r6) # load toggle bit flags
rlwnm. r9, r9, r7, 28, 28 # check nth flag
beq- nextCHID # if toggle is off, don't load this character
add r9, r8, r7
lbzx r9, r9, r6 # else, load the associated CHID specification
cmpw r9, r4 # compare to passed r4
beq- writeColors # if match, then write corresponding colors
nextCHID:
addi r7, r7, 1
cmpwi r7, 4
bgt- return #if this isn't any of the specified characters, then just return
b CHIDindexLoop # else, try next CHID (there are 4)
#end loop
writeColors:
mulli r4, r7, 0x28 # create a character alignment out of loop count
addi r4, r4, 8 # add 8 to account for toggle and CHID data
slwi r3, r3, 3 # CSID << 3 == 8-byte alignment
add r4, r4, r3 # r4 = final displacement
add r4, r4, r6 # r4 = final pointer
lbz r3, 0(r4) # r3 = 1st byte
stb r3, 0(r5) # store As
lwz r3, 1(r4)
stw r3, 1(r5) # store Ae R1G1B1
lwz r3, 5(r4)
srwi r3, r3, 8
stw r3, 5(r5) # store 00 R2G2B2
return:
blr
I’d also like to offer some notes about creating and using portable data to summarize redundancies in codes without having to rely on static overwrites. Achilles1515Decipio-CarmenSinsOfApathyDRGN
Notes for developers:
Immediate values like those hard-coded into PPC instructions are extremely useful, but on a large enough scale there comes an opportunity to minimize a code by simply representing the hard data as a separate body to be parsed.
5 separate handles that deliver different sets of similarly formatted color information is a perfect example in which the difference between repetitions could be represented by pure data; allowing for a single routine to handle it all in just a handful of instructions.
For example, here's my take on the 2 previous iterations of this code:
And you don't need a static overwrite. I think there might be a common misconception that static overwrites are the only way to store your custom variables outside of the stack. Static overwrites are very useful, especially for creating modular gecko codes; but they are rigid and you may have better options available to you that can be more easily organized.
When it comes to modular codes (meant to coexist alongside other codes in a potentially arbitrary codespace) I think that avoiding static overwrites is a valuable design decision to make if it can be afforded. In many cases (especially where data only needs to be local to your injection code) there are alternatives to programming explicit, static locations of data into your code, and they can be exploited by both gecko codes and MCM DOL mods.
In the ASM I captioned above, I’ve written the handle for designating costume-keyed data to load from a BA that comes from the blrl at the bottom, labeled “getData:”
The “bl” that calls the “getData” label saves its location so that it can be returned to. It immediately hits the blrl we've told it to branch to; which turns it back around to where it came from with a present in the link register that tells us where our data is.
From this little dance, you can retrieve an address local to your code meaning you can store data alongside your instructions. In the case of gecko codes, you can create a table of data local to multiple injections by manually branching to the "blrl + data" table contained within another injection--so long as the injections are submitted together as a single code.
---
With MCM however, there’s an even fancier trick you can do with the “standalone function” feature. Basically, you stuff the “blrl + data” portion of this exploit into a named function, and then any code compiled with MCM can reference it by simply calling it with the special branching syntax:
bl <getData> # this works between ports
This layer of abstraction allows us to encapsulate data in a callable function that MCM then compiles into available code space behind the scenes as needed. Now, at no point do we need to know where this data is located; only that it is named "getData"
If we add handles to another function that use this data in order to work for each sword user (IDs 06=Link, 12=Marth, 14=YLink, 1A=Roy) then all that’s left to port are some tiny injections. The total code size is now ~half data, and almost totally portable:
I think several popular codes would benefit from using portable data like this. I have my eye on Frame Speed Modifiers @Ampers@Tater@Zadamanim
I thought about posting my following idea as a new "request" thread, but I think it makes more sense to go here, so it can follow some of the history of this code's variations and evolution. I would have liked to write this myself, but between work, school, DTW upgrades, and other Melee projects as-of-yet unreleased, I don't have much time. But I'd like to quickly share the idea! It's been one of those ideas burning a hole in my head for too long. And perhaps we could even see it implemented in the next version of 20XX. Some of you guys already know the instruction set really well, and so someone else would probably be able to write it quicker/more-efficiently than me anyways.
Anyway....
I propose we modify one of the above codes in this thread so that instead of reading from a central, pre-built table, it reads from a bit of data located at the end of character DAT files. This has several advantages:
1) Every single costume could have its own set of colors, rather than several costumes sharing colors
2) This would save space in the DOL or wherever else you might've wanted to store the look-up table
3) Costume designers would then have control to have their costume release with their chosen colors for that costume
4) Swapping costumes in your game is then hassle-free because you don't have to update sword colors
5) Even easier to set the colors if the color format is changed a bit for the bit of data
The bit of data could look something like this:
With the colors being in RRGGBBAA format (so above is a light red, followed by white).
This would be loaded into RAM with the rest of the file as long as the header is updated with the new file length. The code would check this location, and if there is a string there like this (we could have semething shorter if we really care that much about these few bytes), then it reads and uses the color data given there. If it doesn't find anything there, the code could just use the game's default values, or maybe a default for that color slot (I'm leaning toward the former). The "if" statement is quite an important note, so that this code could be added to any game without problems, by making it backwards-compatible with existing costumes, and simply making it an option for new costumes. This bit of data is a standard we would need to define and agree on. So if you like this idea and have a better suggestion for the "identification string", post your ideas. It might be useful if the color data is aligned to 4 bytes (which I just realized it isn't in my example).
This same logic could be applied to spacies' lazers, shines, Falcon Punch colors, Ness Up-B colors, etc., opening up a ton of customization options for costumes.
I thought about posting my following idea as a new "request" thread, but I think it makes more sense to go here, so it can follow some of the history of this code's variations and evolution. I would have liked to write this myself, but between work, school, DTW upgrades, and other Melee projects as-of-yet unreleased, I don't have much time. But I'd like to quickly share the idea! It's been one of those ideas burning a hole in my head for too long. And perhaps we could even see it implemented in the next version of 20XX. Some of you guys already know the instruction set really well, and so someone else would probably be able to write it quicker/more-efficiently than me anyways.
Anyway....
I propose we modify one of the above codes in this thread so that instead of reading from a central, pre-built table, it reads from a bit of data located at the end of character DAT files. This has several advantages:
1) Every single costume could have its own set of colors, rather than several costumes sharing colors
2) This would save space in the DOL or wherever else you might've wanted to store the look-up table
3) Costume designers would then have control to have their costume release with their chosen colors for that costume
4) Swapping costumes in your game is then hassle-free because you don't have to update sword colors
5) Even easier to set the colors if the color format is changed a bit for the bit of data
With the colors being in RRGGBBAA format (so above is a light red, followed by white).
This would be loaded into RAM with the rest of the file as long as the header is updated with the new file length. The code would check this location, and if there is a string there like this (we could have semething shorter if we really care that much about these few bytes), then it reads and uses the color data given there. If it doesn't find anything there, the code could just use the game's default values, or maybe a default for that color slot (I'm leaning toward the former). The "if" statement is quite an important note, so that this code could be added to any game without problems, by making it backwards-compatible with existing costumes, and simply making it an option for new costumes. This bit of data is a standard we would need to define and agree on. So if you like this idea and have a better suggestion for the "identification string", post your ideas. It might be useful if the color data is aligned to 4 bytes (which I just realized it isn't in my example).
This same logic could be applied to spacies' lazers, shines, Falcon Punch colors, Ness Up-B colors, etc., opening up a ton of customization options for costumes.
Testing it now real quick on a mostly vanilla ISO.
Edit: Nope. Not working. Looks like it's not calculating the file's ending offset correctly. Right now the code is looking at offset 0x81215330, while the file's actual end is at 0x8126F51F (end of the "bit of data", not the original end of the file).
Edit 2: I made an infographic for the data format to help others:
Testing it now real quick on a mostly vanilla ISO.
Edit: Nope. Not working. Looks like it's not calculating the file's ending offset correctly. Right now the code is looking at offset 0x81215330, while the file's actual end is at 0x8126F51F (end of the "bit of data", not the original end of the file).
Sweet! Seems to be working... I think? I'm not 100% sure because the colors weren't what I expected. But taking a second look at the code, I realized the color format wasn't what I thought it was. I'll have to boot the game again to double check that the colors were actually correct (can't right now though), but they were changing when they were supposed to, and of course not when they weren't. For both Marth and Roy. When I set up 20XX's per-costume sword swing colors, I'll double check that the colors are actually correct. This is really cool though!
For the color format, I know they're both for alpha, but what do the e and s in Ae and As represent? And for the finished code, what do you think of using R1G1B1A1, R2G2B2A2? For simplicity and consistency with colors used elsewhere in Melee.
Sweet! Seems to be working... I think? I'm not 100% sure because the colors weren't what I expected. But taking a second look at the code, I realized the color format wasn't what I thought it was. I'll have to boot the game again to double check that the colors were actually correct (can't right now though), but they were changing when they were supposed to, and of course not when they weren't. For both Marth and Roy. When I set up 20XX's per-costume sword swing colors, I'll double check that the colors are actually correct. This is really cool though!
For the color format, I know they're both for alpha, but what do the e and s in Ae and As represent? And for the finished code, what do you think of using R1G1B1A1, R2G2B2A2? For simplicity and consistency with colors used elsewhere in Melee.
I didn't format it RGBA (and I'm assuming why Punkline didn't) because the alpha does not correspond to the RGB. It's the alpha for a portion of the trail that contains color1 and color2 (start and end). You'll see what I mean by swapping the two alphas. So make the first two bytes 00FF.
I didn't format it RGBA (and I'm assuming why Punkline didn't) because the alpha does not correspond to the RGB. It's the alpha for a portion of the trail that contains color1 and color2 (start and end). You'll see what I mean by swapping the two alphas. So make the first two bytes 00FF.
Yes, there are 2 different axes. 1 for color, 1 for alpha.
the color is a "tip" to "base" relationship, where the alpha is a "trail start" to "trail end" relationship.
The loop that calculates this is in the sword trail draw function. I've only looked at the resulting array of RGBA vertex pairs in the stack from the context of a breakpoint at 800c2da4:
With this in mind, the format technically supports 4-color RGBA interpolations, but the loop that interpolates the colors from the given parameters are what limit the options.
---
This concept you guys are cooking up is really amazing, btw. I had some input about other variables that might be useful to include in a code like this, but I didn't really know how to explain any of it very well. I made another thread detailing an experiment I went over back in october that works with sword trail data in a non-destructive way--a bit different than what's going on here. It deals with the some of the same variables though.
There's a little section in the sword-using characters' article data offsets that resembles this table I covered in another set of notes about sword trails:
Sword trail parameters describe variables that can be used to change the way sword trails are calculated and drawn. Similar data structures exist for drawing beamsword trails, though the keyframe data is handled a bit differently in order to animate the length of the trail vertices.
For normal player sword trails, a silly ctr-based structure exists in both the draw/keyframe update functions and is responsible for designating where in the player entity default sword trail article data has been loaded. The list is keyed to the internal character index, but only for the range that includes sword users.
The non-sword users included in this list will causes erroneous/inappropriate use of the C4 event to potentially read arbitrary data in place of a real structure; which may end up crashing if forced. With some small steps however, this routine can be exploited to read data from wherever; thereby allowing (in theory) for every character to have a “normal” sword trail so long it can be reliably pointed to during the course of each update.
The following absurd ctr-based pointer structure could feasibly be exploited to give a wide selection of characters default handles for these fake “normal” sword trail parameters; though without a bit of function surgery, this would exclude the 6 characters at the beginning of the internal character roster, as well as all boss/wireframe characters. (if anyone’s interested, I have details on some tested methods of getting around this)
The point of this mess is to produce a pointer to a formatted character-specific data structure that can be handled by a single routine. This messy control structure exists in both the sword trail keyframe update and draw functions, where the resulting routine handles the keyframe/draw according to the provided parameters.
I’ve been calling this common data structure “Sword Trail Parameters” and they are comprised of 2 tables used separately for each routine.
The game uses the pointer at internal player data offset 0x2D4 to access these character-specific parameters for sword users after a player has been properly instantiated. My understanding is that Dantarion’s notes describe these as “Article Floating Points.”
---
Inside of a player entity, vanilla sword trail parameters can be accessed like so: Marth/Roy = internal player data offset 0x2D4 -> 0x78 Link/YLink = internal player data offset 0x2D4 -> 0x64
As proven effective by codes like costume dependent marth sword trail colors, the functionally equivalent internal player data offsets seem to be: 0x2498 = Marth/Roy sword trail data 0x2484 = Link/Ylink sword trail data
The data is formatted like so:
-- For draw update -- 0x00 - float - Trail End Taper Coefficient 1 (assumed to be % of player 0x20F8) 0x04 - float - Trail End Taper Coefficient 2 (assumed to be % of player 0x20FC) 0x08 - AOB[2] - Starting Alpha, Ending Alpha (opacity of trail from newest to oldest keyframe) 0x0A - AOB[3] - R1, G1, B1 (color channels for gradient color in vertex 1) 0x0E - AOB[3] - R2, G2, B2 (color channels for gradient color in vertex 2)
(bytes missing from this specification appear to be unparsed)
-- For keyframe update, non-beamsword only-- 0x14 - word - Player Bone attachment (boneID) 0x18 - float - pole vertex 1 (used for 0x20F8 assignment in non-beamsword trails) 0x1C - float - pole vertex 2 (used for 0x20FC)
The offsets at the bottom of the spoiler in that quote describe the full set of parameters that could be fit into file data without much extra code. Any of these may be edited (destructively) for immediate effects, but the respawn mechanic will clobber any modifications. I presume this is why the code was originally created with a hook in the function that initializes article data for Marth.
Edit - If the data were included in a way that was already formatted, we might be able to even further minimize the code by reducing it to a simple call to memcpy, while also allowing for these other variables to become costume-dependant arguments.
I updated the OP and included instructions on how to add SinsOfApathy
's optimized version of my code to a 20XX 4.06 ISO. Let me know if I made any mistakes.
Punkline
Is the Costume Dependent Sword Trails Colors code for all sword users that you wrote compatible with MCM v2.0? I had to use MCM v2.0 so that I could use the settings.py from Achilles' 20XX 4.06 github repository.
When I try adding the code in the 'MCM mod (all ports)' spoiler, I get errors when I load MCM v2.0:
Code:
Non-hex characters were found in the code for Costume Dependent Sword Trail Colors
(on line 64: <CDSC_getData> ALL).
(Error Code 05)
So, I tried creating the following MCM code based off the 1.02 Gecko Code you posted:
-==-
Costume Dependent Sword Trail Colors
Adds costume dependent sword trail colors for all sword users
[Punkline, Achilles1515, Decipio-Carmen, SinsOfApathy]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0x800EB294 --- FC000800 -> Branch
I tried using MCM v2.0 to add that to my 20XX 4.06 ISO and I get an error when I try to start a game:
Code:
IntCPU: Unknown instruction 00000000 at PC = 4e800020 last_PC = 81200cf0 LR = 80394b74
Next I tried using MCM v2.0 to add the above MCM code to an otherwise unmodified vanilla 1.02 ISO and got some unknown instruction warnings, and it wouldn't let me load the ISO.
I was using Dolphin 5.0 and made sure all my other Gecko Codes were disabled, but I feel like the above MCM code is probably wrong.
I’ve been working on a code that conditionally overhauls the sword trail draw and keyframe updates with custom, volatile data--allowing for any character to use sword trails. It’s all meant to take advantage of some advanced features in MCM in order to create a reusable core library--such that additional codes can later be written from it, like custom subaction event syntaxes, or programmable trail states.
In other words, it’s got some big moving parts and is a little… thick. I'm still pulling it apart and putting it back together.
---
I really admire this project you guys have continued to develop. It works entirely inside of the existing allocated player entity for Marth, and so it works cleanly without needing much care.
After staring at sword trails for so long, I wanted to look into simpler options and ended up using some of what I’ve learned to revise this evolving code.
(To make it clear, this is separate from the library I'm writing.)
The resulting optimization was so effective that I scaled it up to include all sword using characters. Krusteaz
Because of the way the data has been formatted, it's also now quite a bit easier to copy/paste hex-colors. Let me know if there are any bugs.
New Code -Costume Dependent Sword Trails (all sword users)
Code:
-==-
Costume Dependent Sword Trail Colors
For all sword users
[Achilles1515, Decipio-Carme, Sins of Apathy, Punkline]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0xE7E74 --- FC000800 -> Branch
7CCB3378 8865E129
8085DB14 38A5FF9C
7D4802A6
bl <CDSC_storeColors>
7D4803A6 7D665B78
FC000800 00000000
----------- 0x1330FC --- 4E800020 -> Branch
8865E169 8085DB54
38A5FFF0 7D4802A6
bl <CDSC_storeColors>
7D4803A6 4E800020
1.01 ----- 0xE7C00 --- FC000800 -> Branch
7CCB3378 8865E129
8085DB14 38A5FF9C
7D4802A6
bl <CDSC_storeColors>
7D4803A6 7D665B78
FC000800 00000000
----------- 0x132E20 --- 4E800020 -> Branch
8865E169 8085DB54
38A5FFF0 7D4802A6
bl <CDSC_storeColors>
7D4803A6 4E800020
1.00 ----- 0xE79CC --- FC000800 -> Branch
7CCB3378 8865E129
8085DB14 38A5FF9C
7D4802A6
bl <CDSC_storeColors>
7D4803A6 7D665B78
FC000800 00000000
----------- 0x132A84 --- 4E800020 -> Branch
8865E169 8085DB54
38A5FFF0 7D4802A6
bl <CDSC_storeColors>
7D4803A6 4E800020
PAL ------- 0xE8628 --- FC000800 -> Branch
7CCB3378 8865E129
8085DB14 38A5FF9C
7D4802A6
bl <CDSC_storeColors>
7D4803A6 7D665B78
FC000800 00000000
----------- 0x1338A0 --- 4E800020 -> Branch
8865E169 8085DB54
38A5FFF0 7D4802A6
bl <CDSC_storeColors>
7D4803A6 4E800020
<CDSC_getData> ALL
4E800021 # blrl
#0x0
# toggle
0000000F # this line stores 4 bits that toggle custom trails by character
# 4 bits = +8=Link, +4=Marth, +2=YLink, +1=Roy
# 0x4
#Ln Mr Yl Ry -- these are CHIDs for the toggles above
06 12 14 1A # this line defines 4 character IDs for the code to allow
# 0x8 - Ln
#Ae As R1G1B1 R2G2B2
FF 00 FFFFFF FFFFFF # 0 - Link NR - Hylian Swordsman
FF 11 ffbf81 ff8000 # 1 - Link Red - Charged Spin Slash
FF 00 d0ffc0 a6f4ee # 2 - Link Blue - Mikau Fins
CC 00 e89393 9e1067 # 3 - Link Black - Poe Wisps
FF 00 f6baba e81d60 # 4 - Link Pink - Lovely Link
# 0x30 - Mr
CC 22 FF40FF 0040FF # 0 - Marth NR - Shield Breaker
FF 00 e48e48 ffdf5d # 1 - Marth Red - Mango Marth
FF 11 c89a50 d8eba5 # 2 - Marth Green - Kiwi Slash
FF 00 F7E183 FFFFFF # 3 - Marth Black - Golden Sting
CC 00 7D77C8 FFFFFF # 4 - Marth White - Pale Lavender
# 0x58 - Yl
FF 00 73c478 daf4c7 # 0 - YLink NR - Kokiri Gale
FF 00 FF0000 FF5010 # 1 - YLink Red - Orange Rupee
FF 11 81ffec 00ffff # 2 - YLink Blue - Spin Slash
FF 11 ede2b8 c9edf2 # 3 - YLink Pink - Pastel Sword
CC 00 430549 c72f19 # 4 - YLink Black - Lense of Truth
# 0x80 - Ry
CC 22 fa4100 f5dd89 # 0 - Roy NR - Fire Blade
FF 00 ae1a2b fdecaa # 1 - Roy Red - Grapefruit Roy
FF 00 f4e9c7 119aa6 # 2 - Roy Blue - Lamplight
FF 00 80FFAA FFFFFF # 3 - Roy Green - Emerald Edge
FF 22 f7f29a FFFFFF # 4 - Roy Yellow - Radiant Swing
# 0xA8
<CDSC_storeColors> ALL
7C0802A6
bl <CDSC_getData>
7CC802A6 7C0803A6
38E00000 39000004
81260000 5D293F39
41820014 7D283A14
7D2930AE 7C092000
41820014 38E70001
2C070004 41810038
4BFFFFD8 1C870028
38840008 54631838
7C841A14 7C843214
88640000 98650000
80640001 90650001
80640005 5463C23E
90650005 4E800020
Code:
-==-
Costume Dependent Sword Trail Colors
For all sword users
[Achilles1515, Decipio-Carme, Sins of Apathy, Punkline]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0x800eb294 --- FC000800 -> Branch
# @ 800eb294 : fcmpu cr0,f0,f1
# r6 holds important data that gets saved in unused r11
# r10 saves LR
# r5 = internal player data offset 0x24F0
# Link/Ylink
mr r11, r6
lbz r3, -0x1ed7(r5) # load costume ID
lwz r4, -0x24EC(r5) # load CHID
subi r5, r5, 0x64 # location of sword trail data start
mflr r10 # save LR
bl <CDSC_storeColors>
mtlr r10
mr r6, r11
fcmpu cr0,f0,f1
.long 0x00000000
----------- 0x8013651c --- 4E800020 -> Branch
# @ 8013651C : blr
# r10 saves LR
# r5 = internal player data offset 0x24B0
# Marth/Roy
lbz r3, -0x1e97(r5) # load costume ID
lwz r4, -0x24AC(r5) # load CHID
subi r5, r5, 0x10 # location of sword trail data start
mflr r10 # save LR
bl <CDSC_storeColors>
mtlr r10
blr
<CDSC_getData> ALL
4E800021 # blrl
#0x0
# toggle
0000000F # this line stores 4 bits that toggle custom trails by character
# 4 bits = +8=Link, +4=Marth, +2=YLink, +1=Roy
# 0x4
#Ln Mr Yl Ry -- these are CHIDs for the toggles above
06 12 14 1A # this line defines 4 character IDs for the code to allow
# 0x8 - Ln
#Ae As R1G1B1 R2G2B2
FF 00 FFFFFF FFFFFF # 0 - Link NR - Hylian Swordsman
FF 11 ffbf81 ff8000 # 1 - Link Red - Charged Spin Slash
FF 00 d0ffc0 a6f4ee # 2 - Link Blue - Mikau Fins
CC 00 e89393 9e1067 # 3 - Link Black - Poe Wisps
FF 00 f6baba e81d60 # 4 - Link Pink - Lovely Link
# 0x30 - Mr
CC 22 FF40FF 0040FF # 0 - Marth NR - Shield Breaker
FF 00 e48e48 ffdf5d # 1 - Marth Red - Mango Marth
FF 11 c89a50 d8eba5 # 2 - Marth Green - Kiwi Slash
FF 00 F7E183 FFFFFF # 3 - Marth Black - Golden Sting
CC 00 7D77C8 FFFFFF # 4 - Marth White - Pale Lavender
# 0x58 - Yl
FF 00 73c478 daf4c7 # 0 - YLink NR - Kokiri Gale
FF 00 FF0000 FF5010 # 1 - YLink Red - Orange Rupee
FF 11 81ffec 00ffff # 2 - YLink Blue - Spin Slash
FF 11 ede2b8 c9edf2 # 3 - YLink Pink - Pastel Sword
CC 00 430549 c72f19 # 4 - YLink Black - Lense of Truth
# 0x80 - Ry
CC 22 fa4100 f5dd89 # 0 - Roy NR - Fire Blade
FF 00 ae1a2b fdecaa # 1 - Roy Red - Grapefruit Roy
FF 00 f4e9c7 119aa6 # 2 - Roy Blue - Lamplight
FF 00 80FFAA FFFFFF # 3 - Roy Green - Emerald Edge
FF 22 f7f29a FFFFFF # 4 - Roy Yellow - Radiant Swing
# 0xA8
<CDSC_storeColors> ALL
# r3 = CSID (costume)
# r4 = CHID (character)
# r5 = location to dump color info
# r10 is deliberately untouched so that it may be used like a saved register by the calling function
mflr r0 # back up lr in r0
bl <CDSC_getData> # this just clobbers the LR with a pointer to our data
mflr r6 # r6 = location of custom color data start
mtlr r0 # restore LR for return
li r7, 0 # loop increment var (becomes ID for CHID if toggle bit is active)
li r8, 4 # start of CHID bytes from r6
#start loop
CHIDindexLoop:
lwz r9, 0(r6) # load toggle bit flags
rlwnm. r9, r9, r7, 28, 28 # check nth flag
beq- nextCHID # if toggle is off, don't load this character
add r9, r8, r7
lbzx r9, r9, r6 # else, load the associated CHID specification
cmpw r9, r4 # compare to passed r4
beq- writeColors # if match, then write corresponding colors
nextCHID:
addi r7, r7, 1
cmpwi r7, 4
bgt- return #if this isn't any of the specified characters, then just return
b CHIDindexLoop # else, try next CHID (there are 4)
#end loop
writeColors:
mulli r4, r7, 0x28 # create a character alignment out of loop count
addi r4, r4, 8 # add 8 to account for toggle and CHID data
slwi r3, r3, 3 # CSID << 3 == 8-byte alignment
add r4, r4, r3 # r4 = final displacement
add r4, r4, r6 # r4 = final pointer
lbz r3, 0(r4) # r3 = 1st byte
stb r3, 0(r5) # store As
lwz r3, 1(r4)
stw r3, 1(r5) # store Ae R1G1B1
lwz r3, 5(r4)
srwi r3, r3, 8
stw r3, 5(r5) # store 00 R2G2B2
return:
blr
I’d also like to offer some notes about creating and using portable data to summarize redundancies in codes without having to rely on static overwrites. Achilles1515Decipio-CarmenSinsOfApathyDRGN
Notes for developers:
Immediate values like those hard-coded into PPC instructions are extremely useful, but on a large enough scale there comes an opportunity to minimize a code by simply representing the hard data as a separate body to be parsed.
5 separate handles that deliver different sets of similarly formatted color information is a perfect example in which the difference between repetitions could be represented by pure data; allowing for a single routine to handle it all in just a handful of instructions.
For example, here's my take on the 2 previous iterations of this code:
And you don't need a static overwrite. I think there might be a common misconception that static overwrites are the only way to store your custom variables outside of the stack. Static overwrites are very useful, especially for creating modular gecko codes; but they are rigid and you may have better options available to you that can be more easily organized.
When it comes to modular codes (meant to coexist alongside other codes in a potentially arbitrary codespace) I think that avoiding static overwrites is a valuable design decision to make if it can be afforded. In many cases (especially where data only needs to be local to your injection code) there are alternatives to programming explicit, static locations of data into your code, and they can be exploited by both gecko codes and MCM DOL mods.
In the ASM I captioned above, I’ve written the handle for designating costume-keyed data to load from a BA that comes from the blrl at the bottom, labeled “getData:”
The “bl” that calls the “getData” label saves its location so that it can be returned to. It immediately hits the blrl we've told it to branch to; which turns it back around to where it came from with a present in the link register that tells us where our data is.
From this little dance, you can retrieve an address local to your code meaning you can store data alongside your instructions. In the case of gecko codes, you can create a table of data local to multiple injections by manually branching to the "blrl + data" table contained within another injection--so long as the injections are submitted together as a single code.
---
With MCM however, there’s an even fancier trick you can do with the “standalone function” feature. Basically, you stuff the “blrl + data” portion of this exploit into a named function, and then any code compiled with MCM can reference it by simply calling it with the special branching syntax:
bl <getData> # this works between ports
This layer of abstraction allows us to encapsulate data in a callable function that MCM then compiles into available code space behind the scenes as needed. Now, at no point do we need to know where this data is located; only that it is named "getData"
If we add handles to another function that use this data in order to work for each sword user (IDs 06=Link, 12=Marth, 14=YLink, 1A=Roy) then all that’s left to port are some tiny injections. The total code size is now ~half data, and almost totally portable:
I think several popular codes would benefit from using portable data like this. I have my eye on Frame Speed Modifiers @Ampers@Tater@Zadamanim
Kind of an odd request, but would it be possible to make a version of this gecko code that excludes marth? I wanna be able to use this with the new marth sword trail code that lets you assign colors to the alts, but they interfere.
Punkline
Is the Costume Dependent Sword Trails Colors code for all sword users that you wrote compatible with MCM v2.0? I had to use MCM v2.0 so that I could use the settings.py from Achilles' 20XX 4.06 github repository.
2.0 has some issues with using multiple standalone functions, so I rewrote it to be a few lines longer but only use 1 standalone function. That seemed to get it to work, though I've only lightly tested it:
Code:
-==-
Costume Dependent Sword Trail Colors
For all sword users
[Achilles1515, Decipio-Carme, Sins of Apathy, Punkline]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0x800eb294 --- FC000800 -> Branch
7D4802A6
bl <CDSC_getData>
7C6802A6 386300A8
7C6803A6 7CCB3378
8865E129 8085DB14
38A5FF9C 4E800021
7D4803A6 7D665B78
FC000800 00000000
1.02 ----- 0x8013651c --- 4E800020 -> Branch
7D4802A6
bl <CDSC_getData>
7C6802A6 386300A8
7C6803A6 8865E169
8085DB54 38A5FFF0
4E800021 7D4803A6
4E800020
<CDSC_getData>
4E800021 # blrl
#0x0
# toggle
0000000B # this line stores 4 bits that toggle custom trails by character
# 4 bits = +8=Link, +4=Marth, +2=YLink, +1=Roy
# 0x4
#Ln Mr Yl Ry -- these are CHIDs for the toggles above
06 12 14 1A # this line defines 4 character IDs for the code to allow
# 0x8 - Ln
#Ae As R1G1B1 R2G2B2
FF 00 FFFFFF FFFFFF # 0 - Link NR - Hylian Swordsman
FF 11 ffbf81 ff8000 # 1 - Link Red - Charged Spin Slash
FF 00 d0ffc0 a6f4ee # 2 - Link Blue - Mikau Fins
CC 00 e89393 9e1067 # 3 - Link Black - Poe Wisps
FF 00 f6baba e81d60 # 4 - Link Pink - Lovely Link
# 0x30 - Mr
CC 22 FF40FF 0040FF # 0 - Marth NR - Shield Breaker
FF 00 e48e48 ffdf5d # 1 - Marth Red - Mango Marth
FF 11 c89a50 d8eba5 # 2 - Marth Green - Kiwi Slash
FF 00 F7E183 FFFFFF # 3 - Marth Black - Golden Sting
CC 00 7D77C8 FFFFFF # 4 - Marth White - Pale Lavender
# 0x58 - Yl
FF 00 73c478 daf4c7 # 0 - YLink NR - Kokiri Gale
FF 00 FF0000 FF5010 # 1 - YLink Red - Orange Rupee
FF 11 81ffec 00ffff # 2 - YLink Blue - Spin Slash
FF 11 ede2b8 c9edf2 # 3 - YLink Pink - Pastel Sword
CC 00 430549 c72f19 # 4 - YLink Black - Lense of Truth
# 0x80 - Ry
CC 22 fa4100 f5dd89 # 0 - Roy NR - Fire Blade
FF 00 ae1a2b fdecaa # 1 - Roy Red - Grapefruit Roy
FF 00 f4e9c7 119aa6 # 2 - Roy Blue - Lamplight
FF 00 80FFAA FFFFFF # 3 - Roy Green - Emerald Edge
FF 22 f7f29a FFFFFF # 4 - Roy Yellow - Radiant Swing
# 0xA8
7C0802A6
bl <CDSC_getData>
7CC802A6 7C0803A6
38E00000 39000004
81260000 5D293F39
41820014 7D283A14
7D2930AE 7C092000
41820014 38E70001
2C070004 41810038
4BFFFFD8 1C870028
38840008 54631838
7C841A14 7C843214
88640000 98650000
80640001 90650001
80640005 5463C23E
90650005 4E800020
Kind of an odd request, but would it be possible to make a version of this gecko code that excludes marth? I wanna be able to use this with the new marth sword trail code that lets you assign colors to the alts, but they interfere.
I'm not sure if you're speaking of an interference of hooks or not, but you can toggle the effect on each character type individually by changing the flags here:
To mask out Marth, change that highlighted F to a B.
2.0 has some issues with using multiple standalone functions, so I rewrote it to be a few lines longer but only use 1 standalone function. That seemed to get it to work, though I've only lightly tested it:
Code:
-==-
Costume Dependent Sword Trail Colors
For all sword users
[Achilles1515, Decipio-Carme, Sins of Apathy, Punkline]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0x800eb294 --- FC000800 -> Branch
7D4802A6
bl <CDSC_getData>
7C6802A6 386300A8
7C6803A6 7CCB3378
8865E129 8085DB14
38A5FF9C 4E800021
7D4803A6 7D665B78
FC000800 00000000
1.02 ----- 0x8013651c --- 4E800020 -> Branch
7D4802A6
bl <CDSC_getData>
7C6802A6 386300A8
7C6803A6 8865E169
8085DB54 38A5FFF0
4E800021 7D4803A6
4E800020
<CDSC_getData>
4E800021 # blrl
#0x0
# toggle
0000000B # this line stores 4 bits that toggle custom trails by character
# 4 bits = +8=Link, +4=Marth, +2=YLink, +1=Roy
# 0x4
#Ln Mr Yl Ry -- these are CHIDs for the toggles above
06 12 14 1A # this line defines 4 character IDs for the code to allow
# 0x8 - Ln
#Ae As R1G1B1 R2G2B2
FF 00 FFFFFF FFFFFF # 0 - Link NR - Hylian Swordsman
FF 11 ffbf81 ff8000 # 1 - Link Red - Charged Spin Slash
FF 00 d0ffc0 a6f4ee # 2 - Link Blue - Mikau Fins
CC 00 e89393 9e1067 # 3 - Link Black - Poe Wisps
FF 00 f6baba e81d60 # 4 - Link Pink - Lovely Link
# 0x30 - Mr
CC 22 FF40FF 0040FF # 0 - Marth NR - Shield Breaker
FF 00 e48e48 ffdf5d # 1 - Marth Red - Mango Marth
FF 11 c89a50 d8eba5 # 2 - Marth Green - Kiwi Slash
FF 00 F7E183 FFFFFF # 3 - Marth Black - Golden Sting
CC 00 7D77C8 FFFFFF # 4 - Marth White - Pale Lavender
# 0x58 - Yl
FF 00 73c478 daf4c7 # 0 - YLink NR - Kokiri Gale
FF 00 FF0000 FF5010 # 1 - YLink Red - Orange Rupee
FF 11 81ffec 00ffff # 2 - YLink Blue - Spin Slash
FF 11 ede2b8 c9edf2 # 3 - YLink Pink - Pastel Sword
CC 00 430549 c72f19 # 4 - YLink Black - Lense of Truth
# 0x80 - Ry
CC 22 fa4100 f5dd89 # 0 - Roy NR - Fire Blade
FF 00 ae1a2b fdecaa # 1 - Roy Red - Grapefruit Roy
FF 00 f4e9c7 119aa6 # 2 - Roy Blue - Lamplight
FF 00 80FFAA FFFFFF # 3 - Roy Green - Emerald Edge
FF 22 f7f29a FFFFFF # 4 - Roy Yellow - Radiant Swing
# 0xA8
7C0802A6
bl <CDSC_getData>
7CC802A6 7C0803A6
38E00000 39000004
81260000 5D293F39
41820014 7D283A14
7D2930AE 7C092000
41820014 38E70001
2C070004 41810038
4BFFFFD8 1C870028
38840008 54631838
7C841A14 7C843214
88640000 98650000
80640001 90650001
80640005 5463C23E
90650005 4E800020
I'm not sure if you're speaking of an interference of hooks or not, but you can toggle the effect on each character type individually by changing the flags here:
To mask out Marth, change that highlighted F to a B.
Thanks it worked, but not in the way I'd hoped. Marth's sword trails are neutral blue, but they stay neutral blue even when the 20XX 4.06 F.E. sword trails are toggled on. I'm trying to make it so all sword character's have colored swings, and marth can have different colored swings assigned to each L/R alt.
edit: What I meant by interfere is that your code takes priority over the L/R alts in 20XX 4.06
2.0 has some issues with using multiple standalone functions, so I rewrote it to be a few lines longer but only use 1 standalone function. That seemed to get it to work, though I've only lightly tested it
For some reason it doesn't work for me. When I try using MCM 2.0 to add it to a vanilla 1.02 ISO, I get unknown poniter complaints when I try to load the ISO. When I try adding it to a 20XX 4.06 ISO, I can load the ISO but I get the default sword colors. I've tried toggling the Fire Emblem Sword Swings and even removing it with MCM. Still getting the default sword colors. But if it's too much of a pain to get it to work with 2.0, I can understand.