Increase Pokémon sprite animation size

By default, Pokémon sprite animations have maximum sizes that limit how creative you can be with them. It's possible to overcome these limits and have animations use up to 255 tiles.

Contents

• 1. Understanding the problem
• 2. Edit engine/gfx/load_pics.asm
• 3. Edit engine/gfx/pic_animation.asm

1. Understanding the problem

Pokémon sprite animations are composed of frames; for example, Haunter's 5-frame animation:

Sometimes you may try to redesign an animation; for example, this one by SoupPotato:

But some tiles are incorrect when it plays:

This is because sprite animations have size limits:

• A 5x5-tile sprite (40x40 pixels) uses 5×5=25 tiles for its first frame, and can use another 25 for its animation tiles, for a total of 50 tiles
• A 6x6-tile sprite (48x48 pixels) uses 6×6=36 tiles for its first frame, and can use another 36 for its animation tiles, for a total of 72 tiles
• A 7x7-tile sprite (56x56 pixels) uses 7×7=49 tiles for its first frame, and can use another 49 for its animation tiles, for a total of 98 tiles

What are "animation tiles"? Well, all graphics are composed of 8x8-pixel tiles, and only a few of them change from one frame to the next. So animations are stored in a compressed form: every tile of the first frame is kept, but then there's only one copy of each unique tile for all its animation frames. So Haunter's animation gets stored like this:

That takes up 56 tiles: 36 for the first frame, and 20 for the animation frames, which is within the 72-tile limit. But here's the edited animation:

That's 78 tiles. The last 6 don't even get loaded, so they show up incorrectly when the animation plays, which is why the earlier screenshot shows white tiles where Haunter's hand is.

To see how this might be solved, let's look at BGB's VRAM viewer:

The top-left segment of VRAM (video memory) stores tiles for move animations. The middle-left is for text characters. The bottom-left is for the enemy's front sprite, the player's back sprite, and the battle interface. Finally, the bottom-right is for the enemy's animation: its entire first frame, and then the unique animation tiles. The top-right and middle-right segments are unused.

By studying how the animation graphics are loaded and played, we can use the entire bottom-left and middle-left segments to allow 255-tile animations.

2. Edit engine/gfx/load_pics.asm

Most of the code and idea was taken from Prism, adapted for current pokecrystal.

diff --git a/engine/gfx/load_pics.asm b/engine/gfx/load_pics.asm
--- a/engine/gfx/load_pics.asm
+++ b/engine/gfx/load_pics.asm
@@ -58,7 +58,7 @@ GetMonFrontpic:
 	call _GetFrontpic
 	pop af
 	ld [rSVBK], a
-	ret
+	jp CloseSRAM
 
 GetAnimatedFrontpic:
 	ld a, [wCurPartySpecies]
@@ -70,12 +70,18 @@ GetAnimatedFrontpic:
 	xor a
 	ld [hBGMapMode], a
 	call _GetFrontpic
+	ld a, BANK(vTiles3)
+	ld [rVBK], a
 	call GetAnimatedEnemyFrontpic
+	xor a
+	ld [rVBK], a
 	pop af
 	ld [rSVBK], a
-	ret
+	jp CloseSRAM
 
 _GetFrontpic:
+	ld a, BANK(sScratch)
+	call GetSRAMBank
 	push de
 	call GetBaseData
 	ld a, [wBasePicSize]
@@ -86,15 +92,24 @@ _GetFrontpic:
 	ld a, BANK(wDecompressEnemyFrontpic)
 	ld [rSVBK], a
 	ld a, b
-	ld de, wDecompressEnemyFrontpic
+	ld de, wDecompressScratch
 	call FarDecompress
+
+	; Save decompressed size
+	swap e
+	swap d
+	ld a, d
+	and $f0
+	or e
+	ld [sScratch], a
+
 	pop bc
-	ld hl, wDecompressScratch
-	ld de, wDecompressEnemyFrontpic
+	ld hl, sScratch + $10
+	ld de, wDecompressScratch
 	call PadFrontpic
 	pop hl
 	push hl
-	ld de, wDecompressScratch
+	ld de, sScratch + $10
 	ld c, 7 * 7
 	ld a, [hROMBank]
 	ld b, a
@@ -130,10 +145,8 @@ GetFrontpicPointer:
 	ret
 
 GetAnimatedEnemyFrontpic:
-	ld a, BANK(vTiles3)
-	ld [rVBK], a
 	push hl
-	ld de, wDecompressScratch
+	ld de, sScratch + $10
 	ld c, 7 * 7
 	ld a, [hROMBank]
 	ld b, a
@@ -147,18 +160,24 @@ GetAnimatedEnemyFrontpic:
 	call GetFarWRAMByte
 	pop hl
 	and $f
-	ld de, wDecompressEnemyFrontpic + 5 * 5 tiles
+	ld de, wDecompressScratch + 5 * 5 tiles
 	ld c, 5 * 5
 	cp 5
 	jr z, .got_dims
-	ld de, wDecompressEnemyFrontpic + 6 * 6 tiles
+	ld de, wDecompressScratch + 6 * 6 tiles
 	ld c, 6 * 6
 	cp 6
 	jr z, .got_dims
-	ld de, wDecompressEnemyFrontpic + 7 * 7 tiles
+	ld de, wDecompressScratch + 7 * 7 tiles
 	ld c, 7 * 7
 .got_dims
 
+	; Get animation size (total - base sprite size)
+	ld a, [sScratch]
+	sub c
+	ret z ; Return if there's no animation
+	ld c, a
+
 	push hl
 	push bc
 	call LoadFrontpicTiles
@@ -167,10 +186,28 @@ GetAnimatedEnemyFrontpic:
 	ld de, wDecompressScratch
 	ld a, [hROMBank]
 	ld b, a
+
+	; If we can load it in a single pass, just do it
+	ld a, c
+	sub (128 - 7 * 7)
+	jr c, .copy_and_finish
+
+	; Otherwise, load the first part...
+	inc a
+	ld [sScratch], a
+	ld c, (127 - 7 * 7)
 	call Get2bpp
-	xor a
-	ld [rVBK], a
-	ret
+
+	; Then move up a bit and load the rest
+	ld de, wDecompressScratch + (127 - 7 * 7) tiles
+	ld hl, vTiles4
+	ld a, [hROMBank]
+	ld b, a
+	ld a, [sScratch]
+	ld c, a
+
+.copy_and_finish
+	jp Get2bpp
 
 LoadFrontpicTiles:
 	ld hl, wDecompressScratch
@@ -184,11 +221,17 @@ LoadFrontpicTiles:
 	push bc
 	call LoadOrientedFrontpic
 	pop bc
+	ld a, c
+	and a
+	jr z, .handle_loop
+	inc b
+	jr .handle_loop
 .loop
 	push bc
 	ld c, 0
 	call LoadOrientedFrontpic
 	pop bc
+.handle_loop
 	dec b
 	jr nz, .loop
 	ret

3. Edit engine/gfx/pic_animation.asm

diff --git a/engine/gfx/pic_animation.asm b/engine/gfx/pic_animation.asm
--- a/engine/gfx/pic_animation.asm
+++ b/engine/gfx/pic_animation.asm
@@ -621,6 +621,9 @@ PokeAnim_ConvertAndApplyBitmask:
 	add [hl]
 	pop hl
 	ld [hl], a
+	cp $7f
+	ret c
+	inc [hl]
 	ret