After finishing the buffer and upload infrastructure, the next step was finally connecting that work to the graphics pipeline. Until now, STAGE VK could create a Vulkan device, manage the swapchain, record command buffers, render Dear ImGui and upload data to GPU buffers, but it still had no rendering path of its own. This implementation changes that. The goal was simple: render the first triangle using a vertex buffer, custom shaders and a Vulkan graphics pipeline, while int

Until now, most of the work on STAGE VK had been focused on getting Vulkan itself running correctly. The engine could create an instance, select a GPU, create the logical device and queues, manage a swapchain, record command buffers, synchronize frames and finally present an image to the screen. After that, I separated the rendering architecture into VulkanModule, RenderModule and EditorModule, and added the first editor tools on top of Dear ImGui. All of that gave me a worki

Performance profiling became the next major editor tool implemented in STAGE VK. The engine already exposed basic frame information such as FPS and delta time, but this was only enough to know whether the application was running at an acceptable rate. It did not explain where CPU time was being spent, how long the GPU required to execute a frame, or what Vulkan work was being submitted. The original performance panel was therefore replaced by a dedicated profiling architectur

The editor console was implemented as the first dedicated debugging tool for STAGE VK. Until this point, engine messages were mainly exposed through the native application console. While this was sufficient during the first stages of development, it was not a practical solution for an editor-oriented workflow. Vulkan validation messages, engine diagnostics and general runtime information needed to be accessible directly from the editor and presented in a way that could be fil

RenderModule, Dear ImGui and the First Editor Layer In the previous STAGE VK development update, the Vulkan backend reached the point where it could acquire a swapchain image, record GPU commands, submit them to the graphics queue and present the result to the window. The rendered result was still intentionally simple: a solid colour. However, reaching that point exposed the next architectural problem. VulkanModule was responsible for both managing the Vulkan frame lifecycle

Swapchain, Command Buffers, Synchronization and Presentation Welcome to the third STAGE VK development update. In the previous post, I completed the first stage of the Vulkan backend: creating the Vulkan instance, enabling validation, creating the window surface, selecting a physical device, discovering the required queue families and finally creating the logical device and its queues. At that point, STAGE VK was connected to the GPU, but it still could not actually produce a

Validation Layers, GPU selection, Queue Families and Logical Device creation Welcome to the second STAGE VK development post. It has been a while since I started this project, and for academic, professional, and personal reasons I did not have the chance to share any updates. However, the idea of continuing to build my own game engine with Vulkan has always stayed in the back of my mind. When I started STAGE VK, I thought I would probably have a triangle on screen by this poi

Welcome to my first post about STAGE VK. STAGE stands for Simple Tridimensional Animation Game Engine , and VK refers to Vulkan. Why? The motivation that led me to start this personal project comes from the master’s degree I am currently studying at UPC in Barcelona, Advanced Programming for AAA Games . At the same time, a group video game project called Bound by Death is also being developed, for which another Game Engine is being built using the DirectX 12 API. It is a fa