change(/wiki): i forgor to commit

Author: Longor1996

.vscode/launch.json

@@ -0,0 +1,16 @@
+{
+	"configurations": [
+		{
+			"name": "Zola: Watch",
+			"type": "f5anything",
+			"request": "launch",
+			"command": "just dev"
+		},
+		{
+			"name": "Zola: Watch (open browser)",
+			"type": "f5anything",
+			"request": "launch",
+			"command": "just dev-open"
+		}
+	]
+}

content/_index.md

@@ -33,7 +33,7 @@ link = "/wiki/procedural-generation"
 
 [[extra.list]]
 title = "Engines"
-content = "Don't want to start entirely from scratch? Fear not! There are various <a href='wiki/engines'>Game Engines</a> you can use as basis for your project..."
+content = "Don't want to start entirely <a href='wiki/engine-creation'>from scratch</a>? Fear not! There are various <a href='wiki/engines'>Game Engines</a> you can use as basis for your project..."
 link = "/wiki/engines"
 
 [[extra.list]]

content/wiki/compression/index.md

@@ -15,9 +15,10 @@ Once we have our data structure of choice in place, we might still want (or outr
 
 To remedy these issues, we'll have to *compress* our voxels, for which there are many methods...
 
-- [Lossy Compression](/wiki/lossy-compression)
-- [Palette Compression](/wiki/palette-compression)
 - [Run-Length Encoding](/wiki/run-length-encoding)
+- [Palette Compression](/wiki/palette-compression)
+- [LZW Compression](/wiki/lzw-compression)
+- [Lossy Compression](/wiki/lossy-compression)
 
 > **Note:** Compressing voxel data is, of course, also greatly useful for persistence and networking.
 

content/wiki/datastructures/index.md

@@ -7,8 +7,6 @@ categories = ["datastructures"]
 tags = ["datastructures", "storage", "spatial-acceleration"]
 +++
 
-{% info_notice() %} Note: This section is about *runtime* storage, not [serialization](/wiki/serialization). {% end %}
-
 The simplest way to store voxels is to define a three-dimensional array of elements (be it `struct`s or `integer`s), where each element represents a single voxel:
 
 ```c#
@@ -41,7 +39,8 @@ var voxels = new VOXEL[height * depth * width];
 // So let's define a function (here a lambda) for it:
 var idx = (int x, int y, int z) => (x + z*width + y*width*depth);
 // ^ NOTE: You may want to throw an error right here
-//         if the coordinate components are out of bounds.
+//         if either the coordinate components
+//         or the resulting index are out of bounds.
 
 // Set a voxel:
 voxels[idx(x,y,z)] = voxel;
@@ -52,7 +51,7 @@ var voxel = voxels[idx(x,y,z)];
 
 Now, storing voxels in a plain array like this is perfectly fine for small scenes...
 
-However, for larger scenes, we'll have to use a data-structure that allows both loading and purging *parts of our volume* (called [Chunks](/wiki/chunking)) from memory, nearly in realtime, without slowing down *accessing* our voxel data.
+However, for larger scenes, we'll have to use a data-structure that allows both loading and purging *parts of our volume* (called [Chunks](/wiki/chunking) or Bricks) from memory, nearly in realtime, without slowing down the *access times* of our voxel data too much.
 
 > **Note:** These techniques can often be combined.
 

content/wiki/engine-creation/index.md

@@ -33,12 +33,15 @@ The core of a game engine is (similar to an operating system) an abstraction for
 - The Core Lifecycle
 - The Task Manager
 - The Data/Asset Model
+- The User Interface
 - The Scene Structure
+- The Render Abstraction
+- The Streaming Mechanism
 - The Extension Mechanism
 
 {% info_notice() %}
 **Note:** Since *everything else* is built on top of these, some serious thought should be put into their design.
-Rebuilding/replacing them at a later time is considered a Bad Idea™, as they influence every part of the engine.
+Rebuilding/replacing them at a later time is considered a Very Bad Idea™, as they influence every part of the engine.
 {% end %}
 
 While the following sections will explain each concept on its own, do keep in mind that they're highly intertwined.
@@ -59,10 +62,22 @@ While the following sections will explain each concept on its own, do keep in mi
 
 {{stub_notice(kind="section")}}
 
+### The User Interface
+
+{{stub_notice(kind="section")}}
+
 ### The Scene Structure
 
 {{stub_notice(kind="section")}}
 
+### The Render Abstraction
+
+{{stub_notice(kind="section")}}
+
+### The Streaming Mechanism
+
+{{stub_notice(kind="section")}}
+
 ### The Extension Mechanism
 
 {{stub_notice(kind="section")}}

content/wiki/engines/index.md

@@ -36,10 +36,12 @@ Following are a few things you must keep in mind and be aware of **before** you
 2. It is a *massive* amount of work, potentially spanning over years of your life.
 3. Having several years of programming experience is a must; nobody will hold your hand in this endeavour.
 4. All the tooling for asset-, level- and gameplay-creation? You'll have to make them.
-5. Running into driver bugs will eat a lot of time and cause premature balding.
+5. Running into driver bugs and various platform/OS differences will eat a lot of time and cause premature balding.
 
 The above list might make you question *"Why would anyone do this?!"*, to which most of [us](/wiki/community) will say... because it's fun! :D
 
 A more concrete reason is that, by writing both the high- and low-level code, you can gain *a lot* of performance (that'd otherwise be left on the table) *and* the freedom to make some truly awesome things.
 
-{% todo_notice() %} Create an article for game engine creation. {% end %}
+But with that said, keep in mind that *creating a game* is still best done with an existing engine.
+
+If you're still here, [let's get started](/wiki/engine-creation), shall we?

content/wiki/palette-compression/index.md

@@ -6,8 +6,6 @@ categories = ["compression"]
 tags = ["compression", "optimization", "flyweight"]
 +++
 
-> This is a rewrite; the original article can be found here: [https://www.longor.net/articles/voxel-palette-compression-reddit](https://www.longor.net/articles/voxel-palette-compression-reddit)
-
 When writing a voxel engine, eventually you will come to realize that storing your voxels as 32-bit integers (or worse: as individual heap-allocated objects!) is eating a lot more memory than you'd like, potentially slowing down your game without any obvious reason as to *why*, and doing [bit-twiddling](https://graphics.stanford.edu/~seander/bithacks.html) to pack your data into a smaller space, is probably giving you quite a headache, so you might be thinking: There *has* to be a better way! *Right*...?
 
 **And there is!**
@@ -91,3 +89,7 @@ Given a 32-bit architecture which aligns allocations on 32-bit/4-byte boundaries
 This gives you at minimum ***31 bits*** to encode a voxel type in (*63* bits on a 64-bit CPU!), which should be *way* more than enough for terrain (which tends to make up the majority of a voxel world by sheer volume), thus eliminating a *ton* of allocations and pointers!
 
 {% todo_notice() %} Implementation? {% end %}
+
+## References
+
+This article is a rewrite; the original article can be found here: [https://www.longor.net/articles/voxel-palette-compression-reddit](https://www.longor.net/articles/voxel-palette-compression-reddit)

content/wiki/rendering/index.md

@@ -19,21 +19,21 @@ Since there is no way to write about all possible methods, this article will tal
 ## Hardware Acceleration
 
 Talking about rendering is impossible without talking about hardware acceleration
-and thus **GPU**s (*Graphics Processing Unit*); so let's do that real quick!
+and thus <abbr title="Graphics Processing Units">GPUs</abbr>; so let's do that real quick!
 
 The primary purpose of a GPU is to calculate/compute/solve a *massive* number of highly similar problems[^embarassinglyparallel] "all at once",
 by splitting up large sets of data into smaller groups, which are then worked thru by a large number of tiny processing units[^gpumanycores].
 
 {% info_notice() %}
 [Historically](https://en.wikipedia.org/wiki/Graphics_processing_unit#History),
-the problem in question was mainly [rasterization](https://en.wikipedia.org/wiki/Rasterisation)
+the problem in question was mainly vertex transformation and [rasterization](https://en.wikipedia.org/wiki/Rasterisation)
 (and later fragment processing) of triangles via GPUs on dedicated [graphics cards](https://en.wikipedia.org/wiki/Graphics_card).
 
 These days GPUs are much more [general purpose](https://en.wikipedia.org/wiki/General-purpose_computing_on_graphics_processing_units)
 and are used in so many applications that we won't bother listing them here.
 {% end %}
 
-To hopefully nobodies surprise, rendering voxels *is* such a massively parallel process, that *not* using GPUs would be very (very) silly.
+To hopefully nobodies surprise, rendering voxels is *such* a massively parallel process, that *not* using GPUs would be very (very) silly!
 
 How do we gain access to the awesome processing power of GPUs? Well...
 
@@ -79,8 +79,9 @@ so check out their documentation before rejecting any!
 
 ## Windowing Abstraction Libraries
 
-Creating a surface to actually draw into is, due to the many platforms that exist,
-terribly annoying, so it's best to leave it to a windowing library...
+Creating a surface to actually draw into is *terribly* annoying,
+due to the many platforms and operating systems that exist,
+so it's best to leave it to a windowing library...
 
 | Name | Language | Platforms |
 |------|----------|-----------|