[ASM & Hex] Shiny Chance/Charm

[Zervais]

I'm a big lover of shiny Pokemon and want players of my hack to experience them more often, if possible. I am looking for information/a way to increase the shiny chance. Is there specific bytes I can edit to change the chance shinies are encountered? And is there a way to implement an item much like the shiny charm in the later games?

Thanks, friends.

 

[Dionen]

it is your lucky day! haha
https://www.pokecommunity.com/showpost.php?p=8547374&postcount=400

 

[Zervais]

it is your lucky day! haha
https://www.pokecommunity.com/showpost.php?p=8547374&postcount=400

That's great but what bit can I edit to increase the chance further? I'm looking for 1/1000 chance to encounter a shiny in the wild.

 

[BluRose]

That's great but what bit can I edit to increase the chance further? I'm looking for 1/1000 chance to encounter a shiny in the wild.

explained this to aligateur yesterday lol
https://www.pokecommunity.com/showpost.php?p=9483765&postcount=1037

 

[Blah]

explained this to aligateur yesterday lol
https://www.pokecommunity.com/showpost.php?p=9483765&postcount=1037

lets be real here.

	mov r0, #0xA
	lsl r0, r0, #0x7
	add r0, r0, #0x55 @1/1365 chance with shiny charm
	b calcChance

replace that with:

	ldr r0, =(1365)
	b calcChance

I used to have this idea that calculating large values was faster than just setting them. Setting them makes the code actually easier to edit though, and the speed is negligible due to execution frequency. It does take 2 extra bytes of extra space if the loaded value is an entire word, but 2 bytes is nothing.

You'll notice that Gamefreak's compiler chose to optimize these into bit shifts, but it's probably the case that their original values were set, rather than derived. I think everyone should use ldr (or mov in the case of 1 byte values) to set values, even if it's purely for readability.

 

[BluRose]

Spoiler:

lets be real here.

	mov r0, #0xA
	lsl r0, r0, #0x7
	add r0, r0, #0x55 @1/1365 chance with shiny charm
	b calcChance

replace that with:

	ldr r0, =(1365)
	b calcChance

I used to have this idea that calculating large values was faster than just setting them. Setting them makes the code actually easier to edit though, and the speed is negligible due to execution frequency. It does take 2 extra bytes of extra space if the loaded value is an entire word, but 2 bytes is nothing.

You'll notice that Gamefreak's compiler chose to optimize these into bit shifts, but it's probably the case that their original values were set, rather than derived. I think everyone should use ldr (or mov in the case of 1 byte values) to set values, even if it's purely for readability.

but fbi! it's always nice to be able to read gf's code based on their optimization and things. i mean, it's really a simple difference anyways (let's be real, you're not sorting through ida looking for something if you don't even know all/most of the asm commands themselves), but i almost think it would be better just to keep within the game's style for consistency? granted, a communal comsistency is probably more important...
nevermind i guess ahaha~
watch as one day in the future lag becomes a problem because of decisions made now based off of "negligible speed differences"

 

[Blah]

but fbi! it's always nice to be able to read gf's code based on their optimization and things. i mean, it's really a simple difference anyways (let's be real, you're not sorting through ida looking for something if you don't even know all/most of the asm commands themselves), but i almost think it would be better just to keep within the game's style for consistency? granted, a communal comsistency is probably more important...
nevermind i guess ahaha~
watch as one day in the future lag becomes a problem because of decisions made now based off of "negligible speed differences"

It depends on where you are neglecting optimizations. This code here is only run once every time the game needs to generate a Pokemon. Now consider that the game executes code every row of pixels that is drawn on the screen for things like flash and battle animations. Optimizing something like the Hblank IRQ service routine is important, this shiny routine? Not at all XD

As for consistency, I think readability is much more important than keeping it harder to read. Remember that gamefreak's ASM is output by a compiler, the original is written in C. You shouldn't try to copy the compiler's tendencies at the cost of making your code harder to modify in the future. :)