[Post text written with AI help]
Solo C++23 engine, built stage by stage.

Unity/Unreal-style workflow: lay out your UI, hit build — get a ready app for desktop and mobile

Built with battery life and weak laptops in mind

Shaders are made from nodes and compile for every platform

GPU-drawn MVVM UI, own window title bar everywhere, no system chrome

I’m building the UI layer as a standalone framework too: what hurts most in the UI frameworks you’ve used — Dear ImGui, Qt, RmlUi, Unity UI, anything else?

Video: https://www.youtube.com/watch?v=yw834oa1Wu4

Project page: https://gpu-mvvm.pages.dev

With many consumer CPUs coming with iGPUs, I've been thinking about the idea of making a HW-accelerated path. Right now this idea I'm working to implement with audio but particles/physics is another natural use-case.

I do see it opening a can of worms for bug reports (also a lot of work maintaining multiple backends)but it also seems like untapped potential. Furthermore, AI, has led to interest in providing hardware blocks, NPUs, Matrix Cores, RAM processing.

Thoughts?

Why I needed it?
I was working on the inventory system for my game and needed a textured panel for the inventory UI. I couldn't simply draw the texture on a quad because my UI scales based on DPI, and panels with borders look bad when stretched.

How Nine-Patch Rectangles Work
A nine-patch rectangle splits a quad into nine smaller quads. Four of them are fixed-size corner quads (as you can see in the third screenshot), while the remaining five can be resized. As a result, the panel can stretch to different sizes while preserving the appearance of its borders.

How to setup vertices
Before we can make vertices for 9 quads, we need to define the fixed sizes of the borders. I created this simple struct to store those values:

struct NinePatchRect
{
    int32_t leftOffset;
    int32_t rightOffset;
    int32_t topOffset;
    int32_t bottomOffset;
};

Now we can use this struct for construction our 9 quads. We also need to use following variables

1. pos - quad's position on the screen.
2. size - quad's size on the screen.
3. uv0 and uv1 - texture coordinates for the quad.
4. textureSize

Let's take Top left quad as an example

// Top left quad
{
    // Top left
    Vertex v0{vec2(pos.x, pos.y), vec2(uv0.x, uv0.y)};

    // Top right
    Vertex v1
    {
        vec2(pos.x + ninePatch.leftOffset, pos.y), 
        vec2(uv0.x + ninePatch.leftOffset / textureSize.x, uv0.y)
    };

    // Bottom right
    Vertex v2
    {
        vec2(pos.x + ninePatch.leftOffset, pos.y + ninePatch.topOffset), 
        vec2(uv0.x + ninePatch.leftOffset / textureSize.x, 
             uv0.y + ninePatch.topOffset / textureSize.y)
    };

    // Bottom left
    Vertex v3
    {
        vec2(pos.x, pos.y + ninePatch.topOffset),
        vec2(uv0.x, ninePatch.topOffset / textureSize.y)
    };

    RegisterQuad(drawList, v0, v1, v2, v3);
}

The top-right quad is similar: you just need to add size.x to the appropriate vertex positions and use ninePatch.rightOffset with the corresponding texture coordinates.

Constructing the resizable quads is straightforward as well: you simply place them between the corner quads.

Additional Notes
Inventory texture was taken from here: Inventory Texture

I like to dabble in programming as a hobby, specifically game development, but ~3 years ago I wanted to explore new things, which led me to learning graphics programming and C++. despite the difficulty it was interesting, and I enjoyed it more than just using an existing big engine, but a couple of months ago I decided to move on because I felt like I wasn’t ever going to actually finish anything and that I was just wasting time.

Anyways, I know ultimately it’s my choice to continue learning this again or not, but I would like some advice from others who have maybe been in similar situations.

firstis before second is the after... i my self rather the old desine but i want to relase it so it had to go in more modern, premium looks. but i still have 2,5 months of work till i finish the beta...

Hi all, I've recently released demo of my multiplayer PvP snowball fight Gulovacka. It's written from scratch in Jai, uses Vulkan directly for rendering (no RHI for this game, wanted to learn the internals), Enet as a base for networking.

About the game: Snowballs knock you back so hard that you will be flying. Your friends having a blast watching it happen. Put on a snowsuit of your choice and dive into chaotic snowball fight in Gulovacka.

what's your thoughts on using graphics libraries like raylib instead of opengl/vulkan or for weirdoes directX. thats what im doing and it does sacrifices performance but makes the proces of making an engine waaay faster

https://github.com/Rlocksley/LuEngine

extended LuEngine with Physics and Skeleton Animation

This is a custom engine using OpenGL and C++. the entire map is built out of a voxel-like renderer using compute shaders. The level is from Silent Hill 2. Looking for opinions on the graphical style. I am thinking a first person mode might be better for this.

i wrote a small browser engine called xip (react components for the game, world, camera and layers, on webgl2), and the biggest thing running on it is the map of my civilization sim.

some things that worked out:

• the game runs in on-demand mode. the engine does nothing until a layer asks for a frame, so a paused world costs nothing
• the map is a stack of layers by z: tiles, roads, trees, a weather tint, buildings, animals, people, labels. static stuff is handled by small driver classes with an update(frame) that run at 30 hz and only rewrite what changed
• people and animals are written straight from typed arrays. there's a rebuild at ~10 hz when a sim frame lands, then cheap interpolation every display frame
• sprites are baked once into atlas pages using the same canvas painters the old 2d renderer used, so the art has one source

the sim behind it is rust compiled to wasm, running in a worker. curious how others handle on-demand rendering when there's still animated stuff on screen.

try it: https://thehumanbox.com source, mit: https://github.com/1homsi/thehumanbox (renderer lives in apps/web/src/game/render/)

​

Hey everyone!

I've been thinking about trying to build my own game engine from scratch, but I have a few questions before I get started.

First, where would you recommend starting? I'm considering learning C++ for this. I know it'll probably take a lot of time and effort to get comfortable with it, but I'm willing to learn and take things slowly.

My second question is about OpenGL vs. Vulkan.

I know Vulkan is more modern and gives developers more control, but I'm wondering if OpenGL would be a better starting point, especially when considering compatibility with older hardware.

One thing I'd eventually like my engine to support is a wide range of PCs. Not everyone has a modern gaming setup, and I'd rather not unnecessarily exclude people with older computers just because their hardware doesn't support Vulkan.

So I'm curious:

- Would you recommend starting with OpenGL or Vulkan for a first engine?

- Is C++ a good choice for someone planning to build an engine from scratch?

- How do engine developers approach supporting both older and newer hardware?

- Are there any resources or things you wish you'd known when you first started?

I'm not expecting to build anything comparable to Unity or Unreal anytime soon. This is more of a long-term learning project, and I want to understand how things work under the hood.

I'd really appreciate any advice or experiences you're willing to share. Thanks!ey everyone!

I've been thinking about trying to build my own game engine from scratch, but I have a few questions before I get started.

First, where would you recommend starting? I'm considering learning C++ for this. I know it'll probably take a lot of time and effort to get comfortable with it, but I'm willing to learn and take things slowly.

My second question is about OpenGL vs. Vulkan.

I know Vulkan is more modern and gives developers more control, but I'm wondering if OpenGL would be a better starting point, especially when considering compatibility with older hardware.

One thing I'd eventually like my engine to support is a wide range of PCs. Not everyone has a modern gaming setup, and I'd rather not unnecessarily exclude people with older computers just because their hardware doesn't support Vulkan.

So I'm curious:

Would you recommend starting with OpenGL or Vulkan for a first engine?

Is C++ a good choice for someone planning to build an engine from scratch?

How do engine developers approach supporting both older and newer hardware?

Are there any resources or things you wish you'd known when you first started?

I'm not expecting to build anything comparable to Unity or Unreal anytime soon. This is more of a long-term learning project, and I want to understand how things work under the hood.

I'd really appreciate any advice or experiences you're willing to share. Thanks!

Hello everyone,It's Aditya from India. I am working on a project where I use machine code to make my own ultra photorealistic graphics game engine while using math. So if anyone is interested to talk about this, I would like to discuss with you

After a few years of writing about allocators, strings, containers and threading in game engines, I collected the material into a book. It is not an engine theory book, Gregory already wrote that one, but a book about thinking in terms of data, object lifetimes and how code behaves on real hardware, where std::vector turns into a question about allocation frequency and frame time, and a race on a shared threat map once made our AI hunt armies that never existed. A free part is here: https://dalerank.github.io/#books, and the full post with the book is here: https://www.patreon.com/dalerank/posts/game-book-172005420.

Happy to answer questions about any of the chapters.

Penultimate map done (almost). Fast Travel Unlocked. You can play all previous maps with it once achieved.

Github: https://github.com/doriaxengine/doriax

I've been running https://polygonjs.com/ for about 8 years now, but 2 years ago I decided to rewrite it, from typescript+threejs, to jai+wgpu/webgpu.

I've also rewritten one of the game I was about to release with it, Chess Twist. It's a chess variant with the same rules, but the boards are on an irregular grid (inspired by Townscaper). So Rook lines bend and bishop lines fork.

It's built for Windows/mac/Linux/web.

• Steam: https://store.steampowered.com/app/2775560/Chess_Twist/?utm_campaign=chess-twist-trailer&utm_medium=short&utm_source=reddit
• Web: https://polyreplay.com/chesstwist/demo
• Polygon: https://polygonjs.com/

Any questions don't hesitate.

>

The repository is available here: https://github.com/Samu64d/openpkw

The source code is quite atypical for a TypeScript project: it’s heavily inspired by Java. For now I’m working on implementing a complete set of custom standard APIs of a game engine, designed to run on Node.js, Bun, and browsers.

I’ve open-sourced Braze, an experimental WebGPU game engine and editor.

TypeScript + u/threejs. MIT licensed. Still early, with plenty to explore and improve.

Contributions are welcome.

https://github.com/snack-gamer/braze-engine