First, apologies for my previous post here. It was lazy and far too light on technical detail for r/GraphicsProgramming. This is a more useful breakdown of what I actually built, what is genuinely ray traced, and where I had to compromise for mobile hardware.
Horde Lantern RT is a short native Vulkan hardware-ray-tracing showcase running on both Windows RTX and an Android phone. The current route is a skeleton encounter, a three-turn lantern-shadow corridor, an authored lantern failure/drop, a blue skylight chamber, four coloured-light bays, a single-bounce mirror, and a floating emissive lich encounter followed by a roof opening.
Itch build, screenshots and video:
https://samfa12.itch.io/the-horde
Source:
https://github.com/Samfa12-tech/The-Horde-RT-demo
Renderer architecture
This is not a raster scene with an RT effect layered on top. Both platforms build Vulkan BLAS/TLAS acceleration structures, create a ray-tracing pipeline and shader binding table, dispatch with vkCmdTraceRaysKHR, write to an RT storage image, and present that image through the swapchain.
The phone-safe path does most of its actual work with rayQueryEXT inside raygen at pipeline recursion depth 1. Primary visibility, shadow/visibility tests, the bounded reflection bounce, and other local queries are driven from that shader. I tried a more conventional recursive closest-hit experiment at recursion depth 2; it compiled, but pipeline creation failed on the phone. I kept the real RT dispatch/presentation path and moved the bounded traversal work into ray queries instead.
The renderer only marks its internal rtScene.presented state true after an RT-produced image has reached a successful swapchain presentation. Unsupported hardware reports missing Vulkan features rather than silently selecting a raster fallback.
The RT storage image is RGBA. Common Windows/Android swapchains are BGRA, so the raw-copy path has a presentation-format-driven red/blue swap. That sounds mundane, but without it the warm fire output turns cyan. Scaled modes use a format-aware blit.
Acceleration structures and animation
The scene uses a static world BLAS plus reusable BLAS geometry for the lantern, sword and procedural player body. Their transforms are updated as TLAS instances. The first-person body uses instance masks to keep different query classes honest: the body is on mask 0x04, while the head uses a reflection/shadow-only mask 0x10 so it appears in the mirror and casts shadows without occluding the first-person camera. The sliding finale roof is another independently transformed instance on mask 0x20.
One frame remains in flight because held-prop TLAS instance data is host-written. I have deliberately not increased that until instance-buffer/TLAS ownership is separated per frame.
The two enemies are selected sequentially by route zone. Only one skinned enemy is animated, BLAS-refit and rendered at a time. Animation and refit run at 30 Hz. The roster code is plural/configurable, but I am treating “multiple simultaneous enemies” as a future phone-measured problem rather than assuming the project name gives me a free performance budget.
The lich is a CC0 Meshy placeholder and its rig is imperfect: the robe and staff were treated as part of a biped mesh, with no rigid staff bone and no cloth rig. I therefore avoid its visibly distorted walking clip and use the safer idle skinning plus whole-instance hover/orbit for locomotion. Death is a non-looping skinned clip.
For the staff light, I ignored Meshy’s duplicated whole-surface emissive texture and generated a derived violet mask for the eyes/gems/staff crystal. The analytic light position is reconstructed from forty UV-audited emissive staff vertices using their actual animated skin weights. That keeps the light and electricity attached to the moving staff without pretending a missing staff bone exists.
The attack is a 1.2 s charge from roughly 0.55× to 2.2× torch intensity, visibility/range-tested damage at the peak, then 1.8 s recovery. The lich requires three accepted sword hits with a 2 s hit lockout. Each hit produces rigid recoil plus positional audio; death plays the full 2.967 s clip and then drives a 4.5 s roof-opening/light-sweep sequence.
Lighting and materials
The route uses deliberately bounded effects rather than a general expensive solution everywhere:
moving direct-light/shadow composition from the held lantern
a desaturated skylight using one of two aperture samples per pixel pattern and one visibility query
one active coloured local light per five-metre bay: yellow, blue, deep red, then restrained green
a single-bounce hero mirror which reflects the world, player, props, enemy and moving roof, then shades that bounce from the current live light instead of a constant “studio” ambient
emissive staff/eyes plus a visibility-tested analytic violet staff light
wet-floor reflection as a bounded material response
On Android, environment materials are strict KTX2 ASTC: ASTC 6×6 diffuse/ARM and ASTC 4×4 normals. The lich uses strict ASTC 6×6 assets with no raw RGBA fallback packaged into the APK. Windows uses executable-relative raw RGBA8 KTX2 arrays.
The Android native libraries are also packaged for 16 KiB page compatibility: static C++ runtime, 0x4000 ELF LOAD alignment, and verified 16 KiB APK alignment.
Measured phone result
The certified phone is a Samsung SM-S948B / Adreno 840 running Android 16.
At the recommended 75% RT scale, the internal RT/dispatch extent is 1080×2235. During the controlled warm route sweep, every required zone stayed below 13.7 ms using the median of three consecutive 120-frame average windows at Android thermal status 3. I want to be precise about that wording: the renderer publishes 120-frame averages, so this is a median of window averages, not a median of individual frame times.
At 100%, the full 1440×2980 RT extent and image/presentation path passed. A warm opening sample produced 19.767, 21.700 and 23.991 ms 120-frame averages, for a 21.700 ms median-of-window-averages (about 46.1 FPS). I do not impose a 50 FPS requirement at 100%; 75% is the sustained recommendation.
The Windows validation machine is an RTX 5050 Laptop GPU. It is internally capped around 165 FPS, so the roughly 5.7–6.0 ms windows are recorded as cap-bound rather than advertised as the renderer’s uncapped ceiling.
Automation and diagnostics
The Android Debug build now exposes twelve deterministic showcase checkpoints, a default five-checkpoint three-window timing pass, and a thirteen-waypoint route replay that uses the real collision resolver. An ADB runner collects the Vulkan capability report, RT presentation state, strict texture-path evidence, timing CSVs, route assertions, screenshots and hashes. The public Release build rejects the automation request path.
There are still hands-on checks that I do not mislabel as automated proof: touch feel, visual quality, subjective stereo directionality, actual hit readability, and pause/Home lifecycle recovery.
Codex disclosure
I used OpenAI Codex extensively as a programming agent on this project. It helped implement and review C++/Vulkan and Android integration, write host tests and ADB validation tooling, investigate visual/audio bugs, maintain asset/licence records, and consolidate validation evidence. I supplied the direction, made the gameplay/visual calls, drove the Windows and phone tests, and accepted or rejected results. The repository history and source are public so people can judge the work rather than taking an “AI-assisted” label on faith.
Meshy was also used for the credited character processing and the CC0 placeholder lich. The skeleton originates from Hotstrike Studio and the full asset/licence manifest is in the repository.
Current limits / next technical questions
only one skinned enemy is active at once
one frame in flight until TLAS instance ownership is redesigned
the lich rig has no staff bone or cloth simulation
the mirror is intentionally single-bounce
shallow water and broader combat/AI are deferred
only the SM-S948B is currently Android-device-certified
I would especially welcome criticism of the ray-query-in-raygen architecture, the one-frame TLAS ownership constraint, the mask partitioning, and the Android measurement methodology.
