Could Critical Hits have been intended to happen less times in RBY?

[Crystal_]

Okay this is just a theory but I'd like to share it. The other day I looked at the dissasembly of Pokemon red to read about how critical hits and the focus energy glitch exactly worked. I saw that if focus energy has been used, there is a jump to a function that does a right shift (divide by 2), while if focus energy hasn't been used the jump doesn't happen and the game does a left shift instead (multiply by 2) and skips the right shift.

According to the comments there, the bug is that focus enegy's shift was supposed to be a shift to the left instead of to the right. However, would've that made sense? I mean, in that case it would always be a left shift (multiply by 2) regardless of whether focus energy has been used or not, meaning that Focus Energy would literally have no effect.

My theory is that maybe they also made a mistake on the non-focus energy shift and that they maybe wanted it to be a shift to the right instead or to the left, so that if focus energy was used it was a x2, and else, a /2. IMO it seems much more likely that they swapped the two shifts by accident than that the forgot to add another shift somewhere or something of the sort. Plus, they reduced the critical hit ratio in the next generation for the most part (Pokemon went to crit from an average ~15% to 6.25%).

So what do you guys think?

CriticalHitTest: ; 3e023 (f:6023)
	xor a
	ld [$d05e], a
	ld a, [H_WHOSETURN] ; $FF00+$f3
	and a
	ld a, [$cfe5]
	jr nz, .asm_3e032
	ld a, [W_PLAYERMONID]
.asm_3e032
	ld [$d0b5], a
	call GetMonHeader
	ld a, [W_MONHBASESPEED]
	ld b, a
	[B]srl b                        ; (effective (base speed/2))[/B]
	ld a, [H_WHOSETURN] ; $FF00+$f3
	and a
	ld hl, W_PLAYERMOVEPOWER ; $cfd4
	ld de, W_PLAYERBATTSTATUS2 ; $d063
	jr z, .calcCriticalHitProbability
	ld hl, W_ENEMYMOVEPOWER ; $cfce
	ld de, W_ENEMYBATTSTATUS2 ; $d068
.calcCriticalHitProbability      ; 0x3e04f
	ld a, [hld]                  ; read base power from RAM
	and a
	ret z                        ; do nothing if zero
	dec hl
	ld c, [hl]                   ; read move id
	ld a, [de]
	[B]bit 2, a                     ; test for focus energy
	jr nz, .focusEnergyUsed      ; bug: using focus energy causes a shift to the right instead of left,
	                             ; resulting in 1/4 the usual crit chance
	sla b                        ; (effective (base speed/2)*2)
	jr nc, .noFocusEnergyUsed
	ld b, $ff                    ; cap at 255/256
	jr .noFocusEnergyUsed
.focusEnergyUsed
	srl b
.noFocusEnergyUsed[/B]
	ld hl, HighCriticalMoves      ; table of high critical hit moves

(...)

 

[KuroSeka]

mhh seems legit ,but i think ure right

hehe °^°

 

[Satoshi Ookami]

That seems to be case why critical hits were based on speed and happened more often than in newer games.

Still... it's pretty weird that programmers would actually made such a huge mistake... I mean... bit shifting is one of basics of ASM programming.

 

[Airikita]

Ah yes, I noticed a failed bit shift in the formula for medium-slow exp groups. When you catch a Pokemon of the medium-slow group, the starting EXP is given based on their level. This is where the level 1 bug comes to play (in GBC Pokemon Gold)

The bit shift fails after the calculation renders FFFFCB for the base exp at level 1, and the bit shift probably fails in a ~similar~ fashion with srl b as part of the calculation, and doesn't change the FF's, thus it could have been 0000CB or less. At level 5, the exp is 000087.

I assume it is a simple matter of adding 0x35 to 0xCB, but the bit shift for srl b is stored in a stack preceding the calculations. register bc is stored as 0020 twice, which the 00 for b is meant to switch off FFFF from the other two positions, and srl b fails to erase FF's because it is 00.

I assume Gamefreak does not know how to manage srl errors/problems.

EDIT: and come to think of it, I believe I know where I can fix the bug, but I removed the break points... once I figure out code-hooks for GB asm, I can repair it.