Upgraded the Builder build system to compile regression tests and mad…

…e a program for running the tests with multiple threads.

.github/workflows/ci.yml

@@ -3,22 +3,46 @@
 name: DFPSR tests
 on: [push]
 jobs:
-  test:
+  scriptedTest:
     runs-on: ${{ matrix.os }}
     strategy:
       matrix:
-        os: [ubuntu-latest, macos-latest, windows-latest]
+        os: [ubuntu-latest, macos-latest]
         architecture: [x86_32, x86_64, arm, arm64]
     steps:
       - name: Checkout
         uses: actions/checkout@v4
-      - name: Run tests on Linux and macOS
-        if: matrix.os != 'windows-latest'
+      - name: Run tests on Linux
+        if: matrix.os == 'ubuntu-latest'
+        run: |
+          cd ./Source/test
+          ./test.sh
+      - name: Run tests on MacOS
+        if: matrix.os == 'macos-latest'
         run: |
-          cd ./Source
+          cd ./Source/test
           ./test.sh
+  builderTest:
+    runs-on: ${{ matrix.os }}
+    strategy:
+      matrix:
+        os: [ubuntu-latest, macos-latest, windows-latest]
+        architecture: [x86_32, x86_64, arm, arm64]
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      - name: Run tests on Linux
+        if: matrix.os == 'ubuntu-latest'
+        run: |
+          cd ./Source/test
+          ./test_linux.sh
+      - name: Run tests on MacOS
+        if: matrix.os == 'macos-latest'
+        run: |
+          cd ./Source/test
+          ./test_macos.sh
       - name: Run tests on Windows
         if: matrix.os == 'windows-latest'
         run: |
-          cd Source
-          cmd /c test.bat
+          cd Source\test
+          cmd /c test_windows.bat

.github/workflows/ci.yml.tabs

@@ -2,22 +2,46 @@
 name: DFPSR tests
 on: [push]
 jobs:
-	test:
+	scriptedTest:
 		runs-on: ${{ matrix.os }}
 		strategy:
 			matrix:
-				os: [ubuntu-latest, macos-latest, windows-latest]
+				os: [ubuntu-latest, macos-latest]
 				architecture: [x86_32, x86_64, arm, arm64]
 		steps:
 			- name: Checkout
 				uses: actions/checkout@v4
-			- name: Run tests on Linux and macOS
-				if: matrix.os != 'windows-latest'
+			- name: Run tests on Linux
+				if: matrix.os == 'ubuntu-latest'
+				run: |
+					cd ./Source/test
+					./test.sh
+			- name: Run tests on MacOS
+				if: matrix.os == 'macos-latest'
 				run: |
-					cd ./Source
+					cd ./Source/test
 					./test.sh
+	builderTest:
+		runs-on: ${{ matrix.os }}
+		strategy:
+			matrix:
+				os: [ubuntu-latest, macos-latest, windows-latest]
+				architecture: [x86_32, x86_64, arm, arm64]
+		steps:
+			- name: Checkout
+				uses: actions/checkout@v4
+			- name: Run tests on Linux
+				if: matrix.os == 'ubuntu-latest'
+				run: |
+					cd ./Source/test
+					./test_linux.sh
+			- name: Run tests on MacOS
+				if: matrix.os == 'macos-latest'
+				run: |
+					cd ./Source/test
+					./test_macos.sh
 			- name: Run tests on Windows
 				if: matrix.os == 'windows-latest'
 				run: |
-					cd Source
-					cmd /c test.bat
+					cd Source\test
+					cmd /c test_windows.bat

Doc/Generator/Input/Starting.txt

@@ -45,7 +45,8 @@ sudo apt install libx11-dev
 sudo apt install libasound2-dev</BLOCKQUOTE></PRE>
 
 *
-Check that you have g++ installed at /usr/bin/g++ and change CPP_COMPILER_PATH in Source/tools/builder/buildProject.sh if it's located somewhere else.
+Check that you have g++ installed at /usr/bin/g++.
+If it is located in a different path, then add the path to the top of compilerPaths_posix.txt.
 You can also change TEMPORARY_FOLDER if using another system than Linux where /tmp is called something else, or you want to keep objects in a persistent folder after your system reboots.
 The advantage of using /tmp, is that the files there can be placed in memory and you don't have to erase them manually.
 
@@ -67,10 +68,8 @@ Download a mingw edition of CodeBlocks from their website. <A href="http://www.c
 This is the easiest way to install GNU's C++ compiler g++ on Windows, but CodeBlocks can also be used as a debugger if you create a project with the same source code, backends and compiler flags.
 
 *
-Open Source\tools\builder\buildProject.bat in a text editor.
-
-*
-Check that CPP_COMPILER_FOLDER and CPP_COMPILER_PATH refers to where your GNU C++ compiler is installed. If you installed CodeBlocks in the default path C:\Program, this should usually be the case. Otherwise just update the path.
+Open Source\tools\builder\compilerPaths_windows.txt in a text editor and add your installation path for the g++ compiler at at the top of the line-break separated list.
+Do not leave any empty lines in between, because empty lines are used to stop the search for compilers.
 
 *
 Open CMD.exe, go to the Source\tools\wizard folder and execute build_windows.bat from the same folder.

Doc/Generator/Input/StyleGuide.txt

@@ -4,26 +4,26 @@ Title: Code convention for David Forsgren Piuva's Software Renderer
 
 To keep the style consistent, the style being used in the library is explained in this document.
 ---
-1. Tabs for indentation then spaces for alignment. It's the best of both worlds by both having variable length tabs	and correct alignment that works between lines of the same indentation.
+Tabs for indentation then spaces for alignment. It's the best of both worlds by both having variable length tabs	and correct alignment that works between lines of the same indentation.
 ---
-2. No new line for opening brackets.
+No new line for opening brackets.
 Makes the code more compact and decreases the risk of copy-paste errors.
 ---
-3. No hpp extensions, use h for all headers. Could be either way, but this library uses *.h for compact naming, so keep it consistent.
+No hpp extensions, use h for all headers. Could be either way, but this library uses *.h for compact naming, so keep it consistent.
 ---
-4. C-style casting for raw data manipulation and C++-style for high-level classes when possible.
+C-style casting for raw data manipulation and C++-style for high-level classes when possible.
 When using assembly intrinsics and raw pointer manipulation to alter the state of bits,
 verbose high-level abstractions only make it harder to count CPU cycles in your head.
 Always use the tool that makes sense for the problem you're trying to solve.
 C++ style is for things that are abstracted on a higher level.
 C style is for when a byte is just a byte and you just want to manipulate it in a specific way.
 ---
-5. Follow the most relevant standard without making contemporary assumptions.
+Follow the most relevant standard without making contemporary assumptions.
 For code not intended for a specific system, follow the C++ standard.
 For code targeting a certain hardware using intrinsic functions, follow the hardware's standard.
 For code targeting a certain operating system, follow the operating system's standard.
 ---
-6. Do not assume that a type has a certain size or format unless it is specified explicitly.
+Do not assume that a type has a certain size or format unless it is specified explicitly.
 The int type is not always 32 bits, so only use when 16 bits are enough, use int32_t for a signed 32-bit integer.
 Fixed integers such as uint8_t, uint16_t, uint32_t, uint64_t, int32_t and int64_t are preferred.
 For bit manipulation, use unsigned integers to avoid depending on two's complement.
@@ -32,22 +32,27 @@ The float type does not have to be any of the IEEE standards according to the C+
 std::string is not used, because it has an undefined character encoding, so use dsr::String or dsr::ReadableString with UTF-32 instead.
 char* should only be used for constant string literals and interfacing with external libraries.
 ---
-7. The code should work for both little-endian and big-endian, because both still exist.
+The code should work for both little-endian and big-endian, because both still exist.
 You may however ignore mixed-endian.
 ---
-8. Do not call member methods with "this" set to null, because that is undefined behavior.
+Do not call member methods with "this" set to null, because that is undefined behavior.
 ---
-9. Avoid mixing side-effects with expressions for determinism across compilers.
+Leave an empty line at the end of each source document.
+Even though the C++ standard tells compilers to ignore line breaks as white space during parsing, white space is still used to separate the tokens that are used.
+A future C++ compiler might be designed to allow interactive input directly from the developer and ignore end of file for consistent behavior between command line input and source files.
+So without a line break at the end, the last token in a cpp file may be ignored on some compilers.
+---
+Avoid mixing side-effects with expressions for determinism across compilers.
 Non-deterministic expressions such as ((x++ - ++x) * x--) should never be used, so use ++ and -- in separate statements.
 Side-effects within the same depth of an expressions may be evaluated in any order because it is not specified in C++.
 Checking the return value of a function with side-effects is okay, because the side effect always come before returning the result in the called function.
 Lazy evaluation such as x != nullptr && foo(x) is okay, because lazy evaluation is well specified as only evaluating the right hand side when needed.
 Call chaining such as constructor(args).setSomeValue(value).setSomeOtherValue(value) is okay, because the execution order is explicit from differences in expression depth.
 ---
-10. Use the std library as little as possible.
+Use the std library as little as possible.
 Each compiler, operating system and standard library implementation has subtle differences in how things work, which can cause programs to break on another computer.
 The goal of this framework is to make things more consistent across platforms, so that code that works on one computer is more likely to work on another computer.
 ---
-11. Don't over-use the auto keyword.
+Don't over-use the auto keyword.
 Spelling out the type explicitly makes the code easier to read.
 ---

Doc/Starting.html

@@ -79,7 +79,8 @@
 
 </P><P>
 <IMG SRC="Images/SmallDot.png">
-Check that you have g++ installed at /usr/bin/g++ and change CPP_COMPILER_PATH in Source/tools/builder/buildProject.sh if it's located somewhere else.
+Check that you have g++ installed at /usr/bin/g++.
+If it is located in a different path, then add the path to the top of compilerPaths_posix.txt.
 You can also change TEMPORARY_FOLDER if using another system than Linux where /tmp is called something else, or you want to keep objects in a persistent folder after your system reboots.
 The advantage of using /tmp, is that the files there can be placed in memory and you don't have to erase them manually.
 
@@ -105,11 +106,8 @@
 
 </P><P>
 <IMG SRC="Images/SmallDot.png">
-Open Source\tools\builder\buildProject.bat in a text editor.
-
-</P><P>
-<IMG SRC="Images/SmallDot.png">
-Check that CPP_COMPILER_FOLDER and CPP_COMPILER_PATH refers to where your GNU C++ compiler is installed. If you installed CodeBlocks in the default path C:\Program, this should usually be the case. Otherwise just update the path.
+Open Source\tools\builder\compilerPaths_windows.txt in a text editor and add your installation path for the g++ compiler at at the top of the line-break separated list.
+Do not leave any empty lines in between, because empty lines are used to stop the search for compilers.
 
 </P><P>
 <IMG SRC="Images/SmallDot.png">

Doc/StyleGuide.html

@@ -28,44 +28,57 @@
 </P><P>
 To keep the style consistent, the style being used in the library is explained in this document.
 </P><IMG SRC="Images/Border.png"><P>
-1. Use common sense! If it looks wrong to human readers then it's wrong. Don't defeat the purpose of any rule by taking it too far.
+Tabs for indentation then spaces for alignment. It's the best of both worlds by both having variable length tabs	and correct alignment that works between lines of the same indentation.
 </P><IMG SRC="Images/Border.png"><P>
-2. Don't use iterators when there is any other way to accomplish the task. You can't write efficient algorithms without knowing the data structures.
-</P><IMG SRC="Images/Border.png"><P>
-3. Tabs for indentation then spaces for alignment. It's the best of both worlds by both having variable length tabs	and correct alignment that works between lines of the same indentation.
-</P><IMG SRC="Images/Border.png"><P>
-4. No dangling else, use explicit {} for safety. Otherwise someone might add an extra statement and get random crashes.
+No new line for opening brackets.
+Makes the code more compact and decreases the risk of copy-paste errors.
 </P><IMG SRC="Images/Border.png"><P>
-5. No hpp extensions, use h for all headers. Could be either way, but this library uses *.h for compact naming, so keep it consistent.
+No hpp extensions, use h for all headers. Could be either way, but this library uses *.h for compact naming, so keep it consistent.
 </P><IMG SRC="Images/Border.png"><P>
-6. C-style casting for raw data manipulation and C++-style for high-level classes.
+C-style casting for raw data manipulation and C++-style for high-level classes when possible.
 When using assembly intrinsics and raw pointer manipulation to alter the state of bits,
 verbose high-level abstractions only make it harder to count CPU cycles in your head.
 Always use the tool that makes sense for the problem you're trying to solve.
 C++ style is for things that are abstracted on a higher level.
 C style is for when a byte is just a byte and you just want to manipulate it in a specific way.
 </P><IMG SRC="Images/Border.png"><P>
-7. Don't call member methods with "this" set to nullptr.
-This would be undefined behavior and may randomly crash.
-Use global functions instead. They allow checking pointers for null
-because they are explicit arguments declared by the programmer.
+Follow the most relevant standard without making contemporary assumptions.
+For code not intended for a specific system, follow the C++ standard.
+For code targeting a certain hardware using intrinsic functions, follow the hardware's standard.
+For code targeting a certain operating system, follow the operating system's standard.
 </P><IMG SRC="Images/Border.png"><P>
-8. Avoid using STD/STL directly in SDK examples.
-Exposing types from the standard library should be done using an alias or wrapper in the dsr namespace.
-This allow replacing the standard library without breaking backward compatibility.
-The C++ standard libraries have broken backward compatibility before and it can happen again.
+Do not assume that a type has a certain size or format unless it is specified explicitly.
+The int type is not always 32 bits, so only use when 16 bits are enough, use int32_t for a signed 32-bit integer.
+Fixed integers such as uint8_t, uint16_t, uint32_t, uint64_t, int32_t and int64_t are preferred.
+For bit manipulation, use unsigned integers to avoid depending on two's complement.
+The char type is usually 8 bits large, but it is not specified by the C++ standard, so use uint8_t instead for buffers and DsrChar for 32-bit Unicode characters.
+The float type does not have to be any of the IEEE standards according to the C++ standard, but you can assume properties that are specified in a relevant standard.
+std::string is not used, because it has an undefined character encoding, so use dsr::String or dsr::ReadableString with UTF-32 instead.
+char* should only be used for constant string literals and interfacing with external libraries.
 </P><IMG SRC="Images/Border.png"><P>
-9. Don't abuse the auto keyword everywhere just to make it look more "modern".
-Explicit type safety is what makes compiled languages safer than scripting.
+The code should work for both little-endian and big-endian, because both still exist.
+You may however ignore mixed-endian.
 </P><IMG SRC="Images/Border.png"><P>
-10. No new line for opening brackets.
-Makes the code more compact and decreases the risk of copy-paste errors.
+Do not call member methods with "this" set to null, because that is undefined behavior.
+</P><IMG SRC="Images/Border.png"><P>
+Leave an empty line at the end of each source document.
+Even though the C++ standard tells compilers to ignore line breaks as white space during parsing, white space is still used to separate the tokens that are used.
+A future C++ compiler might be designed to allow interactive input directly from the developer and ignore end of file for consistent behavior between command line input and source files.
+So without a line break at the end, the last token in a cpp file may be ignored on some compilers.
+</P><IMG SRC="Images/Border.png"><P>
+Avoid mixing side-effects with expressions for determinism across compilers.
+Non-deterministic expressions such as ((x++ - ++x) * x--) should never be used, so use ++ and -- in separate statements.
+Side-effects within the same depth of an expressions may be evaluated in any order because it is not specified in C++.
+Checking the return value of a function with side-effects is okay, because the side effect always come before returning the result in the called function.
+Lazy evaluation such as x != nullptr && foo(x) is okay, because lazy evaluation is well specified as only evaluating the right hand side when needed.
+Call chaining such as constructor(args).setSomeValue(value).setSomeOtherValue(value) is okay, because the execution order is explicit from differences in expression depth.
 </P><IMG SRC="Images/Border.png"><P>
-11. Don't fix the style of someone else's code if you can easily read it.
-Especially if there's no style rule explicitly supporting the change.
-Otherwise style changes will defeat the purpose by introducing more version conflicts.
+Use the std library as little as possible.
+Each compiler, operating system and standard library implementation has subtle differences in how things work, which can cause programs to break on another computer.
+The goal of this framework is to make things more consistent across platforms, so that code that works on one computer is more likely to work on another computer.
 </P><IMG SRC="Images/Border.png"><P>
-12. Don't change things that you don't know how to test.
+Don't over-use the auto keyword.
+Spelling out the type explicitly makes the code easier to read.
 </P><IMG SRC="Images/Border.png"><P>
 </P>
 </BODY> </HTML>

Source/check.sh

@@ -1,2 +1 @@
 cppcheck . --enable=all
-

Source/test/Tests.DsrProj

@@ -0,0 +1,25 @@
+# Flags here will be inherited by each test.
+CompilerFlag "-std=c++14"
+Debug
+Supressed = 1
+#Graphics
+#Sound
+Import "../DFPSR/DFPSR.DsrHead"
+
+# Compile and run each source file ending with Test.cpp in tests as its own project.
+#   All settings are inherited from the caller when using source files as projects.
+Projects from "*Test.cpp" in "tests"
+
+# TODO:
+# * Allow creating scopes for temporary settings, so that a stack keeps track of which
+#   settings were local to the scope and should be erased when leaving the scope.
+# * Or just make a method for clearing all local settings while keeping external settings such as target platform.
+
+# Flags here will not be inherited by the tests.
+Supressed = 0
+
+# Enable to run faster by skipping compilation of testCaller when it already exists.
+#SkipIfBinaryExists
+
+# Compile the program that will run all the tests
+Crawl "testCaller.cpp"

Source/test.sh → Source/test/test.sh

@@ -1,14 +1,14 @@
 #!/bin/bash
 
-ROOT_PATH=.
+ROOT_PATH=..
 TEMP_ROOT=${ROOT_PATH}/../../temporary
 CPP_VERSION=-std=c++14
 MODE="-DDEBUG"
 DEBUGGER="-g"
 SIMD="-march=native"
 O_LEVEL=-O2
 
-chmod +x ${ROOT_PATH}/tools/build.sh;
+chmod +x ${ROOT_PATH}/tools/buildScripts/build.sh;
 ${ROOT_PATH}/tools/buildScripts/build.sh "NONE" "NONE" "${ROOT_PATH}" "${TEMP_ROOT}" "NONE" "${MODE} ${DEBUGGER} ${SIMD} ${CPP_VERSION} ${O_LEVEL}";
 if [ $? -ne 0 ]
 then
@@ -21,7 +21,7 @@ TEMP_SUB=$(echo $TEMP_SUB | tr "+" "p")
 TEMP_SUB=$(echo $TEMP_SUB | tr -d " =-")
 TEMP_DIR=${TEMP_ROOT}/${TEMP_SUB}
 
-for file in ./test/tests/*.cpp; do
+for file in ./tests/*.cpp; do
 	[ -e $file ] || continue
 	# Get name without path
 	name=${file##*/};