Date: October 15, 2025 Status: Proposed Author: Gemini AI Assistant
This document outlines a comprehensive refactoring plan for the YAZE architecture. The current structure has resulted in tight coupling between components, slow incremental build times, and architectural inconsistencies (e.g., shared libraries located within the app/ directory).
The primary goals of this refactoring are:
core, gfx, zelda3) from the applications that consume them (app, cli).The proposed architecture organizes the codebase into two distinct layers: Foundational Libraries and Applications.
This plan will be executed in three main phases.
This phase establishes a new, top-level library for application-agnostic project management and ROM patching logic.
src/core/.src/app/core/{project.h, project.cc} → src/core/ (pending)src/app/core/{asar_wrapper.h, asar_wrapper.cc} → src/core/ (done)src/app/core/features.h → src/core/ (pending)yaze::core to yaze::project for clarity.src/core/CMakeLists.txt, define the yaze_core_lib static library containing the moved files. This library should have minimal dependencies (e.g., yaze_util, absl).This phase decouples the graphics engine from the GUI application, turning it into a foundational, reusable library. This is critical for supporting multiple rendering backends as outlined in docs/G2-renderer-migration-plan.md.
src/app/gfx/ directory to src/gfx/.src/gfx/CMakeLists.txt, define the yaze_gfx_lib static library. This will aggregate all graphics components (backend, core, resource, etc.).yaze application target will now explicitly depend on yaze_gfx_lib.This phase dissolves the ambiguous src/app/core directory and simplifies the application's structure.
src/app/core/service/ directory to src/app/service/. This creates a clear, top-level service layer for gRPC implementations.src/app/core/{window.cc, window.h, timing.h} into the existing src/app/platform/ directory. This consolidates all platform-specific windowing and input code.src/app/core/{controller.cc, controller.h} to src/app/. This highlights its role as the primary orchestrator of the GUI application.yaze_app_core_lib target.app/controller.cc, app/platform/window.cc, app/service/*.cc, etc.) directly to the main yaze executable target.This architectural refactoring fully supports and complements the ongoing EditorManager improvements detailed in docs/H2-editor-manager-architecture.md.
EditorManager and its new coordinators (UICoordinator, PopupManager, SessionCoordinator) are clearly components of the Application Layer.core, gfx) out of src/app, we create a clean boundary. The EditorManager and its helpers will reside within src/app/editor/ and src/app/editor/system/, and will consume the new yaze_core_lib and yaze_gfx_lib as dependencies.EditorManager's role as a UI and session coordinator even clearer, as it no longer lives alongside low-level libraries.src/core/ and move project, asar_wrapper, and features files.yaze_core_lib CMake target.src/app/gfx/ to src/gfx/. (DEFERRED - app-specific)yaze_gfx_lib CMake target. (DEFERRED - app-specific)src/app/core/service/ to src/app/service/.src/app/core/testing/ to src/app/test/ (merged with existing test/).window.cc, timing.h to src/app/platform/.controller.cc to src/app/.yaze_core_lib to yaze_app_core_lib to distinguish from foundational yaze_core_lib.src/app/core/ now only contains core_library.cmake for app-level functionality.#include "app/core/..." directives updated to new paths.src/core/ with project.{h,cc}, features.h, and asar_wrapper.{h,cc}yaze::core to yaze::project for project management typesyaze_core_lib in src/core/CMakeLists.txt with minimal dependencies#include "core/project.h" and #include "core/features.h"src/app/core/service/ → src/app/service/ (gRPC services)src/app/core/testing/ → src/app/test/ (merged with existing test infrastructure)src/app/core/window.{cc,h}, timing.h → src/app/platform/src/app/core/controller.{cc,h} → src/app/yaze_core_lib to yaze_app_core_lib to avoid naming conflictsrc/app/core/Graphics refactoring (src/app/gfx/ → src/gfx/) deferred as it's app-specific and requires careful consideration of rendering backends.
z3ed CLI can link against yaze_core_lib and yaze_zelda3_lib without pulling in any GUI or rendering dependencies, resulting in a smaller, more portable executable.gfx library paves the way for supporting SDL3, Metal, or Vulkan backends with minimal disruption to the rest of the application.