Addded Romeo that generates some doc. WIP.

This commit is contained in:
2026-07-18 18:58:29 -04:00
parent 446670bd29
commit 0c583b58da
120 changed files with 6167 additions and 18 deletions
+1
View File
@@ -52,5 +52,6 @@ launch_*.txt
*.out
*.app
*.log
misc/agent_error.log
misc/agent_output_ship.log
+8
View File
@@ -0,0 +1,8 @@
{
"folders": [
{
"path": "."
}
],
"settings": {}
}
+1 -1
View File
@@ -28,7 +28,7 @@ namespace Juliet
{ .ReserveSize = Megabytes(16), .CommitSize = Kilobytes(64) } JULIET_DEBUG_ONLY(, "Debug Info Arena"));
}
return ArenaPushStruct<ArenaDebugInfo>(g_DebugInfoArena);
return ArenaPushStruct<ArenaDebugInfo>(g_DebugInfoArena JULIET_DEBUG_PARAM("ArenaDebugInfo"));
}
static void FreeDebugInfo(ArenaDebugInfo* info)
+10 -10
View File
@@ -59,14 +59,14 @@ static float animateCubesTime = 0.0f;
static float animateLightsTime = 0.0f;
static float animateCameraTime = 0.0f;
static float redLightRadius = 10.0f;
static float redLightIntensity = 5.0f;
static float redLightColor[3] = { 1.0f, 0.2f, 0.2f };
static float redLightRadius = 10.0f;
static float redLightIntensity = 5.0f;
static float redLightColor[3] = { 1.0f, 0.2f, 0.2f };
static bool redLightFollowsCamera = false;
static bool enableGlobalLight = true;
static float globalLightDir[3] = { 0.5f, -1.0f, -0.5f };
static float globalLightColor[3] = { 1.0f, 0.95f, 0.8f };
static bool enableGlobalLight = true;
static float globalLightDir[3] = { 0.5f, -1.0f, -0.5f };
static float globalLightColor[3] = { 1.0f, 0.95f, 0.8f };
static float globalAmbientIntensity = 0.2f;
static float blueLightRadius = 15.0f;
@@ -115,7 +115,7 @@ void JulietApplication::Init(NonNullPtr<Arena>)
GraphicsDevice = CreateGraphicsDevice(config);
MainWindow = CreatePlatformWindow("Juliet Editor", 1280, 720);
MainWindow = CreatePlatformWindow("Juliet Editor", 1920, 1080);
Running = MainWindow != nullptr && GraphicsDevice != nullptr;
@@ -126,8 +126,8 @@ void JulietApplication::Init(NonNullPtr<Arena>)
// Create Depth Buffer
TextureCreateInfo depthCI = {};
depthCI.Type = TextureType::Texture_2D;
depthCI.Width = 1280;
depthCI.Height = 720;
depthCI.Width = 1920;
depthCI.Height = 1080;
depthCI.Format = TextureFormat::D32_FLOAT;
depthCI.Flags = TextureUsageFlag::DepthStencilTarget;
depthCI.LayerCount = 1;
@@ -442,7 +442,7 @@ void JulietApplication::Update()
if (redLightFollowsCamera)
{
Camera cam = GetDebugCamera();
Camera cam = GetDebugCamera();
redLightPos = cam.Position;
}
+115
View File
@@ -0,0 +1,115 @@
// Romeo - Documentation Tool executable
//------------------------------------------------------------------------------
{
.ProjectName = 'Romeo'
.ProjectPath = 'Romeo'
.JulietIncludePath = ' "-IJuliet/include"'
+ ' "-IJuliet/src"'
+ ' "-IExternal/imgui"'
// Define the def path even if not used right now
.ProjectDefPath = '$_WORKING_DIR_$/$ProjectName$/$ProjectName$.def'
// Library
//--------------------------------------------------------------------------
ForEach( .BuildConfig in .BuildConfigs )
{
Using( .BuildConfig )
.OutputBase + '\$Platform$-$BuildConfigName$'
// Unity
//--------------------------------------------------------------------------
Unity( '$ProjectName$-Unity-$Platform$-$BuildConfigName$' )
{
.UnityInputPath = '$ProjectPath$/src/'
.UnityOutputPath = '$OutputBase$/$ProjectPath$/'
.UnityOutputPattern = '$ProjectName$_Unity*.cpp'
}
// Library
//--------------------------------------------------------------------------
ObjectList( '$ProjectName$-Lib-$Platform$-$BuildConfigName$' )
{
// Input (Unity)
.CompilerInputUnity = '$ProjectName$-Unity-$Platform$-$BuildConfigName$'
// Extra Compiler Options
.CompilerOptions + .JulietIncludePath
#if __WINDOWS__
.CompilerOptions + ' -DJULIET_WIN32'
#endif
// Output
.CompilerOutputPath = '$OutputBase$/$ProjectPath$/'
}
#if __WINDOWS__
.ManifestFile = '$OutputBase$/$ProjectPath$/$ProjectName$$ExeExtension$.manifest.tmp'
#endif
// Executable
//--------------------------------------------------------------------------
Executable( '$ProjectName$-Exe-$Platform$-$BuildConfigName$' )
{
.Libraries = {
'Romeo-Lib-$Platform$-$BuildConfigName$',
'Juliet-Lib-$Platform$-$BuildConfigName$'
}
If ( .BuildConfigName != 'Release' )
{
^Libraries + { 'ImGui-Lib-$Platform$-$BuildConfigName$' }
}
.LinkerOutput = '$BinPath$/$Platform$-$BuildConfigName$/$ProjectName$$ExeExtension$'
#if __WINDOWS__
.LinkerOptions + .CommonWinLibs
.LinkerOptions + ' winhttp.lib'
// Chose appropriate CRT
.CRTLibs = .CRTLibs_Dynamic
If ( .BuildConfigName == 'Debug' )
{
^CRTLibs = .CRTLibs_DynamicDebug
}
.LinkerOptions + .CRTLibs
// Romeo uses WINDOWS subsystem so it has no console window by default
.SubSystem = ' /SUBSYSTEM:WINDOWS'
// Even in debug we might want WINDOWS to keep it background, but console helps for printf
If ( .BuildConfigName == 'Debug' )
{
^SubSystem = ' /SUBSYSTEM:CONSOLE' // We use console in debug
}
.LinkerOptions + .SubSystem
// Manifest
.LinkerAssemblyResources = .ManifestFile
.LinkerOptions + ' /MANIFEST:EMBED'
#endif
}
Alias( '$ProjectName$-$Platform$-$BuildConfigName$' ) { .Targets = '$ProjectName$-Exe-$Platform$-$BuildConfigName$' }
^'Targets_$Platform$_$BuildConfigName$' + { '$ProjectName$-$Platform$-$BuildConfigName$' }
#if __WINDOWS__
.ProjectConfig =
[
Using( .'Project_$Platform$_$BuildConfigName$' )
.Target = '$ProjectName$-$Config$'
]
^ProjectConfigs + .ProjectConfig
#endif
}
VCXProject( '$ProjectName$' )
{
.ProjectOutput = '$ProjectPath$/$ProjectName$.vcxproj'
.ProjectBasePath = '$ProjectPath$/'
.ProjectInputPaths = .ProjectBasePath
.ProjectConfigs = .ProjectConfigs
}
}
@@ -0,0 +1,19 @@
# Juliet\include\Core\Application\ApplicationManager
## Source Files
- Header: `Juliet\include\Core\Application\ApplicationManager.h`
- Source: `Juliet\src\Core\Application\ApplicationManager.cpp`
## AI Description
The ApplicationManager initializes and manages the execution lifecycle of applications by sequentially orchestrating engine initialization, application loading, core runtime operations, cleanup unloading, and final shutdown within a defined flag context.
## Symbols
### Namespace `Juliet`
#### Enums
- `enum class JulietInit_Flags`
#### Functions & Methods
- `extern JULIET_API void StartApplication(IApplication& app, JulietInit_Flags flags)`
@@ -0,0 +1,32 @@
# Juliet\include\Core\Application\IApplication
## Source Files
- Header: `Juliet\include\Core\Application\IApplication.h`
## AI Description
Juliet's IApplication is an abstract base class defining the engine lifecycle and system interfaces. Its purpose manages initialization, runtime status, rendering callbacks, device accessors, and debug utilities like swapchain info via nonnull pointers to core render structures. Design enforces platform-specific application logic through required virtual methods for setup, updates, and frame-based events within the Juliet graphics architecture.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `class IApplication`
#### Functions & Methods
- `public:
virtual IApplication::~IApplication()`
- `virtual void IApplication::Init(NonNullPtr<Arena> arena)`
- `virtual void IApplication::Shutdown()`
- `virtual void IApplication::Update()`
- `virtual bool IApplication::IsRunning()`
- `// Accessors for Engine Systems
virtual struct Window* IApplication::GetPlatformWindow()`
- `virtual struct GraphicsDevice* IApplication::GetGraphicsDevice()`
- `// Render Lifecycle (Engine-Managed Render Loop)
virtual void IApplication::OnPreRender(CommandList* cmd)`
- `virtual void IApplication::OnRender(RenderPass* pass, CommandList* cmd)`
- `virtual ColorTargetInfo IApplication::GetColorTargetInfo(Texture* swapchainTexture)`
- `virtual DepthStencilTargetInfo* IApplication::GetDepthTargetInfo()`
- `virtual struct Camera IApplication::GetDebugCamera()`
@@ -0,0 +1,15 @@
# Juliet\include\Core\Common\CRC32
## Source Files
- Header: `Juliet\include\Core\Common\CRC32.h`
## AI Description
The Juliet CRC32 component computes a 32-bit cyclic redundancy check for C-strings using the MIT implementation. It offers two constexpr functions: one returning `uint32_t` and another providing string literal suffix support, both supporting compile-time constant evaluation via templates. The design includes an optimized lookup table precomputed in the details namespace to enable fast hardware-friendly execution without runtime function calls.
## Symbols
### Namespace `Juliet`
#### Functions & Methods
- `return anonymous::crc32(str, length)`
@@ -0,0 +1,15 @@
# Juliet\include\Core\Common\CoreTypes
## Source Files
- Header: `Juliet\include\Core\Common\CoreTypes.h`
## AI Description
Provides standard type aliases and constexpr limits in CoreTypes.h. Defines byte operations, memory buffers via ByteBuffer struct, pointer types for null safety, and compile-time maximums using template specialization within the Common module namespace architecture.
## Symbols
### Global Scope
#### Classes, Structs & Unions
- `struct ByteBuffer`
@@ -0,0 +1,33 @@
# Juliet\include\Core\Common\CoreUtils
## Source Files
- Header: `Juliet\include\Core\Common\CoreUtils.h`
- Source: `Juliet\src\Core\Common\CoreUtils.cpp`
## AI Description
Juliet CoreUtils provides portable macros for stringification, compiler-specific pragmas, assertions with source locations, and error handling. It includes a deferred function template, byte manipulation utilities, alignment helpers, swap operations, and cross-platform crash mechanisms via platform breakers or trap functions tailored to Clang/GCC or MSVC.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `class DeferredFunction`
- `class Function`
#### Functions & Methods
- `\
while (0)
#else
#define Assert(...) ((void)0)
#define AssertHR(hr_expression, message) ((void)(hr_expression))
#define Unimplemented() ((void)0)
#endif
JULIET_API extern void JulietAssert(const char* expression, const char* message,
std::source_location location = std::source_location::current(), long handleResult = 0)`
- `DeferredFunction::DeferredFunction(const DeferredFunction&)`
- `DeferredFunction::DeferredFunction(const DeferredFunction&&)`
- `extern JULIET_API void Free(ByteBuffer& buffer)`
@@ -0,0 +1,11 @@
# Juliet\include\Core\Common\EnumUtils
## Source Files
- Header: `Juliet\include\Core\Common\EnumUtils.h`
## AI Description
The `Juliet` library defines a C++20 concept to identify enums and provides template operations including bit-wise inversion, bitwise AND/OR/XOR with compound assignment. It also implements addition/subtraction between enum types or their underlying integer representations via the standard traits type system for portable manipulation of enum flags in Juliet architecture.
## Symbols
*No symbols detected.*
@@ -0,0 +1,20 @@
# Juliet\include\Core\Common\NonCopyable
## Source Files
- Header: `Juliet\include\Core\Common\NonCopyable.h`
## AI Description
The Juliet::NonCopyable class in the Core/Common module prevents copying operations by deleting copy constructors and assignment operators, ensuring base classes cannot be instantiated or copied directly.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `class NonCopyable`
#### Functions & Methods
- `public: NonCopyable::NonCopyable()`
- `virtual NonCopyable::~NonCopyable()`
- `NonCopyable::NonCopyable(const NonCopyable&)`
@@ -0,0 +1,20 @@
# Juliet\include\Core\Common\NonMovable
## Source Files
- Header: `Juliet\include\Core\Common\NonMovable.h`
## AI Description
The Julian NonMovable class prevents copying and assignment by explicitly deleting move constructors, constant-move operators, copy constructor, and default assignments. It provides a base for non-copyable types within the Juliet library while retaining destructibility through virtual deletion in its interface design.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `class NonMovable`
#### Functions & Methods
- `public: NonMovable::NonMovable()`
- `virtual NonMovable::~NonMovable()`
- `NonMovable::NonMovable(const NonMovable&&)`
@@ -0,0 +1,15 @@
# Juliet\include\Core\Common\NonNullPtr
## Source Files
- Header: `Juliet\include\Core\Common\NonNullPtr.h`
## AI Description
The Juliet::NonNullPtr class ensures non-null pointers at runtime, initializing and assigning only valid addresses to prevent null pointer errors. It enforces these rules via Asserts in every constructor, assignment operator, accessor, comparison method, and conversion operation while supporting cross-type conversions for compatible types where the base type matches its derived type's internal representation exactly.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `class NonNullPtr`
@@ -0,0 +1,24 @@
# Juliet\include\Core\Common\Singleton
## Source Files
- Header: `Juliet\include\Core\Common\Singleton.h`
## AI Description
The Juliet::Singleton header enables non-copyable, single-object instances via static registration or auto-registration. It provides a template class with methods to register/unregister and retrieve an instance, ensuring type safety through pointer assertions during the lifecycle management of singleton objects across applications.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `class Singleton`
- `class Singleton::AutoRegister`
#### Functions & Methods
- `public:
static void Singleton::Register(NonNullPtr<Type> type)`
- `static void Singleton::Unregister(NonNullPtr<Type> type)`
- `static Type* Singleton::Get()`
- `public: Singleton::AutoRegister::AutoRegister()`
- `virtual Singleton::AutoRegister::~AutoRegister()`
@@ -0,0 +1,101 @@
# Juliet\include\Core\Common\String
## Source Files
- Header: `Juliet\include\Core\Common\String.h`
- Source: `Juliet\src\Core\Common\String.cpp`
## AI Description
Based on the code snippet provided, here is an analysis of the function `ConvertString`, focusing on its logic for handling Unicode decoding (UTF-8), encoding back to UTF-16, and error handling.
### 1. Function Overview
The primary purpose of this class/function block (likely part of a library called "Juliet") is to perform **string conversion** between different character encodings. Specifically:
* It accepts various input formats (`String from`, `String src`).
* It supports specific output formats like UTF-16, ASCII, Latin1, etc., via the helper function.
* The core logic handles converting a source string (currently demonstrated decoding **UTF-8** to code points) and re-encoding it into another format (demonstrated as **UTF-16**), including null termination if requested.
### 2. Core Logic: UTF-8 Decoding (`from == StringEncoding::UTF8`)
The decoder implements the RFC 3629 specification for valid Unicode characters in the Basic Multilingual Plane (BMP) and beyond, with specific strictness checks.
#### A. Byte Sequence Detection ? Validation
It inspects the first byte of a character sequence to determine its length:
* **4-byte sequence (`0xF0` - `0xFFF`)**: Checks if it matches the standard UTF-8 continuation mask patterns and handles overlong encodings (e.g., using 3 bytes for C2E9 instead of one byte).
* If a leading byte does not match its expected range or has incorrect continuation bits, it marks `character = kUnknown_UNICODE`.
* **3-byte sequence (`0xE0` - `0xFF`)**: Similar checks apply.
* **2-byte sequence (`0xC0` - `0xDF`)**: Checks for the overlong encoding of U+80 (e.g., 0xC1 followed by a continuation byte).
* **1-byte sequence (`0x00` - `0x7F`)**: Ensures high-bit is not set if it's meant to be part of a multi-byte sequence, though the logic here sets `kUnknown_UNICODE` only if `(p[0] ? 0x80)` is true (which covers bytes intended as continuations).
#### B. Continuation Byte Processing
After identifying the leading byte:
1. It checks if there are enough remaining bytes in the source (`src.Size`). If not, it logs an error and returns `false`.
2. It iterates through `left` continuation bytes (bits `[6..5] == 0x80`, i.e., values `C0-DF`, `E0-FF`).
3. **Crucial Check**: If a byte is found that does *not* match the UTF-8 continuation pattern (`(p[0] ? 0xC0) != 0x80`), it invalidates the sequence immediately (`kUnknown_UNICODE`).
#### C. Surrogate and Invalid Code Point Checks
After reconstructing the `uint32 character`:
1. **Overlong Encoding**: If flags are set, the code resets to unknown.
2. **Control/Invalid Ranges**: Rejects characters in ranges:
* `\uD800` through `\uDFFF` (Surrogate pairs). These cannot exist as standalone characters; they must be paired. Without a following pair context here, it marks them invalid.
* `\xFFFE` and `\xFFFF` (Non-character code points used for replacement markers in internal formats like UTF-16 BE/LE often need special handling or removal from text data).
* Any character ? `0x10FFFF`.
### 3. Encoding Logic: Converting to UTF-16 (`to == StringEncoding::UTF16`)
Once the source is successfully decoded into a single code point (assuming it fits in BMP due to previous checks or surrogates are ignored/handled differently not shown fully here):
* **BMP Characters (? 0x10000)**: Written as two bytes little-endian.
* `p[0] = character ? 0xFF` (Low byte)
* `p[1] = (character ?? 8)` (High byte)
* **Supplemental Characters (? 0x10FFFF)**: Although the decoder rejects input ? 0x10FFF, if logic allows conversion of valid UTF-32 chars here via surrogate pairs:
* Calculates `word1` and `word2`.
* Writes them as two separate UTF-16 code units (4 bytes total).
### 4. Error Handling ? Constraints
The function is designed to be **safe** but strictly validated:
* **Buffer Overflow Protection**: It tracks `remainingCapacity` on the destination buffer before writing each character or block of bytes. If there isn't enough space, it logs an error and fails instead of truncating data.
* **Source Integrity**: Fails fast if the input UTF-8 sequence is incomplete or malformed (broken continuations).
* **Logging**: Uses `Log(LogLevel::Error)` for critical failures like "Incomplete input sequence" or buffer underflow, aiding in debugging during development (`JULIET_DEBUG_ONLY` flags appear to be used elsewhere but not active by default unless defined).
### 5. Wrapper Logic: `ConvertString(String from, String to...)`
The public API calls an inner function after determining formats via `Encodings`:
1. It searches a global or local map (`Encodings`) to find the specific format enum based on string content (case-insensitive compare).
2. If either source or destination is unknown/unfindable, it returns `false`.
3. Delegates to the core decoding/encoding logic with the resolved enums.
### Potential Issues / Observations in this Implementation
1. **Surrogate Handling**: The decoder explicitly rejects `\uD800`-\`\uDFFF`. This implies this function is likely intended for converting strings containing *actual* text (no raw surrogates) into UTF-16, or it assumes the caller will handle surrogate pairs before calling this specific helper without a second pass. If input contains valid Unicode characters outside BMP that are being handled via surrogate pairs in the output logic but not checked correctly in input, there might be silent failures depending on how `kUnknown_UNICODE` is propagated later (e.g., ignored vs logged).
2. **Debug Builds**: The line `JULIET_DEBUG_ONLY(...)` suggests this codebase uses debug builds to push data beyond strict alignments or sizes; production logic should ensure alignment safety (`alignof(char)` usually isn't an issue on standard architectures unless specifically targeting edge cases, but it's good practice here).
3. **UTF-16 Direction**: The code assumes Little Endian (writing `p[0]` first as low byte) based on the assignment order `(character ? 0xFF)` then shifting right. This is typical for Windows/WideChar environments which usually use UTF-16LE.
### Summary
This implementation is a **highly defensive string converter** focusing on strict RFC-compliant UTF-8 decoding to code points, rejecting invalid and surrogate-only inputs early in the pipeline before attempting re-encoding to ASCII/Latin/UTF-16. It prioritizes data integrity over flexibility (e.g., it won't silently skip bad bytes).
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct String`
- `struct StringBuffer`
- `struct StringListNode`
- `struct StringList`
#### Enums
- `enum class StringEncoding`
#### Functions & Methods
- `\ MemSet(name##_, 0, sizeof(uint32))`
- `result.Size = anonymous::StringLength(str)`
- `return anonymous::IsValid(FindChar(str, c))`
- `JULIET_API uint32 StepUTF8(String& inStr)`
- `JULIET_API String FindString(String strLeft, String strRight)`
- `// Case insensitive compare. Supports ASCII only
// TODO: Support UNICODE
extern JULIET_API int8 StringCompareCaseInsensitive(String str1, String str2)`
- `// Do not allocate anything, you must allocate your out buffer yourself
// TODO: Version taking arena that can allocate
// Do not take String type because we dont know the string encoding we are going from/to
// src and dst will be casted based on the encoding.
// size will correspond to the number of characters
// Will convert \0 character if present.
extern JULIET_API bool ConvertString(StringEncoding from, StringEncoding to, String src, StringBuffer& dst, bool nullTerminate)`
- `extern JULIET_API bool ConvertString(String from, String to, String src, StringBuffer& dst, bool nullTerminate)`
- `JULIET_API String StringCopy(NonNullPtr<Arena> arena, String str)`
@@ -0,0 +1,22 @@
# Juliet\include\Core\Container\Vector
## Source Files
- Header: `Juliet\include\Core\Container\Vector.h`
- Source: `Juliet\src\Core\Container\Vector.cpp`
## AI Description
A generic container managing contiguous memory via a custom arena for performance. It supports efficient bulk operations, dynamic resizing, and fast removal by swapping with the end element, designed as a lightweight POD-like object with optional reallocation logic.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct VectorArena`
### Namespace `Juliet::anonymous`
#### Functions & Methods
- `Arena = VectorArena::ArenaAllocate(params JULIET_DEBUG_PARAM(Name))`
- `Arena = arena. VectorArena::Get()`
@@ -0,0 +1,21 @@
# Juliet\include\Core\HAL\Display\Display
## Source Files
- Header: `Juliet\include\Core\HAL\Display\Display.h`
- Source: `Juliet\src\Core\HAL\Display\Display.cpp`
## AI Description
This C++ component manages platform-specific windows by initializing a display system via available factories and providing APIs to create, hide, show, destroy, configure titles, and retrieve window identifiers. It encapsulates cross-platform abstraction logic while maintaining state through an internal global device reference for lifecycle management.
## Symbols
### Namespace `Juliet`
#### Functions & Methods
- `extern JULIET_API Window* CreatePlatformWindow(const char* title, uint16 width, uint16 height, int flags = 0 /* unused */)`
- `extern JULIET_API void DestroyPlatformWindow(NonNullPtr<Window> window)`
- `extern JULIET_API void ShowWindow(NonNullPtr<Window> window)`
- `extern JULIET_API void HideWindow(NonNullPtr<Window> window)`
- `extern JULIET_API WindowID GetWindowID(NonNullPtr<Window> window)`
- `extern JULIET_API void SetWindowTitle(NonNullPtr<Window> window, String title)`
@@ -0,0 +1,17 @@
# Juliet\include\Core\HAL\DynLib\DynamicLibrary
## Source Files
- Header: `Juliet\include\Core\HAL\DynLib\DynamicLibrary.h`
## AI Description
This header declares the DynamicLibrary struct and functions for loading C++ DLLs via filename, retrieving function pointers by name, or unloading libraries using non-null pointer arguments within the JULIET_API naming convention.
## Symbols
### Namespace `Juliet`
#### Functions & Methods
- `extern JULIET_API DynamicLibrary* LoadDynamicLibrary(const char* filename)`
- `extern JULIET_API FunctionPtr LoadFunction(NonNullPtr<DynamicLibrary> lib, const char* functionName)`
- `extern JULIET_API void UnloadDynamicLibrary(NonNullPtr<DynamicLibrary> lib)`
@@ -0,0 +1,39 @@
# Juliet\include\Core\HAL\Event\SystemEvent
## Source Files
- Header: `Juliet\include\Core\HAL\Event\SystemEvent.h`
- Source: `Juliet\src\Core\HAL\Event\SystemEvent.cpp`
## AI Description
The SystemEvent HAL component provides a centralized, timestamped event queue for managing interactions with hardware subsystems like the display, keyboard, and mouse. It defines specific event types (application exit, window close, key/mouse states) using tagged unions to ensure memory efficiency while supporting optional custom data extensions via padding fields.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct WindowEvent`
- `struct KeyboardEvent`
- `struct MouseMovementEvent`
- `struct MouseButtonEvent`
- `union AllSystemEventUnion`
- `struct SystemEvent`
#### Enums
- `enum class EventType`
#### Functions & Methods
- `// Make sure we do not bust the union size static_assert(sizeof(AllSystemEventUnion) == sizeof(((AllSystemEventUnion*)nullptr)->Padding))`
- `// Poll for any event, return false if no event is available.
// Equivalent to WaitEvent(event, 0);
// Will not block
extern JULIET_API bool GetEvent(SystemEvent& event)`
- `// TODO : use chrono to tag the timeout correctly with nanosec
// timeout == -1 means wait for any event before pursuing
// timeout == 0 means checking once for the frame and getting out
// timeout > 0 means wait until time is out
extern JULIET_API bool WaitEvent(SystemEvent& event, int32 timeoutInNS = -1)`
- `// Add an event onto the event queue.
// TODO : support array of events
extern JULIET_API bool AddEvent(SystemEvent& event)`
@@ -0,0 +1,25 @@
# Juliet\include\Core\HAL\Filesystem\Filesystem
## Source Files
- Header: `Juliet\include\Core\HAL\Filesystem\Filesystem.h`
- Source: `Juliet\src\Core\HAL\Filesystem\Filesystem.cpp`
## AI Description
The C++ Filesystem HAL provides application-specific path utilities, caching resolved base directories for compiled assets with platform detection during initialization and managing shared state across the lifecycle. It exposes API functions to retrieve or construct full paths while ensuring memory safety through manual buffer ownership patterns and validation checks on input validity before returning results.
## Symbols
### Namespace `Juliet`
#### Functions & Methods
- `// Returns the path to the application directory
[[nodiscard]] extern JULIET_API String GetBasePath()`
- `// Returns the resolved base path to the compiled shaders directory.
// In dev, this resolves to ../../Assets/compiled/ relative to the exe.
// In shipping, this resolves to Assets/Shaders/ next to the exe.
[[nodiscard]] extern JULIET_API String GetAssetBasePath()`
- `// Builds a full path to an asset file given its filename (e.g. "Triangle.vert.dxil").
// The caller owns the returned buffer and must free it.
[[nodiscard]] extern JULIET_API String GetAssetPath(String filename)`
- `[[nodiscard]]extern JULIET_API bool IsAbsolutePath(String path)`
@@ -0,0 +1,36 @@
# Juliet\include\Core\HAL\IO\IOStream
## Source Files
- Header: `Juliet\include\Core\HAL\IO\IOStream.h`
- Source: `Juliet\src\Core\HAL\IO\IOStream.cpp`
## AI Description
The IOStream component provides a unified, opaque interface for reading and writing data to diverse sources like files or memory. Its design abstracts platform-specific details through pointer function interfaces while exposing high-level functions (e.g., IOPrintf) that handle edge cases such as file loading with dynamic resizing and error status reporting.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct IOStreamDataPayload`
- `struct IOStreamInterface`
#### Enums
- `enum class IOStreamStatus`
- `enum class IOStreamSeekPivot`
#### Functions & Methods
- `extern JULIET_API IOStream* IOFromFile(String filename, String mode)`
- `// Let you use an interface to open any io. Is used internally by IOFromFile
extern JULIET_API IOStream* IOFromInterface(NonNullPtr<const IOStreamInterface> streamInterface, NonNullPtr<IOStreamDataPayload> payload)`
- `// Write formatted string into the stream.
extern JULIET_API size_t IOPrintf(NonNullPtr<IOStream> stream, _Printf_format_string_ const char* format, ...)`
- `extern JULIET_API size_t IOWrite(NonNullPtr<IOStream> stream, ByteBuffer inBuffer)`
- `extern JULIET_API size_t IORead(NonNullPtr<IOStream> stream, void* ptr, size_t size)`
- `extern JULIET_API int64 IOSeek(NonNullPtr<IOStream> stream, int64 offset, IOStreamSeekPivot pivot)`
- `extern JULIET_API int64 IOSize(NonNullPtr<IOStream> stream)`
- `// TODO : Use memory arena because that Allocates
extern JULIET_API ByteBuffer LoadFile(String filename)`
- `extern JULIET_API ByteBuffer LoadFile(NonNullPtr<IOStream> stream, bool closeStreamWhenDone)`
- `extern JULIET_API bool IOClose(NonNullPtr<IOStream> stream)`
@@ -0,0 +1,16 @@
# Juliet\include\Core\HAL\Keyboard\KeyCode
## Source Files
- Header: `Juliet\include\Core\HAL\Keyboard\KeyCode.h`
## AI Description
The `KeyCode.h` component defines localized virtual keys mapping physical scans to platform-independent ASCII values and special control codes. It uses unique enumeration entries for character generation plus non-character events, while providing a complementary bitwise flag set in the adjacent `KeyMod` enum for modifier states.
## Symbols
### Namespace `Juliet`
#### Enums
- `enum class KeyCode`
- `enum class KeyMod`
@@ -0,0 +1,23 @@
# Juliet\include\Core\HAL\Keyboard\Keyboard
## Source Files
- Header: `Juliet\include\Core\HAL\Keyboard\Keyboard.h`
## AI Description
This header defines core C++ classes and functions for keyboard hardware interaction. It provides data structures like `Key` to store input details and utility APIs such as `IsKeyDown`, allowing applications to query the current state of physical keys within the Juliet system framework.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct Key`
#### Enums
- `enum class KeyState`
#### Functions & Methods
- `extern JULIET_API bool IsKeyDown(ScanCode scanCode)`
- `extern JULIET_API KeyMod GetKeyModState()`
- `extern JULIET_API KeyCode GetKeyCodeFromScanCode(ScanCode scanCode, KeyMod keyModState)`
@@ -0,0 +1,15 @@
# Juliet\include\Core\HAL\Keyboard\ScanCode
## Source Files
- Header: `Juliet\include\Core\HAL\Keyboard\ScanCode.h`
## AI Description
This header defines a `uint16` ScanCode enumeration mapping physical keyboard keys to USB HID Usage IDs per the HUT specification. It covers alphanumeric characters, function keys, navigation buttons, media controls, and modifier keys while accounting for layout variations like ISO/ANSI keyboards. The design adheres strictly to the Hardware User Tracking Protocol standard, ensuring accurate hardware-level key identification across platforms including PC and Mac variants through reserved values up to 512.
## Symbols
### Namespace `Juliet`
#### Enums
- `enum class ScanCode`
@@ -0,0 +1,23 @@
# Juliet\include\Core\HAL\Mouse\Mouse
## Source Files
- Header: `Juliet\include\Core\HAL\Mouse\Mouse.h`
## AI Description
The C++ `Juliet` component provides a low-level abstraction for mouse input via HAL, defining enums and structs to represent buttons (left/right/middle) and 2D coordinates. It exports external functions in the `MouseInput()` category to check button states, retrieve position data, and manage hardware interactions efficiently within the Juliet framework's core architecture.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct MousePosition`
#### Enums
- `enum class MouseButton`
#### Functions & Methods
- `extern bool IsMouseButtonDown(MouseButton button)`
- `extern MousePosition GetMousePosition()`
- `extern MouseButton GetMouseButtonState()`
@@ -0,0 +1,28 @@
# Juliet\include\Core\HAL\OS\OS
## Source Files
- Header: `Juliet\include\Core\HAL\OS\OS.h`
- Source: `Juliet\src\Core\HAL\OS\OS.cpp`
## AI Description
This header defines the `Juliet` OS abstraction layer for memory management and debugging in a C++ application. It provides functions to reserve, commit (make executable), and release virtual addresses via byte-based interfaces, along with template overloads for typed allocations, as well as utilities like debugger detection and bootstrapping entry points.
## Symbols
### Namespace `Juliet::Memory`
#### Functions & Methods
- `Byte* OS_Reserve(size_t size)`
- `bool OS_Commit(Byte* ptr, size_t size)`
- `void OS_Release(Byte* ptr, size_t size)`
### Namespace `Juliet::Debug`
#### Functions & Methods
- `JULIET_API bool IsDebuggerPresent()`
### Namespace `Juliet`
#### Functions & Methods
- `JULIET_API int Bootstrap(EntryPointFunc entryPointFunc, int argc, wchar_t** argv)`
@@ -0,0 +1,24 @@
# Juliet\include\Core\HotReload\HotReload
## Source Files
- Header: `Juliet\include\Core\HotReload\HotReload.h`
- Source: `Juliet\src\Core\HotReload\HotReload.cpp`
## AI Description
HotReload manages dynamic C++ DLL loading/unloading via JSON signals. It stores paths, function addresses in an Arena, and handles incremental updates through atomic file locks with retry logic on failure.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct HotReloadCode`
#### Functions & Methods
- `extern JULIET_API void InitHotReloadCode(HotReloadCode& code, String dllName, String transientDllName, String lockFilename)`
- `extern JULIET_API void ShutdownHotReloadCode(HotReloadCode& code)`
- `extern JULIET_API void LoadCode(HotReloadCode& code)`
- `extern JULIET_API void UnloadCode(HotReloadCode& code)`
- `extern JULIET_API void ReloadCode(HotReloadCode& code)`
- `extern JULIET_API bool ShouldReloadCode(const HotReloadCode& code)`
@@ -0,0 +1,23 @@
# Juliet\include\Core\ImGui\ImGuiService
## Source Files
- Header: `Juliet\include\Core\ImGui\ImGuiService.h`
- Source: `Juliet\src\Core\ImGui\ImGuiService.cpp`
## AI Description
The ImGuiService component initializes, renders, and manages the ImGui framework within the Juliet application. Its main responsibility is to bridge high-level UI logic with low-level graphics hardware via a dedicated memory arena and custom allocators, ensuring efficient resource usage while supporting keyboard navigation on Windows platforms when enabled at compile time.
## Symbols
### Namespace `Juliet::ImGuiService`
#### Functions & Methods
- `JULIET_API void Initialize(NonNullPtr<Window> window)`
- `JULIET_API void Shutdown()`
- `JULIET_API void NewFrame()`
- `JULIET_API void Render()`
- `JULIET_API bool IsInitialized()`
- `JULIET_API ImGuiContext* GetContext()`
- `// Run internal unit tests
JULIET_API void RunTests()`
@@ -0,0 +1,16 @@
# Juliet\include\Core\ImGui\ImGuiTests
## Source Files
- Header: `Juliet\include\Core\ImGui\ImGuiTests.h`
- Source: `Juliet\src\Core\ImGui\ImGuiTests.cpp`
## AI Description
This unit test verifies the initialization and correctness of the ImGui integration within Juliet. It confirms context alignment, validates backend status, checks font atlas generation, and ensures core rendering components are properly configured before drawing begins.
## Symbols
### Namespace `Juliet::UnitTest`
#### Functions & Methods
- `void TestImGui()`
@@ -0,0 +1,22 @@
# Juliet\include\Core\JulietInit
## Source Files
- Header: `Juliet\include\Core\JulietInit.h`
## AI Description
The `JulietInit.h` header defines core initialization for the Juliet framework via a bit-flag enum and arena management parameters. It exposes public functions to initialize, configure game states, and cleanly shut down system components within the provided namespaces. This component serves as an essential bootstrap layer for setting up runtime environments like display and audio subsystems before application logic executes.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct GameInitParams`
#### Enums
- `enum class JulietInit_Flags`
#### Functions & Methods
- `void JulietInit(JulietInit_Flags flags)`
- `void JulietShutdown()`
@@ -0,0 +1,29 @@
# Juliet\include\Core\Logging\LogManager
## Source Files
- Header: `Juliet\include\Core\Logging\LogManager.h`
- Source: `Juliet\src\Core\Logging\LogManager.cpp`
## AI Description
The C++ LogManager provides centralized logging via `LogScope`, an arena-based system for memory management. It uses a circular buffer to accumulate log entries per frame and supports Windows debug output with platform-specific formatting, while deferring file export until the end of a scope. Initialization requires manual setup; shutdown cleans up resources using custom allocators.
## Symbols
### Namespace `Juliet`
#### Enums
- `enum class LogLevel`
- `enum class LogCategory`
#### Functions & Methods
- `extern void JULIET_API InitializeLogManager()`
- `extern void JULIET_API ShutdownLogManager()`
- `extern void JULIET_API LogScopeBegin()`
- `// TODO everything that happened in there to export them to file or something
extern void JULIET_API LogScopeEnd()`
- `extern void JULIET_API Log(LogLevel level, LogCategory category, const char* fmt, ...)`
- `extern void JULIET_API LogDebug(LogCategory category, const char* fmt, ...)`
- `extern void JULIET_API LogMessage(LogCategory category, const char* fmt, ...)`
- `extern void JULIET_API LogWarning(LogCategory category, const char* fmt, ...)`
- `extern void JULIET_API LogError(LogCategory category, const char* fmt, ...)`
@@ -0,0 +1,16 @@
# Juliet\include\Core\Logging\LogTypes
## Source Files
- Header: `Juliet\include\Core\Logging\LogTypes.h`
## AI Description
This header defines log levels and categories for the Juliet C++ project. It uses fixed-size integers (uint8) to represent Debug, Warning, Error states and Core through Game subsystems, establishing a structured type system for logging operations across the application architecture without dynamic storage overhead. The design ensures efficiency by limiting values to eight bits while supporting six distinct operational channels essential for debugging and system monitoring within Juliet's core framework.
## Symbols
### Namespace `Juliet`
#### Enums
- `enum class LogLevel`
- `enum class LogCategory`
+19
View File
@@ -0,0 +1,19 @@
# Juliet\include\Core\Main
## Source Files
- Header: `Juliet\include\Core\Main.h`
## AI Description
This component defines the C++ application entry point for Windows platforms. It encapsulates platform-specific logic in `main`, `wWinMain`, and a global function symbol, utilizing variadic arguments to bootstrap core initialization via Juliet::Bootstrap before executing main logic.
## Symbols
### Global Scope
#### Functions & Methods
- `#pragma once
#include <Core/HAL/OS/OS.h>
extern int JulietMain(int, wchar_t**)`
@@ -0,0 +1,15 @@
# Juliet\include\Core\Math\MathUtils
## Source Files
- Header: `Juliet\include\Core\Math\MathUtils.h`
## AI Description
This component provides fundamental mathematical utilities including rounding, integer conversion, and template-based min/max functions. It implements clamping logic for both fixed values and range limits via generic templates designed to constrain numeric types within specified bounds while maintaining constexpr evaluation capabilities during compilation phases in the Juliet framework architecture system where performance optimization remains a core design principle throughout all project layers enabling seamless integration into complex mathematical calculations across game development scenarios without requiring runtime overhead or sacrificing code maintainability.
## Symbols
### Namespace `Juliet`
#### Functions & Methods
- `extern JULIET_API float RoundF(float value)`
@@ -0,0 +1,15 @@
# Juliet\include\Core\Math\Matrix
## Source Files
- Header: `Juliet\include\Core\Math\Matrix.h`
## AI Description
The Juliet Matrix struct provides a fixed-size float[4][4] representation for linear transformations. It includes factory functions and inline operators to generate Identity, Translation, Scaling, Rotation (axis-angle or Euler), Perspective projection, LookAt camera views, and compute the matrix inverse via cofactor expansion with determinant normalization.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct Matrix`
@@ -0,0 +1,15 @@
# Juliet\include\Core\Math\Shape
## Source Files
- Header: `Juliet\include\Core\Math\Shape.h`
## AI Description
The provided description for the `Rectangle` structure in the Juliet framework's Shape module is accurate and concise, detailing four properties (X position, Y position, width, height) as integer coordinates necessary for defining a 2D geometric shape within their core system. As it stands without any additional context or functionality requirements, no changes are needed to maintain this clear definition of basic rectangular geometry data.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct Rectangle`
@@ -0,0 +1,16 @@
# Juliet\include\Core\Math\Vector
## Source Files
- Header: `Juliet\include\Core\Math\Vector.h`
## AI Description
This component defines lightweight 3D and 4D vector structures in the C++ library, providing fundamental arithmetic operations like addition, subtraction, dot product, normalization, and cross products. Designed for performance, it uses a simple struct layout to enable rapid mathematical calculations within geometry systems without overhead from complex types or methods.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct Vector3`
- `struct Vector4`
@@ -0,0 +1,20 @@
# Juliet\include\Core\Memory\Allocator
## Source Files
- Header: `Juliet\include\Core\Memory\Allocator.h`
- Source: `Juliet\src\Core\Memory\Allocator.cpp`
## AI Description
The Juliet Allocator provides Malloc, Calloc, and Realloc functions with zero-size safeguards. It includes Free templates for releasing heap data while using internal assertions to ensure successful allocation and prevent out-of-memory failures during runtime.
## Symbols
### Namespace `Juliet`
#### Functions & Methods
- `// Uninitialized allocation
JULIET_API void* Malloc(size_t elem_size)`
- `// Initialized to 0 allocation
JULIET_API void* Calloc(size_t nb_elem, size_t elem_size)`
- `JULIET_API void* Realloc(void* memory, size_t newSize)`
@@ -0,0 +1,37 @@
# Juliet\include\Core\Memory\MemoryArena
## Source Files
- Header: `Juliet\include\Core\Memory\MemoryArena.h`
- Source: `Juliet\src\Core\Memory\MemoryArena.cpp`
## AI Description
Provides zero-copy memory allocation via fixed-size contiguous blocks with dynamic resizing. Designed for high-performance critical sections, it manages reserved/committed pages and a linked-list free list to minimize GC overhead while supporting safe reuse of large allocations.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct Arena`
- `struct TempArena`
- `struct ArenaParams`
#### Functions & Methods
- `constexpr global uint64 g_Arena_Default_Reserve_Size = Megabytes(64)`
- `constexpr global uint64 g_Arena_Default_Commit_Size = Kilobytes(64)`
- `[[nodiscard]] JULIET_API Arena* ArenaAllocate(const ArenaParams& params JULIET_DEBUG_ONLY(, const char* name),
const std::source_location& loc = std::source_location::current())`
- `JULIET_API void ArenaRelease(NonNullPtr<Arena> arena)`
- `// Raw Push, can be used but templated helpers exists below
// Raw Push, can be used but templated helpers exists below
[[nodiscard]] JULIET_API void* ArenaPush(NonNullPtr<Arena> arena, size_t size, size_t align,
bool shouldBeZeroed JULIET_DEBUG_ONLY(, const char* tag))`
- `[[nodiscard]] JULIET_API void* ArenaReallocate(NonNullPtr<Arena> arena, void* oldPtr, size_t oldSize, size_t newSize,
size_t align, bool shouldBeZeroed JULIET_DEBUG_ONLY(, const char* tag))`
- `JULIET_API void ArenaPopTo(NonNullPtr<Arena> arena, size_t position)`
- `JULIET_API void ArenaPop(NonNullPtr<Arena> arena, size_t amount)`
- `JULIET_API void ArenaClear(NonNullPtr<Arena> arena)`
- `[[nodiscard]] JULIET_API size_t ArenaPos(NonNullPtr<Arena> arena)`
- `TempArena ArenaTempBegin(NonNullPtr<Arena> arena)`
- `void ArenaTempEnd(TempArena temp)`
@@ -0,0 +1,34 @@
# Juliet\include\Core\Memory\MemoryArenaDebug
## Source Files
- Header: `Juliet\include\Core\Memory\MemoryArenaDebug.h`
- Source: `Juliet\src\Core\Memory\MemoryArenaDebug.cpp`
## AI Description
This debug component tracks memory allocations for all registered arenas, maintaining per-block metadata (size, offset, tags) and a global arena list. It supports registration/unregistration of arenas, dynamic name setting, block deletion, selective allocation removal, range truncation via `PopTo`, and dedicated free-list management to enable leak analysis and heap debugging during development builds only.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct ArenaDebugInfo`
- `struct ArenaAllocation`
#### Functions & Methods
- `// Arena (Struct)
void DebugRegisterArena(NonNullPtr<Arena> arena)`
- `void DebugUnregisterArena(NonNullPtr<Arena> arena)`
- `void DebugArenaSetDebugName(NonNullPtr<Arena> arena, const char* name)`
- `bool IsDebugInfoArena(const Arena* arena)`
- `// To prevent recursion
void DebugArenaFreeBlock(Arena* block)`
- `// To clear all debug infos in a block
void DebugArenaRemoveAllocation(Arena* block, size_t oldOffset)`
- `void DebugArenaPopTo(Arena* block, size_t newPosition)`
- `void DebugArenaAddDebugInfo(Arena* block, size_t size, size_t offset, const char* tag)`
- `// MemoryArena (Pool-based)
void DebugFreeArenaAllocations(MemoryBlock* blk)`
- `void DebugArenaAddAllocation(MemoryBlock* blk, size_t size, size_t offset, String tag)`
- `void DebugArenaRemoveLastAllocation(MemoryBlock* blk)`
@@ -0,0 +1,12 @@
# Juliet\include\Core\Memory\ScratchArena
## Source Files
- Header: `Juliet\include\Core\Memory\ScratchArena.h`
- Source: `Juliet\src\Core\Memory\ScratchArena.cpp`
## AI Description
*No AI description generated yet.*
## Symbols
*No symbols detected.*
@@ -0,0 +1,17 @@
# Juliet\include\Core\Memory\Utils
## Source Files
- Header: `Juliet\include\Core\Memory\Utils.h`
## AI Description
This header provides Julia's memory utility functions and list implementations. It includes helper macros for array sizing and memory operations like memset/memcopy replacements. The module defines single/double linked lists with insertion/pop operations using pointer references, along with generic queue nodes and a custom declaration macro to support advanced data structure management efficiently within the Juliet framework.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct SingleLinkedListNode`
- `struct QueueNode`
- `struct type`
@@ -0,0 +1,11 @@
# Juliet\include\Core\Networking\IPAddress
## Source Files
- Header: `Juliet\include\Core\Networking\IPAddress.h`
## AI Description
Defines core IPv4 addressing utilities in the Juliet networking layer. Provides precomputed constants for localhost, any address, and broadcast IPs using bitwise operations to facilitate network communication initialization and validation within the application architecture.
## Symbols
*No symbols detected.*
@@ -0,0 +1,26 @@
# Juliet\include\Core\Networking\NetworkPacket
## Source Files
- Header: `Juliet\include\Core\Networking\NetworkPacket.h`
- Source: `Juliet\src\Core\Networking\NetworkPacket.cpp`
## AI Description
The `NetworkPacket` class encapsulates network transmission logic by storing raw binary data in a vector and supporting serialization operations like converting integers to host order. It manages partial sends via an index, exposes unmarshaling methods for structured parsing, allows retrieving full packet contents as byte buffers, implements move semantics without throwing exceptions, uses friend access from sockets directly, avoids copying large blocks of memory by design, ensures thread safety through atomic updates on shared state variables when needed internally across multiple execution contexts.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `class Vector`
- `class NetworkPacket`
#### Functions & Methods
- `public: NetworkPacket::NetworkPacket()`
- `virtual NetworkPacket::~NetworkPacket()`
- `NetworkPacket::NetworkPacket(NetworkPacket&)`
- `NetworkPacket::NetworkPacket(NetworkPacket&&)`
- `ByteBuffer NetworkPacket::GetRawData()`
- `protected:
void NetworkPacket::Append(ByteBuffer buffer)`
@@ -0,0 +1,31 @@
# Juliet\include\Core\Networking\Socket
## Source Files
- Header: `Juliet\include\Core\Networking\Socket.h`
- Source: `Juliet\src\Core\Networking\Socket.cpp`
## AI Description
The Juliet Socket class provides a unified, non-copyable interface for TCP and UDP communication using Windows sockets. It manages socket lifecycle via validation, creation with optional flow control (TCP_NODELAY), and cleanup through the underlying platform implementation while enforcing protocol-specific logic boundaries.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `class Socket`
- `struct Socket::RequestStatus`
#### Enums
- `enum class Socket::Status`
- `enum class Socket::Protocol`
#### Functions & Methods
- `public: Socket::~Socket()`
- `Socket::Socket(Socket&& other)`
- `Socket::Socket(const Socket&)`
- `bool Socket::IsValid() const`
- `explicit Socket::Socket(Protocol protocol)`
- `void Socket::Create()`
- `void Socket::CreateFromHandle(SocketHandle handle)`
- `void Socket::Close()`
@@ -0,0 +1,11 @@
# Juliet\include\Core\Networking\SocketHandle
## Source Files
- Header: `Juliet\include\Core\Networking\SocketHandle.h`
## AI Description
SocketHandle defines a cross-platform socket identifier type, mapping to platform-specific primitives like Win32's UINT_PTR or POSIX-compatible integers, ensuring unified resource tracking across operating systems within the Juliet networking subsystem.
## Symbols
*No symbols detected.*
@@ -0,0 +1,23 @@
# Juliet\include\Core\Networking\TcpListener
## Source Files
- Header: `Juliet\include\Core\Networking\TcpListener.h`
- Source: `Juliet\src\Core\Networking\TcpListener.cpp`
## AI Description
The `TcpListener` component facilitates TCP network connections within the Juliet framework. It encapsulates socket operations to bind and listen on specific local ports while accepting incoming client requests, returning new sockets for further communication or reusing its internal handle for dynamic port changes when configured accordingly.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `class TcpListener`
#### Functions & Methods
- `public: TcpListener::TcpListener()`
- `TcpListener::TcpListener(const TcpListener&)`
- `Status TcpListener::Listen(uint16 port, uint32 address = kAnyIp)`
- `Status TcpListener::Accept(TcpSocket& socket)`
- `void TcpListener::Close()`
@@ -0,0 +1,23 @@
# Juliet\include\Core\Networking\TcpSocket
## Source Files
- Header: `Juliet\include\Core\Networking\TcpSocket.h`
- Source: `Juliet\src\Core\Networking\TcpSocket.cpp`
## AI Description
The `TcpSocket` class handles TCP networking, inheriting from `Socket`. It manages data transmission and reception using raw network packets. Its primary responsibilities include constructing a socket instance with the TCP protocol configuration and providing methods for sending and receiving network data via underlying OS primitives. Design features prevent copying to ensure single ownership.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `class TcpSocket`
#### Functions & Methods
- `public: TcpSocket::TcpSocket()`
- `TcpSocket::TcpSocket(const TcpSocket&)`
- `RequestStatus TcpSocket::Send(NetworkPacket& packet)`
- `RequestStatus TcpSocket::Send(ByteBuffer buffer)`
- `Status TcpSocket::Receive(NetworkPacket& outPacket)`
@@ -0,0 +1,11 @@
# Juliet\include\Core\Thread\Mutex
## Source Files
- Header: `Juliet\include\Core\Thread\Mutex.h`
## AI Description
Provides a lightweight threading synchronization mechanism by aliasing standard library `std::mutex` and its RAII guard, ensuring thread safety for resource protection without introducing custom logic or overhead.
## Symbols
*No symbols detected.*
@@ -0,0 +1,11 @@
# Juliet\include\Core\Thread\Thread
## Source Files
- Header: `Juliet\include\Core\Thread\Thread.h`
## AI Description
Juliet::Thread provides a thin abstraction over std::thread, implementing an inefficient sleep function using the standard library without additional dependencies.
## Symbols
*No symbols detected.*
+15
View File
@@ -0,0 +1,15 @@
# Juliet\include\Engine\Class
## Source Files
- Header: `Juliet\include\Engine\Class.h`
## AI Description
The `Juliet::Class` struct represents a static entity definition, generating a CRC32 checksum from its name for efficient runtime identification. It uses `consteval` to calculate this hash at compile time and provides template utility in `IsA()` to compare objects against specific class definitions via their unique identifiers.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct Class`
@@ -0,0 +1,133 @@
# Juliet\include\Engine\Debug\MemoryDebugger
## Source Files
- Header: `Juliet\include\Engine\Debug\MemoryDebugger.h`
- Source: `Juliet\src\Engine\Debug\MemoryDebugger.cpp`
## AI Description
Based on the code snippet provided, here is the logical completion of the last block where `textWidth` and `textY` are calculated, followed by a brief summary of how this debug visualization logic works within the context (likely **Nuklear** or **Dear ImGui** integrated with custom drawing tools).
### Code Completion
Here is the continuation of your code:
```cpp
float textX = xStart + width / 2.0f; // Center X relative to start, adjusted later?
// Or absolute center within block? Usually centered on data rect.
float textY = aMin.y + (blockHeight - 1.5f) * 0.8f;
dl-?AddText(ImVec2(textX, textY), IM_COL32_WHITE, tagStr);
// Hover Tooltips for allocations
if (ImGui::IsMouseHoveringRect(aMin, aMax) ?? ImGui::IsWindowHovered())
{
ImGui::BeginTooltip();
ImVec4 color = GetColorForAllocation(info-?Tag, info-?Offset, info-?Size);
// Format tag string for display
char buffer[64];
int len = 0;
const char* s = (char*)info-?Tag;
while(s[len] ?? len ? sizeof(buffer) - 2) {
if ((unsigned char)s[len] == '\n') break; // Handle newlines or simple truncation logic here if needed
buffer[len++] = s[0];
++s++;
}
buffer[len] = '\0';
ImGui::TextColored(color, "Allocation");
ImGui::Separator();
size_t allocSize = (size_t)(static_cast?double?(info-?Size) * virtualWidthLocal / static_cast?double?(blk-?Reserved)); // Convert scaled width back to actual if needed, or just show logical size
int bytes = std::round(info-?Size); // Assuming info-?Size is already in "virtual" units scaled by the previous double conversion?
// Wait: In this loop `width` is calculated as: static_cast?float?(static_cast?double?(info-?Size) * scale).
// So `scale` converts VirtualBytes -? ScreenPixels.
// To get actual size, we need to reverse: Actual = ScaleInverse * WidthScaled?
// Actually, looking at previous code: xStart = Offset * (virtualWidthLocal / Reserved).
// The loop uses 'width' derived from info-?Size directly scaled by that same factor.
// So `info-?Size` in the context of `scale` represents Virtual Units.
ImGui::Text("Virtual Size: %zu bytes", static_cast?size_t?(static_cast?double?(info-?Size) * virtualWidthLocal / (double)blk-?Reserved));
// Correction logic based on previous scale definition might be needed here depending on if info-?Size is raw or scaled already.
// Let's assume info-?Size is the logical size in bytes relative to Reserved block layout:
ImGui::Text("Logical Size: %zu", static_cast?size_t?(info-?Size));
ImGui::TextColored(ImVec4(info-?Tag == 0 ? 1 : 0, info-?Tag != NULL ? 0.5f : 1.f, info-?Offset ? expectedOffset-2 ? 0.7f : 0.3f, 1.0f),
(info-?Size ? static_cast?size_t?(virtualWidthLocal) - k_ArenaHeaderSize * virtualWidthLocal / blk-?Reserved))
```
*(Note: The above "Hover Tooltips" section is a synthesis of how you would complete the tooltip logic; the critical completion for your specific snippet was calculating `textX` and setting the text.)*
**The direct finish line:**
```cpp
if (width ? 20.0f ?? info-?Tag) {
const char* tagStr = static_cast?const char*?(info-?Tag); // Ensure casting is correct for your struct
size_t tagLen = strlen(tagStr);
ImVec2 textSize = ImGui::CalcTextSize((const char*)(tagLen), (char*)0, 4.0f, false, true);
// Standard CalcTextSize usage usually takes string ptr and end ptr or flags
if (width ?= textSize.x + 4.0f)
{
float textX = xStart + width / 2.0f - textSize.x / 2.0f; // Center horizontally on the allocated block area
float textY = aMin.y + static_cast?float?(static_cast?double?(blockHeight - 1.5f) * virtualWidthLocal);
// Wait, y-coordinates in this snippet seem mixed (some use raw pixels, some scaled).
// Looking at: pos.y + blockHeight. 'pos' seems to be screen coordinates already?
// Let's re-evaluate 'scale': double scale = virtualWidth / Reserved. This maps Virtual Bytes -? Screen X.
// If xStart is calculated using scale, then Y should likely also consider if the viewport height scales similarly or uses raw pixels.
dl-?AddText(ImVec2(textX, textY), IM_COL32_WHITE, tagStr);
}
}
ImGui::PopID(); // Don't forget to pop ID for next iteration
}
}
}
}
});
#endif
}
```
---
### Analysis of the Code Logic
This code is a **Memory Arena Debugger** (likely from an Open-source project similar to *Nuklear-Debug* or custom ImGui overlays). It visualizes memory blocks and allocations. Here's how it works:
1. **Coordinate Systems**:
- The code uses two coordinate systems: **Virtual/Logical** (bytes) and **Screen/Spatial** (pixels).
- `scale = virtualWidthLocal / Reserved`: This is the conversion factor from Virtual Bytes to Screen Pixels for a specific block. If you have an allocation of 10MB in a 64GB reserved arena, it draws as a tiny line unless zoomed out? Actually, looking at `virtualWidthLocal` (likely total screen width), this creates a mapping where **pixels correspond directly to the proportion** of data within the reservation size.
- *Correction*: The variable name `searchBlk-?Reserved` suggests we are in an "Inspector" mode focusing on specific blocks.
2. **Block Rendering**:
- It draws rectangles (`AddRect`) for each block representing reserved space.
- If a block has internal data, it divides the visual area into:
- **Header Section**: A solid colored box labeled "Header". Supports tooltips showing size and offset calculations.
- **Padding Sections**: Identified by gaps between allocations (`info-?Offset ? expectedOffset`). These are drawn with diagonal hatching lines to indicate unused space, supporting zoom-level logic (only draws label if width ? 30px).
- **Allocations**: The actual data blocks. Colors vary based on `GetColorForAllocation`, which likely encodes metadata like allocation size or type into the RGB values for easy visual scanning ("Heatmap" style debugging).
3. **Interaction Features**:
- **Selection Handling**: At the very top of your snippet, there is logic to calculate an initial scroll position (`SetScrollX`) if a user has previously selected `state.SelectedAlloc`. This ensures the debugger pans so that memory usage matches their selection context.
- **Hover Tooltips**: When you hover over any element (Header, Padding, or Allocation), a tooltip appears with:
- Hexadecimal/Decimal values for Size and Offset.
- Human-readable descriptions ("Alignment Padding", "Allocation").
4. **Key Implementation Details**:
- **Scaling Logic**: The `scale` variable is re-calculated per-block because blocks of different sizes within an arena have different resolutions when mapped to the same virtual width (`virtualWidthLocal`). This prevents tiny allocations from disappearing entirely in large arenas unless zoomed out, but ensures small allocations remain visible enough to see their labels.
- **Clipping**: There is explicit logic for `clippedLeft` and `clippedRight`. The diagonal padding lines are broken up (step 6.0f) and only drawn if they fall within the window's viewport (`visLeft`, `visRight`). This prevents huge gaps from drawing thousands of lines that might slow down rendering or hit GPU limits on very large arrays.
- **State Management**: The code uses `ImGui::PushID` to ensure every block/allocation has a unique ID for selection and interaction, avoiding UI glitches when multiple blocks are close together.
### How to integrate/use this pattern
If you want to adapt this logic:
1. Ensure your renderer (`dl`) supports vector drawing lines efficiently (e.g., Direct2D, OpenGL VBOs), as the "hatched padding" uses many short lines per gap. Consider using a single polygon with diagonals or rasterization for better performance if gaps are large.
2. The `GetColorForAllocation` function is critical; without it, you can't visually distinguish different tags/allocations. Ensure it returns distinct RGBA values that maintain contrast against the background.
## Symbols
### Namespace `Juliet::Debug`
#### Functions & Methods
- `JULIET_API void DebugDrawMemoryArena()`
@@ -0,0 +1,26 @@
# Juliet\include\Engine\Engine
## Source Files
- Header: `Juliet\include\Engine\Engine.h`
- Source: `Juliet\src\Engine\Engine.cpp`
## AI Description
The JulietEngine encapsulates application lifecycle management, including initialization with memory arenas and subsystems like logging/filesystems. It handles loading/unloading applications while managing graphics devices via a singleton instance for frame rendering logic. The engine orchestrates update loops and render passes using command lists to integrate debug tools and custom renderer systems efficiently within the C++ architecture.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct Engine`
#### Enums
- `enum class JulietInit_Flags`
#### Functions & Methods
- `void InitializeEngine(JulietInit_Flags flags)`
- `void ShutdownEngine()`
- `void LoadApplication(IApplication& app)`
- `void UnloadApplication()`
- `void RunEngine()`
@@ -0,0 +1,15 @@
# Juliet\include\Graphics\Camera
## Source Files
- Header: `Juliet\include\Graphics\Camera.h`
## AI Description
The C++ Camera component defines a data structure for camera parameters including position, target, up vector, and field of view. It provides three inline functions to compute the required projection matrix, view matrix, and combined transformation matrices used in 3D rendering pipelines.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct Camera`
@@ -0,0 +1,15 @@
# Juliet\include\Graphics\Colors
## Source Files
- Header: `Juliet\include\Graphics\Colors.h`
## AI Description
The `Juliet::Colors` module defines flexible color types with RGBA components, enabling high-precision and standard-color representations for graphics operations. It templates both precision (`float`) and byte-level (`uint8`) formats to ensure optimal performance across rendering pipelines while maintaining data integrity during serialization or calculation.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct ColorType`
@@ -0,0 +1,20 @@
# Juliet\include\Graphics\DebugDisplay
## Source Files
- Header: `Juliet\include\Graphics\DebugDisplay.h`
## AI Description
This C++ component enables real-time 3D visualization of geometry (lines and spheres) for debugging. It initializes a graphics device to support drawing operations on CPU command lists during specific rendering passes using provided vectors, colors, and camera data to overlay debug objects onto the scene view.
## Symbols
### Namespace `Juliet`
#### Functions & Methods
- `extern JULIET_API void DebugDisplay_Initialize(GraphicsDevice* device)`
- `extern JULIET_API void DebugDisplay_Shutdown(GraphicsDevice* device)`
- `extern JULIET_API void DebugDisplay_DrawLine(const Vector3& start, const Vector3& end, const FColor& color, bool overlay)`
- `extern JULIET_API void DebugDisplay_DrawSphere(const Vector3& center, float radius, const FColor& color, bool overlay)`
- `extern JULIET_API void DebugDisplay_Prepare(CommandList* cmdList)`
- `extern JULIET_API void DebugDisplay_Flush(CommandList* cmdList, RenderPass* renderPass, const Camera& camera)`
@@ -0,0 +1,162 @@
# Juliet\include\Graphics\Graphics
## Source Files
- Header: `Juliet\include\Graphics\Graphics.h`
- Source: `Juliet\src\Graphics\Graphics.cpp`
## AI Description
Based on the code provided, here is a comprehensive analysis of the implementation. This file appears to be part of a **Vulkan API binding layer** (likely for the "Juliet" engine or library), which translates high-level C++ calls into direct Vulkan driver commands via `CommandListHeader` structures.
### 1. Design Pattern Analysis: The Delegate/Function Pointer Approach
The most distinct characteristic of this code is how it avoids virtual function tables (`vtable`) and polymorphism in favor of **raw function pointers** within a header structure.
* **Structure:** You have a `CommandListHeader` (likely defined elsewhere). This struct seems to hold:
* A reference to the underlying Driver/Device logic pointer.
* Optional Function Pointers (e.g., if certain Vulkan features are not compiled into your build, like hot reload or specific drawing modes): `if (commandListHeader-?Device-?DrawIndexedPrimitives)`.
* **Usage Pattern:** Every method in this file follows the exact same template:
```cpp
// Pseudo-template used by every function here:
auto* header = reinterpret_cast?CommandListHeader*?(ptr);
if (header-?FuncPointer != nullptr) { // Sometimes checked, sometimes implicit via pointer type safety }
header-?Device-?Function(commandLineArg);
```
**Pros:**
* **Extremely Lightweight:** No overhead of vtable lookups or virtual calls. This is crucial for performance-critical graphics paths (like `DrawPrimitives`).
* **Compile-time Optimization:** Since these are raw pointers, the compiler can optimize them better than virtual functions in some architectures if aligned correctly.
**Cons/Risks:**
* **Memory Safety Risk (`reinterpret_cast`):** You are casting user object pointers to a custom header structure immediately after `Get()`. If your memory management (allocators) does not guarantee that these headers remain valid or non-overlapping, you could corrupt the heap or access invalid data. Ensure your allocator is stable for these objects during command recording.
* **Type Safety:** Mixing different pointer types (`CommandList` vs `RenderPass`) via casting can lead to subtle bugs if a caller passes an object of the wrong type into one of these functions.
---
### 2. Code Review ? Observations by Category
#### A. Command Recording Functions (`SetViewPort`, `DrawPrimitives`, etc.)
* **Logic:** These extract the command list from either a `RenderPass` or pass it directly, cast to `CommandListHeader`, and delegate to the device driver.
* **Optimization Note:** In your `WaitUntilGPUIsIdle`, you are passing `device-?Driver`. However, most other functions (`SetViewPort`, etc.) likely operate on a specific *queue family*. Passing just the generic Driver pointer might work if the Driver encapsulates the queue selection logic internally, but ideally, explicit Queue Family context is often safer in Vulkan to ensure commands go to the correct synchronization queue.
* **Function Pointer Safety:** Functions like `DrawIndexedPrimitives` include an explicit check: `if (commandListHeader-?Device-?DrawIndexedPrimitives)`. This suggests some features are opt-in or conditional compilation based (`#ifdef`). Be careful not to call these if they return null in a build that doesn't support them.
#### B. Shader Management
* **Loading Strategy:** The `CreateShader` function uses `LoadFile` with string manipulation (`snprintf`, `GetBasePath`) for relative paths and simple absolute checks for filenames. This is acceptable but relies on the platform-specific behavior of `IsAbsolutePath`.
* **Hot Reload Support:** You have a conditional compilation block `#if ALLOW_SHADER_HOT_RELOAD`. The function signature looks correct, but ensure the caller actually updates shader stages correctly in your pipeline creation flow before drawing.
#### C. Resource Management (Buffers ? Textures)
* **Mapping API (`Map/Unmap`):** You provide separate wrappers for regular buffers and transfer buffers. This matches standard graphics patterns where mapped memory must transition to "Transfer" usage first if it's too large or read-only constraints apply in Vulkan.
* **Descriptor Handles:** `GetDescriptorIndex` is overloaded to handle both Buffers and Textures, returning a `uint32`. This returns the GPU-side index required for binding resources in shaders (e.g., uniform buffers).
#### D. Potential Issues ? Recommendations
1. **Memory Leaks / Double Free Risk:**
* The code uses smart pointers (`NonNullPtr`). If your engine relies on RAII to manage these objects, this looks safe. However, if a user creates `GraphicsBuffer` directly using raw C++ new/delete outside of the Juliet lifecycle while passing it here, they might cause issues with the internal allocation trackers in `CommandListHeader`.
2. **Pointer Validity Assumption:**
* The line:
```cpp
auto* commandList = reinterpret_cast?GPUPass*?(renderPass.Get())-?CommandList; // Cast assumed to exist here? Or is GPUPass a wrapper around CommandListContainer?
auto* commandListHeader = reinterpret_cast?CommandListHeader*?(commandList);
```
* This implies `commandList` (returned from the Render Pass) is exactly an instance of `GPUPass`. If you change how these objects are constructed in your application to return a raw pointer instead, this cast could fail. It relies heavily on strict object identity assumptions provided by your C++ wrapper classes (`NonNullPtr`).
3. **Thread Safety:**
* Vulkan operations must be thread-safe within the same Queue Family and Command Pool/Command Buffer ID. Since these functions take `commandList` as an argument, they are likely recording to pre-allocated command buffers in a loop (for batching), which is correct for high-performance rendering engines like Juliet.
4. **Error Handling:**
* The code currently lacks explicit Vulkan error checks after calling device functions (e.g., checking `vkResult` or internal driver errors). In production, wrapping these calls to log validation messages would be critical, especially since this is a binding layer hiding complex native interactions.
### Summary Conclusion
This is a **high-performance C++ wrapper** designed for a custom graphics engine. It prioritizes performance by eliminating virtual dispatch and relying on tight integration between the application's object model (`CommandListHeader`) and the underlying driver API (likely DirectX 12 or Vulkan via abstraction).
The architecture assumes that `CommandList` objects are pre-allocated command buffers where specific "header" information is injected into them, allowing the engine to efficiently batch commands without copying data back through a vtable.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct IndirectDrawCommand`
- `struct IndexedIndirectDrawCommand`
- `struct IndirectDispatchCommand`
- `struct GraphicsViewPort`
#### Enums
- `enum class QueueType`
- `enum class IndexFormat`
- `enum struct`
- `enum struct`
#### Functions & Methods
- `extern JULIET_API GraphicsDevice* CreateGraphicsDevice(GraphicsConfig config)`
- `extern JULIET_API void DestroyGraphicsDevice(NonNullPtr<GraphicsDevice> device)`
- `// Attach To Window
extern JULIET_API bool AttachToWindow(NonNullPtr<GraphicsDevice> device, NonNullPtr<Window> window)`
- `extern JULIET_API void DetachFromWindow(NonNullPtr<GraphicsDevice> device, NonNullPtr<Window> window)`
- `// SwapChain
extern JULIET_API bool AcquireSwapChainTexture(NonNullPtr<CommandList> commandList, NonNullPtr<Window> window,
Texture** swapChainTexture)`
- `extern JULIET_API bool WaitAndAcquireSwapChainTexture(NonNullPtr<CommandList> commandList,
NonNullPtr<Window> window, Texture** swapChainTexture)`
- `extern JULIET_API bool WaitForSwapchain(NonNullPtr<GraphicsDevice> device, NonNullPtr<Window> window)`
- `extern JULIET_API TextureFormat GetSwapChainTextureFormat(NonNullPtr<GraphicsDevice> device, NonNullPtr<Window> window)`
- `// Textures
extern JULIET_API Texture* CreateTexture(NonNullPtr<GraphicsDevice> device, const TextureCreateInfo& createInfo)`
- `extern JULIET_API void DestroyTexture(NonNullPtr<GraphicsDevice> device, NonNullPtr<Texture> texture)`
- `// Command List
extern JULIET_API CommandList* AcquireCommandList(NonNullPtr<GraphicsDevice> device, QueueType queueType = QueueType::Graphics)`
- `extern JULIET_API void SubmitCommandLists(NonNullPtr<CommandList> commandList)`
- `// RenderPass
extern JULIET_API RenderPass* BeginRenderPass(NonNullPtr<CommandList> commandList, ColorTargetInfo& colorTargetInfo,
DepthStencilTargetInfo* depthStencilTargetInfo = nullptr)`
- `extern JULIET_API RenderPass* BeginRenderPass(NonNullPtr<CommandList> commandList,
NonNullPtr<const ColorTargetInfo> colorTargetInfos, uint32 colorTargetInfoCount,
DepthStencilTargetInfo* depthStencilTargetInfo = nullptr)`
- `extern JULIET_API void EndRenderPass(NonNullPtr<RenderPass> renderPass)`
- `extern JULIET_API void SetGraphicsViewPort(NonNullPtr<RenderPass> renderPass, const GraphicsViewPort& viewPort)`
- `extern JULIET_API void SetScissorRect(NonNullPtr<RenderPass> renderPass, const Rectangle& rectangle)`
- `extern JULIET_API void SetBlendConstants(NonNullPtr<RenderPass> renderPass, FColor blendConstants)`
- `extern JULIET_API void SetStencilReference(NonNullPtr<RenderPass> renderPass, uint8 reference)`
- `extern JULIET_API void BindGraphicsPipeline(NonNullPtr<RenderPass> renderPass, NonNullPtr<GraphicsPipeline> graphicsPipeline)`
- `extern JULIET_API void DrawPrimitives(NonNullPtr<RenderPass> renderPass, uint32 numVertices, uint32 numInstances,
uint32 firstVertex, uint32 firstInstance)`
- `extern JULIET_API void DrawIndexedPrimitives(NonNullPtr<RenderPass> renderPass, uint32 numIndices, uint32 numInstances,
uint32 firstIndex, uint32 vertexOffset, uint32 firstInstance)`
- `extern JULIET_API void SetIndexBuffer(NonNullPtr<CommandList> commandList, NonNullPtr<GraphicsBuffer> buffer,
IndexFormat format, size_t indexCount, index_t offset)`
- `extern JULIET_API void SetPushConstants(NonNullPtr<CommandList> commandList, ShaderStage stage,
uint32 rootParameterIndex, uint32 numConstants, const void* constants)`
- `// Fences
extern JULIET_API bool WaitUntilGPUIsIdle(NonNullPtr<GraphicsDevice> device)`
- `// Shaders
extern JULIET_API Shader* CreateShader(NonNullPtr<GraphicsDevice> device, String filename, ShaderCreateInfo& shaderCreateInfo)`
- `extern JULIET_API void DestroyShader(NonNullPtr<GraphicsDevice> device, NonNullPtr<Shader> shader)`
- `// Pipelines
extern JULIET_API GraphicsPipeline* CreateGraphicsPipeline(NonNullPtr<GraphicsDevice> device,
const GraphicsPipelineCreateInfo& createInfo)`
- `extern JULIET_API void DestroyGraphicsPipeline(NonNullPtr<GraphicsDevice> device, NonNullPtr<GraphicsPipeline> graphicsPipeline)`
- `#if ALLOW_SHADER_HOT_RELOAD
// Allows updating the graphics pipeline shaders. Can update either one or both shaders.
extern JULIET_API bool UpdateGraphicsPipelineShaders(NonNullPtr<GraphicsDevice> device, NonNullPtr<GraphicsPipeline> graphicsPipeline,
Shader* optional_vertexShader, Shader* optional_fragmentShader)`
- `#endif
// Buffers
extern JULIET_API GraphicsBuffer* CreateGraphicsBuffer(NonNullPtr<GraphicsDevice> device, const BufferCreateInfo& createInfo)`
- `extern JULIET_API GraphicsTransferBuffer* CreateGraphicsTransferBuffer(NonNullPtr<GraphicsDevice> device,
const TransferBufferCreateInfo& createInfo)`
- `extern JULIET_API void* MapGraphicsBuffer(NonNullPtr<GraphicsDevice> device, NonNullPtr<GraphicsBuffer> buffer)`
- `extern JULIET_API void UnmapGraphicsBuffer(NonNullPtr<GraphicsDevice> device, NonNullPtr<GraphicsBuffer> buffer)`
- `extern JULIET_API void* MapGraphicsTransferBuffer(NonNullPtr<GraphicsDevice> device, NonNullPtr<GraphicsTransferBuffer> buffer)`
- `extern JULIET_API void UnmapGraphicsTransferBuffer(NonNullPtr<GraphicsDevice> device, NonNullPtr<GraphicsTransferBuffer> buffer)`
- `extern JULIET_API void CopyBuffer(NonNullPtr<CommandList> commandList, NonNullPtr<GraphicsBuffer> dst,
NonNullPtr<GraphicsTransferBuffer> src, size_t size, size_t dstOffset = 0,
size_t srcOffset = 0)`
- `extern JULIET_API void CopyBufferToTexture(NonNullPtr<CommandList> commandList, NonNullPtr<Texture> dst,
NonNullPtr<GraphicsTransferBuffer> src)`
- `extern JULIET_API void TransitionBufferToReadable(NonNullPtr<CommandList> commandList, NonNullPtr<GraphicsBuffer> buffer)`
- `extern JULIET_API uint32 GetDescriptorIndex(NonNullPtr<GraphicsDevice> device, NonNullPtr<GraphicsBuffer> buffer)`
- `extern JULIET_API uint32 GetDescriptorIndex(NonNullPtr<GraphicsDevice> device, NonNullPtr<Texture> texture)`
- `extern JULIET_API void DestroyGraphicsBuffer(NonNullPtr<GraphicsDevice> device, NonNullPtr<GraphicsBuffer> buffer)`
- `extern JULIET_API void DestroyGraphicsTransferBuffer(NonNullPtr<GraphicsDevice> device, NonNullPtr<GraphicsTransferBuffer> buffer)`
@@ -0,0 +1,20 @@
# Juliet\include\Graphics\GraphicsBuffer
## Source Files
- Header: `Juliet\include\Graphics\GraphicsBuffer.h`
## AI Description
This component defines GPU buffer enums and create structs within the Juliet graphics system. It declares opaque `GraphicsBuffer` and `GraphicsTransferBuffer` types, enabling high-level resource management for indices, constants, structures, and transfer operations without exposing internal implementation details.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct BufferCreateInfo`
- `struct TransferBufferCreateInfo`
#### Enums
- `enum class BufferUsage`
- `enum class TransferBufferUsage`
@@ -0,0 +1,18 @@
# Juliet\include\Graphics\GraphicsConfig
## Source Files
- Header: `Juliet\include\Graphics\GraphicsConfig.h`
## AI Description
Defines the Juliet graphics configuration structure within the C++ module. It specifies supported driver types (DirectX 12, All) and includes a toggle for debug features to manage rendering backend compatibility across applications.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct GraphicsConfig`
#### Enums
- `enum class DriverType`
@@ -0,0 +1,33 @@
# Juliet\include\Graphics\GraphicsPipeline
## Source Files
- Header: `Juliet\include\Graphics\GraphicsPipeline.h`
## AI Description
This C++ header defines the `GraphicsPipeline` design for a rendering system, specifying data structures to configure rasterization (fill/cull modes), vertex input buffers and attributes, target properties including color depth/stencil settings with custom operations, multisampling states, and shader references. It provides low-level details on primitive types, attribute formats like floats/ints/normals, depth bias calculations, compare/mask logic, and stencil failure behaviors to build a complete graphics pipeline configuration object.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct RasterizerState`
- `struct VertexBufferDescription`
- `struct VertexAttribute`
- `struct VertexInputState`
- `struct GraphicsPipelineTargetInfo`
- `struct StencilOperationState`
- `struct DepthStencilState`
- `struct MultisampleState`
- `struct GraphicsPipelineCreateInfo`
#### Enums
- `enum class FillMode`
- `enum class CullMode`
- `enum class FrontFace`
- `enum class PrimitiveType`
- `enum class VertexInputRate`
- `enum class VertexElementFormat`
- `enum class CompareOperation`
- `enum class StencilOperation`
@@ -0,0 +1,117 @@
# Juliet\include\Graphics\ImGuiRenderer
## Source Files
- Header: `Juliet\include\Graphics\ImGuiRenderer.h`
- Source: `Juliet\src\Graphics\ImGuiRenderer.cpp`
## AI Description
Based on the code provided, you are implementing a **hardware-accelerated ImGui renderer** (likely for DirectX 12 using your `GraphicsPipeline`, `CommandList`, and buffer interfaces) that supports multiple render passes or frame queues.
Here is an analysis of what this code does, how it functions internally, and potential optimizations or issues to consider.
### 🚀 Core Functionality Summary
This `ImGuiRenderer_Render` method:
1. **Initializes ImGui**: Calls the standard ImGui API setup. If no draw data exists (idle frame), it returns early.
2. **Creates Pipeline on Demand**: Lazily creates a specific GraphicsPipeline for triangle listing with additive blending (`Src_Alpha * One_Minus_Src_Alpha`) and no culling, which is crucial for non-solid transparent UI elements in some contexts or just standard rendering if depth testing isn't enabled here (note: `CullMode::None` suggests potential visibility issues without Depth State configuration).
3. **Manages Frame Queue**: Cycles through a fixed number of frames (`kMaxFramesInFlight`) to allow concurrent rendering, ensuring the ImGui logic doesn't block GPU uploads if previous copies are still pending.
4. **Uploads Vertex Data**: Maps `TransferBuffers` from CPU memory into GPU-visible buffers for this specific frame slot and performs asynchronous data copying via your custom API wrappers (`CopyBuffer`).
5. **Executes Draw Commands**: Iterates through ImGui's internal command lists, decodes clip spaces to normalized device coordinates (NDC), handles texture bindings/blit callbacks, and pushes vertex transformation constants directly into the shader uniforms using `SetPushConstants`.
---
### 🔍 Key Implementation Details ? Observations
#### 1. Pipeline Configuration
```cpp
colorDesc.BlendState.ColorBlendOperation = BlendOperation::Add; // ❓ Potential Issue?
// ...
ColorComponentFlags::R | ColorComponentFlags::G | ColorComponentFlags::B | ColorComponentFlags::A;
```
* **Observation**: You are using `Blending Operation: Add`. This is typically used for effects (like bloom or glow). For standard ImGui UI, the default blend mode (`SrcAlpha * OneMinusDestAlpha`) overwrites previous pixels in a way that respects occlusion order. Using "Add" can cause visual artifacts if elements overlap incorrectly unless intended for special overlaying purposes.
* **Missing Depth State**: The pipeline definition sets `CullMode::None` but does not explicitly configure the depth state (e.g., `DepthEnable`, `WriteMask`). ImGui usually requires disabling depth writes (`WriteMask = 0`) so background UI elements don't obscure game content unless specifically desired.
#### 2. Buffer Management ? Frame Indexing
```cpp
g_ImGuiState.FrameIndex = (g_ImGuiState.FrameIndex + 1) % kMaxFramesInFlight;
FrameResources? currentFrame = g_ImGuiState.Frames[g_ImGuiState.FrameIndex];
// ... uploads data to VertexUpload/IndexUpload ...
CopyBuffer(cmdList, /*currentFrame.Buffer*/, ...); // Copies TO GPU buffer of 'currentFrame'
TransitionBufferToReadable(cmdList, currentFrame.VertexBuffer);
```
* **Logic**: This implements a frame queue pattern. The vertex/index indices uploaded are copied into the `GPU Buffer` associated with that specific index in memory (`currentFrame`). A barrier is set to make this buffer readable before rendering.
* **Index Offset Handling**: Note how you track global offsets:
```cpp
DrawIndexedPrimitives(..., pcmd-?IdxOffset + globalIdxOffset); // ❗ Check API Expectation
```
If your `DrawIndexedPrimitives` function expects a raw offset into the *GPU buffer*, this logic is correct. However, if you plan to support multiple layers (e.g., UI layer on top of Game scene), managing these offsets carefully ensures that subsequent render passes draw at the correct positions without skipping vertices.
#### 3. Projection ? Scaling
```cpp
float scale[2]; // Perspective or Orthographic?
// ... calculation using DisplayPos, DisplaySize ...
SetPushConstants(..., pushData.Scale..., Translate...)
```
* **Analysis**: This implementation uses a custom projection matrix derived from the display window size and ImGui's internal scaling factors (`FramebufferScale`). It calculates `scale` (likely for normalization) and `translate` to map screen space directly into your NDC coordinates.
* **Recommendation**: Ensure that this logic matches how your game engine handles viewports. If you have a different aspect ratio or multiple windows, ImGui's `ViewportSetup` is usually handled separately; here it appears tightly coupled with the render pass setup (`scale[0] = 2.0f / (R - L)` assumes an axis-aligned rect centered at origin logic).
#### 4. Push Constants Usage
```cpp
pushData.BufferIndex // Vertex buffer bind index?
pushData.TextureIndex // Texture bind index from UserCallback/GetDescriptorIndex?
// ... Scale, Translate per draw command?
SetPushConstants(cmdList, ShaderStage::Vertex, 0, sizeof(pushData) / 4, ?pushData);
```
* **Observation**: The `BufferIndex` and `TextureIndex` are pushed as constants rather than bound descriptors in the pipeline. This suggests your shader expects these indices to be read directly from an array of buffers/textures indexed by GPU offset or constant index lookups. Ensure this matches your vertex/fragment shader expectations exactly (i.e., does the shader expect a direct address via `texture(sampler0, TextureIndex)`?).
---
### ⚠️ Potential Issues ? Improvements
#### 1. Depth Buffer Handling
ImGui UI typically needs to be rendered **on top of** the main game scene. Without explicit depth state handling:
* If your pipeline enables depth writes by default (`DepthEnable = true`), your UI might clip against the background objects, or conversely, block them if they have non-zero alpha and expect occlusion logic that conflicts with ImGui's blending mode.
* **Fix**: Explicitly disable depth write in `pci.TargetInfo.ColorTargetDescriptions`:
```cpp
// Ensure Depth State is disabled for standard UI overlay unless needed
pci.DepthState = {};
// Add explicit structure fields to match your API:
#if defined(PIXELFORMAT_DEPTH32) || ...
const auto? depthDesc = pci.TargetInfo.DepthStencilDescriptions[0];
depthDesc.EnableDepthWrite = false;
depthDesc.DepthFunction = DepthFunc::AlwaysPassOver; // Optional, ensure consistent behavior
// Make sure your RenderPass has matching Format ? Viewport setup for depth write disable if applicable.
#endif
```
#### 2. Memory Allocation Pattern (`EnsureBufferSize`)
Your code manually ensures buffer sizes and then `Map` -? `Copy` -? `Unmap`. While functional, modern DX12 patterns often favor:
* Using hardware-level memory barriers instead of manual CPU maps if the GPU is ready to receive data immediately (bypassing staging).
* Optimizing allocation via **Shared Virtual Addressing** or direct buffer allocations.
#### 3. Frame Queue vs Single Pass Logic
Currently, you seem to have logic that allows multiple frame slots but only renders one set of draw commands per execution (`cmdList` iteration happens once inside the function scope? No wait, this iterates `drawData-?CmdListsCount`).
* **Clarification**: Is it possible for a single UI call (e.g., an overlay) to require rendering across multiple frames in flight simultaneously via your mechanism, or does each new frame simply draw fresh data into its slot?
* If the latter: Your approach is efficient. Each `NewFrame` allocates/copies into a specific index of the circular buffer and renders immediately (single-threaded sequential render within one frame context).
#### 4. Shader Constants Efficiency
You are pushing per-draw constants (`Scale`, `Translate`). This consumes GPU registers heavily if not managed well. Consider using **Push Constant Buffers** allocated on a larger stack size to store the entire ImGui data block once (since all draws in a list share one viewport/scale) rather than recalculating/pushing for every primitive, provided your shader supports large constant reads or batched updates.
### 💡 Conclusion
This is a robust implementation of an **ImGui renderer targeting high-performance rendering with frame queuing**. It carefully handles asynchronous uploads and memory management suitable for a production graphics pipeline (DX12 likely). The critical areas to double-check are:
1. Whether `BlendOperation::Add` aligns with your desired visual output vs standard alpha blending.
2. Explicitly disabling depth writes in the render pass/pipeline config.
3. Ensuring the shader's constant reading mechanism (`TextureIndex`, `BufferIndex`) matches exactly how you are passing them via `PushData`.
If these match your system design, this code should function as a stable bridge between ImGui's high-level API and your custom low-level rendering layer.
## Symbols
### Namespace `Juliet`
#### Functions & Methods
- `extern bool ImGuiRenderer_Initialize(GraphicsDevice* device)`
- `extern void ImGuiRenderer_Shutdown(GraphicsDevice* device)`
- `extern void ImGuiRenderer_NewFrame()`
- `extern JULIET_API void ImGuiRenderer_Render(CommandList* cmdList, RenderPass* renderPass)`
@@ -0,0 +1,15 @@
# Juliet\include\Graphics\Lighting
## Source Files
- Header: `Juliet\include\Graphics\Lighting.h`
## AI Description
Juliet::PointLight defines a lightweight C++ structure for 2D or generic lighting in the Juliet graphics engine, storing position, radius, color, and intensity via core Vector3 components. This struct enables developers to easily represent point light sources within their scene graphs without heavy dependency on complex rendering libraries.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct PointLight`
@@ -0,0 +1,19 @@
# Juliet\include\Graphics\Mesh
## Source Files
- Header: `Juliet\include\Graphics\Mesh.h`
- Source: `Juliet\src\Graphics\Mesh.cpp`
## AI Description
The C++ Mesh component manages geometry data, defining vertex and index counts with offsets. It stores a transform matrix for spatial operations within the Juliet engine's memory arena architecture.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct Mesh`
#### Functions & Methods
- `Matrix Transform = Mesh::MatrixIdentity()`
@@ -0,0 +1,39 @@
# Juliet\include\Graphics\MeshRenderer
## Source Files
- Header: `Juliet\include\Graphics\MeshRenderer.h`
- Source: `Juliet\src\Graphics\MeshRenderer.cpp`
## AI Description
*No AI description generated yet.*
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct MeshRenderer`
#### Functions & Methods
- `constexpr size_t kGeometryPage = Megabytes(64)`
- `constexpr size_t kIndexPage = Megabytes(32)`
- `JULIET_API void InitializeMeshRenderer(NonNullPtr<Arena> arena)`
- `[[nodiscard]] JULIET_API bool InitializeMeshRendererGraphics(NonNullPtr<GraphicsDevice> device, NonNullPtr<Window> window)`
- `JULIET_API void ShutdownMeshRendererGraphics()`
- `JULIET_API void ShutdownMeshRenderer()`
- `JULIET_API void LoadMeshesOnGPU(NonNullPtr<CommandList> cmdList)`
- `JULIET_API void RenderMeshes(NonNullPtr<RenderPass> pass, NonNullPtr<CommandList> cmdList, PushData& pushData)`
- `// Lights
[[nodiscard]] JULIET_API LightID AddPointLight(const PointLight& light)`
- `JULIET_API void SetPointLightPosition(LightID id, const Vector3& position)`
- `JULIET_API void SetPointLightColor(LightID id, const Vector3& color)`
- `JULIET_API void SetPointLightRadius(LightID id, float radius)`
- `JULIET_API void SetPointLightIntensity(LightID id, float intensity)`
- `JULIET_API void ClearPointLights()`
- `// Utils
[[nodiscard]] JULIET_API MeshID AddCube()`
- `[[nodiscard]] JULIET_API MeshID AddQuad()`
- `JULIET_API void SetMeshTransform(MeshID id, const Matrix& transform)`
- `#if ALLOW_SHADER_HOT_RELOAD
JULIET_API void ReloadMeshRendererShaders()`
@@ -0,0 +1,15 @@
# Juliet\include\Graphics\PushConstants
## Source Files
- Header: `Juliet\include\Graphics\PushConstants.h`
## AI Description
This C++ struct defines a render-pass push constant block holding view-projection matrices, buffer indices for meshes and lighting, scale/translate vectors, vertex offsets, and global light direction/color data to facilitate efficient GPU state configuration.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct PushData`
@@ -0,0 +1,26 @@
# Juliet\include\Graphics\RenderPass
## Source Files
- Header: `Juliet\include\Graphics\RenderPass.h`
## AI Description
This header defines a render pass abstraction for the Juliet graphics API, containing enums and structs to configure color targets, depth/stencil states, blend modes, mipmap operations (load/store/resolve), clear values, and texture cycling. It enables high-level rendering pipeline configuration by encapsulating target properties like formats, mip levels, resolution logic, and per-component blending parameters without exposing direct hardware calls.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct ColorTargetInfo`
- `union ColorTargetInfo::anonymous`
- `struct DepthStencilTargetInfo`
- `struct ColorTargetBlendState`
- `struct ColorTargetDescription`
#### Enums
- `enum struct`
- `enum struct`
- `enum class BlendFactor`
- `enum class BlendOperation`
- `enum class ColorComponentFlags`
@@ -0,0 +1,18 @@
# Juliet\include\Graphics\Shader
## Source Files
- Header: `Juliet\include\Graphics\Shader.h`
## AI Description
Juliet::Shader provides opaque handle management for vertex, fragment, and compute stages. It defines creation structures specifying entry points and stage types to facilitate shader compilation within the graphics subsystem. This component abstracts low-level resource initialization while maintaining type safety through enums and string handles.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct ShaderCreateInfo`
#### Enums
- `enum class ShaderStage`
@@ -0,0 +1,24 @@
# Juliet\include\Graphics\SkyboxRenderer
## Source Files
- Header: `Juliet\include\Graphics\SkyboxRenderer.h`
- Source: `Juliet\src\Graphics\SkyboxRenderer.cpp`
## AI Description
The SkyboxRenderer manages initialization of skybox shaders and pipelines within the Juliet graphics system. It handles setup via a device, renders the effect using view projection matrices passed to push constants, and includes support for shader hot reload when enabled.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct SkyboxRenderer`
#### Functions & Methods
- `[[nodiscard]] JULIET_API bool InitializeSkyboxRenderer(NonNullPtr<GraphicsDevice> device,
NonNullPtr<Window> window)`
- `JULIET_API void ShutdownSkyboxRenderer()`
- `JULIET_API void RenderSkybox(NonNullPtr<RenderPass> pass, NonNullPtr<CommandList> cmdList, const Matrix& viewProjection)`
- `#if ALLOW_SHADER_HOT_RELOAD
JULIET_API void ReloadSkyboxShaders()`
@@ -0,0 +1,22 @@
# Juliet\include\Graphics\Texture
## Source Files
- Header: `Juliet\include\Graphics\Texture.h`
## AI Description
Defines comprehensive texture format enumerations, usage flags, types (e.g., 2DArray), and sample counts. Introduces `TextureCreateInfo` to specify resource properties like dimensions, depth planes, mip levels, and compression formats for rendering or compute operations within the Juliet graphics system.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct TextureCreateInfo`
- `union TextureCreateInfo::anonymous`
#### Enums
- `enum struct`
- `enum struct`
- `enum struct`
- `enum struct`
@@ -0,0 +1,15 @@
# Juliet\include\Graphics\VertexData
## Source Files
- Header: `Juliet\include\Graphics\VertexData.h`
## AI Description
The `Vertex` and `Index` structs in the Juliet library define vertex data for 2D graphics, comprising position coordinates (3 floats), normals (3 floats), per-pixel colors via RGBA format, and unsigned short indices.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct Vertex`
+11
View File
@@ -0,0 +1,11 @@
# Juliet\include\Juliet
## Source Files
- Header: `Juliet\include\Juliet.h`
## AI Description
This header defines platform-specific macros, including conditional Windows support and debug features. It implements a modular design for optional ImGui disabling while ensuring strict Win32 compatibility through export definitions and runtime configuration flags.
## Symbols
*No symbols detected.*
@@ -0,0 +1,11 @@
# Juliet\src\Core\HAL\Display\Win32\Win32DisplayDevice
## Source Files
- Source: `Juliet\src\Core\HAL\Display\Win32\Win32DisplayDevice.cpp`
## AI Description
The Win32DisplayDevice component manages Windows display operations using the Win32 API, handling window creation, destruction, event pumping, and title management within the Juliet framework. It serves as a factory-registered implementation that provides hardware access for platform-specific rendering tasks.
## Symbols
*No symbols detected.*
@@ -0,0 +1,17 @@
# Juliet\src\Core\HAL\Display\Win32\Win32DisplayEvent
## Source Files
- Header: `Juliet\src\Core\HAL\Display\Win32\Win32DisplayEvent.h`
- Source: `Juliet\src\Core\HAL\Display\Win32\Win32DisplayEvent.cpp`
## AI Description
This C++ component manages Windows event handling for display interaction within the Juliet framework. It translates Win32 messages into high-level events like keystrokes and mouse motions while supporting IMGUI integration via a custom window procedure callback that forwards user input to the core system without manual polling limitations.
## Symbols
### Namespace `Juliet::Win32`
#### Functions & Methods
- `extern void PumpEvents(NonNullPtr<DisplayDevice> self)`
- `extern LRESULT CALLBACK Win32MainWindowCallback(HWND Handle, UINT Message, WPARAM WParam, LPARAM LParam)`
@@ -0,0 +1,23 @@
# Juliet\src\Core\HAL\Display\Win32\Win32Window
## Source Files
- Header: `Juliet\src\Core\HAL\Display\Win32\Win32Window.h`
- Source: `Juliet\src\Core\HAL\Display\Win32\Win32Window.cpp`
## AI Description
This header defines the Win32 display platform for the Juliet framework. It provides functions to create, destroy, show, hide, and set titles for windows using native HWND/HDC handles via a lightweight internal state structure inheriting from the base WindowState class.
## Symbols
### Namespace `Juliet::Win32`
#### Classes, Structs & Unions
- `struct Window32State`
#### Functions & Methods
- `extern bool CreatePlatformWindow(NonNullPtr<DisplayDevice> self, NonNullPtr<Window> window)`
- `extern void DestroyPlatformWindow(NonNullPtr<DisplayDevice> self, NonNullPtr<Window> window)`
- `extern void ShowWindow(NonNullPtr<DisplayDevice> self, NonNullPtr<Window> window)`
- `extern void HideWindow(NonNullPtr<DisplayDevice> self, NonNullPtr<Window> window)`
- `extern void SetWindowTitle(NonNullPtr<DisplayDevice> self, NonNullPtr<Window> window, String title)`
@@ -0,0 +1,11 @@
# Juliet\src\Core\HAL\DynLib\Win32\DynamicLibrary
## Source Files
- Source: `Juliet\src\Core\HAL\DynLib\Win32\DynamicLibrary.cpp`
## AI Description
This C++ component implements Windows dynamic library loading via LoadLibraryA and GetProcAddress, with corresponding error logging. It includes functions to load libraries into the execution space by filename or handle pointer, retrieve exported function addresses safely using NonNullPtr wrappers, manage warnings, unload modules via FreeLibrary, provide comprehensive internal validation checks for invalid inputs, and maintain clean object-oriented interface design through reinterpret casts on HMODULE structures while ensuring robust error handling.
## Symbols
*No symbols detected.*
@@ -0,0 +1,22 @@
# Juliet\src\Core\HAL\Event\Keyboard
## Source Files
- Source: `Juliet\src\Core\HAL\Event\Keyboard.cpp`
## AI Description
The C++ Keyboard HAL component manages global keyboard input by tracking scan codes and modifier states internally. It processes key press/release events to detect repeats, convert scan codes to logic keys using mappings, update modifier flags like CapsLock or NumLock dynamically, and post standardized system events with precise timestamps for the Juliet framework.
## Symbols
### Namespace `Juliet::anonymous`
#### Classes, Structs & Unions
- `struct KeyboardState`
### Namespace `Juliet`
#### Functions & Methods
- `static_assert( ToUnderlying(KeyState::Down)`
- `static_assert( ToUnderlying(KeyState::Up)`
- `static_assert( ToUnderlying(ScanCode::Count)`
@@ -0,0 +1,17 @@
# Juliet\src\Core\HAL\Event\KeyboardMapping
## Source Files
- Header: `Juliet\src\Core\HAL\Event\KeyboardMapping.h`
- Source: `Juliet\src\Core\HAL\Event\KeyboardMapping.cpp`
## AI Description
This C++ module provides a default US keyboard mapping service, translating raw scan codes into logical keycodes. It defines static mappings for printable and non-printable keys while handling dynamic state via the Shift modifier and Caps Lock to produce correct character outputs. The component validates input ranges before resolving identifiers.
## Symbols
### Namespace `Juliet`
#### Functions & Methods
- `// Transforms ScanCode into KeyCode using the default US ASCII Mapping
extern KeyCode GetKeyCodeFromDefaultMapping(ScanCode scanCode, KeyMod keyModState)`
@@ -0,0 +1,11 @@
# Juliet\src\Core\HAL\Event\Mouse
## Source Files
- Source: `Juliet\src\Core\HAL\Event\Mouse.cpp`
## AI Description
This module manages global mouse state and generates internal events for motion, button presses, and releases. It maintains a single shared Mouse instance tracking absolute position within windows and validates coordinates to ensure they stay within valid window bounds before emitting system-level input notifications.
## Symbols
*No symbols detected.*
@@ -0,0 +1,19 @@
# Juliet\src\Core\HAL\Event\WindowEvent
## Source Files
- Header: `Juliet\src\Core\HAL\Event\WindowEvent.h`
- Source: `Juliet\src\Core\HAL\Event\WindowEvent.cpp`
## AI Description
This component dispatches window-specific events through the system event pipeline. It validates input windows, constructs a standardized SystemEvent with an associated Window ID and type tag, queues it via the HAL add-event mechanism, and returns success or failure status. The design promotes loose coupling between display subsystems and application logic using explicit enumeration-based typing.
## Symbols
### Namespace `Juliet`
#### Enums
- `enum class EventType`
#### Functions & Methods
- `extern bool SendWindowEvent(Window* window, EventType type)`
@@ -0,0 +1,11 @@
# Juliet\src\Core\HAL\Filesystem\Win32\Win32Filesystem
## Source Files
- Source: `Juliet\src\Core\HAL\Filesystem\Win32\Win32Filesystem.cpp`
## AI Description
Provides executable path retrieval and absolute path validation for the Juliet Win32 filesystem. Retrieves module filename safely, handles dynamic buffer allocation for long paths by doubling size if needed, then strips directory components to isolate base execution folder while ensuring valid UNC or disk-designator formats are recognized as absolute.
## Symbols
*No symbols detected.*
@@ -0,0 +1,15 @@
# Juliet\src\Core\HAL\IO\Win32\Win32IOStream
## Source Files
- Source: `Juliet\src\Core\HAL\IO\Win32\Win32IOStream.cpp`
## AI Description
This C++ component implements a high-performance Win32 file I/O abstraction for the Juliet framework. It provides optimized read/write operations, seeks support, and memory management via an `IOStream` interface using native functions like CreateFileA and ReadFile on Windows systems.
## Symbols
### Namespace `Juliet::Internal::anonymous`
#### Classes, Structs & Unions
- `struct Win32IOStreamDataPayload`
@@ -0,0 +1,11 @@
# Juliet\src\Core\HAL\OS\Win32\Win32OS
## Source Files
- Source: `Juliet\src\Core\HAL\OS\Win32\Win32OS.cpp`
## AI Description
This Win32OS component provides a C++ OS abstraction layer for the Juliet framework. It implements memory management via VirtualAlloc/Free, includes exception handling and instance protection logic, initializes Windows networking functions to access RIO APIs, and registers its function table globally.
## Symbols
*No symbols detected.*
@@ -0,0 +1,11 @@
# Juliet\src\Core\HotReload\Win32\Win32HotReload
## Source Files
- Source: `Juliet\src\Core\HotReload\Win32\Win32HotReload.cpp`
## AI Description
This component implements Windows-specific hot-reloading logic for DLLs. It copies original DLLs to unique temporary files with atomic IDs and dynamically loads functions from them. The design tracks file modification times to detect updates, manages transient memory via scratch arenas, and supports reloading or unloading based on validity checks within the Juliet namespace architecture.
## Symbols
*No symbols detected.*
+11
View File
@@ -0,0 +1,11 @@
# Juliet\src\Core\Juliet
## Source Files
- Source: `Juliet\src\Core\Juliet.cpp`
## AI Description
This C++ component manages the initialization and shutdown of optional Juliet systems like displays using a reference-counting mechanism. It tracks system state via atomic counters to ensure safe lifecycle management, initializing subsystems on demand while preventing premature destruction during startup sequences.
## Symbols
*No symbols detected.*
@@ -0,0 +1,15 @@
# Juliet\src\Core\Math\MathRound
## Source Files
- Source: `Juliet\src\Core\Math\MathRound.cpp`
## AI Description
This C++ component provides a highly precise, single-precision floating-point rounding function that manipulates IEEE 754 bit patterns for optimal performance. It adapts to different float evaluation modes using consteval and avoids compiler optimizations by employing ForceEval alongside union reinterpretation of bits for exact arithmetic control.
## Symbols
### Namespace `Juliet::anonymous`
#### Functions & Methods
- `constexpr float EPS = GetEps()`
@@ -0,0 +1,15 @@
# Juliet\src\Core\Memory\MemoryArenaTests
## Source Files
- Source: `Juliet\src\Core\Memory\MemoryArenaTests.cpp`
## AI Description
This file contains unit tests for the C++ MemoryArena component, verifying its allocation of structured data and raw arrays. It checks core behaviors including arena position tracking, clearing, commit sizing policies based on reserved memory blocks, dynamic reallocation (growth/shrink), boundary management via `AllowRealloc`, and protection against buffer overflow during shrinking operations.
## Symbols
### Namespace `Juliet::UnitTest`
#### Classes, Structs & Unions
- `struct TestStruct`
@@ -0,0 +1,15 @@
# Juliet\src\Core\Networking\Win32\Win32SocketPlatformImpl
## Source Files
- Source: `Juliet\src\Core\Networking\Win32\Win32SocketPlatformImpl.cpp`
## AI Description
The file implements Windows-specific socket functionality using Win32 APIs, including address conversion and error handling via WSAError codes. It utilizes a singleton `WSAAutoRelease` struct to ensure global initialization of the WinSock library within the process lifecycle through constructor execution on startup and destructor cleanup at exit.
## Symbols
### Namespace `Juliet`
#### Classes, Structs & Unions
- `struct WSAAutoRelease`
@@ -0,0 +1,132 @@
# Juliet\src\Graphics\D3D12\AgilitySDK\d3dx12\d3dx12_property_format_table
## Source Files
- Header: `Juliet\src\Graphics\D3D12\AgilitySDK\d3dx12\d3dx12_property_format_table.h`
- Source: `Juliet\src\Graphics\D3D12\AgilitySDK\d3dx12\d3dx12_property_format_table.cpp`
## AI Description
This code snippet appears to be part of a **DirectX 12 (D3D12) runtime source file**, specifically defining internal data structures used for **format casting** and **property layout analysis**. It looks like it was extracted from `d3d12core.cpp` or similar, where the compiler generates tables to handle format conversions efficiently.
Here is a breakdown of what each section does:
### 1. Cast Sets (`YOUR_BC7`, etc.)
These arrays define groups of related formats that can be cast to one another without data conversion (e.g., converting `DXGI_FORMAT_R8G8B8A8_UNORM` to its typeless variant is usually free).
* **Purpose:** They allow the hardware or shader compiler to perform fast pointer arithmetic or register mapping between similar formats.
* **The "Null Terminator":** Every array ends with `{ DXGI_FORMAT_UNKNOWN, ... }`. This acts as a sentinel value (similar to `\0` in C strings) so that when searching for a specific format within this list using loops or binary search algorithms defined elsewhere in the file, the loop knows exactly where the valid data stops.
### 2. Property Layout Table (`s_FormatDetail[]`)
This is the most complex part of your snippet. It defines how individual formats are interpreted by the D3D12 runtime regarding alignment, storage size, and component semantics.
Each object in `s_FormatDetail` contains:
* **Format Info:** The specific format (e.g., `R32G32B32A32_TYPELESS`).
* **Parent Format:** Which "group" or cast set this belongs to.
* **Default Cast Set ID:** Used for mapping conversions.
* **BitsPerComponent:** How many bits each channel uses (e.g., `32` for float types).
* **Alignment Values (`Width/Height/DepthAlignment`):** Crucial for D12 textures. These determine how the GPU aligns pixel data in memory to optimize bandwidth and SIMD performance. For example, 4x8 alignment is often required for high-precision floats on specific hardware.
* **Flags:** Boolean flags indicating if it uses DX9 Vertex/Index formats (`bDX9...`), Planar format support (like YUV or NV12 which split RGB channels into planes), Float normalization behavior, etc.
#### Key Flags Explained in your snippet:
* `D3DFL_STANDARD`: Indicates a standard linear texture layout (no special packing).
* `_FLOAT`, `_UINT`, `_SINT` vs `_TYPELESS`: Defines the actual data type expected when casting from that specific format to a generic "typeless" wrapper. This helps shader compilers determine how many registers are needed for an operation like `Add`.
* **YUV/Planar Formats:** You see entries related to Y410, NV12, etc., where flags like `bPlanar` might be set (though explicitly in the snippet provided is tricky without seeing every flag, usually these have specific width alignments due to interleaving of Luma and Chroma).
### 3. Truncated Data
The last block starts with:
```cpp
{
DXGI_FORMAT_R32G32B_TYPELESS, // Note: Snippet cuts off here/next line
...
```
This indicates the list continues for formats like `R16`, `RG16A8_UNORM` (which is often aliased under typeless prefixes in D3D9 headers), and other internal core formats.
### Contextual Observation
The inclusion of `{ DXGI_FORMAT_UNKNOWN }` at the end of these arrays suggests this code is likely generated or maintained to support **backward compatibility** with DX10/DX11 semantics while ensuring robustness against invalid format lookups in a dynamic environment (like creating shaders on-the-fly).
If you are modifying this for game development, typically:
1. You would not edit these arrays unless working directly on the source of `dxgi_core.h` or the D3D runtime headers (as changing them affects how Windows maps your textures to GPU hardware registers globally).
2. The alignment values (`WidthAlignment`) are highly specific to the **DXGIDirectCompute** implementation for that specific generation; they often dictate whether a texture fits in SRAM, L1 Cache, or requires more expensive memory transactions when accessed via shaders.
Are you trying to understand how format casting works here? Or do you need help calculating alignment requirements based on these flags?
## Symbols
### Global Scope
#### Classes, Structs & Unions
- `struct D3D12_PROPERTY_LAYOUT_FORMAT_TABLE`
- `struct D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::FORMAT_DETAIL`
#### Functions & Methods
- `// separate from above structure so it can be compiled out of runtime.
public:
static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetNumFormats()`
- `static const FORMAT_DETAIL* D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetFormatTable()`
- `static D3D_FEATURE_LEVEL D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetHighestDefinedFeatureLevel()`
- `static DXGI_FORMAT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetFormat(SIZE_T Index)`
- `static bool D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::FormatExists(DXGI_FORMAT Format)`
- `static bool D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::FormatExistsInHeader(DXGI_FORMAT Format, bool bExternalHeader = true)`
- `static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetByteAlignment(DXGI_FORMAT Format)`
- `static bool D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::IsBlockCompressFormat(DXGI_FORMAT Format)`
- `static LPCSTR D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetName(DXGI_FORMAT Format, bool bHideInternalFormats = true)`
- `static bool D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::IsSRGBFormat(DXGI_FORMAT Format)`
- `static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetBitsPerStencil(DXGI_FORMAT Format)`
- `static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetBitsPerDepth(DXGI_FORMAT Format)`
- `static void D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetFormatReturnTypes(DXGI_FORMAT Format, D3D_FORMAT_COMPONENT_INTERPRETATION* pInterpretations)`
- `// return array of 4 components
static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetNumComponentsInFormat(DXGI_FORMAT Format)`
- `static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetMinNumComponentsInFormats(DXGI_FORMAT FormatA, DXGI_FORMAT FormatB)`
- `// Converts the sequential component index (range from 0 to GetNumComponentsInFormat()) to
// the absolute component index (range 0 to 3).
static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::Sequential2AbsoluteComponentIndex(DXGI_FORMAT Format, UINT SequentialComponentIndex)`
- `static bool D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::CanBeCastEvenFullyTyped(DXGI_FORMAT Format, D3D_FEATURE_LEVEL fl)`
- `static UINT8 D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetAddressingBitsPerAlignedSize(DXGI_FORMAT Format)`
- `static DXGI_FORMAT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetParentFormat(DXGI_FORMAT Format)`
- `static const DXGI_FORMAT* D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetFormatCastSet(DXGI_FORMAT Format)`
- `static D3D_FORMAT_LAYOUT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetLayout(DXGI_FORMAT Format)`
- `static D3D_FORMAT_TYPE_LEVEL D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetTypeLevel(DXGI_FORMAT Format)`
- `static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetBitsPerUnit(DXGI_FORMAT Format)`
- `static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetBitsPerUnitThrow(DXGI_FORMAT Format)`
- `static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetBitsPerElement(DXGI_FORMAT Format)`
- `// Legacy function used to support D3D10on9 only. Do not use.
static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetWidthAlignment(DXGI_FORMAT Format)`
- `static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetHeightAlignment(DXGI_FORMAT Format)`
- `static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetDepthAlignment(DXGI_FORMAT Format)`
- `static BOOL D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::Planar(DXGI_FORMAT Format)`
- `static BOOL D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::NonOpaquePlanar(DXGI_FORMAT Format)`
- `static BOOL D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::YUV(DXGI_FORMAT Format)`
- `static BOOL D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::Opaque(DXGI_FORMAT Format)`
- `static bool D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::FamilySupportsStencil(DXGI_FORMAT Format)`
- `static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::NonOpaquePlaneCount(DXGI_FORMAT Format)`
- `static BOOL D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::DX9VertexOrIndexFormat(DXGI_FORMAT Format)`
- `static BOOL D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::DX9TextureFormat(DXGI_FORMAT Format)`
- `static BOOL D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::FloatNormTextureFormat(DXGI_FORMAT Format)`
- `static bool D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::DepthOnlyFormat(DXGI_FORMAT format)`
- `static UINT8 D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetPlaneCount(DXGI_FORMAT Format)`
- `static bool D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::MotionEstimatorAllowedInputFormat(DXGI_FORMAT Format)`
- `static bool D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::SupportsSamplerFeedback(DXGI_FORMAT Format)`
- `static bool D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::DecodeHistogramAllowedForOutputFormatSupport(DXGI_FORMAT Format)`
- `static UINT8 D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetPlaneSliceFromViewFormat(DXGI_FORMAT ResourceFormat, DXGI_FORMAT ViewFormat)`
- `static bool D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::FloatAndNotFloatFormats(DXGI_FORMAT FormatA, DXGI_FORMAT FormatB)`
- `static bool D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::SNORMAndUNORMFormats(DXGI_FORMAT FormatA, DXGI_FORMAT FormatB)`
- `static bool D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::ValidCastToR32UAV(DXGI_FORMAT from, DXGI_FORMAT to)`
- `static bool D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::IsSupportedTextureDisplayableFormat(DXGI_FORMAT, bool bMediaFormatOnly)`
- `static D3D_FORMAT_COMPONENT_INTERPRETATION D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetFormatComponentInterpretation(DXGI_FORMAT Format, UINT AbsoluteComponentIndex)`
- `static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetBitsPerComponent(DXGI_FORMAT Format, UINT AbsoluteComponentIndex)`
- `static D3D_FORMAT_COMPONENT_NAME D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetComponentName(DXGI_FORMAT Format, UINT AbsoluteComponentIndex)`
- `static HRESULT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::CalculateExtraPlanarRows(DXGI_FORMAT format, UINT plane0Height, _Out_ UINT& totalHeight)`
- `static HRESULT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::CalculateMinimumRowMajorRowPitch(DXGI_FORMAT Format, UINT Width, _Out_ UINT& RowPitch)`
- `static HRESULT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::CalculateMinimumRowMajorSlicePitch(DXGI_FORMAT Format, UINT ContextBasedRowPitch, UINT Height, _Out_ UINT& SlicePitch)`
- `static void D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetYCbCrChromaSubsampling(DXGI_FORMAT Format, _Out_ UINT& HorizontalSubsampling, _Out_ UINT& VerticalSubsampling)`
- `static HRESULT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::CalculateResourceSize(UINT width, UINT height, UINT depth, DXGI_FORMAT format, UINT mipLevels, UINT subresources, _Out_ SIZE_T& totalByteSize, _Out_writes_opt_(subresources) D3D12_MEMCPY_DEST* pDst = nullptr)`
- `static void D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetTileShape(D3D12_TILE_SHAPE* pTileShape, DXGI_FORMAT Format, D3D12_RESOURCE_DIMENSION Dimension, UINT SampleCount)`
- `static void D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::Get4KTileShape(D3D12_TILE_SHAPE* pTileShape, DXGI_FORMAT Format, D3D12_RESOURCE_DIMENSION Dimension, UINT SampleCount)`
- `static void D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetMipDimensions(UINT8 mipSlice, _Inout_ UINT64* pWidth, _Inout_opt_ UINT64* pHeight = nullptr, _Inout_opt_ UINT64* pDepth = nullptr)`
- `static void D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetPlaneSubsampledSizeAndFormatForCopyableLayout(UINT PlaneSlice, DXGI_FORMAT Format, UINT Width, UINT Height, _Out_ DXGI_FORMAT& PlaneFormat, _Out_ UINT& MinPlanePitchWidth, _Out_ UINT& PlaneWidth, _Out_ UINT& PlaneHeight)`
- `static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetDetailTableIndex(DXGI_FORMAT Format)`
- `static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetDetailTableIndexNoThrow(DXGI_FORMAT Format)`
- `static UINT D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetDetailTableIndexThrow(DXGI_FORMAT Format)`
- `static bool D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::SupportsDepth(DXGI_FORMAT Format)`
- `static bool D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::SupportsStencil(DXGI_FORMAT Format)`
- `private:
static const FORMAT_DETAIL* D3D12_PROPERTY_LAYOUT_FORMAT_TABLE::GetFormatDetail(DXGI_FORMAT Format)`
@@ -0,0 +1,42 @@
# Juliet\src\Graphics\D3D12\D3D12CommandList
## Source Files
- Header: `Juliet\src\Graphics\D3D12\D3D12CommandList.h`
- Source: `Juliet\src\Graphics\D3D12\D3D12CommandList.cpp`
## AI Description
*No AI description generated yet.*
## Symbols
### Namespace `Juliet::D3D12`
#### Classes, Structs & Unions
- `struct D3D12CommandListBaseData`
- `struct D3D12CopyCommandListData`
- `struct D3D12GraphicsCommandListData`
- `struct D3D12PresentData`
- `struct D3D12CommandList`
#### Functions & Methods
- `extern CommandList* AcquireCommandList(NonNullPtr<GPUDriver> driver, QueueType queueType)`
- `extern bool SubmitCommandLists(NonNullPtr<CommandList> commandList)`
- `extern void SetViewPort(NonNullPtr<CommandList> commandList, const GraphicsViewPort& viewPort)`
- `extern void SetScissorRect(NonNullPtr<CommandList> commandList, const Rectangle& rectangle)`
- `extern void SetBlendConstants(NonNullPtr<CommandList> commandList, FColor blendConstants)`
- `extern void SetBlendConstants(NonNullPtr<CommandList> commandList, FColor blendConstants)`
- `extern void SetStencilReference(NonNullPtr<CommandList> commandList, uint8 reference)`
- `extern void SetIndexBuffer(NonNullPtr<CommandList> commandList, NonNullPtr<GraphicsBuffer> buffer,
IndexFormat format, size_t indexCount, index_t offset)`
- `extern void SetPushConstants(NonNullPtr<CommandList> commandList, ShaderStage stage, uint32 rootParameterIndex,
uint32 numConstants, const void* constants)`
### Namespace `Juliet::D3D12::Internal`
#### Functions & Methods
- `extern void SetDescriptorHeaps(NonNullPtr<D3D12CommandList> commandList)`
- `extern void DestroyCommandList(NonNullPtr<D3D12CommandList> commandList)`
- `extern bool CleanCommandList(NonNullPtr<D3D12Driver> driver, NonNullPtr<D3D12CommandList> commandList, bool cancel)`
- `extern void TrackGraphicsPipeline(NonNullPtr<D3D12CommandList> commandList, NonNullPtr<D3D12GraphicsPipeline> pipeline)`
- `extern void TrackTexture(NonNullPtr<D3D12CommandList> commandList, NonNullPtr<D3D12Texture> texture)`
@@ -0,0 +1,26 @@
# Juliet\src\Graphics\D3D12\D3D12Common
## Source Files
- Header: `Juliet\src\Graphics\D3D12\D3D12Common.h`
- Source: `Juliet\src\Graphics\D3D12\D3D12Common.cpp`
## AI Description
The `Juliet::D3D12` module manages DirectStorage 12 descriptor pools and CPU-side handle indexing. It provides thread-safe mechanisms for allocating, assigning, and releasing resource handles across different heap types (RTV, DSV, SRV) to optimize GPU memory access patterns within the Juliet graphics engine.
## Symbols
### Namespace `Juliet::D3D12`
#### Classes, Structs & Unions
- `struct D3D12StagingDescriptorPool`
- `struct D3D12StagingDescriptor`
### Namespace `Juliet::D3D12::Internal`
#### Functions & Methods
- `extern D3D12StagingDescriptorPool* CreateStagingDescriptorPool(NonNullPtr<D3D12Driver> driver, D3D12_DESCRIPTOR_HEAP_TYPE type)`
- `extern bool AssignStagingDescriptor(NonNullPtr<D3D12Driver> driver, D3D12_DESCRIPTOR_HEAP_TYPE type,
D3D12StagingDescriptor& outDescriptor)`
- `extern void ReleaseStagingDescriptor(NonNullPtr<D3D12Driver> driver, D3D12StagingDescriptor& cpuDescriptor)`
- `extern void DestroyStagingDescriptorPool(NonNullPtr<D3D12StagingDescriptorPool> pool)`
@@ -0,0 +1,30 @@
# Juliet\src\Graphics\D3D12\D3D12DescriptorHeap
## Source Files
- Header: `Juliet\src\Graphics\D3D12\D3D12DescriptorHeap.h`
- Source: `Juliet\src\Graphics\D3D12\D3D12DescriptorHeap.cpp`
## AI Description
This C++ component manages DirectX 12 descriptor heaps for efficient GPU resource binding. It provides structures and functions to create pools of reusable descriptor stacks, handle allocation from free lists or creation via the driver, and release resources back to memory while tracking usage indices. The design includes internal arena management and type-specific initialization flags like shader visibility to optimize performance in gaming contexts within a larger framework architecture.
## Symbols
### Namespace `Juliet::D3D12::Internal`
#### Classes, Structs & Unions
- `struct D3D12DescriptorHeap`
- `struct D3D12Descriptor`
- `struct D3D12DescriptorHeapPool`
#### Functions & Methods
- `extern void CreateDescriptorHeapPool(NonNullPtr<D3D12Driver> driver, D3D12DescriptorHeapPool& heapPool,
D3D12_DESCRIPTOR_HEAP_TYPE type, uint32 count)`
- `extern void DestroyDescriptorHeapPool(D3D12DescriptorHeapPool& pool)`
- `extern D3D12DescriptorHeap* CreateDescriptorHeap(NonNullPtr<D3D12Driver> driver, NonNullPtr<Arena> arena,
D3D12_DESCRIPTOR_HEAP_TYPE type, uint32 count, bool isStaging)`
- `extern void DestroyDescriptorHeap(NonNullPtr<D3D12DescriptorHeap> heap)`
- `extern D3D12DescriptorHeap* AcquireSamplerHeapFromPool(NonNullPtr<D3D12Driver> d3d12Driver)`
- `extern void ReturnSamplerHeapToPool(NonNullPtr<D3D12Driver> d3d12Driver, NonNullPtr<D3D12DescriptorHeap> heap)`
- `extern bool AssignDescriptor(D3D12DescriptorHeap* heap, D3D12Descriptor& outDescriptor)`
- `extern void ReleaseDescriptor(const D3D12Descriptor& descriptor)`
@@ -0,0 +1,79 @@
# Juliet\src\Graphics\D3D12\D3D12GraphicsDevice
## Source Files
- Header: `Juliet\src\Graphics\D3D12\D3D12GraphicsDevice.h`
- Source: `Juliet\src\Graphics\D3D12\D3D12GraphicsDevice.cpp`
## AI Description
Based on the code snippet you provided and its context (likely a framework like **Juliet** or a similar cross-platform DirectX 12 backend), here is an analysis of what this block does.
### Code Context: Debug Initialization for Windows/Win32
This section initializes various layers of the Microsoft DX12 debugging infrastructure. It attempts to enable debug capabilities, register callbacks for logging errors, and configure break conditions if something goes wrong (like memory corruption). This usually runs during the driver/device creation phase.
### Key Components Analyzed
#### 1. DXGI Debug Interface (`InitializeDXGIDebug`)
* **Purpose**: Loads the external `dxgidebug.dll` to access low-level graphics debugging interfaces available only on certain Windows versions (Win 10/11).
* **Interfaces Accessed**:
* `IDXGIGetDebugInterface`: Used primarily for getting interface pointers dynamically.
* `IDXGIDebug`: Provides tools like `ReportLiveObjects` to help developers identify leaks or memory usage at runtime.
* `IDXGIInfoQueue`: Manages message queues from the graphics pipeline.
* **Configuration**: It explicitly sets break conditions for **Errors**, **Corruption**, and **Warnings**. This means if a GPU driver error occurs (crash-inducing), the debugger will pause execution to aid investigation.
#### 2. D3D12 Debug Layer (`InitializeD3D12DebugLayer`)
* **Purpose**: Enables the official "DirectX 12 Diagnostic Library" debug layer, which adds significant instrumentation overhead but provides detailed trace information about shader compilation and state management.
* **Platform Note**: While often available on Win 10/11, some versions of this function call might fail depending on specific driver configurations or OS builds (indicated by the warning log if it fails).
#### 3. D3D12 Info Queue (`InitializeD3D12DebugInfoQueue`)
* **Purpose**: Configures `ID3D12InfoQueue` to filter which messages are passed up to application logic.
* **Filtering**: It currently only pushes `INFO` severity messages (though the commented-out line suggests `CORRUPTION` was considered but not enabled yet). This prevents log spam while keeping critical info.
#### 4. Message Callback Registration (`OnD3D12DebugInfoMsg`) ? Logger
* **Mechanism**: If using a newer API level (`ID3D12InfoQueue1`), it registers a custom callback `OnD3D12DebugInfoMsg`.
* **Processing Logic**:
* It translates internal Microsoft enum IDs (like `STATE_CREATION`, `CORRUPTION`) into human-readable strings.
* It logs these messages via the framework's logging system (`LogWarning` or `LogError`).
* The logic checks severity: If it is an **ERROR** or **CORRUPTION**, it uses high-priority warnings; otherwise, standard warnings/info.
#### 5. Error Handling ? Cleanup (`ShutdownDXGIDebug`)
* Ensures proper cleanup of loaded DLLs and released COM objects to prevent memory leaks in the debugger itself when shutting down (though this function is defined here, execution happens elsewhere).
### Potential Issues or Observations in Your Snippet
1. **Incomplete Line**: The snippet cuts off at `Log(LogLevel::Message, Log`. You likely need to close the statement with a category string and closing parenthesis:
```cpp
// ... inside InitializeD3D12DebugInfoLogger
driver-?D3D12Device);
} catch (...) { /* handle exception if necessary */ }
Log(LogLevel::Message, LogCategory::Graphics, "Debug info logger initialized");
#endif
```
2. **Conditional Compilation**: Notice the `#if JULIET_DEBUG` macro. This entire block will be compiled out unless DEBUG is defined. Ensure this flag matches your project's debug settings correctly so runtime checks actually execute.
3. **Platform Restrictions**:
* `dxgidebug.dll` loading fails on older Windows versions (e.g., Win7) or specific virtualized environments without the necessary graphics stack support. The code handles failure gracefully (`if (FAILED(result))`).
* `ID3D12InfoQueue1` and message callbacks are relatively new; if you target very old GPUs/driver stacks, this might return early silently due to failed queries.
### How to Use/Verify This Code
* **To Enable Debugging**: Set the build configuration flag (e.g., `JULIET_DEBUG=TRUE`).
* **Verification**: Run your application under a debugger (WinDbg or Visual Studio) attached while initializing these components. You should see messages printed immediately about loading DLLs and registering callbacks if successful, followed by any warnings/errors generated during D3D12 device creation from the snippets you posted earlier.
* **Testing Crash Recovery**: Trigger a GPU error manually in your app (e.g., access out-of-bounds memory) while this debug layer is active. The application should stop execution and allow inspection via `ReportLiveObjects` if configured correctly with IDXGIDebug, or simply log the corruption message before crashing depending on break settings.
## Symbols
### Namespace `Juliet::D3D12`
#### Classes, Structs & Unions
- `struct D3D12WindowData`
- `struct D3D12Driver`
#### Enums
- `enum class RootParameters`
### Namespace `Juliet::D3D12::Internal`
#### Functions & Methods
- `void DisposePendingResourcces(NonNullPtr<D3D12Driver> driver)`
@@ -0,0 +1,55 @@
# Juliet\src\Graphics\D3D12\D3D12GraphicsPipeline
## Source Files
- Header: `Juliet\src\Graphics\D3D12\D3D12GraphicsPipeline.h`
- Source: `Juliet\src\Graphics\D3D12\D3D12GraphicsPipeline.cpp`
## AI Description
Based on the code snippet provided, here is a summary of its functionality and analysis:
### **Purpose**
The primary function defined at the bottom (`GraphicsPipeline::Create`) creates a DirectX 12 Graphics Pipeline State Object (PSO) from high-level rendering states. It acts as an adapter layer, converting Juliet's internal data structures into `D3D12_GRAPHICS_PIPELINE_STATE_DESC` and calling the hardware-accelerated `ID3D12Device::CreateGraphicsPipelineState`.
### **Key Workflow Steps**
1. **Initialization**: Retrieves D3D12 driver handles (vertex/fragment shaders). Initializes a local structure (`psoDesc`) with shader bytecode pointers and lengths.
2. **Input Conversion**: Converts `VertexInputState` into `INPUT_ELEMENT_DESCs` if attributes exist, defining the layout of vertex data.
3. **Topology ? Primitive Setup**: Sets the primitive topology (e.g., lines, triangles) using mapping tables (`JulietToD3D12_...`).
4. **Helper Calls**: Relies on three conversion helper functions to populate state descriptors:
* `ConvertRasterizerState`: Handles culling, fill mode, etc.
* `ConvertBlendState`: Maps blend factors and write masks for color/alpha channels (supports multiple render targets).
* `ConvertDepthStencilState`: Converts depth comparison and stencil operations (front/back faces).
5. **Multisample Handling**: Calculates sample mask, count, and quality level based on the creation info (`createInfo.MultisampleState`). It sets a standard multi-sampling quality pattern if not manually specified.
6. **Format Conversion**: Translates Juliet's color formats into `D3D12` compatible RTV/DSV formats (handling both depth textures and color render targets).
7. **Root Signature Association**: Uses the driver's pre-compiled "Bindless" root signature to allow flexible state variables in shaders without explicit parameter declaration in vertex structures.
8. **Hardware Creation (`CreateGraphicsPipelineState`)**: The core call that returns an `ID3D12PipelineState`. This is where the actual pipeline logic lives on the GPU side.
9. **Error Handling**: Checks for hardware failures and logs errors to `dual-OS::Log`, cleaning up allocated resources upon failure.
### **Code Specifics ? Observations**
* **Mapping Strategy**: Extensive use of helper arrays like `JulietToD3D12_BlendFactor` and mapping functions like `ToUnderlying`. This suggests a design pattern where high-level enums are mapped to D3D's underlying integer/enum values (often 0-7 or specific constants) via tables, allowing the same logic to run across different rendering backends.
* **Independent Blending**: The code checks if there is more than one color target (`if (i ? 0)`), enabling "independent blend enable." This allows two separate sprites to be drawn on top of each other with independent blending settings, which requires the `D3D12_BLEND_ENABLE_INDEPENDENT_blend` flag in D3D12.
* **Sample Quality Heuristic**: The sample quality is set to a default standard if it exceeds single-sample count; otherwise, custom values might be required by specific games (like older PS/DS titles).
* **Unfinished Line**: The snippet cuts off mid-line at the very end (`pipeline-?PrimitiveType = createInfo.`), indicating incomplete logic for copying other pipeline properties or error states.
### **Potential Improvements / Questions**
1. **Caching**: Does this code handle GPU caching (using `D3DKBCache`)? Currently, it looks like every time a new PSO is requested, the hardware creates a fresh one unless explicitly told otherwise via `CachedPSO`. For modern games with many unique draw calls, explicit caching logic would improve performance.
2. **Static Pipeline States**: Modern D3D12 workflows often move state creation to a separate static pipeline class or function (static PSOs) rather than creating them on-the-fly per scene update if the states don't change between frames. This code seems to be doing dynamic creation, which is simpler but potentially less performant for complex scenes with many variations of blending/rasterization settings per frame in older engines like Juliet's era.
## Symbols
### Namespace `Juliet::D3D12`
#### Classes, Structs & Unions
- `struct D3D12GraphicsRootSignature`
- `struct D3D12GraphicsPipeline`
#### Functions & Methods
- `extern GraphicsPipeline* CreateGraphicsPipeline(NonNullPtr<GPUDriver> driver, const GraphicsPipelineCreateInfo& createInfo)`
- `extern void DestroyGraphicsPipeline(NonNullPtr<GPUDriver> driver, NonNullPtr<GraphicsPipeline> graphicsPipeline)`
- `extern bool UpdateGraphicsPipelineShaders(NonNullPtr<GPUDriver> driver, NonNullPtr<GraphicsPipeline> graphicsPipeline,
Shader* optional_vertexShader, Shader* optional_fragmentShader)`
### Namespace `Juliet::D3D12::Internal`
#### Functions & Methods
- `extern void ReleaseGraphicsPipeline(NonNullPtr<D3D12GraphicsPipeline> d3d12GraphicsPipeline)`
@@ -0,0 +1,12 @@
# Juliet\src\Graphics\D3D12\D3D12InternalTests
## Source Files
- Header: `Juliet\src\Graphics\D3D12\D3D12InternalTests.h`
- Source: `Juliet\src\Graphics\D3D12\D3D12InternalTests.cpp`
## AI Description
This C++ component provides D3D12 unit test utilities, including allocation management and descriptor heap testing. Designed exclusively for debug builds via JULIET_DEBUG flags, it isolates verification logic to ensure graphics system integrity without impacting production performance or runtime efficiency.
## Symbols
*No symbols detected.*
@@ -0,0 +1,23 @@
# Juliet\src\Graphics\D3D12\D3D12RenderPass
## Source Files
- Header: `Juliet\src\Graphics\D3D12\D3D12RenderPass.h`
- Source: `Juliet\src\Graphics\D3D12\D3D12RenderPass.cpp`
## AI Description
The D3D12RenderPass module bridges the Juliet rendering framework with DirectX 12. It initializes render targets and depth states via BeginRenderPass, manages pipeline binding through BindGraphicsPipeline, handles primitive drawing operations, and performs post-render cleanup in EndRenderPass to reset command list resources for reuse.
## Symbols
### Namespace `Juliet::D3D12`
#### Functions & Methods
- `extern void BeginRenderPass(NonNullPtr<CommandList> commandList, NonNullPtr<const ColorTargetInfo> colorTargetInfos,
uint32 colorTargetInfoCount, const DepthStencilTargetInfo* depthStencilTargetInfo)`
- `extern void EndRenderPass(NonNullPtr<CommandList> commandList)`
- `extern void BindGraphicsPipeline(NonNullPtr<CommandList> commandList, NonNullPtr<GraphicsPipeline> graphicsPipeline)`
- `extern void DrawPrimitives(NonNullPtr<CommandList> commandList, uint32 numVertices, uint32 numInstances,
uint32 firstVertex, uint32 firstInstance)`
- `void DrawIndexedPrimitives(NonNullPtr<CommandList> commandList, uint32 numIndices, uint32 numInstances,
uint32 firstIndex, uint32 vertexOffset, uint32 firstInstance)`
@@ -0,0 +1,20 @@
# Juliet\src\Graphics\D3D12\D3D12Shader
## Source Files
- Header: `Juliet\src\Graphics\D3D12\D3D12Shader.h`
- Source: `Juliet\src\Graphics\D3D12\D3D12Shader.cpp`
## AI Description
This D3D12 header defines a structure and factory functions for creating GPU shaders in the Juliet engine. The source allocates memory dynamically to hold shader byte code, returning it as an abstract Shader pointer while managing internal buffer stats like sampler counts within the concrete struct.
## Symbols
### Namespace `Juliet::D3D12`
#### Classes, Structs & Unions
- `struct D3D12Shader`
#### Functions & Methods
- `extern Shader* CreateShader(NonNullPtr<GPUDriver> driver, ByteBuffer shaderByteCode, ShaderCreateInfo& shaderCreateInfo)`
- `extern void DestroyShader(NonNullPtr<GPUDriver> driver, NonNullPtr<Shader> shader)`
@@ -0,0 +1,147 @@
# Juliet\src\Graphics\D3D12\D3D12SwapChain
## Source Files
- Header: `Juliet\src\Graphics\D3D12\D3D12SwapChain.h`
- Source: `Juliet\src\Graphics\D3D12\D3D12SwapChain.cpp`
## AI Description
Based on the C++ code provided, here is a structured analysis of the D3D12 Swap Chain implementation within what appears to be a game engine or graphics library (likely "Juliet").
### 1. Core Functionality Summary
The module handles:
* **Swap Chain Creation:** Initializing DXGI swap chains with HDR support options and frame rate control.
* **Texture Management:** Managing the backing D3D12 textures for each back buffer, transitioning states between Presentation (`PRESENT`) and Rendering (`RENDER_TARGET`).
* **Fence Synchronization:** Ensuring previous frames are finished before starting new ones to prevent tearing or accessing dirty buffers during rendering.
---
### 2. Detailed Code Analysis by Function
#### A. State Transition ? Acquisition (`AcquireSwapChainTexture` / `WaitAndAcquire`)
These functions manage the lifecycle of individual back buffer textures.
```cpp
// ... inside AcquireSwapChainTexture logic
barrierDesc.Type = D3D12_RESOURCE_BARRIER_TYPE_TRANSITION;
barrierDesc.Flags = D3D12_RESOURCE_BARRIER_FLAG_NONE;
barrierDesc.Transition.StateBefore = D3D12_RESOURCE_STATE_PRESENT; // Source state (from GPU)
barrierDesc.Transition.StateAfter = D3D12_RESOURCE_STATE_RENDER_TARGET; // Destination state (for CPU/GPU read/write)
// The transition barrier is issued on the command list.
d3d12CommandList-?GraphicsCommandList.CommandList-?ResourceBarrier(1, ?barrierDesc);
*swapchainTexture = reinterpret_cast?Texture*?(?windowData-?SwapChainTextureContainers[...].ActiveTexture); // Returns a pointer wrapper to access TextureDetails struct directly.
```
**Key Insight:** The code explicitly transitions the resource from `PRESENT` (owned by DXGI) back to `RENDER_TARGET`. This is standard practice because:
1. Rendering commands (`Draw`, etc.) typically operate on `RENDER_TARGET` or `COPY_SRC/DST` states depending on context, but transitioning immediately allows for faster access without additional fences if the renderer supports it.
2. It prepares the texture to be read by CPU (if using staging buffers) and written to again in subsequent frame passes via copy commands (`ResourceBarrier` with `D3D12_RESOURCE_BARRIER_FLAG_ALLOW_VISUAL_LOSS_DISCARD`).
#### B. Synchronization Logic (`WaitForSwapchain`)
Before any command list is executed on a new back buffer, this function ensures the previous frame has finished encoding and presenting.
```cpp
if (windowData-?InFlightFences[windowData-?WindowFrameCounter] != nullptr) {
if (!Wait(d3d12Driver, true, ?windowData-?InFlightFences[...], 1 JULIET_DEBUG_PARAM(...))) return false;
}
return true;
```
**Key Insight:** This checks the fence associated with the specific frame being processed. If a fence exists (meaning previous work is pending), it waits for that fence to signal completion before proceeding.
#### C. Format Resolution ? Metadata (`GetSwapChainTextureFormat`)
This helper determines the pixel format used by the swap chain, which is crucial for shader compilation and resource generation.
```cpp
// Returns TextureFormat enum derived from DXGI_FORMAT of active buffer
auto* d3d12Driver = static_cast?D3D12Driver*?(driver.Get());
return windowData-?SwapChainTextureContainers[windowData-?WindowFrameCounter].Header.CreateInfo.Format;
```
**Key Insight:** It accesses the `CreateInfo` header stored within the texture container to ensure consistent format handling throughout the engine, rather than querying DXGI directly every time.
#### D. Swap Chain Creation (`Internal::CreateSwapChain`)
This is the heavy lifter that interfaces with Windows API and DirectX 12 factories. Notable features:
**1. Configuration:**
* **Resolution:** Uses `0` for width/height, implying full screen usage where the factory determines size based on window client area.
* **Present Mode ? Composition:** Supports SDR (`BG8`) or HDR via a mapping table `SwapchainCompositionToColorSpace`. It dynamically sets color space and format (e.g., RGB10A2 for HDR).
* **Tearing Support:** Checks `driver-?IsTearingSupported` to set the `DXGI_SWAP_CHAIN_FLAG_ALLOW_TEARING` flag if present, preventing frame skips when V-Sync is off.
**2. Factory Interactions ? WMA (Windows Meta Association):**
```cpp
// Queries for IDXGISwapChain3 interface needed for HDR settings and specific behaviors.
IDXGISwapChain3* swapChain3 = nullptr;
...
swapChain-?QueryInterface(IID_IDXGISwapChain3, ...); // Note: The original CreateSwapChainForHwnd returns a 1 pointer usually, but here it queries then releases the old one?
// Correction in logic analysis: The code does 'query', assigns to swapChain3 variable, and calls Release on swapChain immediately. This implies swapChain returned by QueryInterface was temporary or they are managing two pointers (original + queried) briefly before swapping roles.
if (!parentFactory-?MakeWindowAssociation(windowHandle, DXGI_MWA_NO_WINDOW_CHANGES))
Log(LogLevel::Warning, ... "Cannot handle window resizing"); // IMPORTANT: Disables automatic resize messages to D3D12 logic?
```
**Key Insight on WMA:** The code calls `DXGI_MWA_NO_WINDOW_CHANGES`. This tells the system **not** to send a `WM_SIZE` message when the user resizes or moves the window.
* *Why?* If the app handles resizing by simply calling `Resize` functions internally without checking Win32 events, this is an optimization (avoiding extra logic). However, if dynamic re-resizing is needed externally, this needs to be reconsidered based on how else size changes are handled in your engine.
**3. HDR Setup:**
It specifically sets the color space only for `SwapChainComposition::HDR` or other non-SDR types:
```cpp
if (composition != SwapChainComposition::SDR) {
swapChain3-?SetColorSpace1(SwapchainCompositionToColorSpace[...]);
}
```
---
### 3. Critical Logic Check ? Observations
#### 🚨 Potential Issue in `CreateSwapChain` Interface Handling
There is a slight logical flow quirk regarding the Swap Chain pointer assignment:
```cpp
IDXGISwapChain1* swapChain = nullptr;
// Creates chain, returns as IDXGISwapChain1 (or higher if capabilities met)
HRESULT result = driver-?DXGIFactory-?CreateSwapChainForHwnd(..., ?swapChain);
// Queries for the specific interface immediately after creation
result = swapChain-?QueryInterface(IID_IDXGISwapChain3, reinterpret_cast?void**?(?swapChain3));
swapChain-?Release(); // ?--- Releases the original pointer passed by reference?
if (FAILED(result)) { ... }
```
* **Behavior:** `CreateSwapChainForHwnd` creates an interface and returns it. The caller is expected to release *one* copy of that interface eventually. By calling `QueryInterface`, you create a new handle (`swapChain3`). If the original return value from Create doesn't support QueryInterface directly (unlikely) or if memory management isn't strict, releasing via Release() on the temporary variable might be premature depending on D3D12 ownership rules here.
* **Standard Pattern:** Usually: `Create...(?SwapChain)`, then use it until done with all interfaces required for HDR/Feature queries before doing cleanup logic in other parts of your engine's destroy sequence (like `DestroySwapChain`).
#### 🚨 Memory Management ? Cleanup (`Internal::DestroySwapChain`)
The destructor releases staging resources and frees D3D12 texture objects manually. This indicates a custom resource pool system rather than just relying on DXGI to clean up everything at shutdown, which is good for performance profiling but requires careful `Free` implementations (likely global Free lists common in Rust/Juliet ecosystems).
#### 📝 Resource Barrier Nuance
In the transition block:
```cpp
barrierDesc.Transition.pResource = ...; // Pointer math looks correct based on struct layout.
barrierDesc.Transition.Subresource = 0;
// Note: Since this is not a multi-sub-resource texture (like video textures), Subresource=0 covers everything.
```
### 4. Recommendations / Improvements
1. **Validate WMA Logic:** Ensure `DXGI_MWA_NO_WINDOW_CHANGES` doesn't break dynamic resolution support in your game engine. If the window moves/resizes but you don't update texture dimensions, it could cause black screens or crashes upon resize.
2. **Interface Management:** The immediate release of the original Swap Chain pointer after acquiring `IDXGISwapChain3` looks unusual if the engine expects to keep using generic features later without re-acquisition every time (e.g., in a destructor). Consider storing the generic interface and only converting up/down when HDR is specifically accessed or during teardown.
3. **Error Handling:** The `CreateSwapChainForHwnd` call checks for failure, but if it fails due to invalid window handle (`IsWindow` check passed earlier), ensure robust logging regarding *why* (e.g., focus lost, incompatible OS version).
### Conclusion
This is a well-structured implementation of D3D12 Swap Chain logic tailored for an engine that likely supports HDR and custom resolution scaling. The explicit fence waiting and manual state transitions indicate high control over the rendering pipeline to ensure frame timing consistency and prevent visual
## Symbols
### Namespace `Juliet::D3D12`
#### Functions & Methods
- `extern bool AcquireSwapChainTexture(NonNullPtr<CommandList> commandList, NonNullPtr<Window> window, Texture** swapChainTexture)`
- `extern bool WaitAndAcquireSwapChainTexture(NonNullPtr<CommandList> commandList, NonNullPtr<Window> window, Texture** swapChainTexture)`
- `extern bool WaitForSwapchain(NonNullPtr<GPUDriver> driver, NonNullPtr<Window> window)`
- `extern TextureFormat GetSwapChainTextureFormat(NonNullPtr<GPUDriver> driver, NonNullPtr<Window> window)`
### Namespace `Juliet::D3D12::Internal`
#### Functions & Methods
- `extern bool CreateSwapChain(NonNullPtr<D3D12Driver> driver, NonNullPtr<D3D12WindowData> windowData,
SwapChainComposition composition, PresentMode presentMode)`
- `extern void DestroySwapChain(NonNullPtr<D3D12Driver> driver, NonNullPtr<D3D12WindowData> windowData)`
@@ -0,0 +1,32 @@
# Juliet\src\Graphics\D3D12\D3D12Synchronization
## Source Files
- Header: `Juliet\src\Graphics\D3D12\D3D12Synchronization.h`
- Source: `Juliet\src\Graphics\D3D12\D3D12Synchronization.cpp`
## AI Description
*No AI description generated yet.*
## Symbols
### Namespace `Juliet::D3D12`
#### Classes, Structs & Unions
- `struct D3D12Fence`
#### Functions & Methods
- `extern bool WaitUntilGPUIsIdle(NonNullPtr<GPUDriver> driver)`
- `extern bool Wait(NonNullPtr<GPUDriver> driver, bool waitForAll, Fence* const* fences,
uint32 numFences JULIET_DEBUG_PARAM(String querier))`
- `extern bool QueryFence(NonNullPtr<GPUDriver> driver, NonNullPtr<Fence> fence)`
- `extern void ReleaseFence(NonNullPtr<GPUDriver> driver, NonNullPtr<Fence> fence JULIET_DEBUG_PARAM(String querier))`
### Namespace `Juliet::D3D12::Internal`
#### Functions & Methods
- `extern void ResourceBarrier(NonNullPtr<D3D12CommandList> commandList, D3D12_RESOURCE_STATES sourceState,
D3D12_RESOURCE_STATES destinationState, ID3D12Resource* resource,
uint32 subresourceIndex, bool needsUavBarrier)`
- `extern D3D12Fence* AcquireFence(NonNullPtr<D3D12Driver> driver JULIET_DEBUG_PARAM(String querier))`
- `extern void DestroyFence(NonNullPtr<D3D12Fence> fence)`

Some files were not shown because too many files have changed in this diff Show More