modify all md files to point to new wiki

Author: Gin

Wiki/Developer/BuildONNXRuntimeFromSource.md

@@ -1,45 +1,4 @@
-# Build ONNX Runtime From Source
-
-We use ONNX Runtime to run ML model inference efficiently. To download the source code:
-
-```
-git clone --recursive https://github.com/Microsoft/onnxruntime.git
-cd onnxruntime
-```
-
-Make sure the downloaded onnxruntime/ is in the same folder as our project's codebase Arduino-Source/ (or Arduino-Source-Internal/ for internal repo).
-
-## macOS
-
-Build command:
-
-```
-./build.sh --config Release --build_shared_lib --parallel --compile_no_warning_as_error --skip_submodule_sync --cmake_extra_defines CMAKE_OSX_ARCHITECTURES=arm64 --cmake_extra_defines FETCHCONTENT_TRY_FIND_PACKAGE_MODE=NEVER --use_coreml
-```
-
-If you want some debug info, change "Release" to "RelWithDebInfo".
-
-### Explain the build command
-
-By default, the build script uses the third-party libraries installed in the OS system as dependency. but this may create conflict: the ONNX library installed by Homebrew may be too old for the latest ONNX Runtime. To avoid this, you need to add
-`--cmake_extra_defines FETCHCONTENT_TRY_FIND_PACKAGE_MODE=NEVER` as above to let the build script download the correct third-party libraries from server.
-Alternatively, you can use `--use_vcpkg` to achieve the same result.
-
-`--use_coreml` is needed to build ONNX Runtime with CoreML, Apple's ML acceleration library.
-
-
-If you encounter such error as below:
-```
-CMake Error at .../onnxruntime/build/MacOS/Release/_deps/fp16-src/CMakeLists.txt:1 (CMAKE_MINIMUM_REQUIRED):
-  Compatibility with CMake < 3.5 has been removed from CMake.
-
-  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
-  to tell CMake that the project requires at least <min> but has been updated
-  to work with policies introduced by <max> or earlier.
-
-  Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.
-```
-this means your CMake is too old or too new to work with the downloaded third-party libraries. If too old, upgrade your CMake. If too new, you can just open the CMakeLists.txt file that has the error and comment out or delete the line that throws the error:
-```
-CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12 FATAL_ERROR)
-```
+# Build ONNX Runtime From Source
+
+This page has moved here: https://pokemonautomation.github.io/Developer/BuildONNXRuntimeFromSource.html
+

Wiki/Developer/Button.md

@@ -1,39 +1,4 @@
-# Send Button Commands
-
-[<img src="https://canary.discordapp.com/api/guilds/695809740428673034/widget.png?style=banner2">](https://discord.gg/cQ4gWxN)
-
-We mostly use a group of functions with prefix `pbf_` to send buttong commands to a micro-controller (like Arduino or Teensy). 
-The controller then sends the button commands to a connected Nintendo Switch to control a game.
-Those functions are defined in [NintendoSwitch_Commands_PushButtons.h](https://github.com/PokemonAutomation/Arduino-Source/blob/main/SerialPrograms/Source/NintendoSwitch/Commands/NintendoSwitch_Commands_PushButtons.h).
-Example button commands are `pbf_press_button()` and `pbf_press_dpad()`.
-You can read the comments of those functions to understand how to use them.
-
-Note we use ticks to measure the amount of time a button action is executed. Inside the micro-controller 125 ticks is one second. Access this number via [`TICKS_PER_SECOND`](https://github.com/PokemonAutomation/Arduino-Source/blob/main/Common/NintendoSwitch/NintendoSwitch_ControllerDefs.h).
-
-An example automation program that uses those functions is [**PokemonLA_BraviaryHeightGlitch**](https://github.com/PokemonAutomation/Arduino-Source/blob/main/SerialPrograms/Source/PokemonLA/Programs/General/PokemonLA_BraviaryHeightGlitch.cpp).
-
-## Button Command Buffer on Micro-Controller
-
-When a `pbf` function is called, the program may not wait for the micro-controller to finish executing the button command.
-It may just send the command to the micro-controller and continue executing following lines of code.
-Our software that runs on the micro-controller uses a buffer to hold incoming button commands.
-The `pbf` function has to wait only when the buffer on the micro-controller is full. It will wait until the micro-controller finishes executing the oldest command in the buffer so that the buffer has space to receive the new command.*
-
-For example, if the micro-controller buffer is empty and a program sends a command of holding button A for 200 ticks and releasing it for 100 ticks,
-the program will not wait for 300 ticks during exeuction of `pbf_press_button()`.
-The function quickly returns and the program begins executing the next line of code.
-At the same time, the micro-controller will start spending 300 ticks to execute the button command.
-It will keep pressing button A to the Switch for 200 ticks, then release it and wait for 100 ticks.
-
-This is like the case of asynchronous IO processing in some software systems.
-
-**Important:** You should not *rely* this asynchronous behavior to perform parallelization. The internal buffer sizes are undocumented and may change at any time. And some functions may break into a sequence of instructions that occupy multiple buffer slots. The purpose of the asynchronous buffering is to preserve the exact timing of button sequences across an otherwise high-latency serial bus.
-
-## Wait for Commands to Finish
-
-So in the case like you would want the program to wait for the button commands to finish before doing some other tasks (e.g. reading the video stream),
-you need to call `context.wait_for_all_requests()` after the code of button commands.
-This function stops the program from doing anything until all the commands sent to the micro-controller have finished.
-An example usage is in [**PokemonLA_PokedexTasksReader**](https://github.com/PokemonAutomation/Arduino-Source/blob/main/SerialPrograms/Source/PokemonLA/Programs/General/PokemonLA_PokedexTasksReader.cpp).
-The program reads Pokédex tasks. After it sends button commands that tells the game to go to the next Pokédex page,
-it calls `context.wait_for_all_requests()` before reading the video stream. In this way, when the program reads the video stream, the game is indeed showing the next page.
+# Send Button Commands
+
+This page has moved here: https://pokemonautomation.github.io/Developer/Button.html
+

Wiki/Developer/Color.md

@@ -1,28 +1,4 @@
-# Check Color
-
-[<img src="https://canary.discordapp.com/api/guilds/695809740428673034/widget.png?style=banner2">](https://discord.gg/cQ4gWxN)
-
-A simple visual detection method is to check the color of a region of the image. See [this topic](SubImage.md) on how to get a region of the image.
-
-We use [`image_stats()`](https://github.com/PokemonAutomation/Arduino-Source/blob/main/SerialPrograms/Source/CommonFramework/ImageTools/ImageStats.h) to extract color stats from an image.
-An example usage is in [PokemonBDSP_MenuDetector.cpp](https://github.com/PokemonAutomation/Arduino-Source/blob/main/SerialPrograms/Source/PokemonBDSP/Inference/PokemonBDSP_MenuDetector.cpp).
-`image_stats()` returns a struct `ImageStats` that stores average per-pixel color, pixel color stddev and pixel count on this image. Then it calls `is_white()` declared in [SolidColorTest.h](https://github.com/PokemonAutomation/Arduino-Source/blob/main/SerialPrograms/Source/CommonFramework/ImageTools/SolidColorTest.h) to check whether the stats reflect the image is all white.
-
-We also commonly use `is_solid()` in SolidColorTest.h to check whether the image is full of a particular color. 
-For example you can check [PokemonLA_DialogDetector.cpp](https://github.com/PokemonAutomation/Arduino-Source/blob/main/SerialPrograms/Source/PokemonLA/Inference/PokemonLA_DialogDetector.cpp).
-
-## Determine Color Thresholds
-
-When doing color check, you need to set thresholds in `is_solid()` and other functions,
-like what is the maximum color deviation that can still pass the check.
-You can first collect a few test images by taking screenshots using the screenshot button on the **SerialPrograms** executable.
-Pick some thresholds to pass all your test images.
-You can add command line tests (See [its topic](Tests.md)) to run color detection on images directly without temporarily hardcoding tests.
-
-Finally, keep the thresholds a little higher than needed on your test images so that users with different capture card color distortions than yours can still pass the check.
-
-
-## Color Values
-
-We have a `Color` class in [Color.h](https://github.com/PokemonAutomation/Arduino-Source/blob/main/Common/Cpp/Color.h) to represent a 32-bit-precision ARGB pixel color. Each color channel precision is 8-bit `uint8`. The data in `Color` is stored as a `uint32_t`. Some of our color-related functions also take `uint32_t` as color inputs. See `combine_argb()` and `combine_rgb()` in Color.h to know how individual A, R, G, B values form a `uint32_t`.
-
+# Check Color
+
+This page has moved here: https://pokemonautomation.github.io/Developer/Color.html
+

Wiki/Developer/Exception.md

@@ -1,8 +1,4 @@
-# Exception
-
-[<img src="https://canary.discordapp.com/api/guilds/695809740428673034/widget.png?style=banner2">](https://discord.gg/cQ4gWxN)
-
-We have a custom exception [`OperationFailedException`](https://github.com/PokemonAutomation/Arduino-Source/blob/main/Common/Cpp/Exceptions.h) to abort a program.
-This is very handy when we detect an error and wish to stop the program right now and display an error message to user.
-Many programs use this mechanism.
-One example is [**PokemonLA_DistortionWaiter**](https://github.com/PokemonAutomation/Arduino-Source/blob/main/SerialPrograms/Source/PokemonLA/Programs/General/PokemonLA_DistortionWaiter.cpp).
+# Exception
+
+This page has moved here: https://pokemonautomation.github.io/Developer/Exception.html
+

Wiki/Developer/Git.md

@@ -1,49 +1,4 @@
-# Develop Using Github
-
-[<img src="https://canary.discordapp.com/api/guilds/695809740428673034/widget.png?style=banner2">](https://discord.gg/cQ4gWxN)
-
-We use Github to host our codebase and allow open-source development. This guide is for developers who know a little bit of Git but don't know how to use it and Github to contribute to an open-source Github project, or for developers who want to refresh the knowledge of Github development. It also contains some tips about building and developing the code.
-
-For a more detailed guide to using git itself, you can refer to the [git book](https://git-scm.com/book/en). If you prefer videos instead, here are some good introductory videos: [Introduction](https://www.youtube.com/watch?v=uR6G2v_WsRA), [Branching and Merging](https://www.youtube.com/watch?v=FyAAIHHClqI), [Remotes](https://www.youtube.com/watch?v=Gg4bLk8cGNo).
-
-To add a new feature to the code, we use the standard Github development cycle:
-
-- Fork the [Arduino-Source](https://github.com/PokemonAutomation/Arduino-Source/tree/main/SerialPrograms/Source) repository (repo for short) so that you have a complete copy of the codebase repo under your own Github account.
-- Clone your copied repo to your local machine. Make sure your downloaded local repo is linked to your online Github repo.
-- Build the **SerialPrograms** executable. See the [Build guide](https://github.com/PokemonAutomation/Arduino-Source/blob/main/SerialPrograms/README.md) for more details on how to build our programs.
-- Some of the automation programs listed in the **SerialPrograms** require additional resources in the form of files in a folder named `Resources`.
-	- You can download the folder from our latest [program releases](https://github.com/PokemonAutomation/ComputerControl/releases) or from the Github repo [Packages](https://github.com/PokemonAutomation/Packages).
-	- Place the `Resources` folder at the same folder hierarchy as the folder of the built **SerialPrograms** executable, so that when launching the executable it can correctly find the resource folder.
-	For example, if the path of **SerialPrograms** is `C:\git\Arduino-Source\build\SerialPrograms.exe` then the resource folder should be `C:\git\Arduino-Source\Resources`.
-- Make a new Git branch on your local machine. You can name the branch by the name of the new feature you would like to implement. **Do not add any new code directly to the main branch**. All new code should be added to your feature branch. 
-- Before adding commits to the branch, set correct author name and email info in the Git config file. If you want to maintain anonymous, make sure you don't expose your personal info in your Github account and commit messages. Double check you don't set a global author and email info across that could add your personal info on a new Git repo.
-- Write the feature code. Add commits of the new code change to the feature branch.
-	- If you add or remove code files in the source-code folder, you need to update the file list in [CMakeLists.txt](https://github.com/PokemonAutomation/Arduino-Source/blob/main/SerialPrograms/CMakeLists.txt) and [SerialPrograms.pro](https://github.com/PokemonAutomation/Arduino-Source/blob/main/SerialPrograms/SerialPrograms.pro). See [Add New Files](./NewFiles.md) for more details.
-
-- Test the code of this branch to make sure it works and it won't cause problems when merged to the Git trunk (aka main branch) of the codebase.
-- Clean the code:
-	- Remove commented code that no longer used.
-	- Remove unecessary debugging code.
-	- Organize and simplify code, like converting duplicate code blocks into reusable functions.
-	- Add enough comments so that it is easy for you and others to maintain the code in future, and our repo maintainers can understand your code.
-- Push (aka upload) this branch from your local machine to your online Github repo.
-- On Github, send a pull request (PR for short) to notify our repo maintainers that a feature development is ready for review.
-- The repo maintainers review the new code in the PR, comment on it and give some suggestions if needed.
-- Discuss and take those suggestions if needed by improving the code on your local machine. Then push them to update the PR. This may take several rounds of back and forth.
-- The repo maintainers approve the PR about the feature branch, adding the code into the original repo.
-- Prepare for developing next feature:
-	- After the new code has been added to the original repo as new commits, update the main branch of your online Github repo so that you receive the new commits as well. 
-	  - One way to do this is to create a remote branch `upstream` that points to the official repo. Whenever you want to update your main branch, you can call `git fetch upstream`, then `git merge upstream/main`.
-	  - Alternatively, pull (aka download) those commits into the main branch of your local repo.
-	- You can then delete the feature branch.
-
-There are many online resources on how to use Git and Github. Feel free to study them if you are not familiar with them.
-
-# Q&A
-
-## Why create a new branch on local machine?
-
-To have the repo maintainers reviewing your changes, you need to have your new code in a PR. A PR is like a post you sent to the maintainers, which lists all your code changes and optionally your comments about them. Both you and the maintainers can comment under the PR, like you commenting under an internet post. To create a PR, you need to associate a branch to it. Therefore you need to create a new branch on your local machine, push (aka upload) it and link it to a PR. You automatically link a PR to the branch when you click a "Create a PR" button on your Github repo for a particular branch you pushed to Github.
-
-Why not use the default branch that is created when initializing my local repo on my local machine? Because the default branch is often the main branch, which serves as the "base": where the code is without your new change. You don't want to add change to this main branch, destroying the content of what the code is before your change.
-This is also a good habit of making a separate branch for your changes. If you would like to work on two features at the same time, with two branches you can separate the changes cleanly, reducing your mental load. And you never know when something may happen during developing that forces you to write a new feature. Having all your changes in separate branches keep you clean so that you can easily add a new feature on a new branch that is forked from the main branch, without worrying about prior local changes.
+# Develop Using Github
+
+This page has moved here: https://pokemonautomation.github.io/Developer/Git.html
+