It turns out that trying to just give a peep a pathfinding goal and then let them loose doesn't work, because every time they reach a junction, the pathfinder has them walk 'aimlessly' instead of pursuing their target. That's why we were seeing some very large step counts in previous tests - they were (eventually) walking onto the target square, but only after lots of wandering around in circles.
This commit reworks the test data to contain an actual ride for each test scenario, where the peep will path to the tile in front of the ride entrance. A nice side benefit of this is that the ride names must match the test names, so you can now tell from looking at the rides in the test data which one is used for which test instance.
The 'yellow marker' tiles for goal positions are also removed here, as we're deriving goal positions from the ride entrances instead.
To make it a little clearer what the parameter is for, rename FindPath::maxSteps to FindPath::expectedSteps, and extend the comment to describe what happens in negative test scenarios.
There exists a helper function map_get_surface_element_at which already searches a tile's element list for the surface element, so we can just use that.
Introduce some basic scenario-style tests for the pathfinding AI. There
are two tests:
* Test that a peep can get from a given start position to a given end
position, and that it takes them an expected number of ticks to do so.
Also test that they did not walk on any 'forbidden' tiles in the process,
e.g. tiles that are completely the wrong direction from the goal etc.
* Test that a peep can *not* get from a given start position to a given
end position after a given number of ticks.
Each test is parametric, and instantiated for multiple different
start/end positions within the provided test park. If we find a new
situation that needs a test, it should just be a matter of building
that situation in the saved game and then adding a line to the code to
set it up.
Indicating 'forbidden' tiles is done using terrain surface type IDs:
tiles that the pathfinder should never send the peep into should be
painted with the red neon surface type (index 8). This means we have
no way to forbid some path elements on a tile while allowing others,
but we don't need that right now.
Similarly, to help ensure that the test data and code are kept in
sync, the tests also require that peep start tiles are painted with
the green neon surface type (index 11) and that goal tiles are
painted with the yellow neon surface type (index 9).
This replaces most calls/direct access to the footpath edges (i.e. the orthogonal directions, not the corners). This includes places where the whole byte was retrieved, but only compared against orthogonal directions.
This will enable compilation of testpaint on targets different than x86.
It won't function the way it does on x86, but it should provide a way of
tackling various compilation errors that can only be seen in the very
specific environment required by testpaint proper.
Clang-format sees the text behind `#pragma region` as code and formats it. Instead of stating the copyright and date there, it's now in the comment block right below it. The text "Copyright" is left in the `#pragma region` line, as clang-format sees it as a single identifier.
I took the opportunity to normalize the dates, and add the copyright notice to the source files where it was missing them (except for third-party and the generated resources.h file).
This aims to make future refactoring easier. The arguments are removed where possible, but kept and marked with C++17's [[maybe_unused]] where they could not be removed (e.g. when they are used as a callback, rather than called directly).
I've skipped the rides/<category>/* and peep/* source files, because the rides source files are mostly generated and have a ton of unused variables, and the peep source files are being refactored.
I've also skipped most of window/* source files, because most of the functions are used as callbacks and will be bulk-renamed at some point.
* Update includes in PlatformEnvironment.cpp
* Update includes in ParkImporter.h
* Update includes of OpenRCT2.h
* Update includes in Intro.h
* Remove unused include from Input.cpp
* Update includes of Imaging.h
* Update includes in Game.h
* Update includes in Editor.h
* Update includes of Context.cpp
* Update includes in Cheats.cpp, CmdlineSprite.cpp
* Update includes of some source files
* Update includes in some cpp files
* Update includes in some cpp files
* Update includes in TextureCache.h
* Fix tests
* Update includes in Font.cpp
* Update includes in LightFX files
* Update some includes
* Fix GCC builds
* Update some includes
* Update some includes
* Update includes in FontsFamilies.*
* Update includes of Console.h
* Improve includes in Window.h
* Improve headers in Viewport.h/Window.h
* Fix MSVC build
* Fix network-less builds
* Reduce inclusion of Map.h
`typedef struct/union/enum name { ... } name_again;` is not needed whe compiling C++, moving the name at the back to be in front of the object and removing `typedef` makes it usable the very same way.
This also replaces typedefs with the using keyword. They have better readability, especially for function pointer types, and would allow more flexibility when used with templates.