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.
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.
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.
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.
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 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.
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.
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.
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.