Use different syntax for notes/warnings;

guides/Callbacks_and_Modules.md

@@ -83,8 +83,10 @@ There are lots of different rendering-related objects that can be created using
 such as `Model`, `Texture`, `Font`, `Shader`, and more.  Every function to create a new
 object is prefixed with `new`, so to create a 3D model object you can use `lovr.graphics.newModel`.
 
-> Note: Creating graphics objects uses memory and can slow things down if done every frame.  For
-> this reason, it's recommended to create objects only once in `lovr.load` before using them!
+:::note
+Creating graphics objects uses memory and can slow things down if done every frame.  For this
+reason, it's recommended to create objects only once in `lovr.load` before using them!
+::::
 
 Another important component of `lovr.graphics` is **graphics state**.  `Pass` has a number of state
 variables that can be changed, like the color of rendered objects, the font in use, or the
@@ -167,8 +169,10 @@ lovr.physics
 Adding a physics simulation to a scene can make it feel more realistic and immersive.  The
 `lovr.physics` module can be used to set up a physics simulation.
 
-> Note: Physics engines can be tricky to set up.  There are lots of knobs to turn and it may take
-> some tweaking to get things working well.
+:::note
+Physics engines can be tricky to set up.  There are lots of knobs to turn and it may take some
+tweaking to get things working well.
+:::
 
 The first step to creating a simulation is to create a `World` using `lovr.physics.newWorld`.  After
 a world is created you can add `Collider`s to it, using functions like `World:newBoxCollider` or

guides/Distribution.md

@@ -30,8 +30,10 @@ On Unix systems, the `cat` utility can be used to concatenate the two files:
 
     $ cat /path/to/lovr MyProject.zip > MyProject
 
-> Once you have an executable, be sure to distribute it with all the libraries (`.dll` or `.so`
-> files) that came with the original LÖVR download.
+:::note
+Once you have an executable, be sure to distribute it with all the libraries (`.dll` or `.so` files)
+that came with the original LÖVR download.
+:::
 
 macOS
 ---

guides/Getting_Started.md

@@ -17,8 +17,10 @@ what's shown if you run LÖVR without specifying a project.
 
 <img src="/img/nogame.png" alt="The Default Project" width="50%"/>
 
-> Note: If you're using a VR headset, you'll only see the logo if your headset is pointing in the
-> forward direction.
+:::note
+If you're using a VR headset, you'll only see the logo if your headset is pointing in the forward
+direction.
+:::
 
 We're going to make a project so we see something more interesting than the logo.
 

guides/Plugins.md

@@ -18,10 +18,14 @@ To use a plugin, place its library file next to the lovr executable and `require
       myplugin.dothething()
     end
 
-> On Unix systems, some plugin files might be prefixed with `lib` (e.g. `liblovr-plugin.so`).
-> In this case, be sure to require the plugin with the lib prefix: `require 'liblovr-plugin'`.
+:::note
+On Unix systems, some plugin files might be prefixed with `lib` (e.g. `liblovr-plugin.so`). In this
+case, be sure to require the plugin with the lib prefix: `require 'liblovr-plugin'`.
+:::
 
-> On Android, plugins are searched for in the `lib/arm64-v8a` folder of the APK.
+:::note
+On Android, plugins are searched for in the `lib/arm64-v8a` folder of the APK.
+:::
 
 Plugins are not officially supported in WebAssembly yet, but this is theoretically possible.
 
@@ -79,9 +83,11 @@ as git submodules.  A fork of lovr can be created that has this custom plugins f
 easy to quickly get a set of plugins on multiple machines.  Version control also means that the
 plugins are versioned and tied to a known version of lovr.
 
-> By default, the libraries from all CMake targets in the plugin's build script will be moved
-> to the executable folder.  Plugins can override this by setting the `LOVR_PLUGIN_TARGETS` variable
-> to a semicolon-separated list of targets.
+:::note
+By default, the libraries from all CMake targets in the plugin's build script will be moved to the
+executable folder.  Plugins can override this by setting the `LOVR_PLUGIN_TARGETS` variable to a
+semicolon-separated list of targets.
+:::
 
 Creating Plugins
 ---

guides/Scripting_Languages.md

@@ -16,7 +16,9 @@ This document covers only some of them (in alphabetical order):
 * [Wu (Rust dialect)](#wu-rust-dialect)
 * [Yuescript (Moonscript dialect)](#yuescript-moonscript-dialect)
 
-> A *dialect* means the language is inspired by the parent but not fully syntax compatible.
+:::note
+A *dialect* means the language is inspired by the parent but not fully syntax compatible.
+:::
 
 In general there are two ways of using one of them in a LÖVR project:
 
@@ -59,12 +61,13 @@ In general there are two ways of using one of them in a LÖVR project:
             In fused mode the virtual file-system is the only working file access method.
             Meaning the project won't work at all if it relies on 'require'.
 
-> The more elegant and recommended solution is the just-in-time compilation:
->
-> * Source and Lua files can't be out of sync.
-> * Developer friendly workflow.
-> * Runtime error line translation is usually done by the compiler without extra care.
-> * Allows reload during development.
+:::note
+The more elegant and recommended solution is the just-in-time compilation:
+* Source and Lua files can't be out of sync.
+* Developer friendly workflow.
+* Runtime error line translation is usually done by the compiler without extra care.
+* Allows reload during development.
+:::
 
 CSharp.lua (C# dialect)
 ---