[WIP] Pipeline tree/frontend refactor

[athairus]

This PR is for an implementation of the pipeline tree I had envisioned earlier. All nodes in the tree will communicate through a simple and clearly defined interface.

The PR is a package deal: work is being done here in feature-pipeline and also in phoenix-backend under the same name, feature-pipeline.

TODO:

• [ ] FIX TRAVIS #269
• [ ] Recreate frontend
  • [X] Fully implement and refactor all old features (collections excluded)
  • [x] Remove all uses of StackView
  • [ ] Finish input remapping
  • [x] Touch input
    • [x] Emulator needs touch mode
  • [ ] Let user set deadzone settings #262
  • Design a clean UI
  • Keyboard bug: hold down modifier while pressing mapped key, gets stuck

    • 258

• AudioOutput
  • Somehow on the main thread? Or is it really MicroTimer's fault?
  • Move to dedicated thread
• VideoOutput/LibretroCore
  • [x] Support 3D
  • [ ] Detect and support everything besides OpenGL 2.0 (currently hard-coded)
• Fix PhoenixWindow
  • [x] Weird resizing behavior (necessary due to how the window gets positioned when window first spawns)
  • [x] Context reset glitches
• Pull global/dynamic pipeline to and from the main/game threads
  • When and why
  • Why: Let the user set whether emulation runs on a dedicated thread or not
    • Alpha target probably
• [x] Reset SDL on demand to apply new custom gamepad mappings (or is there a simpler way?)
  • [x] Hook up custom input mapping again (we can add the path to GameConsole::source)

[athairus]

Currently have the entire pipeline set up and working except for input. It currently only has GamepadManager up and running and LibretroCore ORs all input together into player 1.

[athairus]

There is a bug with PhoenixWindow I need to look into at some point. Toggling VSync creates this lovely picture:

See my default Windows 10 wallpaper behind it? This must have something to do with how we reset the context to apply the new VSync setting... or a driver bug? (NVIDIA GTX 770, 364.72)

EDIT: Doesn't matter now, better less hacky VSync method is being used now

[athairus]

132 is fixed in this branch

[athairus]

Some Qt stuff we should try out: Q_GLOBAL_STATIC

[athairus]

Making GameConsole simpler

What if we had Nodes register themselves with GameConsole instead of GameConsole owning a set of Nodes? We could then have each Node, in its constructor, call something like this: GameConsole::RegisterNode( Node *node, bool gameConsoleOwnsPointer );. If gameConsoleOwnsPointer is true, it'll get moved to the game thread and will be deleted by GameConsole on app quit. This should be set to false when the object is owned by QML.

Maybe we can take advantage of Qt's meta object system to resolve what type of Node this is at runtime and store it into the appropriate member of GameConsole. Maybe we could take it one step further and have GameConsole track Node pointers by a QMap<QString, Node *> nodes, using a macro like #define connectNodes( a, b ) Node::connectNodes( nodes[ #a ], nodes[ #b ] ) or something, renaming Node::connectNodes to something else to prevent collisions. A program-terminating null check will be added to make sure things are being referenced properly.

Then to add a new Node you simply:

1. Create your Node subclass
2. Call GameConsole::registerNode( this, true/false ); in your Node subclass constructor
3. Make connections as appropriate within GameConsole for your dynamic pipeline type
4. The lifecycle is now automatically managed by either GameConsole or the QML engine

This will also get rid of the pointer properties within GameConsole. The objects will instead make themselves known to GameConsole by calling that function from their constructor.

GameConsole itself will have to be set up earlier than the QML engine for this to work for QML objects. We can simply declare it in main() and make it available to the entire QML engine with the name gameConsole.

[athairus]

Terms

• Pipeline tree - A proper tree made up of nodes (defined in node.h) and instantiated in GameConsole, the root of the tree.
• Node - A QObject subclass with a pair of signal/slot pairs for handling two types of data: Commands and Data
• Heartbeat - A Command that allows emulation to be driven per-frame
• Command - Data meant to be sent infrequently enough that the overhead of a heap allocation per use is insignificant. Commands are accompanied with a QVariant as data if necessary (if it's not necessary, an invalid QVariant is passed). Examples: Play, Stop, Pause, AddController
• Data - Data that is usually synchronized with Heartbeats, in other words, per-frame data. For efficiency data is passed as a pointer, which requires both a QMutex to ensure atomic reads and writes to the data and a circular buffer pool for the producer of that data.
• Circular buffer pool - A circular buffer containing pointers to identically-sized buffers. These buffers should be instantiated at load time and never change throughout the execution of a Core. This ensures that you can safely pass pointers from the circular buffer to consumers without worrying about reference counting or memory leaks. It also works as a buffer in the other sense of the word, allowing a consumer that is temporarily slowed down for whatever reason to "catch up" without dropping any incoming data. Note that the circular buffer is finite in size, so if a consumer consumes more slowly than the rate the data comes in, it will get "lapped" by the producer. This scenario may cause glitches in the consumer (skipped audio, jumpy video) but should not cause any other issues. Note: If a consumer acts as a filter (consumes transforms then produces data) consumers should copy the incoming data into their own buffer. Consumers are not permitted to modify the incoming data.
• Global pipeline - The pipeline tree as it is established once Phoenix has finished loading. Made up of just enough Nodes to provide input data to GlobalGamepad so the gamepad can be used to control Phoenix.
• Dynamic pipeline - The pipeline tree customized for a particular type of Core. The global pipeline is dynamically torn down on load and reconnected on unload. Currently only the Libretro pipeline is available.
• Core - Normally meant to represent a Libretro core, in this case it's meant to represent the API itself. Each API gets its own Core subclass and Nodes to connect it to the dynamic pipeline.
• Main/QML thread - Also known as the GUI thread. Handles events from the windowing system (keyboard, mouse) along with managing our QML-based UI.
• Game thread - Thread dedicated to handling controller input and emulation via a Core. Has its own OpenGL context and offscreen surface.
• Render thread - Dedicated thread created by Qt code that renders the QML-based UI's visual state using OpenGL (Qt Scene Graph). Its OpenGL context and the game thread's OpenGL context are set up as shared.
• Critical segment - The segment of the global/dynamic pipeline that runs from Heartbeat production down to the Core. Required to be single-threaded for efficiency unless the Core cannot live on the game thread.
• Critical segment tail - A particular Node designated as the "tail" of the critical segment. Usually connected as a child of the Core, its job is to acknowledge state changes that made their way into the pipeline tree by way of its head (ALL state changes and property changes must enter through the pipeline tree's head). Currently implemented as ControlOutput.
• SDL segment - The segment of the global/dynamic pipeline whose Nodes call SDL functions. SDL handles are only guarantied to be valid inside this segment. Like the critical segment, it has its own tail (currently SDLUnloader). The head is SDLManager. For the most part, it should overlap with the critical segment. By itself, it's not required to be single-threaded.

[athairus]

Basic render loop breaks QML Timers and I don't know why...