PixelBullet  0.0.1
A C++ game engine
Loading...
Searching...
No Matches
PixelBullet Documentation

This site is the generated documentation home for the PixelBullet workspace. It complements the repository root README.md, which remains the main onboarding document for host setup, build/test quickstarts, and day-to-day development workflows.

What Lives Here

  • Hand-authored documentation pages under docs/
  • Generated API and source documentation for the public include tree under engine/include/pixelbullet plus the implementation tree under engine/src
  • Durable module-local notes that are useful to keep alongside the code they describe

Documentation Map

Guides

  • Repo development and distribution model
  • Engine architecture and ownership model
  • First-person weapon presentation model
  • Graphics roadmap and asset contract
  • Logging workflow

Module Notes

  • The graphics and shader pipeline notes live in the Graphics Module page generated from engine/src/graphics/module_notes.md.

API Surface

  • The repo distribution model lives in Repo development and distribution model; engine source hierarchy, integration ownership, backend ownership, and staged migration direction live in Engine architecture and ownership model.
  • Public engine headers live under engine/include/pixelbullet and are exported through curated engine Bazel targets.
  • Repo-internal first-party engine integration contracts live under engine/integration and are not part of the source-level public API surface.
  • Asset-owned authoring detail inspection and external glTF import execution live under engine/integration/assets, scene runtime contracts live under engine/integration/scene/runtime, authoring persistence and validation contracts live under engine/integration/scene/authoring, shared scene asset helpers such as mesh bounds live under engine/integration/scene/assets, and renderer-facing subrender and shadow contracts live under engine/integration/scene/rendering.
  • The cleaned host/runtime graphics API is now part of the public engine include surface under engine/include/pixelbullet/graphics, including renderer, backend-neutral render-target/stage declarations, backend-neutral frame submission, and backend-neutral GPU diagnostics/session helpers; public window declarations are backend-neutral as well.
  • Public engine headers are backend-neutral and must not include Volk or expose Vulkan handles/constants; Vulkan result helpers, API-version packing, physical-device selection diagnostics, device/surface/instance plumbing, graphics runtime state, frame flow, render-stage runtime, render-target runtime internals, and backend implementation sources now live in focused packages under engine/backend/graphics/vulkan.
  • engine/integration/graphics/runtime owns repo-internal host binding, engine/integration/graphics/textures owns the neutral repo-internal texture-loading facade used by editor and UI surfaces, pixelbullet/graphics/mesh_types.h owns render-facing mesh payload value types, engine/integration/graphics/meshes owns the neutral repo-internal mesh payload loading facade used by render backends, and engine/integration/graphics/materials owns the neutral repo-internal render-material payload facade used by Vulkan scene rendering. Vulkan Image2D loading, mesh buffer upload, and render-material payload loading stay hidden behind focused backend factory/resource code.
  • engine/backend/graphics/vulkan is a package family: core, devices, commands, descriptors, buffers, images, pipelines, passes, presentation, runtime, scene, diagnostics/gpu_listing, ui/rmlui, and ui/imgui own low-level Vulkan backend/resource/test-support headers and implementation sources, including Image/Image2D, GLFW-to-Vulkan surface creation, the texture backend factory, graphics runtime state, frame flow, render-stage runtime, render-target runtime internals, Vulkan-specific render-device runtime access, scene render-resource resolution, Vulkan scene subrender runtimes, hidden-window GPU-listing backend factory, Vulkan RmlUi surface drawing runtime, and Vulkan ImGui descriptor/renderpass/texture submission runtime. Include paths remain rooted at pixelbullet/backend/graphics/vulkan/..., C++ types live under pixelbullet::backend::graphics::vulkan, and the root backend package retains only forward declarations plus source inventory aggregation. engine/src/graphics remains the neutral Graphics/RenderDevice facade plus public render-target/stage declarations, narrow validation helpers, and neutral texture backend seam, engine/src/window owns GLFW window/input lifecycle, neutral input/event callback routing, and window callback state without Vulkan surface helpers, engine/src/scene remains the integration adapter/registration/extraction layer for scene rendering and owns neutral scene subrender runtime interfaces that create Vulkan drawing through focused backend factory seams, and engine/private has been drained and should not be reintroduced.
  • Application startup adapts application specification and launch options into neutral filesystem, window, graphics, and logging config before constructing lower-level systems; public window/graphics and Vulkan backend code consume WindowConfig, GraphicsConfig, GraphicsDeviceSelection, and GraphicsApplicationInfo rather than application-shaped config. GPU launch-default persistence is public under engine/include/pixelbullet/application/launch_gpu_defaults.h as application-owned persistence only; the current-session snapshot lives in engine/include/pixelbullet/graphics/gpu_session.h as GraphicsDeviceSelectionSession, and engine/src/graphics must not depend on application launch-default state. engine/src/application owns CLI flow, user-facing GPU-listing output, and saved-default semantics, while engine/src/graphics owns the neutral GPU diagnostics/backend session seam and creates Vulkan GPU enumeration through the focused backend factory under engine/backend/graphics/vulkan/diagnostics/gpu_listing. RmlUi surface integration lives under engine/integration/ui/rmlui; engine/src/ui/rmlui owns RmlUi lifecycle through a neutral runtime interface and creates Vulkan drawing through engine/backend/graphics/vulkan/ui/rmlui. Sampled ImGui texture integration lives under engine/integration/application/imgui; public application ImGui headers live under engine/include/pixelbullet/application/imgui with includes rooted at pixelbullet/application/imgui, generic application Layer lifecycle remains UI-toolkit-neutral through hooks such as OnUiFrame, engine/src/application/imgui owns the public/application ImGui adapter, context, settings, and appearance through neutral runtime and platform backend seams, engine/src/application/imgui/glfw owns the ImGui GLFW platform backend handoff, and Vulkan descriptor/renderpass/texture submission is created through engine/backend/graphics/vulkan/ui/imgui.
  • Event dispatch/result types are core foundation under pixelbullet/core/event.h; key/mouse events are input-owned under pixelbullet/input, window lifecycle events are window-owned under pixelbullet/window/window_events.h, and application owns only application lifecycle events plus layer routing.
  • Native GLFW window handles are not public API; ImGui and the Vulkan backend use a focused engine/src/window internal access seam when they need the current GLFW window.
  • //engine:pixelbullet_workspace_api is the retained header-only umbrella target for pixelbullet/pixelbullet.h; umbrella composition and public-header enumeration live under engine/include/pixelbullet, while Doxygen owns documentation inventory aggregation.
  • The engine implementation surface is split across subsystem libraries such as pixelbullet_core, pixelbullet_filesystem, pixelbullet_assets, pixelbullet_scene, pixelbullet_window, pixelbullet_audio, pixelbullet_graphics, pixelbullet_logging, pixelbullet_application, and pixelbullet_imgui.
  • pixelbullet_logging is the neutral logging foundation, pixelbullet_application is the application framework surface, and pixelbullet_imgui is the optional Vulkan/GLFW ImGui integration layer.
  • The source-level public header surface lives under engine/include/pixelbullet. The only supported public include form is pixelbullet/<subsystem>/<snake_case>.h. First-party repo code uses pixelbullet/integration/... for engine integration contracts and pixelbullet/backend/graphics/vulkan/... for Vulkan backend contracts; runtime orchestration headers remain internal under engine/src.
  • platform/authoring, platform/scene_play, and platform/ui are first-party internal platform layers shared by the editor, products, and examples, not external distribution surfaces.
  • platform/authoring owns the reusable non-UI authoring core; editor/ is the authoring client and UI shell built on top of it.
  • platform/scene_play owns the canonical runtime client, application layer adapter, shared presentation frame, and presentation spine used by the editor, products, and examples.
  • platform/ui owns capability-based runtime-UI services rather than separate live-vs-authoring facades.
  • products/ is the home for first-party playable builds that consume that platform, currently including level_slice, behavior_lab, combat_lab, and world_sandbox.
  • world_sandbox is the dedicated graphics-first exploration product; level_slice, behavior_lab, and combat_lab remain gameplay, logic, and actor/combat pressure surfaces respectively.
  • The editor, products, and curated examples stay application-focused; their source trees are not treated as primary API documentation surfaces, and first-party code should use direct includes plus focused subsystem deps rather than pixelbullet_workspace_api or root engine runtime aggregates.
  • tests/engine covers first-party engine API and behavior, while tests/internal/engine is the intentional home for engine-private coverage.

Build And Verification Entry Points

The repository is Bazel-first. The main entrypoints are:

bazel test //:fast_ci_tests
bazel build --config=debug //engine:pixelbullet_workspace_api
bazel run //tools/dev:refresh_compile_commands
bazel build //doxygen:html

The generated HTML output is written under bazel-bin/doxygen/html/.

Optional slower validation suites:

bazel test //:desktop_smoke_tests
bazel test //:extended_regression_tests
bazel test //:artifact_smoke_tests
bazel test //:repo_policy_tests
bazel test //:repo_audit_tests

Local CI Parity

PixelBullet supports local job parity, not full GitLab runner emulation.

Windows/MSVC:

.\ci\bootstrap_wsl.ps1
.\ci\local.ps1 fast_ci
.\ci\local.ps1 desktop_smoke
.\ci\local.ps1 extended_regression
.\ci\local.ps1 -Wsl fast_ci

Bash or WSL:

bash ci/bootstrap_wsl.sh
bash ci/local.sh fast_ci
bash ci/local.sh desktop_smoke
bash ci/local.sh extended_regression

Use the bootstrap script when Ubuntu/WSL does not already have Bazelisk on PATH. Add -InstallSystemPackages or --install-system-packages if you want the wrapper to install the broader Ubuntu toolchain with apt-get.

Packaging Notes

PixelBullet currently treats the editor runtime bundle as the only intentional packaged output:

  • //packaging:bundle_editor_release for the editor runtime bundle

The per-app runtime bundle targets remain available for first-party local workflows:

  • //packaging:bundle_level_slice_release for the level_slice runtime bundle
  • //packaging:bundle_behavior_lab_release for the behavior_lab runtime bundle
  • //packaging:bundle_combat_lab_release for the combat_lab runtime bundle
  • //packaging:bundle_world_sandbox_release for the world_sandbox runtime bundle

Those runtime bundle targets, including their _debug variants, should still be treated as host-specific developer artifacts rather than portable distributions.

The legacy aggregate Bazel targets //engine:pixelbullet_foundation and //engine:pixelbullet_engine are no longer part of the supported surface.

Theme Integration

This site uses a pinned upstream doxygen-awesome-css dependency through Bazel, plus a small repo-local header and logo layer under doxygen/theme/ to preserve the PixelBullet presentation. The plain Doxygen helper reuses the same staged theme assets instead of keeping a vendored theme copy in the workspace.