March 30, 2026
Lighting & Atmosphere
This update focuses on one of the biggest visual gaps in RetroEngine so far:
light that actually feels present in the air.
While outdoor scenes had fog and atmosphere, interiors still felt flat.
Light could hit surfaces, but there was no sense of it moving through space
(no beams through windows, no shafts cutting across rooms, and no way to
intentionally shape light as part of the environment).
To solve this, a new light shaft system was introduced.
Instead of physically-based volumetrics, the system treats light as a
controllable volume — something that can be placed, rotated, scaled,
and shaped directly in the scene.
The goal wasn’t realism, but a stylized approach inspired by older hardware:
soft, visible beams that add mood without relying on expensive simulation.
Subtle motion was added to keep the shafts from feeling static,
finding a balance between completely still and overly noisy.
Alongside this, the renderer gained a directional shadow map,
allowing objects to finally sit correctly in the world.
Shadows are generated from a camera-fitted light projection and
sampled directly in the lighting pass, grounding both geometry
and the new shaft system.
The biggest change, however, is how lighting color is handled.
Instead of relying on physically-based behavior, the system now treats
directional light and ambient light as two distinct artistic controls:
one defines lit areas, the other defines shadowed areas.
This allows for predictable color control: warm light with cool shadows,
fully ambient-lit interiors, and lighting that enhances materials
instead of fighting them.
This log represents a turning point where lighting in the engine
becomes something that can be authored intentionally,
not just simulated.
Read Full Log
This is just a short summary — click above to read the full log.
March 14, 2026
Editor Tools & Simulation Time
Instead of a single deep technical topic, this update covers several
major improvements across the engine: editor interaction,
rendering features, performance work, and a new deterministic
simulation time system.
The editor viewport can now directly select objects using AABB
picking, with correct mouse projection even when the UI layout is
docked and resized. This small change makes the editor feel far
more physical — scenes can finally be interacted with directly
instead of purely through panels.
The largest change is the introduction of a deterministic time
system that allows the engine to pause, rewind, and replay
simulation. Inputs and scene updates can now be scrubbed through
a timeline, turning the engine into a temporal sandbox for
debugging and experimentation.
On the rendering side, meshes now support emissive textures and the
renderer gained GPU batching and frustum culling, improving both
visual flexibility and performance as scenes grow.
Finally, the editor’s construction grid and chunk logic were expanded
to support rapid level building using reusable scene vignettes:
small art pieces that snap into place to assemble environments quickly.
This log acts as a quick tour through the newest capabilities,
showing how the engine is evolving from a renderer into a full
development workspace.
Read Full Log
This is just a short summary — click above to read the full log.
March 5, 2026
Atmospheric Rendering
As RetroEngine's terrain streaming matured, something became painfully obvious:
the outdoor scenes were too perfect.
Infinite clarity sounds nice on paper, but in practice it makes worlds feel flat,
artificial, and exposes every terrain pop and draw distance limit.
Looking back at older games revealed the missing ingredient.
Titles like Star Wars: Rogue Squadron used atmospheric fog not just to hide
hardware limitations, but to ground environments and create believable scale.
Distance and height-based fog gave the horizon weight,
letting the world fade naturally instead of ending abruptly.
This log covers the implementation of a scene-level fog system
built as a fullscreen pass that reconstructs world position from depth
and applies both distance fog and height fog in a single calculation.
The system integrates directly into the scene renderer,
running before the CRT simulation stage so it behaves like real atmosphere,
not a screen-space filter.
Several subtle bugs surfaced during development:
fog disappearing under orthographic cameras,
sky geometry unexpectedly controlling fog visibility,
and a particularly nasty constant-buffer layout mismatch
that produced intermittent artifacts and corrupted reconstruction.
The final system is deterministic, scene-controlled,
and extremely cheap to render.
One fullscreen triangle, one depth read per pixel,
and zero work when fog is disabled.
The result is a renderer that finally feels like it exists inside an atmosphere.
Read Full Log
This is just a short summary — click above to read the full log.
February 24, 2026
Texture Cache & Render Style
Adding high-resolution textures to streaming terrain exposed a serious architectural flaw:
every chunk was loading its own copy of the same 4K texture.
The result was predictable (to some), GPU memory exhaustion and a hard device reset.
This log documents the shift from per-entity texture ownership
to a global texture cache with deterministic key normalization
and safe pruning tied to scene state.
One texture. One SRV. Shared across all terrain chunks.
A new editor debug panel now exposes global and scene-only texture memory,
instance counts, SRV usage, and live filtering.
What used to be invisible GPU pressure is now measurable in real time.
The update was validated on a low-end RDNA2 integrated GPU,
holding a stable 60 FPS with streaming terrain active.
Stability and predictability are the goal, not chasing peak hardware.
This log also introduces scene-level color quantization and ordered dither,
integrated directly into the lighting pipeline.
Retro degradation is now deterministic, editor-driven,
and applied uniformly across both mesh and sprite paths.
Read Full Log
This is just a short summary — click above to read the full log.
Indoor chunk tools exposed something I had been ignoring:
everything outside still sat on an infinite flat plane.
That was fine for debugging, but not for building real spaces.
This week, the chunk system quietly evolved into something much larger:
a procedural terrain system built on the same entity pipeline as everything else.
Terrain in RetroEngine does not get a special renderer or hidden pass.
Each terrain chunk is just a normal SceneEntity with a generated mesh.
That decision kept the renderer simple,
but it forced discipline around ownership, lifetime, and serialization.
Several subtle bugs surfaced along the way.
Terrain is serialized as parameters only:
seed, frequency, amplitude, resolution, shading flags.
No mesh blobs on disk.
From that small block of data, an entire world can regenerate.
With deterministic generation in place,
streaming naturally followed.
The camera’s world position maps to chunk coordinates,
and a square region of terrain updates around it.
Fly forward and the world keeps building itself. Everything is
derived from a handful of numbers saved in the scene file.
Read Full Log
This is just a short summary — click above to read the full log.
This dev log focuses on a deceptively simple goal:
making placement inside RetroEngine feel physical instead of list-driven.
What started as “just a construction grid” quickly turned into a stress test
for the editor, the renderer, and some long-standing assumptions about how
temporary data should interact with the GPU.
The construction grid itself is intentionally minimal.
It is editor-only, owns no entities, and does not exist at runtime.
Given a camera and a mouse ray, it answers one question:
where would this land?
That small shift unlocked a more tactile way to assemble spaces
without introducing a second scene graph or heavy gizmo systems.
From there, chunk placement needed clearer rules.
Explicit chunk anchors were introduced to define pivots without adding
hierarchy or hidden ownership.
Chunks remain plain data (reusable, instanced, and disposable),
but now spawn deterministically and predictably on the grid.
The real challenge came with live previews.
Rendering chunks before placement sounds trivial,
but doing it safely in Direct3D 12 forced stricter boundaries
between editor and runtime rendering.
The end result is a preview system that uses the same mesh path as real entities,
but with disciplined resource ownership and no mutation of scene state.
This log also marks roughly 100 days of work on RetroEngine!
The features are getting quieter,
but the engine itself is getting stronger.
Fewer fragile edges.
Clearer rules.
Faster iteration.
Read Full Log
This is just a short summary — click above to read the full log.
This dev log covers a week where the focus was on adding some
fun features, and removing lots of friction.
As I started building more real spaces inside RetroEngine,
small limitations kept surfacing and slowing everything down.
The first set of changes grew out of material authoring.
Animated UVs were unified across sprites and meshes,
turning scrolling textures into a true material feature instead of a special case.
At the same time, alpha cutout was added with deliberate constraints,
favoring predictable, era-correct behavior that works with the CRT pipeline
instead of fighting it.
From there, the work shifted into editor tooling.
Smarter duplication exposed the need for real spatial understanding,
which led to geometry-aware placement, reusable content chunks,
and multi-entity editing without introducing heavy prefab systems
or new runtime complexity.
Taken together, these changes are about scaling the engine responsibly.
RetroEngine remains opinionated and constrained on purpose,
but it is becoming faster and more comfortable to build with.
The goal is still the same:
let simple systems do real work without turning the editor into a second engine.
Read Full Log
This is just a short summary — click above to read the full log.
Up to this point, RetroEngine could render scenes correctly,
but they felt flat.
Objects felt "floaty".
Everything was evenly lit.
There was no sense of locality or presence tying things together.
This dev log is about fixing that without breaking the engine’s core goals.
Lighting was added not as a realism upgrade, but as a way to bring the
CRT pipeline to life and give scenes emotional weight.
The focus stayed on simple, predictable techniques that fit a
retro-inspired renderer.
Point lights were introduced as entity-driven components,
allowing localized illumination without a deferred renderer,
shadow maps, or heavy ray techniques.
To ground objects visually, a cheap but deliberate blob shadow system
was layered in: a classic solution that solves most of the problem
while keeping performance and behavior easy to reason about.
Together, these changes make scenes feel less synthetic and more alive,
while staying true to the engine’s constraints:
no baked lighting, no overengineering, and no effects that fight
the retro aesthetic RetroEngine is built around.
Read Full Log
This is just a short summary — click above to read the full log.
With the CRT pipeline stabilized, the bottleneck shifted away from rendering
and toward scene authoring.
Too much time was being spent duplicating work,
redoing small variations, and manually keeping entities in sync.
This dev log focuses on removing that friction.
Grayscale material paths were added with tint, gamma, bias, gain,
and color ramp controls, allowing a single texture to produce
multiple visual outcomes without reauthoring assets.
The editor was also extended with copy and paste for individual
entity attributes and multi-select editing in the scene outliner,
making it possible to apply changes across groups of objects at once.
Together, these tools shift RetroEngine toward faster iteration,
intentional reuse, and scene composition that scales beyond
one-entity-at-a-time editing.
Read Full Log
This is just a short summary — click above to read the full log.
A full walkthrough of RetroEngine as it exists today.
This 25-minute video covers the editor, rendering pipeline,
CRT simulation, and scene authoring workflow end-to-end.
Watch the Overview
After stabilizing the CRT render pipeline in the last dev log,
I wanted to tackle one last missing detail before moving forward:
phosphor persistence.
The goal sounded simple: subtle ghosting, faint trails, that
unmistakable analog “memory” during motion.
Instead, it opened a can of worms.
What followed was a cascade of failures:
broken masks, impossible depth behavior, infinite trails,
collapsing brightness, and a mysterious green tint that slowly
overtook the entire image.
This dev log documents that failure in detail:
why Rec.709 luma weighting made sense at first,
why it completely fell apart inside a feedback loop,
and how persistence turned out to be a temporal system
rather than a blending problem.
The breakthrough came from a single conceptual shift:
persistence should never add energy.
It should only preserve what is already fading.
By reframing the problem and designing a more physically grounded model,
the CRT finally behaved the way it should:
stable, predictable, and visually convincing.
Read Full Log
This is just a short summary — click above to read the full log.
After unifying the render pipeline in the last dev log, it was time to stop adding
features and start asking harder questions.
The CRT output looked good, but parts of the system were opaque.
Some parameters felt fragile. Others were hard to reason about.
Resolution changes could subtly break things.
Most importantly, I felt like I was often guessing when debugging the render pipeline.
This dev log is about turning the CRT from a black box into an inspectable system.
Debug views were added, energy flow was visualized, and a core masking bug was fixed
by treating phosphors as a physical gate instead of a cosmetic effect.
Along the way, instrumentation caught a serious startup performance regression
before it snowballed, reinforcing why observability matters just as much as visuals.
Read Full Log
This is just a short summary — click above to read the full log.
After cameras became real scene entities, another problem became impossible to ignore.
Lighting was still global.
It worked, but it wasn’t authored. Lighting changes leaked between scenes, couldn’t be
reasoned about in isolation, and didn’t actually belong to the data model yet.
Fixing that led to a larger shift.
Sprites, meshes, cameras, and lighting now all flow through a single unified rendering
pipeline. The old 2D test renderer is gone, and scenes are finally self-contained and
trustworthy.
Along the way, some hard problems surfaced: entity duplication, deletion safety,
and GPU ownership and those were fixed at the root instead of patched over.
Read Full Log
This is just a short summary — click above to read the full log.
The last dev log was about scenes. Saving them, loading them, and fixing the subtle
ownership bug that made everything fragile.
That work mattered. Retro Game Engine finally had memory.
But once the dust settled, something was still missing.
I could author scenes. I could place entities. I could tweak transforms.
But interacting with the world still felt indirect.
Every scene used the same fixed camera.
It worked, but it was frustrating to work with. I needed the ability to set different cameras per scene, and on top of that, a way to utilize an "editor" camera with input controls to move around and examine things better.
Read Full Log
This is just a short summary — click above to read the full log.
RetroEngine now supports full 3D scene saving and loading. Entities, meshes, materials,
textures, and transforms serialize cleanly to disk and can be reloaded through the editor.
This marks the transition from a live rendering sandbox to a real world-authoring tool.
Getting there exposed a subtle but critical engine bug. Loading a second scene reliably
crashed the engine, not due to leaks, but due to incorrect ownership boundaries between
the editor and renderer. Fixing that architectural flaw stabilized multi-scene loading
and laid the groundwork for future features like cameras and per-scene lighting.
Read Full Log
This is just a short summary — click above to read the full log.
This update pulled RetroEngine out of the prototype phase and into real rendering territory.
Albedo textures now work across the entire engine, a proper lighting system is in place
(directional + ambient), emissive behaves like the hardware that inspired the project, and the
editor can import real OBJ models end-to-end.
The CRT pass exposed tiny shading issues that the raw framebuffer completely hid, and fixing
them led to one of the most satisfying wins so far: importing a full spaceship model and having
it light correctly on the first good compile. A three-line bug in the OBJ importer was the final
boss, and once it fell, everything clicked into place.
Read Full Log
This is just a short summary — click above to read the full log.
This update was all about taking the 2D and 3D pipelines and combining them to behave like a real
engine. Depth sorting finally works, sprites get their own textures, and materials no longer
bleed between entities. It wasn’t easy, a lot of this felt like stumbling in the dark until
things clicked, but the engine is much stronger for it.
Two videos in this log show the new per-entity material editor and proper depth-sorted
transforms in action.
Read Full Log
This is just a short summary — click above to read the full log.
This update marks a major turning point for RetroEngine. What began as simple debug panels
has grown into the first real editor: a fully dockable interface powered by ImGui’s docking
branch, tied directly into the engine’s live rendering pipeline.
Scenes can now be edited in real time; adding and removing layers, adjusting parallax,
importing textures, updating names, and instantly seeing the results through the CRT
simulation. A new import pipeline ensures every PNG is safely brought into the project
structure, and JSON scene files now save and load reliably.
Read Full Log
This is just a short summary — click above to read the full log.
In just a few days, RetroEngine took a major step forward.
The engine can now render true 2D parallax scenes, built entirely on its custom DirectX 12 renderer and running through the same HDR signal path as the 3D stage.
This isn’t just a visual feature. It’s the first proof that RetroEngine’s rendering core can support a full 2D pipeline — modular, efficient, and deeply tied into the CRT simulation.
Every pixel is treated as light, not color data, which means the behavior of the image is physically modeled from input to glass.
Read Full Log
This is just a short summary — click above to read the full log.
With the CRT renderer stable, this phase focused on structure and scalability; defining how RetroEngine organizes and renders its world. The new ECS-style architecture introduces clean separation between data and behavior, with components for scenes, materials, and gpu meshes, driving a modular pipeline.
The first 3D scene renderer now runs with verified Blinn–Phong lighting, world-space normals, and HDR output feeding directly into the CRT simulation stage. This milestone proves the engine’s rendering core is stable enough to support both 2D and 3D pipelines under a single system.
Read Full Log
This is just a short summary — click above to read the full log.
RetroEngine began as a blank D3D12 window, a personal experiment to see if a CRT could be simulated not as a filter, but as a physical system. Within the first week, that idea evolved into a functioning real-time display model, complete with beam scanning, phosphor decay, and color-accurate light response.
The renderer now reproduces real phosphor layouts, beam afterglow, and even a simple 3D scene, all rendered through a fully simulated CRT pipeline. This marks the foundation of RetroEngine’s goal: not imitation, but reconstruction of analog light.
Read Full Log
This is just a short summary — click above to read the full log.