Lots of grammar/spelling issues & rewrote some docs

docs/1-introduction/1-1-getting-started/1-1-0-overview.md

@@ -1,23 +1,32 @@
 # Overview
 
-As many may know or not know, there's a few choices in terms of what to use for graphics, such as OpenGL, Vulkan, Metal and what is commonly known as "DirectX".
-However in word of mouth DirectX usually refers to Direct3D, which is one of the many API's that DirectX has, as it is less known that DirectX is more than just graphics, it is:
+As you may or may not know, there's a few choices in terms of what you can use for rendering, such
+as OpenGL, Vulkan, Metal, and what is commonly known as "DirectX". However, in word of mouth
+DirectX usually refers to Direct3D, which is one of the many API's that DirectX has. In fact
+DirectX provides tooling and libraries for more aspects of game development, including:
 
 - **Audio**
-
 - **Fonts**
-
 - **Input**
-
 - **Graphics**
 
-And _other things_ more or less targeted at stuff one needs for game development.
+The goal of LearnD3D11 is, as one might guess, the targeted explanation and showcase of Direct3D11
+within C++, or as one generally refers to it: "DirectX 11". This guide does _NOT_ cover DirectX 12,
+the newer version of the API, as it is very low level and will usually require a good understanding
+of the GPU and how it works. We will cover concepts and some techniques used in graphics programming,
+and we do not expect you to have any prerequisites in this field. It is, however, not a guide
+covering C++ or programming in general; we expect at least the ability and understanding to write
+object-oriented programs in C++.
 
-The goal of LearnD3D11 is as one might guess is the targeted explanation and showcase of Direct3D11 or as one generally refers to it: "DirectX 11".
+During each step we'll provide a project for you to follow along as we explain everything for you
+to start rendering geometry using your GPU.
 
-During each step we'll provide a project for you to follow along as we explain each individual thing needed to get some graphics on your own screen.
+Also note that DirectX is made by Microsoft and is generally only available on Windows. However,
+`DXVK` was developed to run D3D9 through D3D11 on Linux or Wine on top of Vulkan and would be the
+only way of developing and using D3D11 on those platforms. 
 
-This initial section will cover creating the actual window, initializing Direct3D11 and getting our very first visuals (which is commonly known as the Hello Triangle)
+This initial section will cover creating the actual window, initializing Direct3D11 and getting our
+very first visuals (which is commonly known as the Hello Triangle)
 
 ## Project structure
 
@@ -45,5 +54,3 @@ x-x-x-project.vcxproj
 - `obj/` contains all intermediate junk the compiler produced, to keep the folder structure clean
 - `bin/` will contain the compiled program of the chapter along with all necessary `Assets`
 - `Assets/` will contain all the used assets, such as models, shaders and textures and other things. It will be empty for the first few chapters, and we will copy it and its contents to the bin/Debug or bin/Release directory, depending on which configuration you chose
-
-[Next chapter](../1-1-1-hello-window/)

docs/1-introduction/1-1-getting-started/1-1-1-hello-window.md

@@ -98,18 +98,18 @@ resolution you use. Size-wise it will cover 90% of your main monitor.
 glfwWindowHint(GLFW_SCALE_TO_MONITOR, GLFW_FALSE);
 ```
 
-This will tell `GLFW` to not scale the window in any way, should you have setup a specific scaling
-other than 100% on your desktop. That will keep the windowsize at what we set it, without thinking
-about odd fractionals to manually scale the windowsize for any arbitrary scaling on your OS.
+This will tell `GLFW` to not scale the window in any way, should you have set up a specific scaling
+other than 100% on your desktop. That will keep the window size at what we set it, and lets us
+forget about fractional window and pixel scaling.
 
 ```cpp
 glfwWindowHint(GLFW_CLIENT_API, GLFW_NO_API);
 ```
 
 `GLFW` was initially meant to support development of OpenGL based applications, hence the gl in its
 name, but over the years it also started to support other APIs and not just OpenGL. Now since `GLFW`
-automatically creates a context for OpenGL and we want to use DirectX, we will have to tell it to not
-to do so via [glfwWindowHint](https://www.glfw.org/docs/3.3/group__window.html#ga7d9c8c62384b1e2821c4dc48952d2033).
+by default creates a context for OpenGL, and as we want to use DirectX we need to tell `GLFW`
+to not do so via [glfwWindowHint](https://www.glfw.org/docs/3.3/group__window.html#ga7d9c8c62384b1e2821c4dc48952d2033).
 
 There are many other options one can define through glfwWindowHint which can be found [here](https://www.glfw.org/docs/3.3/group__window.html).
 Many of these options might be useful in your application, depending on what you want and how you
@@ -156,7 +156,7 @@ That is more or less the heart of your application, the mainloop.
 You could also call it game loop, since in here everything happens.
 From reading keyboard and mouse input, reacting to it, to telling the graphics
 card to put a frog on the screen. It will keep doing it, until it gets signaled
-to not to do that anymore because you closed the window for example
+to not do that anymore because you closed the window for example
 ([glfwWindowShouldClose](https://www.glfw.org/docs/3.3/group__window.html#ga24e02fbfefbb81fc45320989f8140ab5)),
 or hit Escape and mapped Escape to close the window. [glfwPollEvents](https://www.glfw.org/docs/3.3/group__window.html#ga37bd57223967b4211d60ca1a0bf3c832)
 will make sure that `GLFW` knows about all required events coming from the operating system.
@@ -200,7 +200,7 @@ The further we go into this tutorial series the more stuff we will add to the pr
 But we don't want to cram everything into `Main.cpp`, your main entry point of the program.
 A good practise is to split up things into smaller units, to not lose overview.
 
-Right now we dont have much to show for, just a window, made by a few lines of code,
+Right now we don't have much to show for, just a window, made by a few lines of code,
 but we are going to abstract that code into a new class called `Application` which will also be
 our main container so to speak, in which all the magic will happen.
 
@@ -363,9 +363,9 @@ int main(int argc, char* argv[])
 }
 ```
 
-Let's start with `Main.cpp`. That's all its doing, creating the hellowindow application and running it.
+Let's start with `Main.cpp`. That's all its doing, creating the "hellowindow" application and running it.
 In the future this can be accompanied by loading a configuration, initializing a logger,
-initiating a connection to a possible server server, or other stuff.
+initiating a connection to a possible server, or other stuff.
 
 ```cpp
 public:
@@ -377,7 +377,7 @@ public:
 This is a section of the `Application` class, showing only its publicly available methods. `Run` being
 the most important one to the outside world, like `Main`, it's the entry point into this Application.
 
-We still dont want to cram everything into one main or one method, therefore `Run` is split up
+We still don't want to cram everything into one main or one method, therefore `Run` is split up
 again into the following blocks.
 
 ```cpp
@@ -402,22 +402,22 @@ void Application::Run()
 }
 ```
 
-You can clearly see what it is doing. `Initialize`, as the name suggests, will initialize everything
-which is required for the app to run, which currently is the window in our case. In future chapters it
-will also including initializing `D3D11` and its resources or imgui for some UI.
+This function is pretty simple. `Initialize`, as the name suggests, will initialize everything
+which is required for the app to run, which currently is the window in our case. In future
+chapters it will also include initializing `D3D11`, its resources, and ImGUI for the UI.
 
-`Load`s purpose is to load all the assets required to run the application, in further chapters it will
+`Load`'s purpose is to load all the assets required to run the application, in further chapters it will
 encompass textures, shaders, models and other things.
 
-The next block is the aforementioned mainloop or gameloop, which still does what it was doing before,
-checking with the OS if events need to be processed and now we also call a `Update` and `Render` method.
+The next block is the aforementioned mainloop or game loop, which still does what it was doing before,
+checking with the OS if events need to be processed, and now we also call a `Update` and `Render` method.
 
 `Update` may contain queries about pressed key or mouse buttons, updating variables or other things
 which are - for instance - reflected on display inside the `Render` method.
 
 You probably have noticed that all the protected method in `Application` are virtual, that's because
 we are deriving from `Application` in form of `HelloWindowApplication` and only focus on those four
-methods if required. We now dont have to deal with the mainloop anymore for the time being.
+methods if required. We now don't have to deal with the mainloop anymore for the time being.
 
 ```cpp
 virtual void Cleanup();
@@ -438,5 +438,3 @@ and more.
 [Raw Winapi Hello Window Project on GitHub](https://github.com/GraphicsProgramming/learnd3d11/tree/main/src/Cpp/1-getting-started/1-1-1-HelloWin32Window)
 
 [Project on GitHub](https://github.com/GraphicsProgramming/learnd3d11/tree/main/src/Cpp/1-getting-started/1-1-1-HelloWindow)
-
-[Next chapter](../1-1-2-hello-d3d11/)

docs/1-introduction/1-1-getting-started/1-1-2-hello-d3d11.md

@@ -1,16 +1,16 @@
 # Hello D3D11
 
 In this chapter, we'll introduce you to the basics of using D3D11; how to create a ID3D11Device and
-how to use it to show something in our window. In the last chapter we setup a basic implementation
+how to use it to show something in our window. In the last chapter we set up a basic implementation
 for an application with a window through GLFW. The implementation for `Main.cpp` and
 `Application.cpp` won't be shown here anymore.
 
-If you are looking at the source code for this chapter, you will also notice that
-`Application.cpp` and `Application.hpp` do not exist anymore, as we have moved both of these
-files into a separate `Framework` project to ease development between chapters. This `Framework`
-project will include code that is shared between all chapters, so it might include a lot of other
-files which are not used or are not relevant within some chapters. Please note that the code for
-already existing files is also subject to change to accomodate newer chapters and their needs.
+If you are looking at the source code for this chapter, you will also notice that `Application.cpp`
+and `Application.hpp` do not exist anymore, as we have moved both of these files into a separate
+`Framework` project to ease development between chapters. This `Framework` project will include
+code that is shared between all chapters, so it might include a lot of other files which are not
+used or are not relevant within some chapters. Please note that the code for already existing files
+is also subject to change to accommodate newer chapters and their needs.
 
 However, let's start by breaking down the relevant bits and pieces by showing you how the new
 class, which derives from `Application` will look like.
@@ -173,7 +173,7 @@ You might have noticed that we are not using raw pointers for those pieces, but
 
 `DXGI` stands for DirectX Graphics Infrastructure, in case you are wondering.
 
-Lets go in to `Initialize`
+Let's go in to `Initialize`
 
 ```cpp
 if (!Application::Initialize())
@@ -192,7 +192,7 @@ if (FAILED(CreateDXGIFactory2(
 
 The first part calls the parent class, where `GLFW` is initialized and setup.
 
-`IID_PPV_ARGS(ppType)` Is a compile time macro that is defined as 
+`IID_PPV_ARGS(ppType)` Is a compile-time macro that is defined as 
 ```cpp
 #define IID_PPV_ARGS(ppType) __uuidof(**(ppType)), IID_PPV_ARGS_Helper(ppType)
 ```
@@ -211,7 +211,7 @@ HRESULT CreateDXGIFactory2(
 What the parts of the `IID_PPV_ARGS(ppType)` macro are: 
 
 [the `ppType` in `IID_PPV_ARGS(ppType)`]
-- a pointer to a pointer of a object.
+- a pointer to a pointer of an object.
 
 [the `__uuidof(**(ppType))` part of `IID_PPV_ARGS(ppType)`]
 -  at compile time retrieves a `UUID` from `ppType` type which represents a `GUID`, which is returned as a `REFIID` — which means that the type returned is a reference to an identifier to a specific type of COM object.   
@@ -245,7 +245,7 @@ if (FAILED(D3D11CreateDevice(
 }
 ```
 
-This block is the the entry point into D3D11, where we ask for a device and its device context to be created. The input parameters are:
+This block is the entry point into D3D11, where we ask for a device and its device context to be created. The input parameters are:
 
 We want a LEVEL_11_0, hardware accelerated device, which has support for a specific color format.
 Feature levels are a concept that has been introduced with D3D11, it is a way to specify which set of features we would like to use. Each GPU may support different feature levels (for example a very old GPU might only support LEVEL_9_1, while a more modern one may support every feature level up to, and including LEVEL_11_0), this is a way to avoid rewriting our application in D3D9 just because our GPU doesn't support D3D11.
@@ -290,7 +290,7 @@ The majority of values should make some sense without explanation, like width an
 
 `BufferCount` is 2, because we want double buffering. Double buffering is an age-old technique to avoid presenting an image that is being used by the GPU, instead we work on the "back buffer", while the GPU is happy presenting the "front buffer", then, as soon as we are done with the back buffer, we swap front and back, and begin working on the former front buffer present that one and render to the other one again in the meantime. That process is supposed to reduce flicker or tearing.
 
-`SwapEffect` specifies if the contents of the back buffer should be preserved or discarded after a swap, here we don't care about preserving the back buffer so we just discard everything.
+`SwapEffect` specifies if the contents of the back buffer should be preserved or discarded after a swap, here we don't care about preserving the back buffer, so we just discard everything.
 
 `AlphaMode` specifies how DXGI should handle transparency, we don't care about that (yet), so we'll just say it's unspecified and rely on default behaviour
 
@@ -332,7 +332,7 @@ bool HelloD3D11Application::CreateSwapchainResources()
 }
 ```
 
-When we render things, the GPU simply writes color values to a texture, which you can picture as a buffer which holds color information Swapchain is a container to manage those buffers we want to present on screen. To do that we have to create a special kind of texture called a "Render Target View" or an RTV. First off we have to grab a texture from the swapchain's main buffer (index 0), from that texture, we now have create an RTV from that, which specifies the subresource of the texture that we will be drawing to. We wont keep the actual texture around, we just need the render target view, which we will refer to as render target.
+When we render things, the GPU simply writes color values to a texture, which you can picture as a buffer which holds color information Swapchain is a container to manage those buffers we want to present on screen. To do that we have to create a special kind of texture called a "Render Target View" or an RTV. First off we have to grab a texture from the swapchain's main buffer (index 0), from that texture, we now have to create an RTV from that, which specifies the subresource of the texture that we will be drawing to. We won't keep the actual texture around, we just need the render target view, which we will refer to as render target.
 
 ```cpp
 void HelloD3D11Application::DestroySwapchainResources()
@@ -426,7 +426,7 @@ bool HelloD3D11Application::Load()
 }
 ```
 
-Finally we need to modify `Appplication.hpp` and `Application.cpp`. Since we want to handle resizing as well.
+Finally, we need to modify `Appplication.hpp` and `Application.cpp`. Since we want to handle resizing as well.
 
 ### Application.hpp
 
@@ -446,7 +446,7 @@ virtual void OnResize(
 [[nodiscard]] int32_t GetWindowHeight() const;
 ```
 
-`HandleResize` will be the callback from `GLFW` which handles resize events and `OnResize` will be execute when GLFW runs HandleResize, so that we can handle our custom things we want to execute when resizing the window, like changing the size of the swapchain in our example.
+`HandleResize` will be the callback from `GLFW` which handles resize events and `OnResize` will be executed when GLFW runs HandleResize, so that we can handle our custom things we want to execute when resizing the window, like changing the size of the swapchain in our example.
 
 `GetWindow()` is used to derive the actual native window handle from, which is needed when we create the swapchain. `GetWindowWidth()` and `GetWindowHeight()` do what they say :) Also required for swapchain creation.