Done

1 files changed, 44 insertions, 2 deletions

diff --git a/Improve-the-outdoor-sprite-system.md b/Improve-the-outdoor-sprite-system.md
index ac71c71..c0786e4 100644
--- a/Improve-the-outdoor-sprite-system.md
+++ b/Improve-the-outdoor-sprite-system.md
@@ -40,7 +40,13 @@ As they're currently implemented, these sprite sets are hard to edit. Every set
 This tutorial will improve the outdoor sprite sets by making them variable-length lists ending with 0, and with the first nine sprites being the ones to get walking frames. The existing sprite sets for pokecrystal's maps will be optimized to work with this new format.
 
 
-## TOC
+## Contents
+
+1. [Make outdoor sprite sets variable-length, ending with 0](#1-make-outdoor-sprite-sets-variable-length-ending-with-0)
+2. [Don't automatically sort outdoor sprite sets](#2-dont-automatically-sort-outdoor-sprite-sets)
+3. [Update the outdoor sprite sets](#3-update-the-outdoor-sprite-sets)
+4. [Remove the now-redundant non-walking sprite versions](#4-remove-the-now-redundant-non-walking-sprite-versions)
+5. [Remove the now-redundant variable sprites](#5-remove-the-now-redundant-variable-sprites)
 
 
 ## 1. Make outdoor sprite sets variable-length, ending with 0
@@ -296,7 +302,7 @@ Edit [data/maps/outdoor_sprites.asm](../blob/master/data/maps/outdoor_sprites.as
 +; Route38, Route39, OlivineCity
 +CianwoodGroupSprites:
 +; Route40, Route41, CianwoodCity, BattleTowerOutside
-+	db SPRITE_OLIVINE_RIVAL; variable sprite: becomes SPRITE_SILVER and SPRITE_SWIMMER_GUY
++	db SPRITE_OLIVINE_RIVAL ; variable sprite: becomes SPRITE_SILVER and SPRITE_SWIMMER_GUY
 +	db SPRITE_POKEFAN_M
 +	db SPRITE_LASS
 +	db SPRITE_BUENA
@@ -429,3 +435,39 @@ And here's how they get loaded into VRAM:
 ![Screenshot](screenshots/outdoor-sprites-improved-vram.png)
 
 The comments make it clear which maps the set applies to; and the order matches their order in VRAM, from top to bottom, right and then left.
+
+Some things to note about the new system:
+
+- If you can walk across a map connection from one map group to another, those groups now share an outdoor sprite set. Sprites and tilesets are only reloaded when you warp to a different map, not when you cross a connection, so this is necessary. Previously, connected sets like `OlivineGroupSprites` and `CianwoodGroupSprites` used different lists which had to be kept in sync.
+- Removing the `LoadAndSortSprites` also affects indoor maps. If a map's `object_event`s use many different sprites, make sure to put the walking ones first.
+
+
+## 4. Remove the now-redundant non-walking sprite versions
+
+Two sprites are just copies of other sprites, but with the walking frames removed:
+
+- `SPRITE_STANDING_YOUNGSTER` is a non-walking version of `SPRITE_YOUNGSTER` used by `OlivineGroupSprites` and `CianwoodGroupSprites`
+- `SPRITE_KURT_OUTSIDE` is a non-walking version of `SPRITE_KURT` used by `AzaleaGroupSprites`
+
+This used to be necessary because if there were ten or more walking sprites, you couldn't control which nine would be loaded first and have their walking frames available; it was up to `LoadAndSortSprites`.
+
+Now, though, you can completely delete `SPRITE_STANDING_YOUNGSTER` and `SPRITE_KURT_OUTSIDE`, and use `SPRITE_YOUNGSTER` and `SPRITE_KURT` instead. Just be sure to put them after all the walking sprites in their respective outdoor sprite sets.
+
+For example, if you replace `SPRITE_STANDING_YOUNGSTER` with `SPRITE_YOUNGSTER` in `OlivineGroupSprites`, its standing frames will get loaded in VRAM bank 0, right where `SPRITE_STANDING_YOUNGSTER` in the previous screenshot; and its walking frames won't interfere with the font graphics.
+
+
+## 5. Remove the now-redundant variable sprites
+
+Three sprites are actually variable sprites:
+
+- `SPRITE_WEIRD_TREE` is used by `VioletGroupSprites` and `EcruteakGroupSprites`. It starts out looking like `SPRITE_SUDOWOODO`, and becomes `SPRITE_TWIN` after you battle Sudowoodo. This works because the only Twins in those map groups are encountered after Sudowoodo disappears.
+- `SPRITE_AZALEA_ROCKET` is used by `AzaleaGroupSprites`. It starts out looking like `SPRITE_ROCKET`, and becomes `SPRITE_SILVER` after you save the Slowpoke. This works because the rival encounter occurs after all the Rockets disappear.
+- `SPRITE_OLIVINE_RIVAL` is used by `OlivineGroupSprites` and `CianwoodGroupSprites`. It starts out looking like `SPRITE_SILVER`, and becomes `SPRITE_SWIMMER_GUY` after you run into your rival. This works because the only male Swimmers in those map groups are encountered after your rival disappears.
+
+At first glance, it makes sense why these variable sprites exist. They're a neat way to have ten or more walking sprites: if you know that only nine will be needed at a time, then a variable sprite can look like one now and another later.
+
+...Except, all three of those are used in outdoor sprite sets with enough room for more walking sprites! `VioletGroupSprites` and `EcruteakGroupSprites` only use 8 of max 9; `AzaleaGroupSprites` uses 6 of max 9; and `OlivineGroupSprites` and `CianwoodGroupSprites` use 8 of max 9.
+
+It turns out that Crystal doesn't need these variable sprites, but Gold and Silver did. Crystal is exclusive to the GameBoy Color, so it has twice as much VRAM, and it's able to load walking frames for every sprite in bank 1 while still having room for standing-still sprites in bank 0. But Gold and Silver supported the Super GameBoy, which only had one VRAM bank; so still sprites like `SPRITE_POKE_BALL` and `SPRITE_SLOWPOKE` used up the same space budget as walking sprites.
+
+Anyway, the point is that we don't need them any more. So you can completely delete those three variable sprites, and directly use the sprites that they turned into. Be sure to edit `InitializeEventsScript` in [engine/events/std_scripts.asm](../blob/master/engine/events/std_scripts.asm), which is where those variable sprites get initialized.