fix: Split existing lines over 120 chars triggering the linter (#80)

Author: slurmlord

Asset/Art/dds/dds_files_and_dxt_compression.md

@@ -11,10 +11,10 @@ have their own use cases and advantages, so higher numbers are not just "better"
 
 The advantage of these compression formats compared to something more common like JPEG is that they can be uploaded to
 the GPU directly and always stay fully compressed in GPU memory. With hundreds of megabytes of textures this adds up
-quickly and allows us to improve performance (less memory bandwidth used) and target lower end/older GPUs with less VRAM.
-The decompression is implemented directly in hardware and happens transparently on memory access. The key ingredient for
-this to work is that the format is made out of independent 4x4 blocks of pixels that can be decompressed individually
-instead of the entire texture at once.
+quickly and allows us to improve performance (less memory bandwidth used) and target lower end/older GPUs with
+less VRAM. The decompression is implemented directly in hardware and happens transparently on memory access. The key
+ingredient for this to work is that the format is made out of independent 4x4 blocks of pixels that can be decompressed
+individually instead of the entire texture at once.
 
 A more thorough look at the details of the compression formats can be found here:
 <http://www.reedbeta.com/blog/understanding-bcn-texture-compression-formats/>
@@ -32,30 +32,31 @@ The DXT-Formats mostly differ in their handling of the alpha channel (usually us
 The data rate is constant regardless of image content: 4 bits per pixel for BC1 and BC4 and 8 bits per pixel for every
 other format. This means that BC1 should be used where applicable to save memory, don't forget the 1 bit of alpha comes
 (almost) free! BC2 use cases are rare, usually you probably want BC3. A nice overview of features and use cases for all
-BCn formats can be found here (<https://www.reedbeta.com/blog/understanding-bcn-texture-compression-formats/#comparison-table>).
-Missing in this table is a particular trick for using DXT5 for better quality normal or bump maps explained here, also called
-DXT5nm or DXT5-xGxR and has direct support by a few tools (e.g. NVTT, see below).
-
-The more modern BC4-7 formats should generally be avoided for now since the older Renegade-compatible W3D engine can't load
-them at all, W3D 5.0 (APB, AR and BFD) can't load them yet (though afaik it would be trivial to add support) and most
-importantly, 3ds Max and many other programs cannot open them
+BCn formats can be found here
+(<https://www.reedbeta.com/blog/understanding-bcn-texture-compression-formats/#comparison-table>).
+Missing in this table is a particular trick for using DXT5 for better quality normal or bump maps explained here,
+also called DXT5nm or DXT5-xGxR and has direct support by a few tools (e.g. NVTT, see below).
+
+The more modern BC4-7 formats should generally be avoided for now since the older Renegade-compatible W3D engine can't
+load them at all, W3D 5.0 (APB, AR and BFD) can't load them yet (though afaik it would be trivial to add support) and
+most importantly, 3ds Max and many other programs cannot open them
 (BCn App Support <https://github.com/GameTechDev/Intel-Texture-Works-Plugin/wiki/BCn-App-Support>).
 Nevertheless, we might have a specific need for one of these formats in the future that warrants their use despite the
 tooling issues and we can always just use the uncompressed source texture for the .max files.
 
-At some point in the future, I will specifically take a look at BC5 for optimum quality normal maps and general BC7 vs. BC3
-quality since it should be tremendously better in most use cases at the same size. BC7 instead of BC1 should not be used
-frivolously due to being twice the size and also less amenable to further compression (e.g. zip) since it actually carries
-so much more information, but when you really need a near-lossless result, this will do it. Since the BC7 format is so much
-more complex, some encoders can take many hours for a single texture at high quality, but there are some faster ones out
-there (see below, so far I only tried Compressonator for BC7, will revisit this at some point).
+At some point in the future, I will specifically take a look at BC5 for optimum quality normal maps and general BC7
+vs.BC3 quality since it should be tremendously better in most use cases at the same size. BC7 instead of BC1 should
+not be used frivolously due to being twice the size and also less amenable to further compression (e.g. zip) since it
+actually carries so much more information, but when you really need a near-lossless result, this will do it. Since the
+BC7 format is so much more complex, some encoders can take many hours for a single texture at high quality, but there
+are some faster ones out there (see below, so far I only tried Compressonator for BC7, will revisit this at some point).
 
 ## Which Exporter to Use?
 
 This is where we get the reason why I wrote this post in the first place. I noticed some textures looking awfully blocky
 ingame with obviously off-color artifacts, which was caused by an extremely bad DXT encoder. I then set out to compare
-different compressors and stared at textures for hours (I also used PSNR metrics, but visual inspection was much more useful).
-In total I tested 7 different tools with two DXT1 textures we had uncompressed sources for.
+different compressors and stared at textures for hours (I also used PSNR metrics, but visual inspection was much
+more useful). In total I tested 7 different tools with two DXT1 textures we had uncompressed sources for.
 
 First of all here's my personal ranking in terms of output quality:
 
@@ -70,31 +71,32 @@ First of all here's my personal ranking in terms of output quality:
 - DirectXTex (<https://github.com/Microsoft/DirectXTex>)
 - DDS Converter (<http://www.ddsconverter.com/> but I'd rather you throw it deep into the sea)
 
-To motivate you to switch from a different tool, let me detail the issues encountered with the different encoders (comparison
-images are in the spoiler below).
+To motivate you to switch from a different tool, let me detail the issues encountered with the different encoders
+(comparison images are in the spoiler below).
 
-No matter which tool you use, make sure it generates mipmaps unless it's a UI texture. Some will do this by default, some
-don't (Compressonator). Some tools also offer the ability to specify gamma/sRGB for mipmap generation. This should be set
-to sRGB/2.2 (default for most tools). If you're unsure about gamma, use a checkerboard texture to replace a terrain texture
-ingame, disable anisotropic filtering and look off into the distance, with proper gamma it should look about medium gray
-(with lighting taken into account), otherwise it will look darker (like here <https://paroj.github.io/gltut/Texturing/Tut16%20Mipmaps%20and%20Linearity.html>).
+No matter which tool you use, make sure it generates mipmaps unless it's a UI texture. Some will do this by default,
+some don't (Compressonator). Some tools also offer the ability to specify gamma/sRGB for mipmap generation. This should
+be set to sRGB/2.2 (default for most tools). If you're unsure about gamma, use a checkerboard texture to replace a
+terrain texture ingame, disable anisotropic filtering and look off into the distance, with proper gamma it should look
+about medium gray (with lighting taken into account), otherwise it will look darker
+(like here <https://paroj.github.io/gltut/Texturing/Tut16%20Mipmaps%20and%20Linearity.html>).
 
 If you're working with tiled textures (terrain, walls), make sure you're telling the compressor so it doesn't break the
 smooth tiling (e.g. -wrap for Crunch, -repeat for NVTT), though the difference is usually minimal.
 
-Crunch was originally developed for a more advanced purpose, so make sure you only use the command line options that produce
-a "normal" non-clustered output (in particular, do not use -bitrate or -quality). In terms of visual quality, it particularly
-excels at gradients and dark areas.
+Crunch was originally developed for a more advanced purpose, so make sure you only use the command line options that
+produce a "normal" non-clustered output (in particular, do not use -bitrate or -quality). In terms of visual quality,
+it particularly excels at gradients and dark areas.
 
-NVTT is very close overall, with Crunch displaying better performance on gradients, while NVTT beats it at high-frequency
-detail. Note: Do not use this tool for BC7, unless you want to literally wait for days for a single texture even with the
-"fast" encoding option.
+NVTT is very close overall, with Crunch displaying better performance on gradients, while NVTT beats it at
+high-frequency detail. Note: Do not use this tool for BC7, unless you want to literally wait for days for a single
+texture even with the "fast" encoding option.
 
-Compressonator is one of the few tools to feature both a GUI and a command line interface, although the GUI can a bit weird
-to use. Make sure you generate mipmaps explicitly and set the quality to 1.0. In my experience the quality is always
-slightly behind Crunch/NVTT, but it's definitely not bad and it has been recommended a lot in the past. It can also compress
-to BC7 within a reasonable amount of time (35 seconds for a 4k texture with quality=0.05, though without comparison I
-can't speak for its visual quality).
+Compressonator is one of the few tools to feature both a GUI and a command line interface, although the GUI can a bit
+weird to use. Make sure you generate mipmaps explicitly and set the quality to 1.0. In my experience the quality is
+always slightly behind Crunch/NVTT, but it's definitely not bad and it has been recommended a lot in the past. It can
+also compress to BC7 within a reasonable amount of time (35 seconds for a 4k texture with quality=0.05, though without
+comparison I can't speak for its visual quality).
 
 Nvidia's Photoshop plugin for some reason continues to use a very old version of their texture tools (NVTT is basically
 a complete rewrite). It generally looks most similar to Crunch, suggesting a commonality in the algorithm used. However,

SourceCode/Builds/build_with_msvc6.md

@@ -21,8 +21,8 @@ understanding of how C++ is compiled is necessary. This includes knowing what th
 
 Download and install the following tools and software needed for compilation.
 
-> **ℹ️ Setup Note:** For simplicity, this guide will use the installers for Git and CMake and assumes the user will use the
-default install folder for Visual Studio 6.0 Portable.
+> **ℹ️ Setup Note:** For simplicity, this guide will use the installers for Git and CMake and assumes the
+user will use the default install folder for Visual Studio 6.0 Portable.
 
 ### Visual Studio 6.0 Portable
 
@@ -160,7 +160,8 @@ cmake --workflow --preset vc6-profile
 
 You will find a bunch of files in `build\vc6\<game name>` and a file called `generalszh.exe` or `generalsv.exe`.
 
-For detailed information about each build configuration and their specific purposes, see the [Build Configurations Overview](https://github.com/TheSuperHackers/GeneralsGameCode/wiki/build_configuration).
+For detailed information about each build configuration and their specific purposes, see the
+[Build Configurations Overview](https://github.com/TheSuperHackers/GeneralsGameCode/wiki/build_configuration).
 
 ### Install the game executable