<![CDATA[Esenthel Forum - All Forums]]> https://esenthel.com/forum/ Sun, 31 May 2026 20:44:27 +0000 MyBB <![CDATA[[UI Editor] Feature requests]]> https://esenthel.com/forum/showthread.php?tid=11822 Thu, 28 May 2026 09:41:25 +0000 https://esenthel.com/forum/showthread.php?tid=11822
I'd like to propose two additions to the GUI editor window:

1. Multi-Selection Editing
When multiple UI elements are selected, params that are unique per element (Name, Description, and Text) should be greyed out and non-editable. Params that are common across the selection should remain editable. Where selected elements have differing values for a shared param, display "–" as a placeholder to indicate the values are not uniform amongst the selected elements

This would significantly reduce friction when working on complex interfaces. Currently, when adjusting shared properties like scale or size requires selecting all elements, applying the change, deselecting, then selecting an individual element to verify if the param is correct, and repeating. Multi-selection editing would eliminate that process.

2. Configurable Insert Templates for UI Elements
Add a right-click context menu to entries in the standard UI element list. This menu would open a template configuration window where the default parameters for that element type can be set (width, height, text alignment, text size, and skin override).

Buttons are currently inserted with a default width of 0.270, height of 0.060, text alignment 0, text size 1, and an empty skin override. These defaults probably won't match the design of a custom button, meaning every newly placed button requires manual adjustment (although the skin could be configured in an application element). With configurable templates, a developer could define defaults that match their project's design once, rather than correcting values on each new element placed in different GUI's.

Thanks for considering these! Would love to hear feedback!]]>
I'd like to propose two additions to the GUI editor window:

1. Multi-Selection Editing
When multiple UI elements are selected, params that are unique per element (Name, Description, and Text) should be greyed out and non-editable. Params that are common across the selection should remain editable. Where selected elements have differing values for a shared param, display "–" as a placeholder to indicate the values are not uniform amongst the selected elements

This would significantly reduce friction when working on complex interfaces. Currently, when adjusting shared properties like scale or size requires selecting all elements, applying the change, deselecting, then selecting an individual element to verify if the param is correct, and repeating. Multi-selection editing would eliminate that process.

2. Configurable Insert Templates for UI Elements
Add a right-click context menu to entries in the standard UI element list. This menu would open a template configuration window where the default parameters for that element type can be set (width, height, text alignment, text size, and skin override).

Buttons are currently inserted with a default width of 0.270, height of 0.060, text alignment 0, text size 1, and an empty skin override. These defaults probably won't match the design of a custom button, meaning every newly placed button requires manual adjustment (although the skin could be configured in an application element). With configurable templates, a developer could define defaults that match their project's design once, rather than correcting values on each new element placed in different GUI's.

Thanks for considering these! Would love to hear feedback!]]> <![CDATA[May 2026]]> https://esenthel.com/forum/showthread.php?tid=11819 Tue, 05 May 2026 05:03:20 +0000 https://esenthel.com/forum/showthread.php?tid=11819 -fixed physics tutorials not compiling due to different Box constructor
-added more Edge2 functions
-"Behind" shader now correctly processes "Blend" Materials]]> -fixed physics tutorials not compiling due to different Box constructor
-added more Edge2 functions
-"Behind" shader now correctly processes "Blend" Materials]]> <![CDATA[Lag compensation]]> https://esenthel.com/forum/showthread.php?tid=11816 Wed, 22 Apr 2026 01:28:27 +0000 https://esenthel.com/forum/showthread.php?tid=11816
Networking: Lag Compensation + Physics Rollback
Transport-agnostic server-authoritative simulation layer (lag-compensation branch)

A commercial-grade networking substrate built from scratch under *Engine/Net/*. Two independent tiers of temporal correction, built using shipped-game references:
  • Tier 1 — selective hitbox rewind (Photon Fusion 2 / Source / CS:GO model). Each server tick, every replicated actor contributes a flat list of hitbox samples into a 256-tick ring buffer (~4.27 s @ 60 Hz). Spatial queries take a *(tick, frac)* pair, linearly interpolate the two bracketing snapshots, and test against the interpolated hitboxes. The live gameplay scene is never touched — perfect for hitscan / melee where you only need “where was this limb when the client fired”.
  • Tier 2 — full PhysX rewind + resimulation (UE5 networked-physics model). Snapshots pose / linear + angular velocity / kinematic / sleeping flags for every tracked *Actor* each tick; on demand restores them and drives *Physics.stepOnce(dt)* forward to catch up to the current tick. A *RollbackGuard* (TLS depth counter) is held active for the resim window so gameplay / animation / audio code that checks *RollbackGuard::active()* can suppress side-effects (event fire, notifies, SFX) during replay.

All modules are unconditionally compiled — no CMake flag, no opt-out, no extra link cost (the dependency surface is zero — pure C++, no third-party libraries). The transport layer is abstract: the engine ships *LoopbackTransport* (in-process queue) and *FakeLatencyTransport* (wraps any transport with configurable latency / jitter / loss), plus sketches for *ENetTransport* and a multi-hop *ForwardingTransport* in *Engine/H/Net/NetTransport.h* header comments. User projects subclass *INetTransport* and forward to ENet / Steam Sockets / WebRTC / whatever fits their deployment.

Module layout:
  • *Net/NetTick.h/cpp* — *TickSeq* (*ULong*) + *NetTick{seq, frac}* shared tick + sub-tick type
  • *Net/NetClock.h/cpp* — NTP-style clock sync; rolling 5-sample median-of-offset + RTT + jitter; monotonic server timeline
  • *Net/NetTransport.h/cpp* — *INetTransport* abstract + *LoopbackTransport* + *FakeLatencyTransport* + ENet / multi-hop sketches
  • *Net/NetObject.h/cpp* — *INetReplicated* interface, *NetBase* convenience, *NET_REGISTER_CLASS* factory, *HitboxSample*, *NetWriter* / *NetReader* byte-buffer codecs with opt-in *putUIntPacked* (varint) / *putPosQ16* (quantized position, 6 B vs 12 B) compression helpers
  • *Net/InputCommand.h/cpp* — *InputCommand* POD + *InputBuffer* (client redundancy — re-sends last N unacked cmds) + *InputQueue* (server per-connection, wrap-safe *UShort* seq compare)
  • *Net/NetReplicator.h/cpp* — spawn / despawn / snapshot build + apply / input routing / ping-pong / per-connection relevance callback hook
  • *Net/LagCompensation.h/cpp* — Tier 1 256-tick hitbox ring; *ray* / *sweep* / *sweepArc* / *overlap* / *fetchInterp* CPU-analytic queries (sphere + capsule + box) with *(tick, frac)* OR *(real_time)* addressing for clustered servers
  • *Net/RollbackGuard.h/cpp* — thread-local depth counter; *RollbackGuard::active()* callable from gameplay / anim code
  • *Net/NetRollback.h/cpp* — Tier 2 snapshot / restore *Actor* state, *Physics.stepOnce*-driven resim, 8-tick default cap (user-configurable), *InputReplayFn* hook, *AnimCaptureFn* / *AnimRestoreFn* hooks for bone-sourced hitboxes

~3,200 lines of new engine code across 18 files, zero third-party links, zero *#ifdef*s outside platform branches.

Quick start (single-process, both sides in one *Update()* — this is how every category-20 tutorial is structured):

Code:
// --- Replicated actor ---
struct Target : NetBase
{
Vec pos;
NetClassID netClassId()C override { return 0x54475431u; /* 'TGT1' */ }
void netSerialize  (NetWriter &w, UInt fields)C override { w.putVec(pos); }
void netDeserialize(NetReader &r, UInt fields)  override { pos = r.getVec(); }
void netHitboxes(Memc<HitboxSample> &out)C override
{
HitboxSample &s = out.New();
s.shape = HITBOX_SPHERE;
s.group = 0x0001;
s.half_ext.set(0.3f, 0.3f, 0.3f);
s.xform.identity(); s.xform.pos = pos;
}
};
NET_REGISTER_CLASS(Target, 0x54475431u);

// --- Server ---
NetReplicator SvrRep;  NetClock SvrClk;  LagComp SvrLag;
SvrClk.initServer(60);
SvrRep.serverInit(&transport, &SvrClk);

each_tick:
SvrRep.serverDrainInputs();       // apply client inputs via INetReplicated::netApplyInput
// ...gameplay simulation...
SvrLag.recordTick(SvrRep, tick, Time.curTime());
if(tick % 3 == 0) SvrRep.sendSnapshots(tick);   // 20 Hz @ 60 tick

on_client_fire(from, to, client_tick):
LagHit h;
if(SvrLag.ray(client_tick, 0.0f, from, to, h))
apply_damage(h.owner, h.owner_idx);

// --- Client ---
NetReplicator CliRep;  NetClock CliClk;  InputBuffer CliInputs;
CliClk.initClient(60);
CliRep.clientInit(&transport, &CliClk, /*server_conn*/1);

each_frame:
CliRep.sendPingMaybe();           // periodic NTP sync
CliRep.update(Time.curTime());    // drains spawn/despawn/snapshot/pong
Vec input = sample_keyboard();
pawn->predict(input);             // local prediction on owned pawn
CliInputs.push(input, buttons, CliClk.tick());
CliInputs.sendTo(CliRep);         // redundant — includes last N unacked
CliInputs.ack(CliRep.lastAckedSeq());

on_fire(from, to):
// Ship the compensation tick with the fire cmd so the server can rewind
// to exactly what this client was seeing.
fire_cmd.compensation_tick = CliRep.lastSnapshotTick();

Tier 2 (physics rewind) — only when you actually need resim; most games won't:

NetRollback SvrRoll;
SvrRoll.init(1.0f/60.0f, /*max_resim=*/8);
for(Actor *a : dynamic_physics_actors) SvrRoll.track(*a);

on_physics_step_completed(tick):
SvrRoll.recordTick(tick);

on_authoritative_correction(target_tick):
SvrRoll.rewindAndResimulate(target_tick, currentTick, replayInputs, user);

Physics engine touch points — two small, surgical additions; everything else is pure add-on:
  • *Physics.stepOnce(Flt dt)* — direct *simulate* + *fetchResults* with no accumulator, no *simulation_step_completed* callback. This is what drives Tier 2 resim. Safe only between frames (after *stopSimulation()* or inside *WorldManager::physics_update()*).
  • *Time.rollbackDt(Flt dt)* — thread-local override for *Time.d()*. When *> 0*, *Time.d()* returns it instead of the real frame delta. Set automatically by *NetRollback::rewindAndResimulate* per resim tick to the recorded *dt_used*, so animation code (*Motion::updateAuto*, *AnimatedSkeleton::animate*) replays at the exact dt the forward sim used — deterministic bone poses during rewind.

Animation sync hooks for bone-driven hitboxes — if your game's hitboxes are attached to *AnimatedSkeleton* bones (limbs parented to bone slots), both forward-sim animation and rollback-resim animation must reproduce the same per-tick bone poses. Two engine hooks pair them:

  1. Forward sim — set *Time.rollbackDt(icf.timeDeltaPhysics)* before animating each player tick, so *Motion::updateAuto* uses the physics dt instead of the variable frame dt. Restore with *Time.rollbackDt(0)*.
  2. Rollback resim — pass *NetRollback::setAnimCallbacks(cap, rest, user)*. *AnimCaptureFn* serialises every tracked *Motion* (via *Motion::save* or direct field writes) into a small opaque blob per tick (~64 B per motion × N motions × 256 ticks — fits easily). *AnimRestoreFn* does the inverse before the user's *InputReplayFn* fires, so replayed animation code starts from the correct *Motion.time* / *Motion.blend*. Pair this with *if(RollbackGuard::active()) return;* at the top of anim-event consumers (weapon clash SFX, hit sparks) so they don't re-fire during replay.


Includes 7 more tutorials.
[Image: Screenshot-from-2026-04-21-21-12-54.png]

in this fork:
https://github.com/DrewGilpin/EsenthelEngine]]>
Networking: Lag Compensation + Physics Rollback
Transport-agnostic server-authoritative simulation layer (lag-compensation branch)

A commercial-grade networking substrate built from scratch under *Engine/Net/*. Two independent tiers of temporal correction, built using shipped-game references:
  • Tier 1 — selective hitbox rewind (Photon Fusion 2 / Source / CS:GO model). Each server tick, every replicated actor contributes a flat list of hitbox samples into a 256-tick ring buffer (~4.27 s @ 60 Hz). Spatial queries take a *(tick, frac)* pair, linearly interpolate the two bracketing snapshots, and test against the interpolated hitboxes. The live gameplay scene is never touched — perfect for hitscan / melee where you only need “where was this limb when the client fired”.
  • Tier 2 — full PhysX rewind + resimulation (UE5 networked-physics model). Snapshots pose / linear + angular velocity / kinematic / sleeping flags for every tracked *Actor* each tick; on demand restores them and drives *Physics.stepOnce(dt)* forward to catch up to the current tick. A *RollbackGuard* (TLS depth counter) is held active for the resim window so gameplay / animation / audio code that checks *RollbackGuard::active()* can suppress side-effects (event fire, notifies, SFX) during replay.

All modules are unconditionally compiled — no CMake flag, no opt-out, no extra link cost (the dependency surface is zero — pure C++, no third-party libraries). The transport layer is abstract: the engine ships *LoopbackTransport* (in-process queue) and *FakeLatencyTransport* (wraps any transport with configurable latency / jitter / loss), plus sketches for *ENetTransport* and a multi-hop *ForwardingTransport* in *Engine/H/Net/NetTransport.h* header comments. User projects subclass *INetTransport* and forward to ENet / Steam Sockets / WebRTC / whatever fits their deployment.

Module layout:
  • *Net/NetTick.h/cpp* — *TickSeq* (*ULong*) + *NetTick{seq, frac}* shared tick + sub-tick type
  • *Net/NetClock.h/cpp* — NTP-style clock sync; rolling 5-sample median-of-offset + RTT + jitter; monotonic server timeline
  • *Net/NetTransport.h/cpp* — *INetTransport* abstract + *LoopbackTransport* + *FakeLatencyTransport* + ENet / multi-hop sketches
  • *Net/NetObject.h/cpp* — *INetReplicated* interface, *NetBase* convenience, *NET_REGISTER_CLASS* factory, *HitboxSample*, *NetWriter* / *NetReader* byte-buffer codecs with opt-in *putUIntPacked* (varint) / *putPosQ16* (quantized position, 6 B vs 12 B) compression helpers
  • *Net/InputCommand.h/cpp* — *InputCommand* POD + *InputBuffer* (client redundancy — re-sends last N unacked cmds) + *InputQueue* (server per-connection, wrap-safe *UShort* seq compare)
  • *Net/NetReplicator.h/cpp* — spawn / despawn / snapshot build + apply / input routing / ping-pong / per-connection relevance callback hook
  • *Net/LagCompensation.h/cpp* — Tier 1 256-tick hitbox ring; *ray* / *sweep* / *sweepArc* / *overlap* / *fetchInterp* CPU-analytic queries (sphere + capsule + box) with *(tick, frac)* OR *(real_time)* addressing for clustered servers
  • *Net/RollbackGuard.h/cpp* — thread-local depth counter; *RollbackGuard::active()* callable from gameplay / anim code
  • *Net/NetRollback.h/cpp* — Tier 2 snapshot / restore *Actor* state, *Physics.stepOnce*-driven resim, 8-tick default cap (user-configurable), *InputReplayFn* hook, *AnimCaptureFn* / *AnimRestoreFn* hooks for bone-sourced hitboxes

~3,200 lines of new engine code across 18 files, zero third-party links, zero *#ifdef*s outside platform branches.

Quick start (single-process, both sides in one *Update()* — this is how every category-20 tutorial is structured):

Code:
// --- Replicated actor ---
struct Target : NetBase
{
Vec pos;
NetClassID netClassId()C override { return 0x54475431u; /* 'TGT1' */ }
void netSerialize  (NetWriter &w, UInt fields)C override { w.putVec(pos); }
void netDeserialize(NetReader &r, UInt fields)  override { pos = r.getVec(); }
void netHitboxes(Memc<HitboxSample> &out)C override
{
HitboxSample &s = out.New();
s.shape = HITBOX_SPHERE;
s.group = 0x0001;
s.half_ext.set(0.3f, 0.3f, 0.3f);
s.xform.identity(); s.xform.pos = pos;
}
};
NET_REGISTER_CLASS(Target, 0x54475431u);

// --- Server ---
NetReplicator SvrRep;  NetClock SvrClk;  LagComp SvrLag;
SvrClk.initServer(60);
SvrRep.serverInit(&transport, &SvrClk);

each_tick:
SvrRep.serverDrainInputs();       // apply client inputs via INetReplicated::netApplyInput
// ...gameplay simulation...
SvrLag.recordTick(SvrRep, tick, Time.curTime());
if(tick % 3 == 0) SvrRep.sendSnapshots(tick);   // 20 Hz @ 60 tick

on_client_fire(from, to, client_tick):
LagHit h;
if(SvrLag.ray(client_tick, 0.0f, from, to, h))
apply_damage(h.owner, h.owner_idx);

// --- Client ---
NetReplicator CliRep;  NetClock CliClk;  InputBuffer CliInputs;
CliClk.initClient(60);
CliRep.clientInit(&transport, &CliClk, /*server_conn*/1);

each_frame:
CliRep.sendPingMaybe();           // periodic NTP sync
CliRep.update(Time.curTime());    // drains spawn/despawn/snapshot/pong
Vec input = sample_keyboard();
pawn->predict(input);             // local prediction on owned pawn
CliInputs.push(input, buttons, CliClk.tick());
CliInputs.sendTo(CliRep);         // redundant — includes last N unacked
CliInputs.ack(CliRep.lastAckedSeq());

on_fire(from, to):
// Ship the compensation tick with the fire cmd so the server can rewind
// to exactly what this client was seeing.
fire_cmd.compensation_tick = CliRep.lastSnapshotTick();

Tier 2 (physics rewind) — only when you actually need resim; most games won't:

NetRollback SvrRoll;
SvrRoll.init(1.0f/60.0f, /*max_resim=*/8);
for(Actor *a : dynamic_physics_actors) SvrRoll.track(*a);

on_physics_step_completed(tick):
SvrRoll.recordTick(tick);

on_authoritative_correction(target_tick):
SvrRoll.rewindAndResimulate(target_tick, currentTick, replayInputs, user);

Physics engine touch points — two small, surgical additions; everything else is pure add-on:
  • *Physics.stepOnce(Flt dt)* — direct *simulate* + *fetchResults* with no accumulator, no *simulation_step_completed* callback. This is what drives Tier 2 resim. Safe only between frames (after *stopSimulation()* or inside *WorldManager::physics_update()*).
  • *Time.rollbackDt(Flt dt)* — thread-local override for *Time.d()*. When *> 0*, *Time.d()* returns it instead of the real frame delta. Set automatically by *NetRollback::rewindAndResimulate* per resim tick to the recorded *dt_used*, so animation code (*Motion::updateAuto*, *AnimatedSkeleton::animate*) replays at the exact dt the forward sim used — deterministic bone poses during rewind.

Animation sync hooks for bone-driven hitboxes — if your game's hitboxes are attached to *AnimatedSkeleton* bones (limbs parented to bone slots), both forward-sim animation and rollback-resim animation must reproduce the same per-tick bone poses. Two engine hooks pair them:

  1. Forward sim — set *Time.rollbackDt(icf.timeDeltaPhysics)* before animating each player tick, so *Motion::updateAuto* uses the physics dt instead of the variable frame dt. Restore with *Time.rollbackDt(0)*.
  2. Rollback resim — pass *NetRollback::setAnimCallbacks(cap, rest, user)*. *AnimCaptureFn* serialises every tracked *Motion* (via *Motion::save* or direct field writes) into a small opaque blob per tick (~64 B per motion × N motions × 256 ticks — fits easily). *AnimRestoreFn* does the inverse before the user's *InputReplayFn* fires, so replayed animation code starts from the correct *Motion.time* / *Motion.blend*. Pair this with *if(RollbackGuard::active()) return;* at the top of anim-event consumers (weapon clash SFX, hit sparks) so they don't re-fire during replay.


Includes 7 more tutorials.
[Image: Screenshot-from-2026-04-21-21-12-54.png]

in this fork:
https://github.com/DrewGilpin/EsenthelEngine]]> <![CDATA[RmlUi]]> https://esenthel.com/forum/showthread.php?tid=11815 Mon, 20 Apr 2026 13:58:58 +0000 https://esenthel.com/forum/showthread.php?tid=11815
I'm not a web-dev person, but with Vibe Designing coming soon
( e.g. https://claude.ai/design ) , I think there is value in having a UI
system defined by a declarative language like HTML/CSS.

This also makes it much easier for users to mod or skin the UI if they
want. But really, it's about making it easier for the AI to do it.
Claude Code really seems to struggle with building Esenthel GUIs
programmatically that look good and have the correct font size, etc.,
but with HTML/CSS this problem doesn't exist.

I haven't profiled this, the implementation has not been optimized,
and I'm sure there is a performance penalty. That said, RmlUi is
highly regarded and is designed for games; it is not a full WebKit.

An integration of RmlUi v6.2 (MIT) as
a retained-mode HTML/CSS UI library that coexists with Esenthel's built-in
Gui system without touching it. Both run in the same frame — the native
widget set is still available for lightweight 3D-integrated controls, while
RmlUi handles HTML/CSS/animation-heavy UI (menus, HUDs, settings screens,
chat windows). A single RmlUi render backend lives inside the Engine static
library and drives RmlUi's vertex stream through the engine's existing 2D
batcher, so every renderer backend (DX11, DX12, Vulkan, OpenGL) gets RmlUi
for free with zero backend-specific code.

Game HUD tutorial
[Image: nWMwv7tq]


Using Esenthel GUI elements and RmlUi elements side-by-side tutorial
[Image: 3cB1Nk65]


Quick start:

Code:
#include "Gui/RmlUi.h"                            // EE::RmlUi::* facade

// In a single .cpp where you author Rml event listeners, DOM manipulation,
// etc. — wrap the RmlUi includes so Esenthel macros and X11 defines don't
// collide with RmlUi's template parameters and enum names:
#include "../../ThirdPartyLibs/begin.h"
#undef T1  #undef T2  #undef T3  #undef T4  #undef T5
#undef T6  #undef T7  #undef T8  #undef T9  #undef T10  #undef T11
#undef Always  #undef NotUseful
#include <RmlUi/Core.h>
#include "../../ThirdPartyLibs/end.h"

static Rml::Context         *Ctx=null;
static Rml::ElementDocument *Doc=null;

Bool Init()
{
    EE::RmlUi::Init();                                                 // install render + system interfaces
    EE::RmlUi::LoadFontFace("Data/RmlUi/LatoLatin-Regular.ttf");
    Ctx=EE::RmlUi::CreateContext();                                    // sized to D.resW()/D.resH()
    Doc=Ctx->LoadDocument("Data/RmlUi/demo.rml");
    if(Doc)Doc->Show();
    return true;
}
void Shut()   { EE::RmlUi::Shut(); }
Bool Update() {
    if(Kb.bp(KB_ESC))return false;
    Gui.update();
    EE::RmlUi::PumpInput(Ctx);                                         // Ms/Kb -> context
    EE::RmlUi::Update   (Ctx);                                         // events, animations, dirty geometry
    return true;
}
void Draw()   {
    Renderer(RenderScene);                                             // optional 3D world
    Gui.draw();                                                        // Esenthel Gui above 3D
    EE::RmlUi::Render(Ctx);                                            // RmlUi on top of everything
}

Shipped features:
  • Single-TU backend — Engine/Source/Gui/RmlUi.cpp is the only engine
    source file that includes RmlUi headers. It subclasses
    Rml::RenderInterface and Rml::SystemInterface, owns the 1×1 white
    fallback texture, and exports the EE::RmlUi:: facade used by app code.
    Macro pollution is neutralised locally: Esenthel's template-shortcut
    macros T1..T11 (from Engine/H/_/defines.h, they collide with
    robin_hood.h's template parameters) and X11's Always / NotUseful
    (not stripped by Engine/H/_/headers.h) are undefined inside the
    ThirdPartyLibs/begin.h / end.h bracket just for this one TU.
  • API-agnostic rendering — RenderGeometry feeds RmlUi's pixel-space
    vertex stream into the engine's existing 2D path. Per-vertex
    conversion goes through D.pixelToScreen(Vec2) (canonical helper; no
    hand-rolled Y-flip). D.alpha(ALPHA_MERGE) handles RmlUi's
    premultiplied RGBA (which it emits since v5). Scissor goes through
    D.clip(&engine_rect) / D.pixelToScreen(RectI). Works identically on
    DX11, DX12, Vulkan, OpenGL.
  • Untextured-path fallback — RmlUi calls RenderGeometry with
    texture=0 for solid-colour geometry. The backend binds a pre-built
    1×1 opaque-white Image so the textured shader path effectively
    degenerates to plain vertex colour. This avoids needing a separate
    colour-only code path.
  • FreeType sharing — RmlUi's default FreeType font engine is pointed
    at Esenthel's prebuilt EE_FreeType static lib via
    FREETYPE_INCLUDE_DIRS / FREETYPE_LIBRARY cache vars in
    ThirdPartyLibs/RmlUi/CMakeLists.txt, so one copy of FreeType ships in
    the final link. EE_RMLUI_USE_BUNDLED_FREETYPE=ON is an escape hatch
    if the prebuilt's config flags ever diverge from what RmlUi expects.
  • Texture upload — LoadTexture routes to Image.Import, accepting
    every format Esenthel's asset pipeline supports (BMP/PNG/JPG/JXL/WEBP/
    AVIF/HEIF/TGA/TIF/DDS/PSD/ICO/HDR). GenerateTexture uploads raw
    RGBA8 via a soft image, lock/write, row-copy, unlock, and GPU upload
    (used for the font atlas and procedural decorator textures).
  • Dual-mode input pump — EE::RmlUi::PumpInput(ctx) polls
    mouse position, mouse buttons, and wheel every frame, walks all
    256 KB_KEY values firing key down/up events on edge changes, and
    pumps text characters out of Kb.k.c. When the focused RmlUi element
    is an input field or textarea the key queue is drained so fast typing
    never drops characters; otherwise the head of the queue is peeked
    non-destructively so the built-in Gui still sees the same keys on the
    same frame.
  • Opt-in via CMake — option(EE_RMLUI "... " ON) in the root
    CMakeLists.txt, default ON on Linux x64 + Windows x64, fatal on iOS
    / Android (deferred until those platforms are tested). With
    EE_RMLUI=OFF every integration TU is empty, the
    rmlui_core / rmlui_debugger targets are not added to
    the build graph, and the tutorial targets are skipped in
    Tutorials/CMakeLists.txt.
  • Built from source — RmlUi v6.2 is vendored at
    ThirdPartyLibs/RmlUi/lib/ and compiled via subdirectory inclusion so
    rmlui_core + rmlui_debugger become Engine interface link deps.
    No prebuilt library like the other third-parties, because upstream
    ships clean CMake and the library is small. ABI-visible flags are
    forced onto both targets so they match Engine's ABI.
  • Debugger overlay — rmlui_debugger is linked automatically when
    EE_RMLUI=ON. Call Rml::Debugger::Initialise(ctx) once, then
    Rml::Debugger::SetVisible(true) (or bind to a key) to pop up the live
    inspector — Event Log, Element Info, Outlines, Data Models tabs.
  • Thin facade — Engine/H/Gui/RmlUi.h exposes only the
    EE::RmlUi:: lifecycle and helper functions. It forward-declares
    Rml::Context, ElementDocument, RenderInterface, and
    SystemInterface, so app translation units that just drive lifecycle
    do not pay to parse all of &lt;RmlUi/Core.h&gt;. App translation units
    that want event listeners, DOM mutation, or typed element access can
    include &lt;RmlUi/Core.h&gt; themselves.

Non-invasive integration — zero changes to Engine/Source/Gui/Gui.cpp,
Gui.draw, Gui.update, no new state in DisplayClass, no new
alpha mode, no new shaders. The pre-existing VI + D 2D path is the
only rendering surface used; the existing 2D shaders are the only ones
touched. The tutorial harness (Tutorials/TutorialAuto.{h,cpp},
Tutorials/stdafx.h) is unchanged. EE_RMLUI=OFF builds are
pixel-identical to pre-integration builds (verified against
Tutorial_05_Bars, Tutorial_04_BatchedDrawing,
Tutorial_12_RenderToTexture).

RCSS gotcha — RmlUi's transition/animation parser recognises tween
names as defined in Source/Core/PropertyParserAnimation.cpp. Unlike
standard CSS, it does not accept bare linear or the CSS keyword
ease; use linear-in-out and cubic-in-out (or any of the
supported {back,bounce,circular,cubic,elastic,exponential,linear,quadratic,quartic,quintic​,sine}-{in,out,in-out}
variants). Multi-transitions are comma-separated.

Deferred work:
  • Custom Rml::FontEngineInterface on top of Esenthel's Font class, so
    .pak-packaged fonts could feed RmlUi. Upstream's default FreeType
    engine is sufficient for now; TTF files ship alongside the tutorials.
  • Rml::FileInterface on EE::File — would let RmlUi resolve
    .rml / .rcss / texture paths through engine .pak archives. The
    stdio fopen default is used currently; tutorials ship plain files
    under Tutorials/Data/RmlUi/.
  • Data Binding (MVC layer via Rml::DataModelConstructor) — supported by
    the linked rmlui_core but not yet demonstrated by a tutorial.
  • Lua bindings (rmlui_lua) — disabled in the wrapper (RMLUI_LUA_BINDINGS=OFF);
    enabling would require wiring an Esenthel Lua runtime into the engine
    first.
  • Windows smoke sweep via run_smoke_test.ps1. Linux is covered
    (all five tutorials + three regression targets pass).

Available in this repo:
https://github.com/DrewGilpin/EsenthelEngine]]>
I'm not a web-dev person, but with Vibe Designing coming soon
( e.g. https://claude.ai/design ) , I think there is value in having a UI
system defined by a declarative language like HTML/CSS.

This also makes it much easier for users to mod or skin the UI if they
want. But really, it's about making it easier for the AI to do it.
Claude Code really seems to struggle with building Esenthel GUIs
programmatically that look good and have the correct font size, etc.,
but with HTML/CSS this problem doesn't exist.

I haven't profiled this, the implementation has not been optimized,
and I'm sure there is a performance penalty. That said, RmlUi is
highly regarded and is designed for games; it is not a full WebKit.

An integration of RmlUi v6.2 (MIT) as
a retained-mode HTML/CSS UI library that coexists with Esenthel's built-in
Gui system without touching it. Both run in the same frame — the native
widget set is still available for lightweight 3D-integrated controls, while
RmlUi handles HTML/CSS/animation-heavy UI (menus, HUDs, settings screens,
chat windows). A single RmlUi render backend lives inside the Engine static
library and drives RmlUi's vertex stream through the engine's existing 2D
batcher, so every renderer backend (DX11, DX12, Vulkan, OpenGL) gets RmlUi
for free with zero backend-specific code.

Game HUD tutorial
[Image: nWMwv7tq]


Using Esenthel GUI elements and RmlUi elements side-by-side tutorial
[Image: 3cB1Nk65]


Quick start:

Code:
#include "Gui/RmlUi.h"                            // EE::RmlUi::* facade

// In a single .cpp where you author Rml event listeners, DOM manipulation,
// etc. — wrap the RmlUi includes so Esenthel macros and X11 defines don't
// collide with RmlUi's template parameters and enum names:
#include "../../ThirdPartyLibs/begin.h"
#undef T1  #undef T2  #undef T3  #undef T4  #undef T5
#undef T6  #undef T7  #undef T8  #undef T9  #undef T10  #undef T11
#undef Always  #undef NotUseful
#include <RmlUi/Core.h>
#include "../../ThirdPartyLibs/end.h"

static Rml::Context         *Ctx=null;
static Rml::ElementDocument *Doc=null;

Bool Init()
{
    EE::RmlUi::Init();                                                 // install render + system interfaces
    EE::RmlUi::LoadFontFace("Data/RmlUi/LatoLatin-Regular.ttf");
    Ctx=EE::RmlUi::CreateContext();                                    // sized to D.resW()/D.resH()
    Doc=Ctx->LoadDocument("Data/RmlUi/demo.rml");
    if(Doc)Doc->Show();
    return true;
}
void Shut()   { EE::RmlUi::Shut(); }
Bool Update() {
    if(Kb.bp(KB_ESC))return false;
    Gui.update();
    EE::RmlUi::PumpInput(Ctx);                                         // Ms/Kb -> context
    EE::RmlUi::Update   (Ctx);                                         // events, animations, dirty geometry
    return true;
}
void Draw()   {
    Renderer(RenderScene);                                             // optional 3D world
    Gui.draw();                                                        // Esenthel Gui above 3D
    EE::RmlUi::Render(Ctx);                                            // RmlUi on top of everything
}

Shipped features:
  • Single-TU backend — Engine/Source/Gui/RmlUi.cpp is the only engine
    source file that includes RmlUi headers. It subclasses
    Rml::RenderInterface and Rml::SystemInterface, owns the 1×1 white
    fallback texture, and exports the EE::RmlUi:: facade used by app code.
    Macro pollution is neutralised locally: Esenthel's template-shortcut
    macros T1..T11 (from Engine/H/_/defines.h, they collide with
    robin_hood.h's template parameters) and X11's Always / NotUseful
    (not stripped by Engine/H/_/headers.h) are undefined inside the
    ThirdPartyLibs/begin.h / end.h bracket just for this one TU.
  • API-agnostic rendering — RenderGeometry feeds RmlUi's pixel-space
    vertex stream into the engine's existing 2D path. Per-vertex
    conversion goes through D.pixelToScreen(Vec2) (canonical helper; no
    hand-rolled Y-flip). D.alpha(ALPHA_MERGE) handles RmlUi's
    premultiplied RGBA (which it emits since v5). Scissor goes through
    D.clip(&engine_rect) / D.pixelToScreen(RectI). Works identically on
    DX11, DX12, Vulkan, OpenGL.
  • Untextured-path fallback — RmlUi calls RenderGeometry with
    texture=0 for solid-colour geometry. The backend binds a pre-built
    1×1 opaque-white Image so the textured shader path effectively
    degenerates to plain vertex colour. This avoids needing a separate
    colour-only code path.
  • FreeType sharing — RmlUi's default FreeType font engine is pointed
    at Esenthel's prebuilt EE_FreeType static lib via
    FREETYPE_INCLUDE_DIRS / FREETYPE_LIBRARY cache vars in
    ThirdPartyLibs/RmlUi/CMakeLists.txt, so one copy of FreeType ships in
    the final link. EE_RMLUI_USE_BUNDLED_FREETYPE=ON is an escape hatch
    if the prebuilt's config flags ever diverge from what RmlUi expects.
  • Texture upload — LoadTexture routes to Image.Import, accepting
    every format Esenthel's asset pipeline supports (BMP/PNG/JPG/JXL/WEBP/
    AVIF/HEIF/TGA/TIF/DDS/PSD/ICO/HDR). GenerateTexture uploads raw
    RGBA8 via a soft image, lock/write, row-copy, unlock, and GPU upload
    (used for the font atlas and procedural decorator textures).
  • Dual-mode input pump — EE::RmlUi::PumpInput(ctx) polls
    mouse position, mouse buttons, and wheel every frame, walks all
    256 KB_KEY values firing key down/up events on edge changes, and
    pumps text characters out of Kb.k.c. When the focused RmlUi element
    is an input field or textarea the key queue is drained so fast typing
    never drops characters; otherwise the head of the queue is peeked
    non-destructively so the built-in Gui still sees the same keys on the
    same frame.
  • Opt-in via CMake — option(EE_RMLUI "... " ON) in the root
    CMakeLists.txt, default ON on Linux x64 + Windows x64, fatal on iOS
    / Android (deferred until those platforms are tested). With
    EE_RMLUI=OFF every integration TU is empty, the
    rmlui_core / rmlui_debugger targets are not added to
    the build graph, and the tutorial targets are skipped in
    Tutorials/CMakeLists.txt.
  • Built from source — RmlUi v6.2 is vendored at
    ThirdPartyLibs/RmlUi/lib/ and compiled via subdirectory inclusion so
    rmlui_core + rmlui_debugger become Engine interface link deps.
    No prebuilt library like the other third-parties, because upstream
    ships clean CMake and the library is small. ABI-visible flags are
    forced onto both targets so they match Engine's ABI.
  • Debugger overlay — rmlui_debugger is linked automatically when
    EE_RMLUI=ON. Call Rml::Debugger::Initialise(ctx) once, then
    Rml::Debugger::SetVisible(true) (or bind to a key) to pop up the live
    inspector — Event Log, Element Info, Outlines, Data Models tabs.
  • Thin facade — Engine/H/Gui/RmlUi.h exposes only the
    EE::RmlUi:: lifecycle and helper functions. It forward-declares
    Rml::Context, ElementDocument, RenderInterface, and
    SystemInterface, so app translation units that just drive lifecycle
    do not pay to parse all of &lt;RmlUi/Core.h&gt;. App translation units
    that want event listeners, DOM mutation, or typed element access can
    include &lt;RmlUi/Core.h&gt; themselves.

Non-invasive integration — zero changes to Engine/Source/Gui/Gui.cpp,
Gui.draw, Gui.update, no new state in DisplayClass, no new
alpha mode, no new shaders. The pre-existing VI + D 2D path is the
only rendering surface used; the existing 2D shaders are the only ones
touched. The tutorial harness (Tutorials/TutorialAuto.{h,cpp},
Tutorials/stdafx.h) is unchanged. EE_RMLUI=OFF builds are
pixel-identical to pre-integration builds (verified against
Tutorial_05_Bars, Tutorial_04_BatchedDrawing,
Tutorial_12_RenderToTexture).

RCSS gotcha — RmlUi's transition/animation parser recognises tween
names as defined in Source/Core/PropertyParserAnimation.cpp. Unlike
standard CSS, it does not accept bare linear or the CSS keyword
ease; use linear-in-out and cubic-in-out (or any of the
supported {back,bounce,circular,cubic,elastic,exponential,linear,quadratic,quartic,quintic​,sine}-{in,out,in-out}
variants). Multi-transitions are comma-separated.

Deferred work:
  • Custom Rml::FontEngineInterface on top of Esenthel's Font class, so
    .pak-packaged fonts could feed RmlUi. Upstream's default FreeType
    engine is sufficient for now; TTF files ship alongside the tutorials.
  • Rml::FileInterface on EE::File — would let RmlUi resolve
    .rml / .rcss / texture paths through engine .pak archives. The
    stdio fopen default is used currently; tutorials ship plain files
    under Tutorials/Data/RmlUi/.
  • Data Binding (MVC layer via Rml::DataModelConstructor) — supported by
    the linked rmlui_core but not yet demonstrated by a tutorial.
  • Lua bindings (rmlui_lua) — disabled in the wrapper (RMLUI_LUA_BINDINGS=OFF);
    enabling would require wiring an Esenthel Lua runtime into the engine
    first.
  • Windows smoke sweep via run_smoke_test.ps1. Linux is covered
    (all five tutorials + three regression targets pass).

Available in this repo:
https://github.com/DrewGilpin/EsenthelEngine]]> <![CDATA[Improved Destruction]]> https://esenthel.com/forum/showthread.php?tid=11814 Mon, 20 Apr 2026 02:21:50 +0000 https://esenthel.com/forum/showthread.php?tid=11814 Fracture Destruction System (improve-destruction-v3 branch)

A production-grade destructible-object system located at Engine/Source/Physics/Fracture*.cpp plus Engine/Source/Game/Objects/Fractured.cpp.

The existing DestructMesh / Game::Destructible implementation from Tutorial 23 is left untouched. The new system ships alongside it under new type names.

Core idea:

A FractureMesh asset pre-bakes a mesh into chunks, a cluster hierarchy, and a connection graph that records which chunks share faces, with per-edge breaking strain.

A Game::Fractured runtime object owns the per-instance state. At runtime, it exists as either a single intact-cluster Actor (cluster proxy) or an array of per-chunk Actors connected by breakable PhysX joints.

Damage accumulates per node, or on the cluster as a whole. Once the threshold is crossed, the object transitions from INTACT to SHATTERED by destroying the proxy and spawning per-chunk actors.

Mass is force-set from bake-time chunk volume so the convex-hull proxy’s mass overestimate does not cause a visible pop at the moment of breakup.

Strain then propagates along the connection graph, so a hit on one chunk weakens its neighbours. This reproduces “spider cracks” style breakage without requiring a full spatial-field solver.

[Image: Screenshot-from-2026-04-19-22-14-24.png]

[Image: Screenshot-from-2026-04-19-21-51-13.png]

Shipped features:
    []Five bake patterns (FRACTURE_PATTERN_) —
    PLANAR_SLICES uses random plane cuts and mirrors the classic DestructMesh algorithm.
    UNIFORM_VORONOI and CLUSTERED_VORONOI use iterative SplitMeshSolid with perpendicular-bisector planes; the older CSG-based spike was dropped because it was numerically unstable.
    RADIAL produces true pie-slice wedges radiating from an impact_point through the wall’s thickness axis.
    BRICK uses a dedicated axis-aligned 6-plane-per-cell path (BakeBrickChunks) with shared-boundary jitter: adjacent bricks read the same boundary entry for their shared seam, so jitter never produces gaps between neighbours.
  • Cluster proxy (FractureSettings::build_cluster_proxy) — the bake computes a single convex hull over all chunks and stores it on the root Cluster, plus the sum of per-chunk volumes as mass_sum. At spawn, the Fractured object creates one kinematic Actor using this proxy instead of N per-chunk actors. 500 intact crates cost 500 bodies, not 10,000.
  • Localised release cascade — when damage crosses cluster_break_threshold, Fractured::releaseRootCluster(impact_pos, velocity_delta) destroys the proxy and spawns per-chunk actors, inheriting the proxy’s linear and angular velocity and force-setting each chunk’s mass to the bake-time volume estimate. A distance-falloff kick is then applied only to chunks within 1.5 m of the impact (mass-scaled, velocity-capped at 4 m/s), so a hit near the bottom of a wall does not catapult distant chunks and make anchored sections rubber-band through joints.
  • Deferred release — applyPointDamage is called from inside PhysX’s onContact callback; destroying and creating actors there corrupts the scene and crashes the next PxRigidActor::is<>() cast. Instead, threshold crossing sets a pending flag plus the impact position and velocity, and the next update() tick flushes the release outside any callback.
  • Connection-graph strain propagation — Fractured::propagateStrain walks live_edges each frame when damage_dirty. Damage above the weakest-link elastic limit (0.9 * break_threshold) bleeds across edges; smaller hits dissipate via damage_decay_tau without creeping. Broken joints are removed by BFS; any connected component that does not reach an anchor becomes dynamic.
  • Bake-time anchors — FractureSettings::anchor_volume marks chunks whose centroid is inside the box with FRAC_FLAG_ANCHORED_AT_BAKE. They spawn kinematic, or the cluster proxy spawns kinematic if any member is anchored. Runtime Fracture::setAnchor(obj, chunk_index, anchored) can flip the anchor state live.
  • Damage API —
    Fracture::applyRadialDamage(pos, radius, strength, impulse, type)
    applyContactDamage(a, b, contacts, n, type)
    breakNode(obj, node_index, dir, type)
    setAnchor(...)

    All accept a DAMAGE_TYPE enum (KINETIC, EXPLOSIVE, PIERCING, THERMAL, CUSTOM) scaled by a global damage_type_scale[5] table, so game code can do things like make grenades 1.5x stronger against concrete with a single tweak.
  • Multi-subscriber BreakEventCallback — Fracture::addBreakEventCallback is void-return and never consumes the event. addBreakEventCallbackB is bool-return; returning true consumes the event and stops the chain. Legacy setBreakEventCallback is preserved as a single-slot wrapper.
  • Debris pool — Fracture::setVfxPoolCap, setSfxVoicesCap, debrisActiveCount, plus low-energy sleep and debris-pool caps in updateDebrisHeuristics. Chunks at rest for debris_sleep_timeout seconds are put to sleep so PhysX stops simulating them.
  • Save / Load — FractureMesh::save(path) and load(path) round-trip the whole asset (chunks, cooked PhysX convex hulls, cluster, and connection graph) through a versioned CC4('F','R','A','C') binary format.
    FractureMesh::adjustStorage(universal, physx, bullet) matches the PhysBody contract and allows the asset to be reloaded on a different backend. A cache (Cache<FractureMesh> FractureMeshes("Fracture Mesh")) is preserved so UID-addressed baked assets can live inside pak files like any other engine asset.

    []Instance sharing — many Game::Fractured instances can point at the same FractureMesh. Geometry and cooked hulls are shared; only runtime state (damage, actor transforms, live joints) is per-instance.

Non-invasive integration:

Zero changes to DestructMesh, Game::Destructible, or Tutorial 23.

PhysX’s Physics.reportContact is not hijacked. The host app registers its own contact callback and can optionally call Fracture::applyContactDamage from inside it.

Contact damage is PhysX-only, since Bullet does not deliver contact events in this engine. Radial damage works on both backends.

Deferred work:
  • Multi-level hierarchical fracture (more than 2 levels deep, with per-level break thresholds and cluster-tree view-level LOD). The data model already supports it via Cluster::parent and Cluster::children; the runtime currently walks one level.
  • Runtime on-the-fly fracture (CSG against an unbaked mesh). Pre-bake only is the shipping path.
  • View-distance simulation LOD (far objects deferred until the player enters a bubble). The cluster proxy is the foundation; bubble activation logic is planned as a later follow-up.
  • Multi-platform cooked-hull round-trip. Saved files are currently PhysX-specific; cross-platform support needs adjustStorage(universal=true, ...) before save.
  • Titan Editor UI for anchor-volume painting, per-chunk material picking, and interactive fracture preview. This branch is intentionally code-only.
  • Auto-dispatch BreakPreset VFX/SFX from a material tag, so Tutorial 31’s 40-line OnBreak puff could collapse to 5 lines. The scaffolding is already in place (multi-subscriber callbacks, damage types), but the preset registry is deferred.

in this fork:
https://github.com/DrewGilpin/EsenthelEngine]]> Fracture Destruction System (improve-destruction-v3 branch)

A production-grade destructible-object system located at Engine/Source/Physics/Fracture*.cpp plus Engine/Source/Game/Objects/Fractured.cpp.

The existing DestructMesh / Game::Destructible implementation from Tutorial 23 is left untouched. The new system ships alongside it under new type names.

Core idea:

A FractureMesh asset pre-bakes a mesh into chunks, a cluster hierarchy, and a connection graph that records which chunks share faces, with per-edge breaking strain.

A Game::Fractured runtime object owns the per-instance state. At runtime, it exists as either a single intact-cluster Actor (cluster proxy) or an array of per-chunk Actors connected by breakable PhysX joints.

Damage accumulates per node, or on the cluster as a whole. Once the threshold is crossed, the object transitions from INTACT to SHATTERED by destroying the proxy and spawning per-chunk actors.

Mass is force-set from bake-time chunk volume so the convex-hull proxy’s mass overestimate does not cause a visible pop at the moment of breakup.

Strain then propagates along the connection graph, so a hit on one chunk weakens its neighbours. This reproduces “spider cracks” style breakage without requiring a full spatial-field solver.

[Image: Screenshot-from-2026-04-19-22-14-24.png]

[Image: Screenshot-from-2026-04-19-21-51-13.png]

Shipped features:
    []Five bake patterns (FRACTURE_PATTERN_) —
    PLANAR_SLICES uses random plane cuts and mirrors the classic DestructMesh algorithm.
    UNIFORM_VORONOI and CLUSTERED_VORONOI use iterative SplitMeshSolid with perpendicular-bisector planes; the older CSG-based spike was dropped because it was numerically unstable.
    RADIAL produces true pie-slice wedges radiating from an impact_point through the wall’s thickness axis.
    BRICK uses a dedicated axis-aligned 6-plane-per-cell path (BakeBrickChunks) with shared-boundary jitter: adjacent bricks read the same boundary entry for their shared seam, so jitter never produces gaps between neighbours.
  • Cluster proxy (FractureSettings::build_cluster_proxy) — the bake computes a single convex hull over all chunks and stores it on the root Cluster, plus the sum of per-chunk volumes as mass_sum. At spawn, the Fractured object creates one kinematic Actor using this proxy instead of N per-chunk actors. 500 intact crates cost 500 bodies, not 10,000.
  • Localised release cascade — when damage crosses cluster_break_threshold, Fractured::releaseRootCluster(impact_pos, velocity_delta) destroys the proxy and spawns per-chunk actors, inheriting the proxy’s linear and angular velocity and force-setting each chunk’s mass to the bake-time volume estimate. A distance-falloff kick is then applied only to chunks within 1.5 m of the impact (mass-scaled, velocity-capped at 4 m/s), so a hit near the bottom of a wall does not catapult distant chunks and make anchored sections rubber-band through joints.
  • Deferred release — applyPointDamage is called from inside PhysX’s onContact callback; destroying and creating actors there corrupts the scene and crashes the next PxRigidActor::is<>() cast. Instead, threshold crossing sets a pending flag plus the impact position and velocity, and the next update() tick flushes the release outside any callback.
  • Connection-graph strain propagation — Fractured::propagateStrain walks live_edges each frame when damage_dirty. Damage above the weakest-link elastic limit (0.9 * break_threshold) bleeds across edges; smaller hits dissipate via damage_decay_tau without creeping. Broken joints are removed by BFS; any connected component that does not reach an anchor becomes dynamic.
  • Bake-time anchors — FractureSettings::anchor_volume marks chunks whose centroid is inside the box with FRAC_FLAG_ANCHORED_AT_BAKE. They spawn kinematic, or the cluster proxy spawns kinematic if any member is anchored. Runtime Fracture::setAnchor(obj, chunk_index, anchored) can flip the anchor state live.
  • Damage API —
    Fracture::applyRadialDamage(pos, radius, strength, impulse, type)
    applyContactDamage(a, b, contacts, n, type)
    breakNode(obj, node_index, dir, type)
    setAnchor(...)

    All accept a DAMAGE_TYPE enum (KINETIC, EXPLOSIVE, PIERCING, THERMAL, CUSTOM) scaled by a global damage_type_scale[5] table, so game code can do things like make grenades 1.5x stronger against concrete with a single tweak.
  • Multi-subscriber BreakEventCallback — Fracture::addBreakEventCallback is void-return and never consumes the event. addBreakEventCallbackB is bool-return; returning true consumes the event and stops the chain. Legacy setBreakEventCallback is preserved as a single-slot wrapper.
  • Debris pool — Fracture::setVfxPoolCap, setSfxVoicesCap, debrisActiveCount, plus low-energy sleep and debris-pool caps in updateDebrisHeuristics. Chunks at rest for debris_sleep_timeout seconds are put to sleep so PhysX stops simulating them.
  • Save / Load — FractureMesh::save(path) and load(path) round-trip the whole asset (chunks, cooked PhysX convex hulls, cluster, and connection graph) through a versioned CC4('F','R','A','C') binary format.
    FractureMesh::adjustStorage(universal, physx, bullet) matches the PhysBody contract and allows the asset to be reloaded on a different backend. A cache (Cache<FractureMesh> FractureMeshes("Fracture Mesh")) is preserved so UID-addressed baked assets can live inside pak files like any other engine asset.

    []Instance sharing — many Game::Fractured instances can point at the same FractureMesh. Geometry and cooked hulls are shared; only runtime state (damage, actor transforms, live joints) is per-instance.

Non-invasive integration:

Zero changes to DestructMesh, Game::Destructible, or Tutorial 23.

PhysX’s Physics.reportContact is not hijacked. The host app registers its own contact callback and can optionally call Fracture::applyContactDamage from inside it.

Contact damage is PhysX-only, since Bullet does not deliver contact events in this engine. Radial damage works on both backends.

Deferred work:
  • Multi-level hierarchical fracture (more than 2 levels deep, with per-level break thresholds and cluster-tree view-level LOD). The data model already supports it via Cluster::parent and Cluster::children; the runtime currently walks one level.
  • Runtime on-the-fly fracture (CSG against an unbaked mesh). Pre-bake only is the shipping path.
  • View-distance simulation LOD (far objects deferred until the player enters a bubble). The cluster proxy is the foundation; bubble activation logic is planned as a later follow-up.
  • Multi-platform cooked-hull round-trip. Saved files are currently PhysX-specific; cross-platform support needs adjustStorage(universal=true, ...) before save.
  • Titan Editor UI for anchor-volume painting, per-chunk material picking, and interactive fracture preview. This branch is intentionally code-only.
  • Auto-dispatch BreakPreset VFX/SFX from a material tag, so Tutorial 31’s 40-line OnBreak puff could collapse to 5 lines. The scaffolding is already in place (multi-subscriber callbacks, damage types), but the preset registry is deferred.

in this fork:
https://github.com/DrewGilpin/EsenthelEngine]]> <![CDATA[Cloth Physics]]> https://esenthel.com/forum/showthread.php?tid=11813 Sat, 18 Apr 2026 12:56:10 +0000 https://esenthel.com/forum/showthread.php?tid=11813 A first-party CPU cloth solver built into the engine at Engine/Source/Physics/Cloth.{h,cpp} + Engine/Source/Physics/Cloth Solver.{h,cpp}, sitting behind the existing Cloth / ClothMesh public API. Replaces NVIDIA's deprecated PhysX 3.x cloth (removed in PhysX 4+) with an XPBD (Extended Position-Based Dynamics) implementation — stable, deterministic, tunable, and owned entirely by the engine.

Core idea — each cloth is a set of mass-weighted particles connected by constraints. Per simulate(dt) the solver substeps (default 8) Jakobsen-style: semi-implicit-Euler predict → XPBD Gauss-Seidel constraint solve (Δλ = (-C - α̃λ)/(w_i+w_j+α̃), α̃ = compliance/dt²) → collision projection against author-placed balls/capsules → derive velocity from position delta. Pinned particles (inv_mass == 0) follow skeleton bones each sub-step via smooth prev↔cur lerp so fast character motion doesn't yank the cape.

[Image: Screenshot-from-2026-04-18-08-13-11.png]

[Image: Screenshot-from-2026-04-18-08-15-29.png]

In this repo: https://github.com/DrewGilpin/EsenthelEngine
See README.md for more info.]]> A first-party CPU cloth solver built into the engine at Engine/Source/Physics/Cloth.{h,cpp} + Engine/Source/Physics/Cloth Solver.{h,cpp}, sitting behind the existing Cloth / ClothMesh public API. Replaces NVIDIA's deprecated PhysX 3.x cloth (removed in PhysX 4+) with an XPBD (Extended Position-Based Dynamics) implementation — stable, deterministic, tunable, and owned entirely by the engine.

Core idea — each cloth is a set of mass-weighted particles connected by constraints. Per simulate(dt) the solver substeps (default 8) Jakobsen-style: semi-implicit-Euler predict → XPBD Gauss-Seidel constraint solve (Δλ = (-C - α̃λ)/(w_i+w_j+α̃), α̃ = compliance/dt²) → collision projection against author-placed balls/capsules → derive velocity from position delta. Pinned particles (inv_mass == 0) follow skeleton bones each sub-step via smooth prev↔cur lerp so fast character motion doesn't yank the cape.

[Image: Screenshot-from-2026-04-18-08-13-11.png]

[Image: Screenshot-from-2026-04-18-08-15-29.png]

In this repo: https://github.com/DrewGilpin/EsenthelEngine
See README.md for more info.]]> <![CDATA[Behavior Trees, Animation Graph, IK]]> https://esenthel.com/forum/showthread.php?tid=11812 Sat, 18 Apr 2026 00:06:09 +0000 https://esenthel.com/forum/showthread.php?tid=11812 A data-oriented behavior tree framework for AI decision-making, built into the engine at Engine/H/Game/AI/BehaviorTree.h + Engine/Source/Game/AI/BehaviorTree.cpp. Designed for attachment to Game::Chr subclasses: build a tree of BtNode objects once in Chr::create(), call bt.tick(Time.d()) from Chr::update() each frame.

[Image: Screenshot-from-2026-04-17-19-48-04.png]


Animation Graph (Ag*) and IK (animation-state-machine branch)
A production-grade composable pose-graph animation system, built into the engine at Engine/H/Animation/AnimGraph.h + Engine/Source/Animation/AnimGraph.cpp. Sits on top of the existing AnimatedSkeleton::animate() primitives without modifying them, stylistically parallels the BehaviorTree framework on the same branch (Bt* prefix, namespace Game{}, non-virtual update() wrapper + protected doUpdate() dispatch, tree-walking virtuals for viz).

[Image: Screenshot-from-2026-04-17-19-49-22.png]

IK On:
[Image: Screenshot-from-2026-04-17-16-02-10.png]

IK Off:
[Image: Screenshot-from-2026-04-17-16-02-24.png]

In this repo: https://github.com/DrewGilpin/EsenthelEngine
See the README.md for more info.]]> A data-oriented behavior tree framework for AI decision-making, built into the engine at Engine/H/Game/AI/BehaviorTree.h + Engine/Source/Game/AI/BehaviorTree.cpp. Designed for attachment to Game::Chr subclasses: build a tree of BtNode objects once in Chr::create(), call bt.tick(Time.d()) from Chr::update() each frame.

[Image: Screenshot-from-2026-04-17-19-48-04.png]


Animation Graph (Ag*) and IK (animation-state-machine branch)
A production-grade composable pose-graph animation system, built into the engine at Engine/H/Animation/AnimGraph.h + Engine/Source/Animation/AnimGraph.cpp. Sits on top of the existing AnimatedSkeleton::animate() primitives without modifying them, stylistically parallels the BehaviorTree framework on the same branch (Bt* prefix, namespace Game{}, non-virtual update() wrapper + protected doUpdate() dispatch, tree-walking virtuals for viz).

[Image: Screenshot-from-2026-04-17-19-49-22.png]

IK On:
[Image: Screenshot-from-2026-04-17-16-02-10.png]

IK Off:
[Image: Screenshot-from-2026-04-17-16-02-24.png]

In this repo: https://github.com/DrewGilpin/EsenthelEngine
See the README.md for more info.]]> <![CDATA[Frame profiler and Input Action System]]> https://esenthel.com/forum/showthread.php?tid=11811 Fri, 17 Apr 2026 01:51:30 +0000 https://esenthel.com/forum/showthread.php?tid=11811 A lightweight CPU scope profiler with an on-screen stats overlay, built into the engine at Engine/H/Misc/Profiler.h + Engine/Source/Misc/Profiler.cpp. Works on all backends (DX11, DX12, Vulkan, GL). Zero overhead when disabled (~1 ns per PROFILE_SCOPE site -- one predictable branch on a cached bool).

Tutorial_04_FrameProfiler (Tutorials/Source/04 - Graphics/Frame Profiler.cpp

[Image: Screenshot-from-2026-04-15-12-49-24.png]

[Image: Screenshot-from-2026-04-15-12-49-34.png]


Input Action System (rebindable, savable, stacked)
An Unreal/Unity-style action abstraction over Esenthel's raw polling API, built into the engine at Engine/H/Input/Input Action.h + Engine/Source/Input/Input Action.cpp. 100% additive -- no changes to Kb/Ms/Joypads/Touches. Works on all backends and platforms.

Tutorial_05_InputRebinding (Tutorials/Source/05 - Gui/20 - Input Rebinding.cpp)

[Image: Screenshot-from-2026-04-16-21-41-02.png]

In this repo: https://github.com/DrewGilpin/EsenthelEngine]]> A lightweight CPU scope profiler with an on-screen stats overlay, built into the engine at Engine/H/Misc/Profiler.h + Engine/Source/Misc/Profiler.cpp. Works on all backends (DX11, DX12, Vulkan, GL). Zero overhead when disabled (~1 ns per PROFILE_SCOPE site -- one predictable branch on a cached bool).

Tutorial_04_FrameProfiler (Tutorials/Source/04 - Graphics/Frame Profiler.cpp

[Image: Screenshot-from-2026-04-15-12-49-24.png]

[Image: Screenshot-from-2026-04-15-12-49-34.png]


Input Action System (rebindable, savable, stacked)
An Unreal/Unity-style action abstraction over Esenthel's raw polling API, built into the engine at Engine/H/Input/Input Action.h + Engine/Source/Input/Input Action.cpp. 100% additive -- no changes to Kb/Ms/Joypads/Touches. Works on all backends and platforms.

Tutorial_05_InputRebinding (Tutorials/Source/05 - Gui/20 - Input Rebinding.cpp)

[Image: Screenshot-from-2026-04-16-21-41-02.png]

In this repo: https://github.com/DrewGilpin/EsenthelEngine]]> <![CDATA[DirectX 12 Ultimate rendering backend]]> https://esenthel.com/forum/showthread.php?tid=11810 Tue, 14 Apr 2026 12:12:36 +0000 https://esenthel.com/forum/showthread.php?tid=11810 https://github.com/DrewGilpin/EsenthelEngine

DX12 seems working nicely on Windows 11 nVidia A2000 GPU.

Lines added (by Claude Code) 11,566

[Image: dx12meshshaders.png]

See README.md for info on the added DX12 specific tutorials.]]> https://github.com/DrewGilpin/EsenthelEngine

DX12 seems working nicely on Windows 11 nVidia A2000 GPU.

Lines added (by Claude Code) 11,566

[Image: dx12meshshaders.png]

See README.md for info on the added DX12 specific tutorials.]]> <![CDATA[Vulkan rendering backend with hardware ray tracing]]> https://esenthel.com/forum/showthread.php?tid=11809 Thu, 09 Apr 2026 22:18:40 +0000 https://esenthel.com/forum/showthread.php?tid=11809 https://github.com/DrewGilpin/EsenthelEngine

Claude Code did ~97% of the work. Added some Vulkan specific tutorials:


[Image: raytracing.png]

Tutorial_17_RayTracing — Hardware ray tracing
The marquee Vulkan-vs-OpenGL feature. Renders a small scene (ground plane + 3 colored boxes) entirely via vkCmdTraceRaysKHR running on the GPU's RT cores — no rasterization at all. Includes:

BLAS (bottom-level acceleration structure) built from raw vertex/index buffers
TLAS (top-level) with one instance of the BLAS
4-shader raytracing pipeline: raygen + primary miss + shadow miss + closest hit
Shader binding table built per Vulkan spec alignment rules
Hardware ray-traced primary rays + hardware ray-traced shadow rays from a directional light, with Lambert shading using flat geometric normals computed in the closest-hit shader via SSBO lookups into the vertex/index buffers
OpenGL has no hardware RT path at all — the legacy GL RT extensions are NV-only and dead. The OpenGL build of this tutorial compiles cleanly but only renders the "Ray tracing: N/A on OpenGL" HUD line.

GPU requirements: any GPU exposing VK_KHR_ray_tracing_pipeline, VK_KHR_acceleration_structure, and VK_KHR_deferred_host_operations. Verified working on AMD Radeon RX 6650 XT (RDNA2) under Mesa RADV; should work on any RTX 20-series+ NVIDIA, RDNA2+ AMD, or Arc Alchemist+ Intel GPU.



[Image: async-compute.png]

Tutorial_17_AsyncCompute — Particle sim on a dedicated compute queue
Demonstrates Vulkan's async-compute feature: a 4096-particle gravity simulation runs on a separate compute queue (when the GPU exposes a queue family with VK_QUEUE_COMPUTE_BIT but NOT VK_QUEUE_GRAPHICS_BIT) while the engine's frame rendering happens in parallel on the graphics queue. OpenGL has no equivalent — it is strictly single-queue.

The HUD reports whether the GPU has a dedicated compute family. The compute shader is hand-written GLSL (particle_update.comp), pre-compiled once to SPIR-V via glslangValidator and checked in as a C header (particle_update_spv.h) so the build needs no shader tooling installed.




[Image: gputimer.png]

Tutorial_17_Benchmark — Renderer throughput benchmark
Renders 50 animated characters in a 10×5 grid with vsync disabled, an atmospheric sky, the FPS counter, and the active API name. On Vulkan it also shows a per-phase GPU time breakdown (Prepare / GBuffer / Light / Sky / Blend / Post) measured via real vkCmdWriteTimestamp query pools. Useful for measuring relative renderer throughput between OpenGL and Vulkan builds on the same hardware.

The GPU timer API (Engine/H/Graphics/GpuTimer.h: GpuTimerEnable, GpuTimerMs, GPU_TIMER_PHASE) is exposed engine-wide so any tutorial can read per-phase GPU times. On DX11/GL it compiles to stubs that return 0.


See README.md for more info.]]> https://github.com/DrewGilpin/EsenthelEngine

Claude Code did ~97% of the work. Added some Vulkan specific tutorials:


[Image: raytracing.png]

Tutorial_17_RayTracing — Hardware ray tracing
The marquee Vulkan-vs-OpenGL feature. Renders a small scene (ground plane + 3 colored boxes) entirely via vkCmdTraceRaysKHR running on the GPU's RT cores — no rasterization at all. Includes:

BLAS (bottom-level acceleration structure) built from raw vertex/index buffers
TLAS (top-level) with one instance of the BLAS
4-shader raytracing pipeline: raygen + primary miss + shadow miss + closest hit
Shader binding table built per Vulkan spec alignment rules
Hardware ray-traced primary rays + hardware ray-traced shadow rays from a directional light, with Lambert shading using flat geometric normals computed in the closest-hit shader via SSBO lookups into the vertex/index buffers
OpenGL has no hardware RT path at all — the legacy GL RT extensions are NV-only and dead. The OpenGL build of this tutorial compiles cleanly but only renders the "Ray tracing: N/A on OpenGL" HUD line.

GPU requirements: any GPU exposing VK_KHR_ray_tracing_pipeline, VK_KHR_acceleration_structure, and VK_KHR_deferred_host_operations. Verified working on AMD Radeon RX 6650 XT (RDNA2) under Mesa RADV; should work on any RTX 20-series+ NVIDIA, RDNA2+ AMD, or Arc Alchemist+ Intel GPU.



[Image: async-compute.png]

Tutorial_17_AsyncCompute — Particle sim on a dedicated compute queue
Demonstrates Vulkan's async-compute feature: a 4096-particle gravity simulation runs on a separate compute queue (when the GPU exposes a queue family with VK_QUEUE_COMPUTE_BIT but NOT VK_QUEUE_GRAPHICS_BIT) while the engine's frame rendering happens in parallel on the graphics queue. OpenGL has no equivalent — it is strictly single-queue.

The HUD reports whether the GPU has a dedicated compute family. The compute shader is hand-written GLSL (particle_update.comp), pre-compiled once to SPIR-V via glslangValidator and checked in as a C header (particle_update_spv.h) so the build needs no shader tooling installed.




[Image: gputimer.png]

Tutorial_17_Benchmark — Renderer throughput benchmark
Renders 50 animated characters in a 10×5 grid with vsync disabled, an atmospheric sky, the FPS counter, and the active API name. On Vulkan it also shows a per-phase GPU time breakdown (Prepare / GBuffer / Light / Sky / Blend / Post) measured via real vkCmdWriteTimestamp query pools. Useful for measuring relative renderer throughput between OpenGL and Vulkan builds on the same hardware.

The GPU timer API (Engine/H/Graphics/GpuTimer.h: GpuTimerEnable, GpuTimerMs, GPU_TIMER_PHASE) is exposed engine-wide so any tutorial can read per-phase GPU times. On DX11/GL it compiles to stubs that return 0.


See README.md for more info.]]> <![CDATA[Wheel controller/collider]]> https://esenthel.com/forum/showthread.php?tid=11808 Mon, 06 Apr 2026 03:16:14 +0000 https://esenthel.com/forum/showthread.php?tid=11808 <![CDATA[April 2026]]> https://esenthel.com/forum/showthread.php?tid=11806 Fri, 03 Apr 2026 04:20:49 +0000 https://esenthel.com/forum/showthread.php?tid=11806 -reduced stack memory usage for World Editor heightmap building (to fix crashes on Linux)
-replaced ThreadMayUseGPUData / ThreadFinishedUsingGPUData with a helper class GPUDataUse for auto lock and release]]> -reduced stack memory usage for World Editor heightmap building (to fix crashes on Linux)
-replaced ThreadMayUseGPUData / ThreadFinishedUsingGPUData with a helper class GPUDataUse for auto lock and release]]> <![CDATA[March 2026]]> https://esenthel.com/forum/showthread.php?tid=11805 Sat, 07 Mar 2026 06:37:33 +0000 https://esenthel.com/forum/showthread.php?tid=11805 -tweaked vignette to automatically apply perceptual gamma adjustment based on vignette color brightness (now dark colors are stronger)
-'Input/Inputs' now supports all button states
-added translation languages: chinese traditional (CT), turkish (TR), czech (CS), ukrainian (UA), hungarian (HU), indonesian (IND)
-improved performance / reduced memory usage of translation functions
-improved outline shader to draw outlines on the outside (and not on inside which made the objects seem thinner)
-fixed issues when using multi-sampling (motion vector shaders - TAA+MotionBlur, SSR, outline)
-increased default 'SoundMaxConcurrent' to 32
-renamed SP->ES, JP->JA, PO->PT
-improved 'LanguageSpecific' function
-'OSLanguage' now supports detection of Chinese Traditional (CT)]]> -tweaked vignette to automatically apply perceptual gamma adjustment based on vignette color brightness (now dark colors are stronger)
-'Input/Inputs' now supports all button states
-added translation languages: chinese traditional (CT), turkish (TR), czech (CS), ukrainian (UA), hungarian (HU), indonesian (IND)
-improved performance / reduced memory usage of translation functions
-improved outline shader to draw outlines on the outside (and not on inside which made the objects seem thinner)
-fixed issues when using multi-sampling (motion vector shaders - TAA+MotionBlur, SSR, outline)
-increased default 'SoundMaxConcurrent' to 32
-renamed SP->ES, JP->JA, PO->PT
-improved 'LanguageSpecific' function
-'OSLanguage' now supports detection of Chinese Traditional (CT)]]> <![CDATA[New animations]]> https://esenthel.com/forum/showthread.php?tid=11803 Sat, 21 Feb 2026 13:21:05 +0000 https://esenthel.com/forum/showthread.php?tid=11803
Back 2 the future

https://www.youtube.com/watch?v=s3nwI2pvhKM

Johnny Bravo

https://www.youtube.com/watch?v=U5WlK9YZrYw

Will Smith Rap

https://www.youtube.com/watch?v=c-WEwwbNS6w


Superman

https://www.youtube.com/watch?v=pHv1r0SlwwE


Batman

https://www.youtube.com/watch?v=WImSZBtwQ9E]]>
Back 2 the future

https://www.youtube.com/watch?v=s3nwI2pvhKM

Johnny Bravo

https://www.youtube.com/watch?v=U5WlK9YZrYw

Will Smith Rap

https://www.youtube.com/watch?v=c-WEwwbNS6w


Superman

https://www.youtube.com/watch?v=pHv1r0SlwwE


Batman

https://www.youtube.com/watch?v=WImSZBtwQ9E]]> <![CDATA[February 2026]]> https://esenthel.com/forum/showthread.php?tid=11802 Wed, 11 Feb 2026 06:13:29 +0000 https://esenthel.com/forum/showthread.php?tid=11802 -Gui Skin Editor can now edit TextBox Panel
-Gui Window title bar now additionally includes StrEx allowing to include images and text color
-added a new kind of light 'LightPointEx' which is more customizable]]> -Gui Skin Editor can now edit TextBox Panel
-Gui Window title bar now additionally includes StrEx allowing to include images and text color
-added a new kind of light 'LightPointEx' which is more customizable]]> <![CDATA[January 2026]]> https://esenthel.com/forum/showthread.php?tid=11801 Sun, 01 Feb 2026 15:11:44 +0000 https://esenthel.com/forum/showthread.php?tid=11801 -IMPORTANT: slightly tweaked bloom formula, please adjust your Editor Settings \ Video Options \ Advanced \ Bloom Scale = 0.6, if you're using custom 'D.bloomScale' in your game codes you might need to adjust it
-Joypad DPAD is now also included in the button functions b, bp, br, bd
-configured engine to use Windows::Gaming::Input first, and if unavailable then fall back to XInput, for improved compatibility when running on Linux
-Gui Objects now additionally support "StrEx descEx"
-added a workaround for old game controllers to have axis centered initially
-other various improvements]]> -IMPORTANT: slightly tweaked bloom formula, please adjust your Editor Settings \ Video Options \ Advanced \ Bloom Scale = 0.6, if you're using custom 'D.bloomScale' in your game codes you might need to adjust it
-Joypad DPAD is now also included in the button functions b, bp, br, bd
-configured engine to use Windows::Gaming::Input first, and if unavailable then fall back to XInput, for improved compatibility when running on Linux
-Gui Objects now additionally support "StrEx descEx"
-added a workaround for old game controllers to have axis centered initially
-other various improvements]]> <![CDATA[Merry Christmas]]> https://esenthel.com/forum/showthread.php?tid=11800 Wed, 24 Dec 2025 11:00:45 +0000 https://esenthel.com/forum/showthread.php?tid=11800
.jpg  676b654d3dfde-merry-christmas-wishes-255207535-16x9.jpg (Size: 110.48 KB / Downloads: 12) ]]>
.jpg  676b654d3dfde-merry-christmas-wishes-255207535-16x9.jpg (Size: 110.48 KB / Downloads: 12) ]]> <![CDATA[Sound Qestion]]> https://esenthel.com/forum/showthread.php?tid=11799 Wed, 24 Dec 2025 09:25:07 +0000 https://esenthel.com/forum/showthread.php?tid=11799 Out of curiosity, what kind of headphones/speakers do you use?
Can you hear quality difference between music/sound files encoded in the engine as 96 vs 128 kbps Opus? (from full quality WAV/FLAC)]]> Out of curiosity, what kind of headphones/speakers do you use?
Can you hear quality difference between music/sound files encoded in the engine as 96 vs 128 kbps Opus? (from full quality WAV/FLAC)]]> <![CDATA[Johnny "incel" Bravo]]> https://esenthel.com/forum/showthread.php?tid=11798 Fri, 05 Dec 2025 19:16:58 +0000 https://esenthel.com/forum/showthread.php?tid=11798
https://www.youtube.com/watch?v=U5WlK9YZrYw]]>
https://www.youtube.com/watch?v=U5WlK9YZrYw]]> <![CDATA[December 2025]]> https://esenthel.com/forum/showthread.php?tid=11797 Mon, 01 Dec 2025 07:55:10 +0000 https://esenthel.com/forum/showthread.php?tid=11797 -added support for Visual Studio 2026
-disabled Windows UWP project setting, now you don't need to install it along with VS]]> -added support for Visual Studio 2026
-disabled Windows UWP project setting, now you don't need to install it along with VS]]>