Skip to content
This repository was archived by the owner on Jul 1, 2021. It is now read-only.

Understanding the Codebase

Neal Nicdao edited this page Aug 1, 2019 · 3 revisions

Directories

  • bin - Contains the executable when built, and resource folders accessible by the application.
    • CoreData - Core resources used by Urho3D. Copied directly from Urho3D and trimmed down. Don't mess with this folder.
    • Data - Folder for resources necessary for OSP to operate, or temporary resources for development purposes. Contains many assets left over from Urho3D (remove them soon).
    • OSPData - Folder for addons. Each folder in here is used as a resource path.
      • Default - Resources for the default game. Any asset related to Parts, the Editor, UI, Planets, etc, goes here.
  • src - The C++ source code.

The Source Code

TODO

Where the important action happens

1. On Execute

The program starts in src/main.cpp. The main function is generated at the bottom of the file with URHO3D_DEFINE_APPLICATION_MAIN.

  • A new OSPApplication class is created
  • Its Start() method is called by Urho3D.
    • UI and Loading screen is initialized
    • An OspUniverse class is initialized, named m_osp
    • An empty scene is created
    • AngelScript Subsystem is initialized
    • All directories in OSPData are listed, and processed by m_osp

2. Processing directories

In the OspUniverse class (src/OSPUniverse.cpp), each directory in bin/OSPData is scanned for resources in the process_directory function. Parts and scripts are loaded here. More functionality should be added to make this class more useful. So far, it does the following:

  • Load Parts:

    • Recursively scans the bin/OSPData/*AddonName*/Parts folder for any .sturdy.gltf files.
    • Start loading them in the background as GLTFFile resources.
  • Load scripts: (this is inflexible and needs improvements)

    • Scan the top level of bin/OSPData/*AddonName*/Scripts for any .as files.
    • Start loading them in the background as ScriptFile resources.
      • If a script has a loaded() function, then it is called immediately after it's loaded.

3. Main.as is Loaded

AngelScript is used for non-intensive parts of the project, such as UI. Once bin/OSPData/Default/Scripts/Main.as is finished loading, its loaded() function is called.

  • Loads menu screen from bin/Data/UI/MenuUI.xml, and adds it to the UI root, making it visible
  • Subscribes to the "Released" event for the DO SOMETHING WITH ROCKETS button

4. The Editor

Pressing DO SOMETHING WITH ROCKETS creates a script object of CraftEditor.

The editor scripts are located in bin/OSPData/Default/Scripts/CraftEditor/, CraftEditor.as containing the CraftEditor class. Through UIController (not important right now), CraftEditor implements ScriptObject, which means it can be added to nodes through an Urho3D ScriptInstance. When CraftEditor is added to the scene, it will automatically setup the UI and nodes required to edit spacecraft.

TODO: Editor needs its own page. just assume that the editor has a list of function pointers each known as "EditorFeatures"

5. SPACE is pressed

CraftEditor.as contains an EditorFeature with the function LunchTime, bound to SPACE of course.

  • The craft is combined into a single rigid body through the SolidifyBlueprint function.
  • OspUniverse::debug_function is called (src/OSPUniverse.cpp), This part is when the universe starts existing.
    • Defines a new "solar system" of just a single planet
    • Creates a PlanetTerrain associated with that new planet
    • Creates a large temporary sphere collider, as planet collisions aren't there yet
    • Creates an ActiveArea located just above the planet

Important Classes

OSPUniverse

Handles lots of the beefy stuff. TODO

ActiveArea

src/ActiveArea.cpp

An ActiveArea is a component that can be added to a Scene. A single Scene cannot represent an entire solar system, which can be billions of kilometers wide. ActiveArea acts like a small window into the large virtual universe defined elsewhere. ActiveArea handles floating origin, and should determine which objects are close enough to the viewer, so that they should appear on the scene. It should also be possible for the application to handle multiple ActiveArea instances (multiple far-away crafts active simultaneously).

Clone this wiki locally