Fix admonitions in the Cheat Sheet (#86)

src/cheatsheet.md

@@ -75,7 +75,7 @@ ldh [rLCDC], a
 
 **To turn the LCD off:**
 
-::: warning
+:::warning: ⚠️
 
 Do not turn the LCD off outside of the Vertical Blank Phase. See "[How to wait for vertical blank phase](#how-to-wait-for-the-vertical-blank-phase)".
 
@@ -146,7 +146,7 @@ You can use one of the 4 constants to specify which layer uses which region:
 -   LCDCF_BG9800
 -   LCDCF_BG9C00
 
-::: tip Note
+:::tip Note
 
 You still need to make sure the window and background are turned on when using these constants.
 
@@ -174,7 +174,7 @@ and a, LCDCF_OBJOFF
 ldh [rLCDC], a
 ```
 
-::: tip
+:::tip
 
 Sprites are in 8x8 mode by default.
 
@@ -184,7 +184,7 @@ Sprites are in 8x8 mode by default.
 
 Once sprites are enabled, you can enable tall sprites using the 3rd bit of the `rLCDC` register: `LCDCF_OBJ16`
 
-::: tip
+:::tip
 
 You can not have some 8x8 sprites and some 8x16 sprites. All sprites must be of the same size.
 
@@ -243,13 +243,13 @@ CopyTilemap:
     jp nz, CopyTilemap
 ```
 
-::: tip
+:::tip
 
 Make sure the layer you're targetting has been turned on. See ["Turn on/off the window"](#turn-onoff-the-window) and ["Turn on/off the background"](#turn-onoff-the-background)
 
 :::
 
-::: tip
+:::tip
 
 In terms of tiles, The background/window tilemaps are 32x32. The Game Boy's screen is 20x18. When copying tiles, understand that RGBDS or the Game Boy won't automatically jump to the next visible row after you've reached the 20th column.
 
@@ -279,7 +279,7 @@ Check out the Pan Docs for more info on the [Background viewport Y position, X p
 
 Moving the window is the same as moving the background, except using the `$FF4B` and `$FF4A` registers. Hardware.inc defines two constants for that: `rWX` and `rWY`.
 
-::: tip
+:::tip
 
 The window layer has a -7 pixel horizontal offset. This means setting `rWX` to 7 places the window at the left side of the screen, and setting `rWX` to 87 places the window with its left side halfway across the screen.
 
@@ -363,7 +363,7 @@ To wait **indefinitely** for a button press, create a loop where you:
     -   call the `UpdateKeys` function again
     -   Loop background to the beginning
 
-::: tip
+:::tip
 
 This will halt all other logic (outside of interrupts), be careful if you need any logic running simultaneously.
 
@@ -396,7 +396,7 @@ Drawing text on the window is essentially drawing tiles (with letters/numbers/pu
 
 To simplify the process you can define constant strings.
 
-::: tip
+:::tip
 
 These constants end with a literal 255, which our code will read as the end of the string.
 
@@ -412,7 +412,7 @@ wScoreText::  db "score", 255
 
 RGBDS has a character map functionality. You can read more in the [RGBDS Assembly Syntax Documentation](https://rgbds.gbdev.io/docs/rgbasm.5#DEFINING_DATA). This functionality, tells the compiler how to map each letter:
 
-::: tip
+:::tip
 
 You need to have your text font tiles in VRAM at the locations specified in the map. See [How to put background/window tile data in VRAM](#how-to-put-backgroundwindow-tile-data-into-vram)
 
@@ -463,13 +463,13 @@ The above character mapping would convert (by the compiler) our `wScoreText` tex
 
 With that setup, we would loop though the bytes of `wScoreText` and copy each byte to the background/window layer. After we copy each byte, we'll increment where we will copy to, and which byte in `wScoreText` we are reading. When we read 255, our code will end.
 
-::: tip
+:::tip
 
 This example implies that your font tiles are located in VRAM at the locations specified in the character mapping.
 
 :::
 
-** Drawing 'score' on the window **
+**Drawing 'score' on the window**
 
 ```rgbasm, lineno
 
@@ -503,7 +503,7 @@ DrawTextTilesLoop::
 -   Move the window downwards, so only 1 or 2 rows show at the bottom of the screen
 -   Draw your text, score, and icons on the top of the window layer.
 
-::: tip
+:::tip
 
 Sprites will still show over the window. To fully prevent that, you can use STAT interrupts to hide sprites where the bottom HUD will be shown.
 
@@ -580,7 +580,7 @@ ld [_OAMRAM + 20], a
 
 TODO - Explanation on limitations of direct OAM manipulation.
 
-::: tip
+:::tip
 
 It's recommended that developers implement a shadow OAM, like @eievui5's [Sprite Object Library](https://github.com/eievui5/gb-sprobj-lib)
 

src/part2/getting-started.md

@@ -70,7 +70,7 @@ Almost done now—next, write another loop, this time for copying [the tilemap](
 Note that while this loop's body is exactly the same as `CopyTiles`'s, the 3 values loaded into `de`, `hl`, and `bc` are different.
 These determine the source, destination, and size of the copy, respectively.
 
-:::tip "[<abbr title="Don't Repeat Yourself">DRY</abbr>](https://en.wikipedia.org/wiki/Don't_Repeat_Yourself)"
+:::tip "Don't Repeat Yourself"
 
 If you think that this is super redundant, you are not wrong, and we will see later how to write actual, reusable *functions*.
 But there is more to them than meets the eye, so we will start tackling them much later.