Godot Engine

The macOS platform port of Godot is implemented using C++, Objective-C, and Objective-C++. It leverages shared Apple code located in drivers/apple.

For packaging and distribution, the platform utilizes specific templates found in misc/dist/macos:

• misc/dist/macos_tools.app: An .app bundle template used for packaging the macOS editor.
• misc/dist/macos_template.app: A template used for packaging macOS export templates.

The iOS platform port in Godot is implemented using C++, Objective-C, and Objective-C++. It is built upon the drivers/apple_embedded abstract platform and utilizes shared Apple code found in drivers/apple.

For packaging iOS export templates, Godot uses the Xcode project template located in the misc/dist/apple_embedded_xcode directory.

The apksig library is designed to simplify APK signing and verification, specifically ensuring that signatures are compatible with the Android platform versions supported by the APK. It supports both JAR signing and the APK Signature Scheme v2.

The library is intended for use outside of Android devices (e.g., in build pipelines) and handles the complexities of different Android version verification logic by choosing appropriate cryptographic algorithms based on the target platform versions.

Godot Engine is a cross-platform, feature-packed engine for creating 2D and 3D games from a unified interface. It supports exporting to major desktop platforms (Linux, macOS, Windows), mobile platforms (Android, iOS), Web-based platforms, and various consoles.

To begin using Godot, you can either download pre-built binaries or compile the engine from source.

Grisu2 is a C++11 implementation of the Grisu2 algorithm, which is used for converting floating-point numbers to decimal strings quickly and accurately. This specific implementation is a modified version of the code found in simdjson (by Daniel Lemire), adapted for use within Godot.

Key characteristics of the Godot-patched version include:

• A simplified grisu2 namespace.
• Unique function names to prevent collisions.
• Support for both float and double types via to_chars.
• Removal of trailing .0 logic to maintain consistency with Godot's String::num_scientific behavior.

The glTF module in Godot is responsible for importing and exporting glTF files. It is organized into several layers:

• glTF Structures: Represented as C++ classes in the structures/ directory, these are the fundamental building blocks of a glTF file.
• glTF Extensions: Located in the extensions/ directory, these provide optional features that extend the base glTF specification.
• GLTFState: A container that holds collections of glTF structures and extensions.
• GLTFDocument: The primary interface that operates on GLTFState and its constituent elements to perform transformations.
• Editor Integration: The editor/ component utilizes GLTFDocument to handle the actual import and export of 3D models within the Godot editor.

The GDScript compilation process follows a general order to transform source code into executable bytecode for the virtual machine. This process is used both in the editor and in exported games. The stages are:

1. Tokenizing: Converting the source code String into a sequence of tokens (language constructs, identifiers, literals).
2. Parsing: Building an Abstract Syntax Tree (AST) from tokens and identifying syntax errors.
3. Analyzing: Verifying code logic, performing typechecking, and resolving scopes.
4. Compiling: Generating bytecode from the AST and populating runtime class information.

Note that the full compilation must complete before the bytecode can be passed to the virtual machine and run.

// General order of operations:
// Tokenizing -> Parsing -> Analyzing -> Compiling

The OpenXR GitHub projects use multiple licenses. While general practices exist, the data in or adjacent to each file is the authoritative license and copyright data.

To ensure compliance, look for:

• License identifiers in each file.
• Adjacent files with a .license extension.
• The .reuse/dep5 copyright description file.

You can use the reuse command line tool to generate a software bill of materials (BOM) in SPDX format from this data. Note that reuse typically excludes generated files; for a complete BOM including API headers and loader source, use the OpenXR-SDK repository instead.

GDScript loading involves two levels of preparation managed by GDScriptCache:

1. Shallow Scripts: Obtained via get_shallow_script(). These are scripts that have been parsed but not yet analyzed or compiled. They provide information about defined classes and class members. They are useful for checking class interfaces or member existence and are critical because they cannot create cyclic dependency problems.

2. Full Scripts: Obtained via get_full_script(). These are scripts that have been statically analyzed and fully compiled. They are ready for execution but can create cyclic dependency problems. The analyzer, for example, avoids requesting full scripts to prevent these issues.

In practice, a full script is typically the result of calling GDScript::reload().