El fenómeno que comentas curre cuando el daño producido va a dejar al pokemon con un valor de HP restante tal que multiplicado por 48 (numero de pixels del HP bar) y dividido por su maximo HP da un valor entero.

Por ejemplo, 6/16 -> 6 * 48 / 16 = 18. Como ves, si el max. HP es 12, 16 o 24, siempre se dará el caso para cualquier valor de HP restante. Para Max. HP impares (o mayores de 48) nunca se dará el caso.

Para que te hagas a la idea de porque ocurre esto, te pongo un ejemplo. Tengo un Pokemon con 18/32 HP. La cantidad de pixels es por tanto 27. Cuando se le hace un ataque, los pixels se decrementan de uno en uno y en cada paso se computa el valor de HP que le corresponde. Imagina que le hacen un daño de 2 HP a este Pokemon. 16/32 se corresponde con 24 pixels; por tanto, la animación tendrá lugar en 3 pasos.

En el primer paso, con px=26, el valor de HP sería 17,33. Como no llega a 17, el juego sigue escribiendo 18 HP, y por tanto no hay cambio en el valor del HP durante la animación de este primer pixel desapareciendo. En el siguiente paso, con px=25, HP sería 16,67. No llega a 16 HP, así que se escribe el valor de 17.

¿Ves por donde voy? La forma de comprobar si el HP ha llegado a un valor correspondiente es ver si el resultado entero es un punto inferior a dicho valor. En el ultimo paso con px=24, el HP sería 16,00 ; y el resultado entero 16. Como dicho resultado no es 15, se interpreta como 17 HP. Por tanto, durante la animación de la HP bar, el valor del HP restante nunca reflejará 16 HP, y solo lo hará unas cuantas frames mas adelante cuando el juego solicite redibujar los HUDs.

Al parecer, este caso extremo si que fue considerado en este bloque: https://github.com/pret/pokecrystal/blob/master/engine/anim_hp_bar.asm#L398-L410 El problema es que sumando 128, es imposible que cuando a continuacion se resta 48 ocurra desbordamiento (carry), y por tanto el registro b (HP restante) nunca se incrementerá para reflejar el valor correcto. Para corregir esta pequeña equivocación, habría que sumar 95 en vez de 128, es decir, (2 * HP_BAR_FRAMES - 1). De esa forma habría desbordamiento al restar 48 cuando el resto es justamente 0 (que en el loop anterior quedaría reflejado en hl como -48).

Es un poco interesante asi que seguramente haga un pequeño video mañana. De hecho, la razón por la que te dejo este tocho aquí es para que si se me olvida la lógica para cuando me ponga con el video pueda tener donde mirar lol