Only 1 H1 allowed per page

docs/en/manuals/extensions-best-practices.md

@@ -38,7 +38,7 @@ For us, it's better to use `const char*` and a few helper functions.
 
 Use the `static` keywork on functions local to your compile unit if possible. This lets the compiler do some optimizations, and can both improve performance as well as reduce executable size.
 
-# 3rd party libraries
+## 3rd party libraries
 
 When choosing a 3rd party library to use (regardless of language), we consider at least these things:
 
@@ -50,7 +50,7 @@ When choosing a 3rd party library to use (regardless of language), we consider a
 * License - Is it ok to use for this project?
 
 
-# Open source dependencies
+## Open source dependencies
 
 Always make sure that you have access to your dependencies. E.g. if you depend on something on GitHub, there's nothing preventing that repository either being removed, or suddenly changes direction or ownership. You can mitigate this risk by forking the repository and using your fork instead of the upstream project.
 
@@ -59,11 +59,11 @@ The code in that library will be injected into your game, so make sure the libra
 <legal note?>
 
 
-# Project structure
+## Project structure
 
 When creating an extension, there are a few things that help out in developing it as well as maintaining it.
 
-## Lua api
+### Lua api
 
 There should only be one Lua api, and one implementation of it. This makes it a lot easier to behave the same for all platforms.
 
@@ -74,7 +74,7 @@ That way you can detect support by checking for nil:
         myextension.do_something()
     end
 
-## Folder structure
+### Folder structure
 
 Here is a folder structure that we use frequently for our extensions.
 
@@ -106,7 +106,7 @@ Here is a folder structure that we use frequently for our extensions.
 
 Note that the `myextension.mm` and `myextension_android.cpp` are only needed if you are doing specific native calls for that platform.
 
-### Platform folders
+#### Platform folders
 
 In certain places, we use the platform architecture as a folder name, to know what files to use when compiling/bundling the application.
 These are of the form:

docs/en/manuals/extensions-details.md

@@ -10,20 +10,20 @@ Here we list some relevant build information, in order to make the integrations
 Here are some things to consider when you create an extension for the Defold engine.
 For more general guidelines on how to develop cross platform native code, and also extension/Lua apis, please refer to [Native Extensions - Best Practices](/manuals/extensions-best-practices)
 
-# C++ version
+## C++ version
 
 In the engine itself we use no C++ version higher than C++98. While you may use a higher version to build your extension, bear in mind that a higher version might come with ABI changes. This might make it impossible to use your extension in conjunction with other extensions in the engine or on the asset store.
 
 When creating libraries (such as extensions), it's good to keep the lowest common denominator as a target.
 
-# Toolchain
+## Toolchain
 
 Clang - macOS, iOS, Win32
 GCC - Android, Linux
 
 *We're plan make both Android and Linux to use Clang as well*
 
-## SDK Versions
+### SDK Versions
 
 * Android: NDK 10e, Build Tools 23.0.2, Api Level 14
 * iOS: iPhoneOS11.2.sdk
@@ -32,7 +32,7 @@ GCC - Android, Linux
 * Linux: Ubuntu 16.04, gcc 5.4.0, libssl-dev, uuid-dev, libxi-dev, libopenal-dev, libgl1-mesa-dev, libglw1-mesa-dev, freeglut3-dev
 * Html5: Emscripten 1.38.0,
 
-## C++ version + ABI compatibility
+### C++ version + ABI compatibility
 
 * Linux: `GCC 5.4.0`
 * Android:`GCC 4.8`
@@ -44,23 +44,23 @@ For iOS/MacOS, we use `-miphoneos-version-min=6.0` and `-mmacosx-version-min=10.
 
 We don't specify a specific C++ version, so we use the default of each compiler.
 
-# Win32 + Clang
+## Win32 + Clang
 
 A recent addition is to be able to build the Windows builds using clang.
 This allows for faster builds on our servers, and also allows us to streamline our builds.
 
-# Static linkage
+## Static linkage
 
 The custom engine is built using static linkage.
 The main reason is that on iOS version < 8, multiple executable binaries in an .ipa aren't allowed in the app store.
 
-# No C++ Exceptions
+## No C++ Exceptions
 
 We don't make use of any exceptions in the engine.
 It isn't generally used in game engines, since the data is (mostly) known beforehand, during development.
 Removing the support for C++ exceptions decreases executable size and improves the runtime performance.
 
-# Defold SDK
+## Defold SDK
 
 With each (biweekly) release of Defold, we release a new Defold SDK.
 With it, we ship the libraries of the engine, and also a build manifest file,