Merge pull request #363 from Luracasmus/patch-6

fix: formatting, broken links, missing descriptions and depth texture formats & mod: minor changes

Author: jbritain

src/content/docs/404.mdx

@@ -6,15 +6,15 @@ hero:
   title: 404 Page Not Found
   tagline: This wasn't what you were looking for, we're sorry we led you astray.
 ---
+
 import { LinkCard } from '@astrojs/starlight/components';
 
 <LinkCard
   title="Go to home"
   href="/"
 />
 
-
-*Psst*  
-Can you hear me? *Shhhh*, don't say anything. They're watching...  
-Listen, I can't explain here, take this: [(handwritten note)](https://shader.properties)  
+*Psst*
+Can you hear me? *Shhhh*, don't say anything. They're watching...
+Listen, I can't explain here, take this: [(handwritten note)](https://shader.properties)
 Be careful, I'll catch up with you later.

src/content/docs/current/Guides/Your First Shader/0_intro.mdx

@@ -42,4 +42,4 @@ A "shader" is, by definition, any program that is executed on the GPU. For Minec
 Odds are, all your previous code has been executed on the CPU. Shaders are instead executed on the GPU (also know as a graphics or video card). CPUs are great at performing complex sequential tasks, whereas GPUs are great are executing simple tasks in parallel. In fact, modern high-end graphics cards are capable of performing *trillions* of calculations per second! You can read more about the differences [here](https://www.intel.com/content/www/us/en/products/docs/processors/cpu-vs-gpu.html).
 :::
 
-For a full list of programs and what they do, see the [Iris Docs](https://shaders.properties/current/reference/programs/overview/).
+For a full list of programs and what they do, see the [Iris Docs](/current/reference/programs/overview/).

src/content/docs/current/Guides/Your First Shader/1_composite.mdx

@@ -124,7 +124,7 @@ This is where we recieve the `texcoord` passed `out` in the vertex shader. This
 /* RENDERTARGETS: 0 */
 ```
 
-This is a comment that the Iris patcher reads. It tells the shader to write back to `colortex0`. For more info, see [the docs](/current/reference/constants/rendertargets).
+This is a comment that the Iris patcher reads. It tells the shader to write back to `colortex0`. For more info, see [the docs](/current/reference/constants/rendertargets/).
 
 ```glsl
 layout(location = 0) out vec4 color;

src/content/docs/current/Guides/Your First Shader/2_gbuffers.mdx

@@ -165,7 +165,7 @@ layout(location = 1) out vec4 someMoreData; // writes to colortex3
 
 
 :::note[Note]
-Iris implements by default something known as 'buffer flipping'. This means that the texture you write to is not actually the same one you read from. This is because different instances of the shader might run at different times and if multiple of them try to access the same pixel, the output could be different depending on which one gets to it first. For more information, see [the docs](/current/reference/shadersproperties/rendering#flip)
+Iris implements by default something known as 'buffer flipping'. This means that the texture you write to is not actually the same one you read from. This is because different instances of the shader might run at different times and if multiple of them try to access the same pixel, the output could be different depending on which one gets to it first. For more information, see [the docs](/current/reference/shadersproperties/rendering/#flip)
 :::
 
 Finally, in main, let's write this data to the textures, so we can access it in `composite`.

src/content/docs/current/Guides/Your First Shader/4_shadows.mdx

@@ -144,7 +144,7 @@ Your shadows should now look a lot more reasonable.
 ![](../../../../../assets/beginner_tutorial/basicshadows.webp)
 
 ## Making Shadows Sharper
-At the moment, our shadows are extremely blocky. This is due to the limited resolution of the shadow map. We can improve things somewhat by increasing this, using the [`shadowMapResolution`](/current/reference/constant/shadowmapresolution) const. This constant can be defined anywhere, but just because it's a nice place to put it, we'll go back to `shadow.fsh`. Let's add the following. It should be outside the `main` function - I put mine just before my `layout` qualifier declaration.
+At the moment, our shadows are extremely blocky. This is due to the limited resolution of the shadow map. We can improve things somewhat by increasing this, using the [`shadowMapResolution`](/current/reference/constant/shadowmapresolution/) const. This constant can be defined anywhere, but just because it's a nice place to put it, we'll go back to `shadow.fsh`. Let's add the following. It should be outside the `main` function - I put mine just before my `layout` qualifier declaration.
 
 ```glsl
 const int shadowMapResolution = 2048;
@@ -390,7 +390,7 @@ Our shadows now have soft edges, and the aliasing artifacts are no longer visibl
 
 ![](../../../../../assets/beginner_tutorial/lownoise.webp)
 
-You'll see the pixels in `noisetex` are pretty chunky. This is because it has a resolution of 64x64, and is being stretched to fit the screen. We could just increase the resolution, but to ensure we're getting a unique value for every pixel, we'll instead use a function called `texelFetch`. `texelFetch` takes in an exact pixel coordinate in a texture and returns the value there without doing any filtering. We will need to convert our `texcoord` to a pixel coordinate within the range (0-64). We can do this using another couple of uniforms, [`viewWidth`](/current/reference/uniforms/system#viewwidth) and [`viewHeight`](/current/reference/uniforms/system#viewheight) (both `float`s). We will also make use of the type `ivec2` which is like a `vec2` except it can store only integer values. Let's make another new function called `getNoise`. It will take in a vec2 texcoord and return a vec4, the lookup value from `noisetex`. We're going to access it in `getSoftShadow` so it should be placed before this function.
+You'll see the pixels in `noisetex` are pretty chunky. This is because it has a resolution of 64x64, and is being stretched to fit the screen. We could just increase the resolution, but to ensure we're getting a unique value for every pixel, we'll instead use a function called `texelFetch`. `texelFetch` takes in an exact pixel coordinate in a texture and returns the value there without doing any filtering. We will need to convert our `texcoord` to a pixel coordinate within the range (0-64). We can do this using another couple of uniforms, [`viewWidth`](/current/reference/uniforms/system/#viewwidth) and [`viewHeight`](/current/reference/uniforms/system/#viewheight) (both `float`s). We will also make use of the type `ivec2` which is like a `vec2` except it can store only integer values. Let's make another new function called `getNoise`. It will take in a vec2 texcoord and return a vec4, the lookup value from `noisetex`. We're going to access it in `getSoftShadow` so it should be placed before this function.
 
 ```glsl
 vec4 getNoise(vec2 coord){

src/content/docs/current/Guides/Your First Shader/5_fog.mdx

@@ -55,9 +55,9 @@ It's good practice to try to minimise duplicate code as much as possible. To org
 
 ## The Fog is Coming
 
-What we want is for something which is nearly out of render distance to have lots of fog, and something which is close to the player not to have any fog at all. To do this, we can divide the distance from the player by a uniform `float`, [`far`](/current/reference/uniforms/rendering#far). The name of this variable is misleading, as what it gives us is the player's render distance, in blocks.
+What we want is for something which is nearly out of render distance to have lots of fog, and something which is close to the player not to have any fog at all. To do this, we can divide the distance from the player by a uniform `float`, [`far`](/current/reference/uniforms/rendering/#far). The name of this variable is misleading, as what it gives us is the player's render distance, in blocks.
 
-Of course, we also need to have a fog color to blend with, and for this, we'll use another uniform, a `vec3` [`fogColor`](/current/reference/uniforms/rendering#fogcolor).
+Of course, we also need to have a fog color to blend with, and for this, we'll use another uniform, a `vec3` [`fogColor`](/current/reference/uniforms/rendering/#fogcolor).
 
 We can then simply do
 

src/content/docs/current/Guides/Your First Shader/6_next_steps.mdx

@@ -14,7 +14,7 @@ This is as far as we go with the tutorial, but there's plenty more that can be d
 Right now, our entities appear partially translucent. This is because we have only written a `gbuffers_terrain` program. Entities are handled by `gbuffers_entities`, which falls back to `gbuffers_textured_lit`. Since we have not overriden this program, it doesn't write our normals or lightmap data to the buffers we need it to. An easy way to resolve this is to rename `gbuffers_terrain` to `gbuffers_textured_lit`, which most programs we care about will fall back to. For more information, see [Gbuffers](/current/reference/programs/gbuffers/).
 
 ### Bright Night
-Since our sunlight and skylight colors are constant, things are still very well lit at night. This can be improved by varying the skylight and sunlight colors based on the time of day. We can do this using the uniform [`worldTime`](/current/reference/uniforms/world#worldtime).
+Since our sunlight and skylight colors are constant, things are still very well lit at night. This can be improved by varying the skylight and sunlight colors based on the time of day. We can do this using the uniform [`worldTime`](/current/reference/uniforms/world/#worldtime).
 
 ## Things to Do
 Here are some things you could try adding to your shader next. Some of these are more complex than others, and may require additional research into graphics programming.

src/content/docs/current/How To/coordinate_spaces.mdx

@@ -20,10 +20,10 @@ This page is designed to be read in tandem with this cheatsheet, which shows eve
 ## Spaces
 
 ### Model Space
-In Iris (and OptiFine), **model space** is whatever coordinate space the vertex position attribute is sent in. The exact coordinate space varies based on the specific geometry, and has the potential to vary across different Minecraft versions. As a result, it is always recommended to treat *model space* like an unknown space and convert to view space with the `gl_ModelViewMatrix`/[`modelViewMatrix`](/current/reference/uniforms/matrices#modelviewmatrix). **Model space** is also sometimes known as "**local space**".
+In Iris (and OptiFine), **model space** is whatever coordinate space the vertex position attribute is sent in. The exact coordinate space varies based on the specific geometry, and has the potential to vary across different Minecraft versions. As a result, it is always recommended to treat *model space* like an unknown space and convert to view space with the `gl_ModelViewMatrix`/[`modelViewMatrix`](/current/reference/uniforms/matrices/#modelviewmatrix). **Model space** is also sometimes known as "**local space**".
 
 
-If using the core profile (and as such using [`vaPosition`](/current/reference/attributes/vaposition) instead of `gl_Vertex`), the *model space* position for terrain should be offset with [`chunkOffset`](/current/reference/uniforms/rendering#chunkoffset). The conversion sheet assumes this has already been done. Here's an example of what that should look like:
+If using the core profile (and as such using [`vaPosition`](/current/reference/attributes/vaposition) instead of `gl_Vertex`), the *model space* position for terrain should be offset with [`chunkOffset`](/current/reference/uniforms/rendering/#chunkoffset). The conversion sheet assumes this has already been done. Here's an example of what that should look like:
 ```glsl
 vec3 model_pos = vaPosition + chunkOffset;
 ```
@@ -36,17 +36,17 @@ The `x` and `y` components of view space line up with screen space (negative is
 ### Player Space
 *Player space* is the vertex position relative to the *camera* (not the player). The difference between view and **player space** is that whilst **view space** directions change based on the camera angle, **player space** directions are constant, aligned to the axes of Minecraft's coordinates. For example, a `vec3(0.0, 1.0, 0.0)` is along the Y axis and as such would be along Minecraft's actual Y axis (upwards).
 
-To get a position which is relative to the actual player model in third person, you can use [`relativeEyePosition`](/current/reference/uniforms/camera#relativeeyeposition).
+To get a position which is relative to the actual player model in third person, you can use [`relativeEyePosition`](/current/reference/uniforms/camera/#relativeeyeposition).
 
 #### Feet and Eye Player Space
-The names of these spaces are misleading, as "**feet player space**" is not in any way related to the player's feet. The difference between the two is that in **feet player space**, the origin remains locked to the player's head position, whereas in **eye player space**, effects like view bobbing are accounted for, meaning that the origin is locked to the camera. This is why the two can be interchanged with the addition and subtraction of [`gbufferModelViewInverse[3]`](/current/reference/uniforms/matrices#gbuffermodelviewinverse) - this fourth component of the matrix accounts for the translation from the player's head to the camera.
+The names of these spaces are misleading, as "**feet player space**" is not in any way related to the player's feet. The difference between the two is that in **feet player space**, the origin remains locked to the player's head position, whereas in **eye player space**, effects like view bobbing are accounted for, meaning that the origin is locked to the camera. This is why the two can be interchanged with the addition and subtraction of [`gbufferModelViewInverse[3]`](/current/reference/uniforms/matrices/#gbuffermodelviewinverse) - this fourth component of the matrix accounts for the translation from the player's head to the camera.
 
 It is also worth noting that in third person mode, view bobbing is disabled, and as such, eye and feet player space are *usually* identical.
 
 ### World Space
-**World space** is the vertex position in Minecraft's actual coordinate system. It is directionally equivalent to **player space**, as it is simply the result of offsetting a *feet player space* position by the camera position. This roughly lines up with the game's actual coordinate positions, however [`cameraPosition`](/current/reference/uniforms/camera#cameraposition) resets every 30000 blocks (or every 1000 blocks when teleporting). If the exact Minecraft position is required, [`cameraPositionInt`](/current/reference/uniforms/camera#camerapositionint) and [`cameraPositionFract`](/current/reference/uniforms/camera#camerapositionfract) can be used
+**World space** is the vertex position in Minecraft's actual coordinate system. It is directionally equivalent to **player space**, as it is simply the result of offsetting a *feet player space* position by the camera position. This roughly lines up with the game's actual coordinate positions, however [`cameraPosition`](/current/reference/uniforms/camera/#cameraposition) resets every 30000 blocks (or every 1000 blocks when teleporting). If the exact Minecraft position is required, [`cameraPositionInt`](/current/reference/uniforms/camera/#camerapositionint) and [`cameraPositionFract`](/current/reference/uniforms/camera/#camerapositionfract) can be used
 
 ## Shadow Space
-"Shadow Space" can refer to a number of different coordinate spaces, all of which are used for the [shadow pass](/current/reference/programs/shadow). As such, the "shadow" versions of coordinate spaces are generally equivalent to their normal versions but from the perspective of the shadow camera (the sun/moon). The shadow spaces include **shadow view space**, **shadow clip space**, **shadow NDC space**, and **shadow screen space**.
+"Shadow Space" can refer to a number of different coordinate spaces, all of which are used for the [shadow pass](/current/reference/programs/shadow/). As such, the "shadow" versions of coordinate spaces are generally equivalent to their normal versions but from the perspective of the shadow camera (the sun/moon). The shadow spaces include **shadow view space**, **shadow clip space**, **shadow NDC space**, and **shadow screen space**.
 
-In the [shadow pass](/current/reference/programs/shadow), the same base matrices are used ([`modelViewMatrix`](/current/reference/uniforms/matrices#modelviewmatrix), [`projectionMatrix`](/current/reference/uniforms/matrices#projectionmatrix), etc), or the `shadow` matrix uniforms (e.g. [`shadowModelView`](/current/reference/uniforms/matrices#shadowmodelview), [`shadowProjection`](/current/reference/uniforms/matrices#shadowprojection)) can be used from any program. When sampling the shadow map, positions can be transformed into **player space**, and from there back into *shadow screen space*.
+In the [shadow pass](/current/reference/programs/shadow/), the same base matrices are used ([`modelViewMatrix`](/current/reference/uniforms/matrices/#modelviewmatrix), [`projectionMatrix`](/current/reference/uniforms/matrices/#projectionmatrix), etc), or the `shadow` matrix uniforms (e.g. [`shadowModelView`](/current/reference/uniforms/matrices/#shadowmodelview), [`shadowProjection`](/current/reference/uniforms/matrices/#shadowprojection)) can be used from any program. When sampling the shadow map, positions can be transformed into **player space**, and from there back into *shadow screen space*.

src/content/docs/current/Reference/Attributes/mc_Entity.mdx

@@ -12,14 +12,14 @@ sidebar:
 
 ---
 
-The `x` component stores the block ID which was assigned to the current block in [`block.properties`](/current/reference/miscellaneous/block_properties). If an ID for the current block is not defined, a value of `-1` is sent.
+The `x` component stores the block ID which was assigned to the current block in [`block.properties`](/current/reference/miscellaneous/block_properties/). If an ID for the current block is not defined, a value of `-1` is sent.
 
 :::tip
 Iris 1.3 and later (as well as OptiFine) uses a signed short for `mc_Entity`, meaning they can store IDs from `-32768` to `32767`. Older Iris versions do not support negative values, and will send the maximum unsigned value,`65535`, for any blocks with unassigned IDs.
 :::
 
-When [`block.properties`](/current/reference/miscellaneous/block_properties) is not present in the shader pack files, block IDs are assigned according to their pre 1.13 numerical values, as described in the [Minecraft Wiki](https://minecraft.wiki/w/Java_Edition_data_values/Pre-flattening#Block_IDs). This is intended for legacy purposes, and should not be used for new shader packs.
+When [`block.properties`](/current/reference/miscellaneous/block_properties/) is not present in the shader pack files, block IDs are assigned according to their pre 1.13 numerical values, as described in the [Minecraft Wiki](https://minecraft.wiki/w/Java_Edition_data_values/Pre-flattening/#Block_IDs). This is intended for legacy purposes, and should not be used for new shader packs.
 
 The `y` component stores the "render type", which is `1` for fluids (water, lava, etc) and `-1` for all other blocks.
 
-This attribute is only available for terrain. For other types of geometry, see [`entityid`](/current/reference/uniforms/id#entityid) and [`blockentityid`](/current/reference/uniforms/id#blockentityid).
+This attribute is only available for terrain. For other types of geometry, see [`entityid`](/current/reference/uniforms/id/#entityid) and [`blockentityid`](/current/reference/uniforms/id/#blockentityid).