Showcasing how i optimize my upcoming game with my engine. When enabled it will show you what function / line is costly in realtime while you play. This helped me optimize some functions that i was able to cache so it doesn't run every frame.

try out my game still in development (a lot of missing assets) https://www.kanvon.com/lumenfall

I mentioned in my last post that the next step was to work out legit lighting... that turned out to be a lot of work, haha.

In the process I've migrated from Sokol to SDL_GPU and adopted HLSL as my shader language. I've also been learning the different lighting techniques, drawing reference from open source renderers and from examples in blog posts and repos by industry experts.

I've set Blender as my initial quality target. At the moment my engine's renderer is forward only. The next goal is to adopt a more modern forward+ approach so I can push the render closer to the Cycles gold standard while staying efficient enough for real time.

Hi everyone, first time posting here, I hope someone can offer some guidance.

I'm currently making a 2D Game Engine. Nothing super complicated; I'm actually following the "COMP 4300 Intro to C++ Game Programming" by Dave Churchill (entire course is on youtube) video classes. I like it because he guides you on what to do without showing everything, so you can fill on many details yourself while learning a lot.

However, I've come to the part where I need to make the 2D Animation system, and I'm at a bit of a lost. Churchill uses ECS for this Engine. So, theoretically, every Actor/Entity should have an Animation Component with only data, that is used later by the Animation System to do its thing.

What I'm doing now, is that the Entity has the entire sprite sheet loaded, and the Animation component holds the sprite location offsets, together with the amount of frames in the animation, and its speed. But here is where I'd like some guidance: How could I handle this data?

For example, I'd like to make a Top-Down 2D type of game. That means that each actor would have at least 3 animations for a single movement: IDLE_UP, IDLE_DOWN, IDLE_SIDE, WALK_UP,... etc. How can I organize this? Each Actor can have all the information (offsets, speed, frames) in its Animation Component, but when I want to access it, all I can think of it's a Map of Maps... one map to access all the IDLE animations, and then another one to access the specific one I need in that state.

It would absolutely work, but I'm wondering if there isn't a better way? Has anyone done something similar? How did you handled it?

Thank you vey much for any help or guidance you can give me. Have a nice day.

NOTE: please NO AI answers. This is not mine but I would, and I quote: "rather go to the bathroom, turn off the lights, sing Bloody Mary, and then ask HER before I ask an AI anything". Please. I'm done with AI slop. I want to talk with a human. Thank you for understanding.

Hi everyone,

While building the core framework for my custom C++ game engine, I decoupled its memory manager into an independent, low-level component designed for zero-crash policies, deterministic O(1) lookup via nomadic index tables, and fragmentation control during IDLE cycles.

I'm sharing it as a technical demonstration / portfolio project (closed-source, pre-compiled .lib for x64 Windows):

https://github.com/GorosTemple/GRS-System-Resource-Manager

Key Technical Aspects:

• 100% free of std and external dependencies (Bare-metal friendly).
• ~31 KB binary logic footprint (.text + .rdata on x64 MSVC).
• Fallback locking systems when OS RAM or virtual memory pools are exhausted.
• Telemetry & Profiler abstraction via dependency injection.

I'm currently using this as a portfolio piece for job opportunities in engine/systems programming, and I'd love to get technical feedback on:

1. The API architecture and dependency injection strategy.
2. The nomadic index table approach vs typical fixed-pool block allocators in real-time engines.
3. Any potential edge cases in the anti-crash locking logic.

Thanks for taking a look!

I have a genuine question as I honestly have no idea what to do and who to ask.

I'm working on relatively complex project in Rust related to computer graphics from scratch. It's not a game engine in traditional sense, more like a graphics-rendering engine but with a notable focus to rendering graphics for video games.

It's a hobby project that I develop since around 2024 on full-time and it consists of a number of quasi-independent low-level and high-level libraries of different kind. It's far from release, even though a part of the planned infrastructure already finished and could theoretically be published on it's own.

A part of my motivation was developing a graphics-rendering infrastructure for Rust. I like Rust due to personal preferences, but unsatisfied with the current state and quality of it's ecosystem related to computer graphics. I wouldn't say that the Rust libraries ("crates" in terms of Rust) I'm developing are too innovative, but they are notably of higher quality in many aspects at least to my personal taste. I can't say whether the community would use my implementation as a replacement for already existing one, but I think it's not necessary bad addendum to the public tools.

I don't use LLMs or any kind of AI-assistance in any form in my work. I'm dedicating notable time and efforts into this project. The entire infrastructure developed completely from sratch and by hand. I also don't use any 3rd-party Rust crates. Partly, because I'm not satisfied with the quality of those, and partly because I can't confidently say whether particular Rust crate is a hand-made work too or vibe-coded. I want to stay in the hand-made field as much as possible. It's not to discourage AI-assistant tools. Some find them useful and maybe they have a point, but hand-crafting for me is a question of personal values. Also, I have prior expertise in the aforementioned fields, and I just don't trust chat-bots.

That said, even though my work might be interesting and maybe even useful for some colleague-programmers, I don't see reasonable ways to show and share it considering the current circumstances.

If I publish it just as it is as an open-source work into the public crates repository (crates-io) and to GitHub, there is a high chance it just will not be recognized. The current media space is currently full of vibe-coded projects published everyday to which I have to compete. Worse, I'm afraid my work would receive public opinion as ai-slop. A Rust library consisting hundred of thousands lines of source code developed by a single person and published as a single git-commit is an evidence of being generated by LLMs regardless of the author's claims.

The second observation is that even if the work eventually receives positive opinion, there is a chance it will be stolen using LLMs. To clarify, I don't mind if my work would be used for learning purposes, and to encourage other to work in the same field (in fact that's partially my goal too). But I'm afraid that with the current capabilities of the LLM-services it could be clean-room-reimplemented in a couple of days by feeding the source code to the chat-bot asking it implementing something similar but in slightly different form and without preserving attribution to the original author. While I maybe don't care that much about monetary interests, as many OSS developers I still care of preserving attribution and public recognition. On top of that, those who have resources (the business), obviously have competitive advantages in promoting their derivative. More restrictive licenses (e.g., GPL) are seemingly ineffective to protect from these threats today.

One possibility here is to never publish the source code, but instead publish it in form of compiled shared libraries (DLLs/so), the documentation covering only the high-level public API, and with the open-source FFI binding to these APIs. This approach even have certain practical advantages as I can provide FFI wrappers for more programming language ecosystems hence covering wider audience. Additionally, LLMs yet didn't reach the point of being capable in reverse-engineering of deeply-optimized compiled binaries into the original source.

The drawbacks is that this approach is obviously a closed-source path. Leaving aside Rust community that has strong appeal toward open-source, the programmer's community in general usually does not trust software without the source code. The gamedev community historically is slightly less harsh toward the closed-source software. We use proprietary soft (e.g., DirectX drivers or quasi-closed game engines), but usually such software coming from well-known vendors, not indie-devs like me.

Anyway, more important consequence here is that this path naturally means that I don't share the source code, which may have a value for some programmers on it's own. Basically, with the closed-source I don't publish the work itself, I'm only distributing it's engineering component.

Another possibility that came into my mind is sharing the source code with the limited number of people who I can trust and who trust me. E.g., publishing it in private GitHub repo with access to close circle of trust. This approach limits public visibility and doesn't impose full protection. Basically, I'm not publishing the work again, I just share it with some people.

Ideally, I would like to share my work without all these caveats but with the programmers to whom I can trust. Unfortunately, I can't find a community of the same-mind people. On occasion I sometimes see people (including this subreddit) that share similar values, but it seems there is no organized society.

Thanks for reading of my long-post. I think the problems I described should be familiar to many. I would appreciate if you share you thoughts and fresh ideas on the topic. Maybe I'm exaggerating the problem. And I would love to hear your opinion on this matter too.

Ilya

A look at the boot, hot reloading, selection, camera and zoom.

This is Melan, my first ever game.

I started making it in August 2023, when I was unemployed and honestly just wanted to make something so I wouldn't feel like shit about myself.

It's based on a story about a friend of mine. It was also the first pixel art I'd ever made, so I had absolutely no idea what I was doing lol.

I didn't know how to code or design games either. Back then AI wasn't really what it is now, so most of my programming knowledge came from YouTube and asking other devs for help whenever I got stuck.

And yeah... the game isn't very good.

The level design is rough, there are bugs, and I spent way too much time rebuilding things. The current version is actually the fifth time I rebuilt the game's code.

Somehow, I still managed to release it on Steam in October 2025.

It didn't make much money, so I eventually had to stop after Chapter 1.

And honestly, I don't really recommend playing it. I'm mostly sharing it because this is where I started, and I still feel weirdly proud of it.

I'm working as an art director now, and maybe someday I'll have enough money to remake Melan properly.

Anyway, that's it. Just wanted to share my first game.

https://store.steampowered.com/app/2887100/Melan/

There are a lot of posts about "new game engine", but their authors somehow forgot to note that they used AI to built that engine...

In contrast to this I want to show stats of my game engine built by me, without AI.

Story starts before AI era when I started to write 3D game engine for web to learn 3D pipeline and see how big "open world" I can achieve in web.

Few years later I decided to make mobile 3D game from my childhood and thought to port part of my engine to mobile to reuse code and also to test how it will work in real world game.

This is video recorded on Android device with real rendering resolution of 2400 x 1800 px @ 120 FPS (video is resized for smaller size) with scene of total ~500K tris using OpenGL ES 3.0. Frame render time (cpu + gpu) is ~3.8ms with forward rendering.

For this game I use from my engine (among other things) 3D scene rendering with instancing, gltf meshes loader, own simplified variant of PBR, bling phong lighting. For background used perlin noise with fbm to look like clouds.

Do you like quality of render?

You can try game itself: "Color Sort in 3D Tower Puzzle" in Google Play. Design made by me too and most of 3D models in Blender too.

Hi everyone!

After a very long development journey, I'm finally ready to share Synapse Engine, a modern, research-oriented AAA-style game engine that I've been developing essentially from scratch.

It started as my MSc thesis at the Budapest University of Technology and Economics, but grew far beyond what I originally planned. Over the past several months I've been rebuilding and refining the architecture around a simple question: What would a modern game engine look like if we designed it around today's GPUs from the ground up?

The project is now over 2,300 files, nearly 94,000 lines of C++ code and around 10,000 lines of shader code, excluding comments and blank lines.

If you just want to check out the project:

• Website: https://synapseengine.dev/
• GitHub: https://github.com/TamasPetii/SynapseEngine
• 250-page technical presentation: https://synapseengine.dev/Presentations/SynapseEnginePresentation.pdf
• Research paper: https://synapseengine.dev/Presentations/Grafgeo_High_Performance_Gpu_Driven_Rendering.pdf
• Dev Diary: https://synapseengine.dev/devblog/01-the-synapse-journey/

The GitHub README is probably the best place to start if you want a quick overview of the project and its architecture. If you're interested in modern game engine development in much more depth, I also put together a 250-page technical presentation covering the entire project, from the ECS and software architecture through GPU-driven rendering, culling, lighting, virtualized shadows and future directions.

The presentation is quite large, but I tried to make it genuinely useful as a learning resource rather than just documenting the final result.

One of my main goals with Synapse Engine is education. Learning these topics was a huge struggle for me, and it took a lot of time to piece everything together because there isn't much high-quality material that shows how these modern techniques actually come together inside a real engine codebase. I wanted to document that process and create something that I would have wanted to have when I started.

What can the engine actually do?

At its core, Synapse is a fully GPU-driven renderer using hierarchical culling, Hi-Z occlusion, cone culling, dynamic LOD selection, indirect rendering, mesh shaders, bindless resources and virtualized shadows. The engine is built around a custom data-oriented ECS and is designed to handle very large scenes with minimal CPU involvement.

For example, with 1,000,000 entities on an RTX 4060, the cumulative culling cost goes from 124.407 ms without culling to 0.653 ms with the full hierarchical culling pipeline.

However, at 10,000,000 entities, even the conventional GPU-driven hierarchical approach becomes insufficient. To address this, Synapse introduces a custom GPU-built Morton-ordered chunking system, which groups entities into spatial chunks and allows entire groups of 32 entities to be rejected at once. This reduces the culling cost from 5.8 ms to just 0.3 ms for 10 million entities.

I also developed a new rendering technique called Dual-HiZ Adaptive Clustered Forward+ while working on the engine. With 8,192 point lights and 8,192 spot lights, it measured 2.873 ms, compared to 8.652 ms for deferred shading in the same setup. The technical presentation contains a detailed explanation of how the technique works.

Synapse isn't primarily intended as a game-development tool for game developers. It is a production-ready, research and educational platform for experimenting with modern game-engine architecture and real-time rendering techniques.

The goal is not to provide a plug-and-play engine for building games, but to provide a complete, practical implementation of modern engine technologies that can be studied, extended, and used as a foundation for further research and development.

The engine is the result, but the architecture, experiments, failures and reasoning behind it are what I really want to share. If you're interested in Vulkan, graphics programming, GPU-driven rendering or modern game engine architecture, I'd love to hear what you think.

Hey everyone,

Just curious if anyone recently used Monogame, or Love2D as a base to build their game engines?

I know MonoGame recently released a update, wondering if anyone is using it..

I'm planning to try, but l wanted to see other folks experiences.

I began working on this engine at the start of 2026, it is my first time creating a 3D graphics engine so it is a bit janky in areas and features like SSAO and SSR currently perform quite badly, but to be able to optimise it has to work first so at least I'm at that stage, I used the LWJGL Vulkan book (https://github.com/lwjglgamedev/vulkanbook) and learnopengl.com for learning most of the graphics techniques but the underlying engine architecture such as multithreading, actor system and multiplayer is fully custom!

Fetch it here: https://gameapibuilder.com

Check our examples: https://meshpage.org/meshpage.php

The main page: https://meshpage.org

And some cool screenshot:

Still crunching on RTG Editor, which reached its internal version 012. RTG Editor is internal editor for my narrative sci-fi puzzle/platformer game and its respective engine. I seek to release the editor also publicly later. Main distinctive feature of my game/engine is software ray-tracing (no GPU acceleration, it's just C++ computing pixels on CPU into software buffer which is then presented on screen).

Main feature implemented in new version is proper texturing support. It was possible also before, but only in very limited capacity (only UV mapping mode was stretch to face). In current version, it's possible to define UV repeat for both axes individually. Either in absolute world coordinates or as value relative to face size. There's support for automatic aspect ratio correction (define repeat just for one axis, another will be inferred to keep aspect) and flipping texture in individual directions.

In the video I quickly edited one of the levels to have some background textured wall (2 minutes work). This is just for video showcase, I made this texture in Pixelformer in 5 minutes, not planning to use it further.

Apart from texturing, I added in new version also selection and multi-selection in orthographic view. Moreover, I implemented contextual help in form of tooltips (just hover over '?' sign) to give explanation of expected input values for properties which are not self-explaining.

RTG on Steam: https://store.steampowered.com/app/4032050/RTG/
RTG Discord: https://discord.com/invite/aRAsxCnPQ5

Hi guys, I am making my opengl c++ game engine basic renderer, assmip model loader, texture, entity system(sparse set) this things done with dear imgui i am thinking of optimization is this right time now or once i add more features then I do optimization and i am new in optimization how and what to do in optimization

Small solo project I've been chipping away at, a Vulkan-based game engine, figured I'd share where it's at.

• PBR shading using Cook-Torrance (BRDF) - just albedo, roughness, normal maps for now
• shadow mapping (dir-light for now)
• .glb,.ktx2 import
• basic AABB collision - block/resolve

Still very much a work in progress - will add metallic and point light sources next

Still learning a lot as I go, so if anyone spots something I could be doing better or has advice, I'd really appreciate it.

I spent early August writing single degree of freedom constraints that can be composed to model different kinds of mechanical joints. Here you see 3 connected hinge joints, each modeled with 3 position and 2 rotation constraints, in a simulation of a triple pendulum system.

Each constraint involves a pair of bodies, and constrains motion along (or about) a single axis relative to the first body. There's one position constraint along each of the forward, up, and right vectors relative to the hinge, keeping points on each body at a fixed distance from each other. Rotation constraints prevent rotation around the up and right vectors, while leaving rotations around the Z axis unbound.

The approach is pretty much the same as described in my XPBD write-up. First, apply position and rotation changes according to the forces and velocities of each object. Then, measure the magnitude and directions of the errors in the prediction, and distribute the corresponding corrections according to the inertias of the bodies involved in the constraint. After all corrections have been applied, derive their new velocities.

This demo uses a physics step of 17ms, with 10 substeps (1.7ms per substep) -- effectively that's 588 physics substeps per second.

The demo can be found under Examples/TriplePendulum, in the ToyMaker repo.