summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRangi <remy.oukaour+rangi42@gmail.com>2018-10-28 11:48:02 -0400
committerRangi <remy.oukaour+rangi42@gmail.com>2018-10-28 11:48:02 -0400
commit76c06bf44a2264a793ee7825ad4b0a7927373b07 (patch)
treedd17037ac0943f78104a67018aa58ab1bbaaa5bd
parent0e3b13416a658afe72686c6424791440ffa1b4b7 (diff)
Relate tutorials
-rw-r--r--Add-a-new-map-and-landmark.md2
-rw-r--r--Improve-the-outdoor-sprite-system.md18
2 files changed, 16 insertions, 4 deletions
diff --git a/Add-a-new-map-and-landmark.md b/Add-a-new-map-and-landmark.md
index d6bb8de..abf6381 100644
--- a/Add-a-new-map-and-landmark.md
+++ b/Add-a-new-map-and-landmark.md
@@ -254,6 +254,8 @@ VRAM is divided into six areas, each 128 tiles large. The middle-right area is f
Notice how text characters are in the middle-left area. This is why, if an NPC is using a sprite from the top-left area that doesn't have walking frames, it will glitch and appear as text when it takes a step.
+This may seem annoying to edit. You have to keep connected sets in sync, like `OlivineGroupSprites` and `CianwoodGroupSprites`; you have to ignore the filler sprites like `SPRITE_FAMICOM` to see which sprites actually get used; and you can't use more than nine sprites with walking frames in a set, even if only nine of them actually walk in any of the maps, because you can't determine which nine will have their walking frames loaded. I strongly recommend following [this tutorial](Improve-the-outdoor-sprite-system) to change the system and fix all of those issues.
+
## 5. Define its properties
diff --git a/Improve-the-outdoor-sprite-system.md b/Improve-the-outdoor-sprite-system.md
index ba812bf..6cf3e0a 100644
--- a/Improve-the-outdoor-sprite-system.md
+++ b/Improve-the-outdoor-sprite-system.md
@@ -438,9 +438,11 @@ The comments make it clear which maps the set applies to; and the order matches
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.
+- 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 separate 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.
+We're technically done at this point, but the new system makes a few sprites redundant. Let's see how that works.
+
## 4. Remove the now-redundant non-walking sprite versions
@@ -451,9 +453,12 @@ Two sprites are just copies of other sprites, but with the walking frames remove
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.
+Now, though, you can completely delete `SPRITE_STANDING_YOUNGSTER` and `SPRITE_KURT_OUTSIDE`, and use `SPRITE_YOUNGSTER` and `SPRITE_KURT` instead:
+
+- Remove the `SPRITE_STANDING_YOUNGSTER` and `SPRITE_KURT_OUTSIDE` definitions and data from [constants/sprite_constants.asm](../blob/master/constants/sprite_constants.asm), [data/sprites/sprites.asm](../blob/master/data/sprites/sprites.asm), [gfx/sprites.asm](../blob/master/gfx/sprites.asm), and [gfx/sprites/*.png](../tree/master/gfx/sprites/).
+- Replace `SPRITE_STANDING_YOUNGSTER` and `SPRITE_KURT_OUTSIDE` with `SPRITE_YOUNGSTER` and `SPRITE_KURT` respectively in [maps/*.asm](../tree/master/maps/) and [data/maps/outdoor_sprites.asm](../blob/master/data/maps/outdoor_sprites.asm). Be sure to put them *after* all the walking sprites in their respective outdoor sprite sets, since their walking frames aren't needed.
-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.
+For example, when 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
@@ -470,4 +475,9 @@ At first glance, it makes sense why these variable sprites exist. They're a neat
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.
+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:
+
+- Remove the `SPRITE_WEIRD_TREE`, `SPRITE_AZALEA_ROCKET`, and `SPRITE_OLIVINE_RIVAL` definitions from [constants/sprite_constants.asm](../blob/master/constants/sprite_constants.asm).
+- Remove their respective `variablesprite` initializers from `InitializeEventsScript` in [engine/events/std_scripts.asm](../blob/master/engine/events/std_scripts.asm).
+
+For more information on variable sprites, see [the tutorial to add a new sprite](Add-a-new-overworld-sprite).