Reorder the template for issues and bugs

This should always have been part of the code, but hey - we learn at some point and improve ourselves.

.github/ISSUE_TEMPLATE/issue.yml

@@ -7,12 +7,6 @@ title: "REPLACE ME"
 description: "This form is for bug and crash reports only, primarily used by developers. Abuse of this form will lead to a permanent interaction ban."
 labels: ["bug"]
 body:
-- type: textarea
-  attributes:
-    label: "OBS Studio Logs"
-    description: "Paste the content or attach the log files from OBS Studio here. In the event of a crash, paste or attach both the crash log and the normal log file."
-  validations:
-    required: true
 - type: textarea
   attributes:
     label: "Current and Expected Behavior"
@@ -25,6 +19,12 @@ body:
     description: "What steps are required to consistently reproduce the bug/crash/freeze?"
   validations:
     required: true
+- type: textarea
+  attributes:
+    label: "Log files & Crash Dumps"
+    description: "Paste the content or attach the log files from OBS Studio here. In the event of a crash, paste or attach both the crash log and the normal log file."
+  validations:
+    required: false
 - type: textarea
   attributes:
     label: "Any additional Information we need to know?"

.github/pull_request_template.md

@@ -1,15 +0,0 @@
-### Explain the Pull Request
-<!-- Describe the PR in as much detail as possible. If possible include example images, videos and documents, and explain why it is necessary. If this is related to a discussion or issue, please also link them. -->
-
-#### Completion Checklist
-<!-- Check all items that apply. Don't lie here, we'll know the moment we verify this. -->
-- [ ] This has been tested on the following platforms: <!-- REQUIRED (at least one) -->
-  - [ ] MacOS 10.15
-  - [ ] MacOS 11
-  - [ ] MacOS 12
-  - [ ] Ubuntu 20.04
-  - [ ] Ubuntu 22.04
-  - [ ] Windows 10
-  - [ ] Windows 11
-- [ ] The copyright headers and license files have been updated. <!-- REQUIRED -->
-- [ ] I will maintain this for the forseeable future, and have added myself to `CODEOWNERS`. <!-- REQUIRED for content or feature additions -->

BUILDING.md

@@ -0,0 +1,155 @@
+# Building
+This document intends to guide you through the process of building StreamFX. It requires understanding of the tools used, and may require you to learn tools yourself before you can advance further in the guide. It is intended to be used by developers and contributors.
+
+## Building Bundled
+<details open><summary>The main method to build StreamFX is to first set up an OBS Studio copy and then integrate the StreamFX repository into it.</summary>
+
+1. [Uninstall](Uninstallation) any currently installed versions of StreamFX to prevent conflicts.
+2. Follow the [OBS Studio build guide](https://obsproject.com/wiki/install-instructions) for automated building on your platform of choice.
+    - **MacOS:** You will need to use the XCode generator to build StreamFX as the Ninja generator does not support the flags StreamFX requires.
+3. Integrate StreamFX into the OBS Studio build flow:
+    1. Navigate to either of these directories:
+         - **With UI:** `<obs studio source>/UI/frontend-plugins`
+         - **Without UI:** `<obs studio source>/plugins`
+    2. Open a `git` enabled shell (git-bash on windows).
+    3. Run `git submodule add 'https://github.com/Xaymar/obs-StreamFX.git' streamfx`.
+    4. Run `git submodule update --init --recursive`.
+    5. Append the line `add_subdirectory(streamfx)` to the `CMakeLists.txt` file in the same directory.
+4. Run the same script(s) from step 2 again.
+5. Done. StreamFX is now part of the build.
+
+</details>
+
+## Building CI-Style
+<details><summary>This method is designed for continuous integration and releases, and requires significant knowledge of CMake, OBS, and various other tools. Additionally it is not guaranteed to work on every machine, as it is only designed for use in continuous integration and nowhere else. It may even stop being maintained entirely with no warning whatsoever. You are entirely on your own when you choose this method.</summary>
+
+#### Install Prerequisites / Dependencies
+- [Git](https://git-scm.com/)
+    - **Debian / Ubuntu:** `sudo apt install git`
+- [CMake](https://cmake.org/) 3.20 (or newer)
+    - **Debian / Ubuntu:** `sudo apt install cmake`
+- A compatible Compiler:
+    - **Windows**  
+      [Visual Studio](https://visualstudio.microsoft.com/vs/) 2019 (or newer)
+    - **MacOS**  
+      Xcode 11.x (or newer) for x86_64  
+      Xcode 12.x (or newer) for arm64
+    - **Debian / Ubuntu**
+        - Essential Build Tools:  
+          `sudo apt install build-essential pkg-config checkinstall make ninja-build` 
+        - One of:
+            - GCC 11 (or newer)  
+              `sudo apt install gcc-11 g++-11`
+            - [LLVM](https://releases.llvm.org/) Clang 14 (or newer)  
+              `sudo bash -c "$(wget -O - https://apt.llvm.org/llvm.sh)"`
+        - One of:
+            - ld or gold  
+              `sudo apt install binutils`
+            - [LLVM](https://releases.llvm.org/) lld  
+              `sudo bash -c "$(wget -O - https://apt.llvm.org/llvm.sh)"`
+            - [mold](https://github.com/rui314/mold)  
+              `sudo apt install mold`
+- [Qt](https://www.qt.io/) 6:
+    - **Windows**  
+      A Node.JS based tool is provided toread and parse the `/third-party/obs-studio/buildspec.json` file. See `/.github/workflows/main.yml` on usage and output parsing.
+    - **MacOS**  
+      A Node.JS based tool is provided toread and parse the `/third-party/obs-studio/buildspec.json` file. See `/.github/workflows/main.yml` on usage and output parsing.
+    - Linux:
+        - **Debian / Ubuntu:** `sudo apt install qt6-base-dev qt6-base-private-dev libqt6svg6-dev`
+- [CURL](https://curl.se/):
+    - **Windows**  
+      A Node.JS based tool is provided toread and parse the `/third-party/obs-studio/buildspec.json` file. See `/.github/workflows/main.yml` on usage and output parsing.
+    - **MacOS**  
+      A Node.JS based tool is provided toread and parse the `/third-party/obs-studio/buildspec.json` file. See `/.github/workflows/main.yml` on usage and output parsing.
+    - **Debian / Ubuntu:**
+      `sudo apt install libcurl4-openssl-dev`
+- [FFmpeg](https://ffmpeg.org/) (Optional, for FFmpeg component only):
+    - **Windows**  
+      A Node.JS based tool is provided toread and parse the `/third-party/obs-studio/buildspec.json` file. See `/.github/workflows/main.yml` on usage and output parsing.
+    - **MacOS**  
+      A Node.JS based tool is provided toread and parse the `/third-party/obs-studio/buildspec.json` file. See `/.github/workflows/main.yml` on usage and output parsing.
+    - **Debian / Ubuntu**  
+      `sudo apt install libavcodec-dev libavdevice-dev libavfilter-dev libavformat-dev libavutil-dev libswresample-dev libswscale-dev`
+- [LLVM](https://releases.llvm.org/) (Optional, for clang-format and clang-tidy integration only):
+    - **Debian / Ubuntu**  
+      `sudo bash -c "$(wget -O - https://apt.llvm.org/llvm.sh)" all`
+- [InnoSetup](https://jrsoftware.org/isinfo.php) (Optional, for **Windows** installer only)
+
+### Cloning the Project
+Using your preferred tool of choice for git, clone the repository including all submodules into a directory. If you use git directly, then you can clone the entire project with `git clone --recursive https://github.com/Xaymar/obs-StreamFX.git streamfx`.
+
+### Configuring with CMake
+There are two ways to handle this step, with the GUI variant of CMake and with the command line version of CMake. This guide will focus on the GUI variant, but all the steps below can be done with the command line version as well.
+
+1. Launch CMake-GUI and wait for it to open.
+2. Click the button named `Browse Build` and point it at an empty folder. For example, create a folder in the project called `build` and select that folder.
+3. Click the button named `Browse Source` and point it at the project itself.
+4. Click the button named `Configure`, select your preferred Generator (the default is usually fine), and wait for it to complete. This will most likely result in an error which is expected.
+5. Adjust the variables in the variable list as necessary. Take a look at [the documentation](#CMake-Options) for what each option does.
+6. Click the button named `Generate`, which will also run `Configure`. Both together should succeed if you did everything correctly.
+7. If available, you can now click the button named `Open Project` to immediately jump into your IDE of choice.
+
+</details>
+
+## CMake Options
+<details><summary>The project is intended to be versatile and configurable, so we offer almost everything to be configured on a silver platter directly in CMake (if possible). If StreamFX detects that it is being built together with other projects, it will automatically prefix all options with `StreamFX_` to prevent collisions.</summary>
+
+### Generic
+- `GIT` (not prefixed)  
+  Path to the `git` binary on your system, for use with features that require git during configuration and generation.
+- `VERSION`  
+  Set or override the version of the project with a custom one. Allowed formats are: SemVer 2.0.0, CMake.
+
+### Code
+- `ENABLE_CLANG`  
+  Enable integration of `clang-format` and `clang-tidy`
+- `CLANG_PATH` (not prefixed, only with `ENABLE_CLANG`)  
+  Path to the `clang` installation containing `clang-format` and `clang-tidy`. Only used as a hint.
+- `CLANG_FORMAT_PATH` and `CLANG_TIDY_PATH` (not prefixed)
+  Path to `clang-format` and `clang-tidy` that will be used.  
+
+### Dependencies
+- `LibObs_DIR`  
+  Path to the obs-studio libraries.
+- `Qt5_DIR`, `Qt6_DIR` or `Qt_DIR` (autodetect)  
+  Path to Qt5 (OBS Studio 27.x and lower) or Qt6 (OBS Studio 28.x and higher).
+- `FFmpeg_DIR`  
+  Path to compatible FFmpeg libraries and headers.
+- `CURL_DIR`  
+  Path to compatible CURL libraries and headers.
+- `AOM_DIR`  
+  Path to compatible AOM libraries and headers.
+
+### Compiling
+- `ENABLE_FASTMATH`  
+  Enable fast math optimizations if the compiler supports them. This trades precision for performance, and is usually good enough anyway.
+- `ENABLE_LTO`  
+  Enable link time optimization for faster binaries in exchange for longer build times.
+- `ENABLE_PROFILING`  
+  Enable CPU and GPU profiling code, this option reduces performance drastically.
+- `TARGET_*`  
+  Specify which architecture target the generated binaries will use.
+
+### Components
+- `COMPONENT_<NAME>`  
+  Enable the component by the given name.
+
+### Installing & Packaging
+These options are only available in CI-Style mode.
+
+- `CMAKE_INSTALL_PREFIX`  
+  The path in which installed content should be placed when building the `install` target.
+- `STRUCTURE_PACKAGEMANAGER`  
+  If enabled will install files in a layout compatible with package managers.
+- `STRUCTURE_UNIFIED`  
+  Enable to install files in a layout compatible with an OBS Studio plugin manager.
+- `PACKAGE_NAME`  
+  The name of the packaged archive, excluding the prefix, suffix and extension.
+- `PACKAGE_PREFIX`  
+  The path in which the packages should be placed.
+- `PACKAGE_SUFFIX`  
+  The suffix to attach to the name, before the file extension. If left blank will attach the current version string to the package.
+- `STRUCTURE_UNIFIED`  
+  Enable to replace the PACKAGE_ZIP target with a target that generates a single `.obs` file instead.
+
+</details>

CONTRIBUTING.md

@@ -1,53 +1,34 @@
 # Contributing
-This document goes over how you (and/or your organization) are expected to contribute. These guidelines are softly enforced and sometimes not required.
+This document intends to teach you the proper way to contribute to the project as a set of guidelines. While they aren't always enforced, your chances of your code being accepted are significantly higher when you follow these. For smaller changes, we might opt to squash your changes to apply the guidelines below to your contribution.
 
-## Localization
-We use Crowdin to handle translations into many languages, and you can join the [StreamFX project on Crowdin](https://crowdin.com/project/obs-stream-effects) if you are interested in improving the translations to your native tongue. As Crowdin handles all other languages, Pull Requests therefore should only include changes to `en-US.ini`.
+<details open><summary><h2 style="display: inline-block;">Repository & Commits</h2></summary>
 
-## Commit Guidelines
-Commits should focus on a single change such as formatting, fixing a bug, a warning across the code, and similar things. This means that you should not include a fix to color format handling in a commit that implements a new encoder, or include a fix to a bug with a fix to a warning.
+As this is a rather large project, we have certain rules to follow when contributing via git.
 
 ### Linear History
-This project prefers the linear history of `git rebase` and forbids merge commits. This allows all branches to be a single line back to the root, unless viewed as a whole where it becomes a tree. If you are working on a branch for a feature, bug or other thing, you should know how to rebase back onto the main branch before making a pull request.
+We follow the paradigm of linear history which forbids branches from being merged, thus changes made on branches are `git rebase`d back onto the root. This simplifies the code history significantly, but makes reverting changes more difficult.
 
-### Commit Message & Title
-We require a commit message format like this:
+❌ `git merge`
+✅ `git rebase`
+
+### Commits
+A commit should be containing a single change, even if it spans multiple units, and has the following format:
 
 ```
-prefix: short description
+short description
 
 optional long description
 ```
 
-The `short description` should be no longer than 80 characters, excluding the `prefix: ` part. The `optional long description` should be present if the change is not immediately obvious - however it does not replace proper documentation.
+The short description should be no longer than 120 characters and focus on the important things. The long description is optional, but should be included for larger changes.
 
-#### The correct `prefix`
-Depending on where the file is that you ended up modifying, or if you modified multiple files at once, the prefix changes. Take a look at the list to understand which directories cause which prefix:
+</details>
 
-- `/CMakeLists.txt`, `/cmake` -> `cmake`
-- `/.github/workflows` -> `ci`
-- `/data/locale`, `/crowdin.yml` -> `locale`
-- `/data/examples` -> `examples`
-- `/data` -> `data` (if not part of another prefix)
-- `/media` -> `media`
-- `/source`, `/include` -> `code`
-- `/templates` -> `templates` (or merge with `cmake`)
-- `/third-party` -> `third-party`
-- `/patches` -> `patches`
-- `/tools` -> `tools`
-- `/ui` -> `ui` (if not part of a `code` change)
-- Most other files -> `project`
 
-If multiple locations match, they should be alphabetically sorted and separated by `, `. A change to both `ui` and `code` will as such result in a prefix of `code, ui`. If a `code` change only affects a single file, or multiple files with a common parent file, the prefix should be the path of the file, like shown in the following examples:
-
-- `/source/encoders/encoder-ffmpeg` -> `encoder/ffmpeg`
-- `/source/filters/filter-shader` -> `filter/shader`
-- `/source/encoders/handlers/handler`, `/source/encoders/encoder-ffmpeg` -> `encoder/ffmpeg`
-
-## Coding Guidelines
+<details open><summary><h2 style="display: inline-block;">Coding</h2></summary>
 
 ### Documentation
-Documentation should be present in areas where it would save time to new developers, and in areas where an API is defined. This means that you should not provide documentation for things like `1 + 1`, but for things like the following:
+The short form of the this part is **Code != Documentation**. Documentation is what you intend your Code to do, while Code is what it actually does. If your Code mismatches the Documentation, it is time to fix the Code, unless the change is a new addition in terms of behavior or functionality. Note that by this we don't mean to document things like `1 + 1` but instead things like the following:
 
 ```c++
 int32_t idepth         = static_cast<int32_t>(depth);
@@ -58,14 +39,18 @@ int32_t container_size = static_cast<int32_t>(pow(2l, (idepth + (idepth / 2))));
 
 ```c++
 class magic_class {
-	void do_magic_thing(float magic_number);
+	void do_magic_thing(float magic_number) {
+		// Lots and lots of SIMD code that does a magic thing...
+	}
 }
 ```
 
-Both of these examples would be much easier to understand if they had proper documentation, and save hours if not even days of delving into code. Documentation is about saving time to new developers, and can't be replaced by code. Code is not Documentation!
+Documenting what a block of Code does not only helps you, it also helps other contributors understand what this Code is supposed to do. While you may be able to read your own Code (at least for now), there is no guarantee that either you or someone else will be able to read it in the future. Not only that, but it makes spotting mistakes and fixing them easier, since we have Documentation to tell us what it is supposed to do!
 
 ### Naming & Casing
-All long-term objects should have a descriptive name, which can be used by other developers to know what it is for. Temporary objects should also have some information, but do not necessarily follow the same rules.
+The project isn't too strict about variable naming as well as casing, but we do prefer a universal style across all code. While this may appear as removing your individuality from the code, it ultimately serves the purpose of making it easier to jump from one block of code to the other, without having to guess at what this code now does.
+
+Additionally we prefer it when things are named by what they either do or what they contain, instead of having the entire alphabet spelled out in different arrangements. While it is fine to have chaos in your own Code for your private or hobby projects, it is not fine to submit such code to other projects.
 
 #### Macros
 - Casing: ELEPHANT_CASE
@@ -249,6 +234,16 @@ Special rules for `class`
 #### Members
 All class members must be `private` and only accessible through get-/setters. The setter of a member should also validate if the setting is within an allowed range, and throw exceptions if an error occurs. If there is no better option, it is allowed to delay validation until a common function is called.
 
-## Building
-Please read [the guide on the wiki](https://github.com/Xaymar/obs-StreamFX/wiki/Building) for building the project.
+</details>
 
+<details open><summary><h2 style="display: inline-block;">Localization</h2></summary>
+
+We use Crowdin to handle translations into many languages, and you can join the [StreamFX project on Crowdin](https://crowdin.com/project/obs-stream-effects) if you are interested in improving the translations to your native tongue. As Crowdin handles all other languages, Pull Requests therefore should only include changes to `en-US.ini`.
+
+</details>
+
+## Further Resources
+- A guide on how to build the project is in BUILDING.MD.
+- A no bullshit guide to `git`: https://rogerdudler.github.io/git-guide/
+    - Remember, `git` has help pages for all commands - run `git <command> --help`.
+	- ... or use visual clients, like TortoiseGit, Github Desktop, SourceTree, and similar. It's what I do.

README.md

@@ -10,3 +10,5 @@ Bring your setup to the modern day with StreamFX! With several super fast filter
 ## Further Links
 * [Wiki](https://github.com/Xaymar/obs-StreamFX/wiki)
 * [Installation Guide](https://github.com/xaymar/obs-streamfx/wiki/Installation)
+* See BUILDING.md
+* See CONTRIBUTING.md