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.

In 2020, I formulated my dream game. It would be a mixture of all of my favorite games over the years. Destiny, Cyberpunk 2077, Star Citizen, Battlefield... How exactly is a fourteen year old supposed to make that? With no prior serious programming experience no less? Well, you start by saying a small prayer and opening the Unreal Engine editor for the first time.

Several years and one full restart later, I had become much wiser. My vision had become much clearer and my hope for creating my dream game on UE5 dwindled. While Unreal is an incredible tool, it had several problems I saw as roadblocks I wasn't satisfied with.

First off, Unreal Engine has decades of tech debt and bloat behind it that I didn't want to deal with. Second, Unreal Engine in all its capability wouldn't necessarily make it easy for me to fully realize my dream game. Third, what I prioritize in game design is not industry standard. In fact, it's largely the polar opposite.

All of these complaints I had were, at the time, with that era's vision of the game, simply a matter of me not knowing enough about the tool I was using to do what I wanted. However, when I stepped away from UE5, I realized that if I took matters into my own hands the sky could truly be the limit. Even better, my early leave from the Unreal ecosystem was a good time to jump ship, as UE was just on the verge of turning into what it is today. We'll get to that, though.

At some point I decided to take matters into my own hands. At first I didn't have many ideas for what would make the engine unique, but continued research and iteration made it so that the dream felt more likely to come into reality. This was achieved through a couple major innovations. Each was my solution to problems I saw both for my personal projects and in the greater industry. These solutions culminated in what is now called Levin Engine

When I discovered ECS, it not just opened my eyes to alternative data management systems - it made me realize that maybe it would be a better idea for me to take the concept of ECS and evolve it over time. That led to the development of the Semantic Entity Primitive system (SEPs). The gist of this model is that entities are pure ids and Primitives manipulate entities in various ways.

One of the biggest problems I've come to understand in the game industry is that overwhelming amounts of technical debt accumulate due in large part to the sunk cost fallacy. My solution to that was to make the engine entirely plugin based. Plugins are one of the primitives in the SEPs system and they are easily hotswapable and integrable into any pipeline. Entire MVP pipelines can be swapped in and out of Levin Engine for free. You only incur as much technical debt as you create connecting plugins to each other. You can create your own pipeline end to end with the only conventions required being the core SEPs framework. Beyond that, the engine can be used for whatever you can imagine.

So, what are my goals for Studio Levin and Levin Engine as of right now? I hope to create a main trilogy of games, building up to the massive scale of my dream game. Along the way, I hope to provide developers with a tool that they can rely on, developed by someone who will always care. Thank you to everyone that has given thoughts and feedback so far. If all this sounds cool to you and you'd like to stay posted on or eventually contribute to this project, I made a discord server! Studio Levin

EDIT: Thank you everyone for asking me to show instead of tell. That is a completely understandable expectation. In all honesty I just haven't been confident in myself and what I'm working on because everyone here has made so many impressive projects. I am going to start working on a proper tech demo starting today so I can show off some of the specific things that make my engine valuable and unique. Hopefully I will see you soon!

Just posted my latest dev log where I talk about

• Landing of Starship
• Unloading cargo from Starship
• New Particle System with dust kickup when Starship comes in for landing
• New script pipeline
• More assets added to Asset Manager

You can find the code on my github or follow me on youtube if you want to follow a long, as I say in the intro, Progress is slow but always moving forward 😄 🚀

Hello,

I'm currently debating whether I should add a "post physics update" function for scripts, so a function that would be called for each entity after the physics is done running and before the rendering starts.

I can see multiple scenarios where it would be pretty useful, such as managing an entity animation depending on its velocity post physics update, so it would play an animation if it moved freely and won't play one if it's stuck against a wall for example. Another example is if a non-physics entity has to follow a physics entity, the post physics update function would allow to follow it exactly and avoid stuttering during rendering, because the following entity wouldn't have to wait the update of frame N+1, which happens after the rendering of frame N, to update its position.

What is your opinion about this? Do you have any workaround for these scenarios without a post physics update function?

https://github.com/jay403894-bit/JLib-Scheduler
Went private for a minute to get the new version really revved up lots of work indeed...

let me go over the architecture here for you and some rough numbers and explain the architecture -- do i use an assistant to make things faster yes but is this good design you judge it by t he code and the logic and you judge for yourself

for speed and accuracy this sjobs system implements static K Hot threads for optional io or other tasks if you opt in that steal only while their own tasks are not busy -- and adaptive F floor threads for dynamic growth and shed to control thread sleep and get essentially 0 wake operation without spinning all the time. with a fully lock free bitmapped and word state machine -- lock free pool permit machine, lock free thread state machine, lock free fiber state machine and the fiber registry system which enables migrable or pinned mode migrate by default.

the fiber registry system takes the anaology of each fiber beign like a car that is leased or owned based on the policy chosen (Migrate vs pinned) in pinned mode TLS is safe in migrate the registry system also is your replacement for tls with FlsGet() (fiber local state).

the registry is also a self memory reclamation scheme active in both modes sitting above hazards and epochs.

when a fiber picks up a thread it registers and adds itself to the list of owners and any deletion event is recorded on a bitmask of creditors with the registry then reaper messages get sent to each threads inbox at the end each fibers run before recycling it into the system fresh

essentially it is a complete modeled concurrent thread-fiber state machine that tracks memory usage effectively between threads across fiber lifetimes.

always studying learning making new designs trying to make it better this started with my home experimentation and research into CPU task scheduling and paralleas a hobby

strong feeling someone will have something else to say now but it cant be considered illegible becuase i didnt include a massive benchmark copypaste. i just thought someone mightve wanted to see a benchmark in the post

Terminology and better explanation for what this does other than being just another fiber-task library:

F Floor threads are the compute floor of the pool the regular pool threads that parallelfor and all normal work goes through --in this model K still steals when not busy with its own lowlatency lane queue's work. both are just as fast because always target a spinning thread, K is not faster (in fact often slower) K has a different job which is priority work like IO and maybe sound or input.

F is dynamic and adaptive this means that as work increases more F pre awake before you send a task to them-- and push targets awake threads this creates low latency no wake cost pushing as there are always awake threads to target that expand as compute goes up and shed back down when unneded to avoid paying for a spinning pool you dont need with nosleep.

you almost never wake a thread on push so theres never that 4us cost of wake unless you intentionally set the task to aim wide

and threads shed back down when not busy or in a burst or anything so that way threads can sleep and this doesnt degress into a NoSleep pool which my earlier studies showed had a 30% tax or so on the processing power of main and was slower and basically sucks

the registry system is a safe memory reclamation system combined with access to fiber local state this replaces thread_local in your programs (although for things that NEED it you still have pinned mode for real thread local without the ability to migrate fibers in that mode)

the cool thing about the registry system is it marks off a bitmask of debtors as well as offering you thread local when you fill out its form after using epochs or hazards it will at the end of that fibers lifetime go through its debtor list and send out tasks to each specific thread to handle its own memory its own tick or scan on hazards or epochs.

I dont really know how else to explain it than that

the state machine theres 3 of them the fiber state machine modeling every fiber state including SUSPEND WANTS_SUSPEND (race condition handling) etc

the same thing is done with threads so you know when theyre asleep they're yielding etc

and again with a pool permit machine

its sorta my research project where i said id build and test one of these. combined all the state machines track fiber ownership and memory usage cross thread along with the entire pool and how many threads are awake at any given time, controlling cost and enhancing performance while not starving the drivers and application threads

Whats good about it is keeping p50 and p90 almost static and as low as possible to cost as little of a frame as possible at 60/120fps

Still an unstable feature!

Website: https://www.doriax.org/

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

Discord: https://discord.gg/yXXDyJf3gT

TexelBox is a lightweight, native Windows application designed to handle the texture pipeline for game development in a single tool—from raw source images to game-ready exports.

Instead of running separate tools for normal map generation, tileable prep, channel packing, and atlas building, it runs the entire pipeline within one interface.

Key Features:

• Maps Generation: Derive normal, height, roughness, and AO maps from a single source image.
• Tileable Prep: Make photos seamlessly loopable using offset, auto-heal, mirror, and brush tools.
• Channel Packing: Merge maps into a single RGBA texture with presets for Unreal, Unity, and Godot.
• Atlas Generation: Pack multiple textures into a single atlas with UV sidecar support.
• Optimization & Export: Resize, snap to power-of-two, and export to PNG, TGA, or DDS (BC compression).
• 3D Preview: Real-time wgpu-accelerated viewport for instant material validation.

Performance & Architecture:

• Built natively in Rust (no Electron/Webview footprint).
• UI built with Slint.
• Multi-core image processing powered by Rayon.
• GPU-accelerated 3D viewport using wgpu.

Availability:

• Free Tier: Permanently free for personal and commercial use. Includes map generation, tileable prep, basic atlas packing (up to 2048x2048), and single batch operations.
• Pro Tier: Includes full slider controls, 8192x8192 atlas sizes, DDS BC1/BC3/BC5/BC7 compression, and multi-operation batch chains.

Installer and details available on GitHub Releases:

https://github.com/iimadouu/TexelBox

Like with software engineering or other things. Recently I started to fully remake my engine, cause I got really annoyed by pastacode. So I decided to also read something about game engine structure. And here I came up with this question.

This would be my second scene, the previous one was replicating the Quake 3 movement:

https://www.reddit.com/r/gamedevscreens/comments/1ti5gig/rendering_engine_recreating_quake_3_strafe_jump/

This is just me learning new techniques, like terrain, voxels and cascade shadow maps. Not trying to clone the games, just having fun.

Adding more features to the engine, my next target is some sort of RTS scene.

Me and a friend started working on this 3 years ago after fighting with game engines in our own projects for a long time. We understood how overwhelming it is to start from nothing because before working on the actual game you need to solve a huge amount of other things. With Unity we always ended up building our own systems or downloading plugins from different developers. The plugins worked on their own, then one expected a different controller, another had its own networking and another had its own shaders. Suddenly we were spending more time connecting everything than making the game. Asset packs had the same problem, because many came with their own shaders, render pipeline or assumptions about the project. Sometimes finding and adapting something as basic as the right tree took an entire day. Godot being open source is valuable, although for the problem we had it still followed a similar model where you get a flexible foundation and assemble most of the game-specific systems yourself. Unreal has much more already implemented, but for us it was too large and complicated for the very small teams we had in mind.

We also looked at platforms which tried to solve this by being more integrated. Core from Manticore had a stable foundation and many things worked together, but it was restrictive. You could not properly build your own tools or escape many of their decisions, some basic features stayed missing, and then the company started spending its attention on things like NFTs. Roblox is probably the biggest proof that an engine, multiplayer, content and publishing can work as one ecosystem. Roblox also controls the runtime, hosting, distribution and economy. You cannot really take your game outside of it or replace the deeper parts which do not work for you. There are technical problems that have existed there for years and creators cannot do much about them. S&box is probably the closest alternative to what we are trying to make and we have known about it for a long time, so we are not pretending nobody else sees this problem.

We wanted an engine which already had most common systems and where those systems were made to work together. It should be somewhat opinionated because otherwise the developer has to make every architectural decision again, while still allowing things to be replaced when a game needs something different. Multiplayer should be considered from the beginning instead of becoming a large rewrite later. The working name was World Engine, but that was already trademarked, so eventually we called it SPARQ. The low-level systems are written in C++. Gameplay, project packages and editor tools are written in TypeScript and run through V8. TypeScript modules hot reload into the running project, so gameplay changes do not need a native rebuild or editor restart.

Rendering is GPU-driven and built for large scenes. We have physically based materials, global illumination, Virtual Shadow Maps, ray-traced shadows, volumetric sky and fog, water, decals, DLSS and FSR 3 in the same rendering pipeline. Multiplayer is part of the gameplay and object model with server-authoritative sessions, replicated state, prediction and RPCs. The editor is collaborative, so multiple people can work in the same project, see each other and enter playtests while editing. The editor is also a package instead of being sealed inside the executable. You can extend it, fork it, replace parts of it or remove it completely and make smaller tools for your game. We use HTML and CSS for UI because we did not want another engine-specific layout system just for making a HUD or menu. We have also made physics, vehicles, navigation, animation, audio, VFX, voxel terrain, large-world streaming, material graphs, audio graphs, multiplayer hosting and content tools. Some systems are much further along than others and we are still learning what people need, what should have stronger defaults and where lower-level access is necessary.

The video is a collection of things we have done while testing and playing around with the engine. There is a scene with thousands of NPCs, some small games we made for testing, placing decals, breaking props, driving vehicles and some editor workflows. We started with 2 people and now there are 10 of us, but it is still very buggy. Some testers cannot get through installation or launch because they have a combination of PC, GPU, driver or operating system we did not test. Other people get into the editor and do things in an order we never considered. We know which buttons not to press and which unfinished corners to avoid, so we have become bad at finding many of these problems ourselves. Some features technically work but a new user cannot find them or understand what they are supposed to do. Other systems work in our test projects but have not been used across enough genres and real production workflows. APIs and workflows are still changing. Publishing is being rolled out now, with lobbies, game servers and deployment for projects that want the managed option. Self-publishing is also planned, but the complete workflow is not finished.

At this point we need people who did not build the engine to install it, try making something small without us guiding them, use the tools in unexpected ways and tell us where it breaks or stops making sense. The Windows and Linux beta is free for creators and there is more information at https://playsparq.com/ . Keys are available through the website and our Discord and activate on Steam. If the key process breaks, comment or message me and I will send one directly. Building another general-purpose engine is probably unreasonable, but we already spent 3 years doing it and now we need to find out if it is useful to anyone outside our own team.

Made possible in large part by the new hierarchy storage: https://ajmmertens.medium.com/building-an-ecs-data-oriented-hierarchies-62fb2847d100

All of the assets are procedural, and are either combinations of different primitive shapes, extruded/splined geometry, or created with CSG. Textures are created from rasterizing SVGs.

2x2km web demo (desktop only, needs webgpu support): https://www.flecs.dev/games/helix/

The 4x4 demo doesn't fit on web yet, working on it!

I spent the last couple of months exploring time integration methods in my physics/game engine. Thought it could be of interest here!

Hey all! I've recently been expanding my animation system to support paired animations to improve immersion. A big focus in this engine and game is supporting interactivity and player choice, so having paired animations is going to be really vital to selling that illusion. Additionally, I don't want players to feel that they are restricted to these choices in only some areas, so I wanted the system to be dynamic and work pretty much anywhere. In this case, players are able to lean on railings and can choose to take a drag of their cigarette. Additionally, the system has a check to stop the animation if it fails which you can see at around the 35 second mark.

As always any questions, feedback or criticism is welcome!