documentation, UI platform selection

* updates contributors and BGT upgrading topics, labels memory management tutorial as incomplete.

* Updates compiling for distribution tutorial to talk about bundling facility, move bundle naming and versioning section to distribution rather than config topic.

* Adds platform selection to UI NVGT launcher.

doc/src/appendix/Contributors.md

@@ -6,7 +6,7 @@ This file contains the names of anyone who has helped contribute to the NVGT eng
 * [Rory Michie](https://github.com/RoryMichie): Has done much work on the NVGT user manual.
 * [Tyler Spivey](https://github.com/tspivey): rewrote the executable loader on Windows to work with packers such as UPX, helped make documentation look more presentable.
 * [Harry Min Khant](https://github.com/harrymkt): Wrote several documentation articles particularly in the references section, improvements to nvgt includes.
-* [Ethin Probst](https://github.com/ethindp): major optimizations to parts of the code, rewrote sound effect parsing, libspeechd integration, docs.
+* [Ethin Probst](https://github.com/ethindp): major optimizations to parts of the code, rewrote sound effect parsing, libspeechd and Android TTS engine integration, atomics, docs.
 * [Valiant8086](https://github.com/valiant8086): Documentation on game distribution.
 * [Gruia Chiscop](https://github.com/GruiaChiscop): AVSpeech implementation.
 * [Abdullah Tepeli](https://github.com/colonel-official): Delete-by-word support for the audio_form include.

doc/src/manual/-BGT Upgrading+.md

@@ -13,6 +13,7 @@ our goal is to make the transition as seamless as possible from BGT to NVGT, but
 * The `sound::stream()` method does exist in NVGT, but it's simply an alias to `sound::load()`. For this reason it is recommended that you change all your `stream()` calls to `load()` instead. The load function performs an  efficient combination of streaming and preloading by default.
 * Take care to check any method calls using the tts_voice object as a few methods such as set_voice have changed from their BGT counterparts.
 * When splitting a string, matching against \r\n is advised as BGT handles this differently. This will result in not having spurious line breaks at the ends of split text.
-* The settings object has been crafted as a ghost object. That is, it will not actually load or write any data from the registry. If you use the registry, consider using a data or ini file instead.
-* The joystick object is also a ghost object and does not currently function.
+* The settings object no longer writes to the registry, but instead has been replaced by the settings.nvgt include which wraps the previous settings object API, but instead writes to configuration files in various formats.
+* The joystick object is a ghost object and does not currently function.
 * There is a type called `var` in the engine now, so you may need to be careful if your project contains any variables named var.
+* It's worth noting that unlike BGT, NVGT by default attempts to fully package your game for you including sounds, libraries, documents and any other assets into a .zip file or similar on other platforms intended for distrobution. If you don't like this behavior, you can create a file next to nvgt.exe called config.properties and add the line build.windows_bundle = 0 which will cause NVGT to just produce a standalone executable like BGT did, though you now may need to copy some libraries from the lib folder for the compiled product to run.

doc/src/manual/-Toolkit Configuration.md

@@ -125,7 +125,7 @@ This section contains options that are directly related to the compiling/bundlin
 * output_basename = string default set from input filename: the output file or directory name of the final compiled package without an extension
 * prebuild_command = string: a custom system command that will be executed before the build begins if set
 * postbuild_command = string: a custom system command that will be executed after the build completes but before the success message
-* product_identifier=string default com.NVGTUser.InputBasenameSlug: the reverse domain bundle identifier for your application (highly recommended to customize for mobile platforms, see remarks at the bottom of this article)
+* product_identifier=string default com.NVGTUser.InputBasenameSlug: the reverse domain bundle identifier for your application (highly recommended to customize for mobile platforms, see compiling for distribution tutorial)
 * product_identifier_domain = string defaults to com.NVGTUser: everything accept the final chunk of a reverse domain identifier (used only if build.product_identifier is default)
 * product_name=string defaults to input file basename: human friendly display name of your application
 * product_version = string default 1.0: human friendly version string to display to users in bundles
@@ -210,11 +210,7 @@ Though explaining how NVGT's compilation process works is a bit beyond the scope
 Internally, you can see this at play by looking in the stub directory of NVGT's installation. You can see several files with the format `nvgt_<platform>_<stubname>.bin`, or sometimes just `nvgt_<platform>.bin` which is the default stub for a given platform. Such files are used to create the final game executable produced by NVGT's compiler, and are selected exactly using the configuration pragmas and options described. If platform is set to windows and stub is set to nc, the file nvgt_windows_nc.bin is used to produce the compiled executable of your game. The only exception is if the platform is set to auto (the default), which will cause your executable to be compiled for the host platform you are compiling on.
 
 ### bundle naming and versioning
-NVGT includes several directives particularly in the build configuration section that allow you to control how your product is identified to end users and to the systems the app is running on. While some are purely for display, others are manditory in certain situations especially when you plan to distribute your app on networks like the app store, google play and similar.
-
-If you plan to release your game on MacOS, IOS, or Android, it is highly recommended that you create what's known as a reverse domain identifier for your app by setting the build.product_identifier property. It's called the reverse domain identifier because the format is like a website in reverse, such as com.samtupy.nvgt. In mild cases it might be used to group similar apps together E. the operating system or distrobution service can implicitly tell that apps with an identifier starting with com.samtupy all belong to the same company, but in extreme cases this identifier might be used by the system as the main way your app is identified, such as on Android for example where the filesystem paths to the apps data folders actually include this identifier. The identifier can contain periods, uppercase / lowercase letters, and numbers, so long as a number is not the first character following a period. There should be at least 2 period delimited segments in this identifier (prefferably at minimum 3), and it might be a good idea to limit the first segment to popular top level domains like com, org, net etc. While in reality a couple of other characters like dashes and underscores might work in identifiers, they may not be as platform agnostic as the rules listed above. It is not important that the reverse website/app identifier you come up with here actually exists on the internet. If you do not provide this value, the default is com.NVGTUser.scriptname where scriptname is the name of the NVGT file passed to the compiler without the extension. It is possible, however, to only customize the com.NVGTUser part if you want NVGT to use the script filename to derive the rest of the identifier for you. So for example if you know that all games you'll be developing on your computer will be from the company com.epicdevelopers, you can set the key build.product_identifier_domain = com.epicdevelopers in nvgt's global config files. Now when you compile mygame.nvgtt, the full reverse domain identifier for that app will be set to com.epicdevelopers.mygame.
-
-Unfortunately, different operating systems and services use different versioning schemes. Windows and MacOS really want version numbers in major.minor.patch format, in fact the windows version resource actually contains 4 words in it's structure to store each period separated version component. While the parsed format isn't actually embedded into a binary structure on MacOS, it's still manditory as soon as you want to distribute your game in the app store, because that service reads such a property from the bundle to identify the version of the app to track updates. As such, the build.product_version_semantic property must be set for MacOS app store distrobutions, while on windows it is an optional display feature that will cause version information to show for your compiled executable. On the other hand, Android and the google play store use an integer version code to track when a given version of an APK is newer than any installed version. This simple requirement makes it very easy to manage this property automatically on android, it is done by dividing the unix timestamp in seconds by 60, you can also set the build.product_version_code property if you wish to control this manually. Finally, the build.product_version configuration option allows you to set, where possible, the version string that is actually displayed to end users.
+NVGT includes several directives particularly in the build configuration section that allow you to control how your product is identified to end users and to the systems the app is running on. While some are purely for display, others are manditory in certain situations especially when you plan to distribute your app on networks like the app store, google play and similar. For more info on these directives, you should read the "configuring bundling facility" section of the compiling for distribution topic.
 
 ## Conclusion
 Hopefully this tutorial has given you a good idea of how you can get NVGT to perform closer to how you would like in various areas from the user interface to the syntax handling. If you have any ideas as to configuration options you'd like to see added, please don't hesitate to reach out on github either with a discussion or pull request!

doc/src/manual/Memory Management Information.md → doc/src/manual/Memory Management Information (incomplete).md

@@ -1,4 +1,4 @@
-# Memory Management Information
+# Memory Management Information (incomplete)
 What is a handle? What are references? What is the difference between the stack and the heap and when/why should I care? What is a value typed object? What is a primative datatype, and when should or shouldn't one use the @ character in their code? When should I worry about garbage collection and what even is that? How much is it wise to bother with all this stuff anyway?
 
 If you've been having any such questions or similar, you've come to the right place. This tutorial will attempt to unravel and demystify all of the jargon behind various memory management techniques and structures as well as advice about when/how to use them. The goal is that by the end of this reading, you will have the knowledge to begin developing confidence particularly in the usage of handles and references in your games, while also learning a lot of interesting stuff about memory management along the way.