1 files changed, 1 insertions, 136 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 1b2056885..01109785d 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,136 +1 @@
-# Reporting Issues
+**The Contributor's Guide has moved to [the Citra wiki](https://github.com/citra-emu/citra/wiki/Contributing).**
-**The issue tracker is not a support forum.** Unless you can provide precise *technical information* regarding an issue, you *should not post in it*. If you need support, first read the [FAQ](https://github.com/yuzu-emu/yuzu/wiki/FAQ) and then either visit our [Discord server](https://discordapp.com/invite/u77vRWY), [our forum](https://community.citra-emu.org) or ask in a general emulation forum such as [/r/emulation](https://www.reddit.com/r/emulation/). If you post support questions, generic messages to the developers or vague reports without technical details, they will be closed and locked.
-If you believe you have a valid issue report, please post text or a screenshot from the log (the console window that opens alongside yuzu) and build version (hex string visible in the titlebar and zip filename), as well as your hardware and software information if applicable.
-# Contributing
-yuzu is a brand new project, so we have a great opportunity to keep things clean and well organized early on. As such, coding style is very important when making commits. We run clang-format on our CI to check the code. Please use it to format your code when contributing. However, it doesn't cover all the rules below. Some of them aren't very strict rules since we want to be flexible and we understand that under certain circumstances some of them can be counterproductive. Just try to follow as many of them as possible.
-# Using clang format (version 6.0)
-When generating the native build script for your toolset, cmake will try to find the correct version of clang format (or will download it on windows). Before running cmake, please install clang format version 6.0 for your platform as follows:
-* Windows: do nothing; cmake will download a pre built binary for MSVC and MINGW. MSVC users can additionally install a clang format Visual Studio extension to add features like format on save.
-* OSX: run `brew install clang-format`.
-* Linux: use your package manager to get an appropriate binary.
-If clang format is found, then cmake will add a custom build target that can be run at any time to run clang format against *all* source files and update the formatting in them. This should be used before making a pull request so that the reviewers can spend more time reviewing the code instead of having to worry about minor style violations. On MSVC, you can run clang format by building the clang-format project in the solution. On OSX, you can either use the Makefile target `make clang-format` or by building the clang-format target in XCode. For Makefile builds, you can use the clang-format target with `make clang-format`
-### General Rules
-* A lot of code was taken from other projects (e.g. Citra, Dolphin, PPSSPP, Gekko). In general, when editing other people's code, follow the style of the module you're in (or better yet, fix the style if it drastically differs from our guide).
-* Line width is typically 100 characters. Please do not use 80-characters.
-* Don't ever introduce new external dependencies into Core
-* Don't use any platform specific code in Core
-* Use namespaces often
-* Avoid the use of C-style casts and instead prefer C++-style `static_cast` and `reinterpret_cast`. Try to avoid using `dynamic_cast`. Never use `const_cast`.
-### Naming Rules
-* Functions: `PascalCase`
-* Variables: `lower_case_underscored`. Prefix with `g_` if global.
-* Classes: `PascalCase`
-* Files and Directories: `lower_case_underscored`
-* Namespaces: `PascalCase`, `_` may also be used for clarity (e.g. `ARM_InitCore`)
-### Indentation/Whitespace Style
-Follow the indentation/whitespace style shown below. Do not use tabs, use 4-spaces instead.
-### Comments
-* For regular comments, use C++ style (`//`) comments, even for multi-line ones.
-* For doc-comments (Doxygen comments), use `/// ` if it's a single line, else use the `/**` `*/` style featured in the example. Start the text on the second line, not the first containing `/**`.
-* For items that are both defined and declared in two separate files, put the doc-comment only next to the associated declaration. (In a header file, usually.) Otherwise, put it next to the implementation. Never duplicate doc-comments in both places.
-```cpp
-// Includes should be sorted lexicographically
-// STD includes first
-#include <map>
-#include <memory>
-// then, library includes
-#include <nihstro/shared_binary.h>
-// finally, yuzu includes
-#include "common/math_util.h"
-#include "common/vector_math.h"
-// each major module is separated
-#include "video_core/pica.h"
-#include "video_core/video_core.h"
-namespace Example {
-// Namespace contents are not indented
-// Declare globals at the top
-int g_foo{}; // {} can be used to initialize types as 0, false, or nullptr
-char* g_some_pointer{}; // Pointer * and reference & stick to the type name, and make sure to initialize as nullptr!
-/// A colorful enum.
-enum SomeEnum {
-    ColorRed,   ///< The color of fire.
-    ColorGreen, ///< The color of grass.
-    ColorBlue,  ///< Not actually the color of water.
-};
-/**
- * Very important struct that does a lot of stuff.
- * Note that the asterisks are indented by one space to align to the first line.
- */
-struct Position {
-    int x{}, y{}; // Always intitialize member variables!
-};
-// Use "typename" rather than "class" here
-template <typename T>
-void FooBar() {
-    const std::string some_string{ "prefer uniform initialization" };
-    int some_array[]{
-        5,
-        25,
-        7,
-        42,
-    };
-    if (note == the_space_after_the_if) {
-        CallAfunction();
-    } else {
-        // Use a space after the // when commenting
-    }
-    // Place a single space after the for loop semicolons, prefer pre-increment
-    for (int i{}; i != 25; ++i) {
-        // This is how we write loops
-    }
-    DoStuff(this, function, call, takes, up, multiple,
-            lines, like, this);
-    if (this || condition_takes_up_multiple &&
-        lines && like && this || everything ||
-        alright || then) {
-        // Leave a blank space before the if block body if the condition was continued across
-        // several lines.
-    }
-    switch (var) {
-    // No indentation for case label
-    case 1: {
-        int case_var{ var + 3 };
-        DoSomething(case_var);
-        break;
-    }
-    case 3:
-        DoSomething(var);
-        return;
-    default:
-        // Yes, even break for the last case
-        break;
-    }
-    std::vector<T> you_can_declare, a_few, variables, like_this;
-}
-}
-```

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1b2056885..01109785d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md
@@ -1,136 +1 @@
1	# Reporting Issues	The Contributor's Guide has moved to [the Citra wiki](https://github.com/citra-emu/citra/wiki/Contributing).
2
3	The issue tracker is not a support forum. Unless you can provide precise technical information regarding an issue, you should not post in it. If you need support, first read the [FAQ](https://github.com/yuzu-emu/yuzu/wiki/FAQ) and then either visit our [Discord server](https://discordapp.com/invite/u77vRWY), [our forum](https://community.citra-emu.org) or ask in a general emulation forum such as [/r/emulation](https://www.reddit.com/r/emulation/). If you post support questions, generic messages to the developers or vague reports without technical details, they will be closed and locked.
4
5	If you believe you have a valid issue report, please post text or a screenshot from the log (the console window that opens alongside yuzu) and build version (hex string visible in the titlebar and zip filename), as well as your hardware and software information if applicable.
6
7	# Contributing
8	yuzu is a brand new project, so we have a great opportunity to keep things clean and well organized early on. As such, coding style is very important when making commits. We run clang-format on our CI to check the code. Please use it to format your code when contributing. However, it doesn't cover all the rules below. Some of them aren't very strict rules since we want to be flexible and we understand that under certain circumstances some of them can be counterproductive. Just try to follow as many of them as possible.
9
10	# Using clang format (version 6.0)
11	When generating the native build script for your toolset, cmake will try to find the correct version of clang format (or will download it on windows). Before running cmake, please install clang format version 6.0 for your platform as follows:
12
13	* Windows: do nothing; cmake will download a pre built binary for MSVC and MINGW. MSVC users can additionally install a clang format Visual Studio extension to add features like format on save.
14	* OSX: run `brew install clang-format`.
15	* Linux: use your package manager to get an appropriate binary.
16
17	If clang format is found, then cmake will add a custom build target that can be run at any time to run clang format against all source files and update the formatting in them. This should be used before making a pull request so that the reviewers can spend more time reviewing the code instead of having to worry about minor style violations. On MSVC, you can run clang format by building the clang-format project in the solution. On OSX, you can either use the Makefile target `make clang-format` or by building the clang-format target in XCode. For Makefile builds, you can use the clang-format target with `make clang-format`
18
19	### General Rules
20	* A lot of code was taken from other projects (e.g. Citra, Dolphin, PPSSPP, Gekko). In general, when editing other people's code, follow the style of the module you're in (or better yet, fix the style if it drastically differs from our guide).
21	* Line width is typically 100 characters. Please do not use 80-characters.
22	* Don't ever introduce new external dependencies into Core
23	* Don't use any platform specific code in Core
24	* Use namespaces often
25	* Avoid the use of C-style casts and instead prefer C++-style `static_cast` and `reinterpret_cast`. Try to avoid using `dynamic_cast`. Never use `const_cast`.
26
27	### Naming Rules
28	* Functions: `PascalCase`
29	* Variables: `lower_case_underscored`. Prefix with `g_` if global.
30	* Classes: `PascalCase`
31	* Files and Directories: `lower_case_underscored`
32	* Namespaces: `PascalCase`, `_` may also be used for clarity (e.g. `ARM_InitCore`)
33
34	### Indentation/Whitespace Style
35	Follow the indentation/whitespace style shown below. Do not use tabs, use 4-spaces instead.
36
37	### Comments
38	* For regular comments, use C++ style (`//`) comments, even for multi-line ones.
39	* For doc-comments (Doxygen comments), use `/// ` if it's a single line, else use the `/*` `/` style featured in the example. Start the text on the second line, not the first containing `/**`.
40	* For items that are both defined and declared in two separate files, put the doc-comment only next to the associated declaration. (In a header file, usually.) Otherwise, put it next to the implementation. Never duplicate doc-comments in both places.
41
42	```cpp
43	// Includes should be sorted lexicographically
44	// STD includes first
45	#include <map>
46	#include <memory>
47
48	// then, library includes
49	#include <nihstro/shared_binary.h>
50
51	// finally, yuzu includes
52	#include "common/math_util.h"
53	#include "common/vector_math.h"
54
55	// each major module is separated
56	#include "video_core/pica.h"
57	#include "video_core/video_core.h"
58
59	namespace Example {
60
61	// Namespace contents are not indented
62
63	// Declare globals at the top
64	int g_foo{}; // {} can be used to initialize types as 0, false, or nullptr
65	char* g_some_pointer{}; // Pointer * and reference & stick to the type name, and make sure to initialize as nullptr!
66
67	/// A colorful enum.
68	enum SomeEnum {
69	ColorRed, ///< The color of fire.
70	ColorGreen, ///< The color of grass.
71	ColorBlue, ///< Not actually the color of water.
72	};
73
74	/**
75	* Very important struct that does a lot of stuff.
76	* Note that the asterisks are indented by one space to align to the first line.
77	*/
78	struct Position {
79	int x{}, y{}; // Always intitialize member variables!
80	};
81
82	// Use "typename" rather than "class" here
83	template <typename T>
84	void FooBar() {
85	const std::string some_string{ "prefer uniform initialization" };
86
87	int some_array[]{
88	5,
89	25,
90	7,
91	42,
92	};
93
94	if (note == the_space_after_the_if) {
95	CallAfunction();
96	} else {
97	// Use a space after the // when commenting
98	}
99
100	// Place a single space after the for loop semicolons, prefer pre-increment
101	for (int i{}; i != 25; ++i) {
102	// This is how we write loops
103	}
104
105	DoStuff(this, function, call, takes, up, multiple,
106	lines, like, this);
107
108	if (this \|\| condition_takes_up_multiple &&
109	lines && like && this \|\| everything \|\|
110	alright \|\| then) {
111
112	// Leave a blank space before the if block body if the condition was continued across
113	// several lines.
114	}
115
116	switch (var) {
117	// No indentation for case label
118	case 1: {
119	int case_var{ var + 3 };
120	DoSomething(case_var);
121	break;
122	}
123	case 3:
124	DoSomething(var);
125	return;
126
127	default:
128	// Yes, even break for the last case
129	break;
130	}
131
132	std::vector<T> you_can_declare, a_few, variables, like_this;
133	}
134
135	}
136	```