Mach is a game engine & graphics toolkit for the future.

Overview

Mach - Game engine & graphics toolkit for the future

Mach engine CI Hexops logo

⚠️ Project status: in-development ⚠️

Under heavy development, not ready for use currently. Follow @machengine on Twitter for updates.

Zero fuss installation & cross compilation

Mach is built from the ground up to support zero fuss installation & cross compilation, only zig and git are needed to build from any OS and produce binaries for every OS.

You do not need any system dependencies, C libraries, SDKs (Xcode, etc.), C compilers or anything else.

If you've ever worked with game engines in Go, Rust, or any other language you've probably run into issues at one point getting the right system dependencies installed, whether it be Xcode versions, compilers, X11/GLFW/SDL C dependencies, etc.

Mach is able to do this thanks to Zig being a C/C++ compiler, Zig's linker zld supporting macOS cross compilation, and us doing the heavy lifting of packaging the required system SDK libraries and C sources for every dependency we need so our Zig build scripts can simply git clone them for you as needed for the target OS you're building for, completely automagically.

Supported platforms

Mach is still incredibly early stages, so far we have support for building from the following OS to the following targets:

Building for From macOS x86_64 From macOS M1/aarch64 From Linux x86_64 From Windows x86_64
macOS x86_64 ⚠️ #8
macOS M1/aarch64 ⚠️ #8
Linux x86_64 🏃 🏃 🏃 🏃
Windows x86_64
iOS 🏃 🏃 🏃 🏃
Android 🏃 🏃 🏃 🏃
  • Tested and verified via CI.
  • ✔️ Should work, not tested via CI yet.
  • 🏃 Planned or in progress.
  • ⚠️ Implemented, but has known issues (e.g. bugs in Zig.)
Issues
  • mach: decide on high-level abstraction API

    mach: decide on high-level abstraction API

    This is speaking of the currently in-development mach API - what most people will use to build Mach applications.

    Goals

    • Provide an abstraction over GLFW, Browser APIs, and Android/iOS APIs, for input/windowing/etc.
    • Provide a way to expose platform-specific behavior when neccesary.
    • Should be usable in very modular ways:
      • "I just want a cross-platform window/input basically, I'll use WebGPU directly for rendering and pretty much nothing else Mach provides"
      • "I want features XY that Mach provides, but not Z"

    State of things today

    As it stands today, your main program is defined as an App struct. Mach consumes this, defines the main entrypoint and calls your application init function and so on. This is the same design from xq's excellent zero-graphics library.

    We then have:

    • App -> your application
    • mach.Engine -> given to most functions and provides access to core engine functionality (the abstraction)
    • mach.Timer -> cross platform timer that works in wasm
    • engine.gpu_driver.swap_chain -> the swap chain
    • engine.gpu_driver.device -> the actual gpu.Interface WebGPU API
    • engine.core.pollEvent() -> event polling
    • engine.core.setSizeLimits() -> window abstraction functions

    The callbacks your App main.zig can define are:

    • pub fn init(app: *App, engine: *mach.Engine) !void
    • pub fn deinit(app: *App, engine: *mach.Engine) void
    • pub fn update(app: *App, engine: *mach.Engine) !bool
    • pub fn resize(app: *App, engine: *mach.Engine, width: u32, height: u32) !void

    Open questions / what this issue is about

    How should the API look?

    proposal-accepted proposal 
    opened by slimsag 33
  • ECS research

    ECS research

    The point of this issue is to collect material / research the best way to write an ECS in Zig leveraging DOD and unique language features like comptime. If anyone has thoughts, please do chime in!


    Things I need to look into more / form opinions about:

    • https://bevyengine.org/learn/book/getting-started/ecs/
    • ECS back and forth blog
    • https://github.com/SanderMertens/flecs
    • https://github.com/Leopotam/ecs
    • prime31: "i did a loose port of EnTT to zig." https://github.com/prime31/zig-ecs
    • Bitron: "by far the best experience I had was with bevy ecs. the way you write systems feels just right."

    kbm:

    flecs. [...] It seems like a great library and I love the features in theory. But I'm not sure if I'm ever going to actually use all of those. Coming from that C# ECS library I used (Entitas) I try to avoid bloat as much as possible from now on.

    Entitas actually had code-generation. So you had to write components and then each time run a script that generates some glue-code. After ~3 years and 1000 components it became a complete nightmare.

    prime31:

    Flecs is exact opposite of bloat. compared to entitas its tiny its also module based, so you can just use the root storage when i use it, i basically just use sorting and its queries. it lets you do whatever you want with systems. you can make your own system scheduler, iterate multiple queries simultaneously, etc. Very flexible

    slimsag:

    The mention about Entitas having code generation is interesting, one thought I had is that if we do not need entities of different types to be in the same e.g. global list, we can leverage comptime to build entity types with components as dedicated fields which would likely be quite efficient

    kbm:

    yeah Entitas used code generation to generate a bunch of interfaces, to facilitate "better readable" code.

    so you could make a PositionComponent {x,y} and hit code generation to generate helper methods which give you stuff like entity.ReplacePosition(x, y) or entity.RemovePosition(x, y)

    Bitron:

    in bevy it looks something like this:

    struct Velocity {..}
    struct Position {..} 
    
    fn main() {
      App::new().add_system(physics).run();
    }
    
    fn physics(mut query: Query<(&mut Position, &Velocity)>) {
      for (mut pos, vel) in query.iter_mut() {
        pos += vel;
      }
    }
    

    prime31: "you can get almost exactly that with Flecs too 😉"

    people I might be able to run ideas by later:

    • prime31
    • kbm
    • Bitron
    • idhank (iddev5)
    opened by slimsag 17
  • Add cube and some more examples, zmath for testing

    Add cube and some more examples, zmath for testing

    • [X] By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.
    opened by PiergiorgioZagaria 15
  • gpu-dawn: reduce Dawn build and iteration times

    gpu-dawn: reduce Dawn build and iteration times

    Update: Before I opened this issue, build and iteration times were quite slow. We've made good progress, keeping this issue open for further improvements. Results so far:

    macOS M1 (original chipset) w/16GB RAM:

    | zig build action | Before | After | Improvement | |---------------------|--------|-------|-------------| | From scratch | 3m14s | 2m38s | 18% | | No changes | 19.4s | 1.3s | 93% | | One file changed | 23.7s | 7.9s | 67% | | libgpu.a size | ? | 41M | ? | | dawn-example size | ? | 17M | ? |

    gpu build-system 
    opened by slimsag 15
  • glfw: Friendlier window creation

    glfw: Friendlier window creation

    GLFW's C API uses "window hints", which aren't hugely user friendly. In Zig, we can do much better by using an "options" struct with default values. My own GLFW wrapper does this for GLFW's window creation, which makes the API much nicer in my opinion.

    It could be argued this deviates too far from the C API, but at the same time it doesn't really change much - just combines a few function calls into one, making the API use Zig idioms. I think of it similarly to error handling.

    Here's an example of how window creation could look using an options struct:

    const window = try glfw.Window.create(640, 480, "Hello, mach-glfw!", .{
        .monitor = monitor,
        .context_version_major = 4,
        .context_version_minor = 5,
        .opengl_profile = .core,
    });
    
    glfw in-progress help-welcome 
    opened by silversquirl 14
  • gpu: experiment: pure-Zig WebGPU implementation

    gpu: experiment: pure-Zig WebGPU implementation

    This issue is for tracking an experiment for a pure-Zig WebGPU implementation.

    Tradeoffs of using Google's Dawn

    Today Mach relies on Dawn (Google Chrome's WebGPU implementation) as it's graphics abstraction layer, specifically we maintain a fork of Dawn and we do a lot of heavy lifting in mach/gpu to translate all of Dawn's build configuration files to Zig's build system, maintain native system SDKs, etc.

    This has several benefits:

    • Dawn will be shipped with Google Chrome sometime in 2022 and will thus be one of, if not the most, battle-tested WebGPU implementations in existence.
    • Google, Intel, and others throw significant resources behind Dawn and it's shader compiler, Tint. Look at the commit history and you'll see there are multiple improvements daily and several engineers working on it.
    • Dawn seems to be the most mature WebGPU and actively developed implementation today (this is debatable and just my personal opinion.)
    • It is all C++/C/ObjC so we can compile it with the zig compiler, we already have cross-compilation working for macOS and Linux, Windows is not far off.

    There are drawbacks:

    • On very modern laptops, Dawn takes 3-8 minutes to compile currently We've managed to reduce this already, and have identified ways to reduce it further - but doing so is quite a chore. In some cases, we're not sure changes will be accepted upstream to eliminate dependencies as Chrome gets them for virtually free.
    • Dawn produces massive binaries, the static lib out of the box with our build setup is ~1GB in size. This increases link times. We've reduced it to ~50MB with omission of debug symbols, but still.
    • Compilation on Windows is something we will solve, but is a real challenge. Dawn wants to support Windows UWP apps in the past, and so it depends on UWP headers and we need to patch these dependencies out. Dawn's shader compiler, Tint, targets HLSL and so needs an HLSL compiler still - DirectXShaderCompiler - which is a fork of LLVM and further adds to the chonkyness.
    • Dawn needs to target the widest array of devices: OpenGL and OpenGL ES fallbacks, DirectX 11 in addition to DirectX 12, older versions of macOS / Metal, etc.

    Overall, Dawn is a battle-tested production-worthy WebGPU implementation. There are good and bad aspects to that.

    Tradeoffs of using gfx-rs/wgpu-native?

    • Compared to Dawn, gfx-rs has much better compilation times - less than a minute compared to Dawn's 3-8 minutes on macOS. If you eliminate Dawn's dependencies on spirv-tools (which is perfectly doable on macOS) they are comparable, unsure about on other OS.
    • gfx-rs requires a full Rust toolchain, and complications the cross compilation story significantly (need to manage Rust cross compilation toolchains, etc.)
    • Binaries are available, but that's not much of an advantage (we could do the same with Dawn easily)

    My assessment is that gfx-rs is a quite strong WebGPU implementation, likely to be on par with Dawn in the future, but overall compile times are still slow, cross compilation would be harder, and I do not want a hard dependency on a Rust toolchain.

    The case for a pure-Zig WebGPU implementation

    • Blazing fast compile times. That's a big one.
    • Having a pure-Zig implementation would allow for ourselves to contribute to the WebGPU implementation more easily, fix bugs when they are present, etc. It's fun and pleasant to dive into Zig code.
    • Having a pure-Zig implementation would open the door for someone to easily add Nintendo Switch and PS5 support using their native graphics APIs.

    Of course, it cannot be understated that this is still a massive undertaking. And so:

    • We could start by targeting just D3D12, Vulkan, and Metal (no D3D11, OpenGL, or OpenGL ES fallbacks.) In theory, this would make our implementation simpler, lighter weight, easier to cross-compile, etc.
    • We can in the short/medium-term still utilize Google's Tint shader compiler for WGSL->(SPIRV/HLSL/MSL), as the shader compiler does appear to be by far the most complex aspect of a functioning WebGPU implementation. We can also leverage Tint as a test bed to compare our own shader compiler against.
    • Tint and Naga both aim for ultra widespread hardware compatibility, and so for e.g. DirectX and Metal backends they perform WGSL->HLSL->DXIL, WGSL->MSL->AIR. We could aim to skip this intermediate text representation and target DXIL (DirectX IL, a subset of LLVM IR) and AIR (Apple IR, also LLVM IR-like, but we'd need to do a cleanroom reverse engineered implementation of it a bit.)

    Lastly, we will still have Dawn as an option - potentially even with binary builds to work around the compilation speed issue - so that one can just flip a build switch and go between the pure-Zig or Dawn implementation.

    How this will work

    1. Make mach/gpu expose a Zig WebGPU interface (similar to the std.mem.Allocator interface) which can plug various implementations:
      • In the case of Dawn, there will be a webgpu.h-backed implementation.
      • In the case of browsers, there will be a JS-backed implementation.
      • In the case of our pure-Zig implementation, we will implement the interface directly.

    Such an interface is useful for many reasons: one could implement a WebGPU interface that wraps another and provides API tracing/perf measurements, record/replay, serializing over a network, etc.

    1. Begin toying around with implementing this for Metal, DirectX 12, and/or Vulkan. The sky is the limit here, really, so help is very welcome.

    I've began toying with a Metal implementation (not very far at all, just far enough to realize how large an undertaking this is) and will work on completing #1 so we have "something" in place.

    Outcomes

    It's very possible we learn this is too much work and/or not worth it. In such a case, most of it would be scrapped!

    gpu experiment 
    opened by slimsag 13
  • (regression) x86_64-macos -> aarch64-macos cross compilation failing after update to Zig master

    (regression) x86_64-macos -> aarch64-macos cross compilation failing after update to Zig master

    After updating to latest Zig master https://github.com/hexops/mach/pull/107 we find an intriguing failure when cross compiling x86_64-macos -> aarch64-macos.

    Notably, linux/windows -> aarch64-macos do not fail.

    image

    https://github.com/hexops/mach/runs/4339864442?check_suite_focus=true

    bug glfw in-progress build-system 
    opened by slimsag 13
  • gpu: build idiomatic Zig interface to WebGPU, abstract away native+browser support

    gpu: build idiomatic Zig interface to WebGPU, abstract away native+browser support

    This would give us a truly nice, cross-platform, seamless graphics API across browsers, mobile and desktop via Vulkan, Metal, and OpenGL as fallback.

    Use the same Zig API for:

    This is also the only truly cross-platform graphics API being blessed by major vendors (e.g. Apple) which leads me to believe it has a real shot long-term at displacing the tried and true Vulkan+Metal+OpenGL combo. And even if it doesn't, there has been a massive undertaking to offer a unified API of that Vulkan+Metal+OpenGL combo in forming WebGPU that very few will be able to effectively beat in the general case (e.g. I think we can effectively beat Godot's, potentially Unity and Unreal's, graphics API abstractions using WebGPU.)

    gpu in-progress 
    opened by slimsag 13
  • glfw: should use u32/i32/etc everywhere instead of usize/isize

    glfw: should use u32/i32/etc everywhere instead of usize/isize

    Currently it produces an isize width and height, which matches the GLFW int type. But presumably a framebuffer is always positive and there's not a good reason to use signed integers?

    glfw help-welcome 
    opened by slimsag 11
  • glfw: Window hints rework

    glfw: Window hints rework

    ~~I took a different approach to the one used for initialization hints, because I realized that it would probably a lot of overhead to call Window.hint for every possible hint, compared to how status quo allows one to avoid that overhead; as well, it would probably be a lot harder to maintain, given that, unlike InitHint, window initialization hints are of more types than just booleans.~~ ~~This approach is (quite a bit) more verbose, but avoids the overhead, and probably makes it easier to maintain.~~

    Also, I found that context_revision and context_no_error are listed in Window.Hint, but are not listed as hints in the docs, only as attributes; I commented them out to make what I have pass tests - is this intentional and I'm missing something, or is this the result of some mishap?

    Edit: ~~it should also be noted that unlike the change made to initialization hints, I didn't completely re-use the in-place API, because I ran into some issues regarding the type-inference in the Window.hint function, so you'll see I ended up re-implementing the code for Window.hint in HintValue.set (where HintValue is a tagged union, with a tag type of Hint).~~

    Edit: as pointed out by @silversquirl, there isn't actually a lot of overhead involved in the struct approach, so now the union slice is no more. ~~Now just to address the other components of this problem, such as Window.hint, which seems to have some some type inference issues which caused compilation to fail under this new model. Should we try and rework it, or discard it in favor of Hints.set (private function)?~~

    Edit: Closes #65

    • [x] By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.
    opened by InKryption 11
  • add hasEvent(), waitEvent(), and waitEventTimeout()

    add hasEvent(), waitEvent(), and waitEventTimeout()

    • [x] By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.
    opened by david-vanderson 10
  • Add a way for non-game Mach apps to opt-out of linux gamemode support

    Add a way for non-game Mach apps to opt-out of linux gamemode support

    With #437 just merged, I realize now all Mach apps will enable Linux gamemode if present on the OS. This is not always ideal, as some Mach apps will be desktop apps.

    We should make this a linux_gamemode option which defaults to true similar to how we have power_preference for GPUs: https://github.com/hexops/mach/blob/6eaacde4443cb25e17715d15778914ebf33ec066/src/structs.zig#L46-L47

    opened by slimsag 0
  • Error running sysaudio on M1 Mac

    Error running sysaudio on M1 Mac

    Apple M1 Max. macOS Version 12.5 (Build 21G72) Zig stage1 version 0.10.0-dev.3361

    ➜  sysaudio git:(main) ✗ git log -1 | tee
    commit eecbad403ca4205ed90ef97f3cd07a3da8def671
    Author: Ali Chraghi <[email protected]>
    Date:   Tue Jul 26 11:31:04 2022 +0430
    
         dev: add other workflows to ci-lint.sh
    
    ➜  sysaudio git:(main) ✗ stage1 build test
    All 2 tests passed.
    Test [3/6] test "connect to device from descriptor"... FAIL (DeviceUnavailable)
    /Users/jonas/src/zig/mach/sysaudio/src/soundio.zig:114:21: 0x1049fa60b in soundio.requestDevice (sysaudio-tests)
                        return if (switch (config.mode.?) {
                        ^
    /Users/jonas/src/zig/mach/sysaudio/src/main.zig:59:5: 0x1049f793f in requestDevice (sysaudio-tests)
        return self.backend.requestDevice(config);
        ^
    /Users/jonas/src/zig/mach/sysaudio/src/main.zig:93:15: 0x1049f4fe7 in test "connect to device from descriptor" (sysaudio-tests)
        const d = try a.requestDevice(device_desc);
                  ^
    Test [6/6] test "requestDevice behavior: invalid id"... SKIP
    4 passed; 1 skipped; 1 failed.
    The following command exited with error code 1 (expected 0):
    cd /Users/jonas/src/zig/mach/sysaudio && /Users/jonas/src/zig/mach/sysaudio/zig-cache/o/d6f82801c5e948c289a0562cab56fa09/sysaudio-tests /Users/jonas/src/zig/zig/build/stage1/bin/zig
    error: UnexpectedExitCode
    /Users/jonas/src/zig/zig/build/stage1/lib/zig/std/os.zig:2749:19: 0x10275ba7f in std.os.mkdiratZ (build)
            .EXIST => return error.PathAlreadyExists,
                      ^
    /Users/jonas/src/zig/zig/build/stage1/lib/zig/std/os.zig:2709:9: 0x10275b903 in std.os.mkdirat (build)
            return mkdiratZ(dir_fd, &sub_dir_path_c, mode);
            ^
    /Users/jonas/src/zig/zig/build/stage1/lib/zig/std/fs.zig:1332:9: 0x10275b78f in std.fs.Dir.makeDir (build)
            try os.mkdirat(self.fd, sub_path, default_new_dir_mode);
            ^
    /Users/jonas/src/zig/zig/build/stage1/lib/zig/std/build/RunStep.zig:277:17: 0x1027b8ad7 in std.build.RunStep.runCommand (build)
                    return error.UnexpectedExitCode;
                    ^
    /Users/jonas/src/zig/zig/build/stage1/lib/zig/std/build/RunStep.zig:183:5: 0x1027a599b in std.build.RunStep.make (build)
        try runCommand(
        ^
    /Users/jonas/src/zig/zig/build/stage1/lib/zig/std/build.zig:3648:9: 0x10275c08b in std.build.Step.make (build)
            try self.makeFn(self);
            ^
    /Users/jonas/src/zig/zig/build/stage1/lib/zig/std/build.zig:508:9: 0x10275b213 in std.build.Builder.makeOneStep (build)
            try s.make();
            ^
    /Users/jonas/src/zig/zig/build/stage1/lib/zig/std/build.zig:502:17: 0x10275b187 in std.build.Builder.makeOneStep (build)
                    return err;
                    ^
    /Users/jonas/src/zig/zig/build/stage1/lib/zig/std/build.zig:463:13: 0x10274f67b in std.build.Builder.make (build)
                try self.makeOneStep(s);
                ^
    /Users/jonas/src/zig/zig/build/stage1/lib/zig/build_runner.zig:213:21: 0x10274b123 in main (build)
                else => return err,
                        ^
    error: the following build command failed with exit code 1:
    /Users/jonas/src/zig/mach/sysaudio/zig-cache/o/3f4d6a422165d32c99ee7fbd383f9521/build /Users/jonas/src/zig/zig/build/stage1/bin/zig /Users/jonas/src/zig/mach/sysaudio /Users/jonas/src/zig/mach/sysaudio/zig-cache /Users/jonas/.cache/zig test
    
    opened by kamidev 8
  • Add system_sdk option to disable/ignore system SDK

    Add system_sdk option to disable/ignore system SDK

    The system SDK process is unfriendly to Nix packaging because Nix packages happen in a readonly environment with minimal dependencies. I don't want my build process to be able to use "git" but I can work around that. Unfortunately, I can't workaround system_sdk running git fetch and so on and trying to write to a read-only filesystem.

    For the purpose of specific OS packages, I'd prefer to just have the option to disable the system SDK inclusion and rely (or fail) on local system packages.

    Alternatively: I've tried making SDK_PATH work as a workaround and it works but this still calls git fetch. So an alternate approach is perhaps to support specifying a non-Git checkout of the system SDK.

    opened by mitchellh 1
  • gpu-dawn binaries for x86_64-macos.11.6.6...11.6.6-none not available.

    gpu-dawn binaries for x86_64-macos.11.6.6...11.6.6-none not available.

    Hi there :)

    I just wanted to try out mach and haven't used zig before. Here is the error I got on my Mac (Intel) is there an easy way to fix it?

    mach 🍎 zig build run-example-boids
    error: gpu-dawn binaries for x86_64-macos.11.6.6...11.6.6-none not available.
    error: -> open an issue: https://github.com/hexops/mach/issues
    error: -> build from source (takes 5-15 minutes):
    error:        use -Ddawn-from-source=true or set `Options.from_source = true`
    
    opened by geekynils 4
  • Capacity calculation can overflow resulting in an infinite loop at runtime or a panic in debug/safe

    Capacity calculation can overflow resulting in an infinite loop at runtime or a panic in debug/safe

    see https://github.com/ziglang/zig/issues/12099

    try storage.ensureTotalCapacity(gpa, math.maxInt(usize));
    

    @addWithOverflow would solve this case.

    https://github.com/hexops/mach/blob/f8f4dcf55fc0b7365abfa66304e1f781b5f4eb42/ecs/src/entities.zig#L130-L133

    opened by tauoverpi 1
Owner
Hexops
Experiment everywhere
Hexops
Enfusion Artifical Intelligence for DayZ and future Bohemia Interactive games.

Enfusion AI Project (eAI) This mod adds headless player units under the control of a script on the server. Although the script is very rudimentary now

William Bowers 56 Aug 5, 2022
CLUSEK-RT is a complex game engine written in C++ and the successor of the CLUSEK game engine

CLUSEK-RT is a complex game engine written in C++ and the successor of the CLUSEK game engine. This engine has been designed with a cross-platform design in mind. Thanks to Vulkan API it delivers a next-gen experience with ray tracing to both Linux and Windows platforms

Jakub Biliński 33 Jul 28, 2022
Ground Engine is an easy to use Game Engine for 3D Game Development written in C++

Ground Engine is an easy to use Game Engine Framework for 3D Game Development written in C++. It's currently under development and its creation will b

 PardCode 54 Aug 10, 2022
Procedural Mesh Modeling Toolkit for Unreal Engine Artists

OpenLand Mesh Procedural Mesh Modeling Toolkit for Unreal Engine Artists. Installation Get it via the marketplace ??️ For non-commercial projects, you

GDi4K 23 Aug 1, 2022
Engine-3D is a 3D-Graphics Renderer built from scratch in C++

Engine3D Engine-3D is a 3D-Graphics Renderer built from scratch in C++, as an Undergraduate Computer Engineering Project for 5th Semester, assigned by

Chirag Lamsal 4 Nov 15, 2021
Yet another approach to developing a personal 3D graphics engine. Windows + Direct3D 12.

RegEngine Yet another approach to developing a personal 3D graphics engine. Windows + Direct3D 12. Work in progress... Nothing to see here. I just ren

Adam Sawicki 8 Jun 22, 2022
DigitalVox4 - Metal Graphics Engine

DigitalVox is the name of a series. Although each version is based on a component system, the specific implementation is very different. Therefore, different code repositories are used for management.

yangfengzzz 8 Jun 11, 2022
Godot Engine – Multi-platform 2D and 3D game engine

Godot Engine 2D and 3D cross-platform game engine Godot Engine is a feature-packed, cross-platform game engine to create 2D and 3D games from a unifie

Godot Engine 51.6k Aug 3, 2022
Flax Engine – multi-platform 3D game engine

Flax Engine – multi-platform 3D game engine

Flax Engine 3.5k Aug 10, 2022
MAZE (My AmaZing Engine) - 🎮 Personal open-source cross-platform game engine

MAZE (My AmaZing Engine) is the self-written open-source cross-platform game engine in the active development stage. At the moment it is my main pet project, developed for the purpose of learning and preserving different game dev technologies.

Dmitriy Nosov 11 Jan 9, 2022
Rogy-Engine- - My 3D game engine source code.

Rogy-Engine Development My 3D game engine. (NOT THE FINAL VERSION- Windows only) Features: PBR shading and reflection probes with parallax correction.

AlaX 92 Jun 18, 2022
The Atomic Game Engine is a multi-platform 2D and 3D engine with a consistent API in C++, C#, JavaScript, and TypeScript

The Atomic Game Engine is a multi-platform 2D and 3D engine with a consistent API in C++, C#, JavaScript, and TypeScript

null 2.7k Aug 6, 2022
Hyperion Engine is a 3D game engine written in C++

Hyperion Engine About Hyperion Engine is a 3D game engine written in C++. We aim to make Hyperion be easy to understand and use, while still enabling

null 163 Aug 9, 2022
Care race game built in c++ with sfml. this project is done in 3rd semester of csit for demonstration of computer graphics.

Car Race Car race is simple game which has been built by using SFML in c++ implementing concepts of Computer Graphics for project Work of 3rd semester

subash kc 4 Dec 18, 2021
Minetest is an open source voxel game engine with easy modding and game creation

Minetest is an open source voxel game engine with easy modding and game creation

Minetest 7.7k Aug 3, 2022
Stealthy way to hijack the existing game process handle within the game launcher (currently supports Steam and Battle.net). Achieve external game process read/write with minimum footprint.

Launcher Abuser Stealthy way to hijack the existing game process handle within the game launcher (currently supports Steam and Battle.net). Achieve ex

Ricardo Nacif 76 Jul 28, 2022
Game Boy, Game Boy Color, and Game Boy Advanced Emulator

SkyEmu SkyEmu is low level cycle accurate GameBoy, GameBoy Color and Game Boy Advance emulator that I have been developing in my spare time. Its prima

Sky 193 Aug 6, 2022
📽 Highly Optimized Graphics Math (glm) for C

?? OpenGL Mathematics (glm) for C Documentation Almost all functions (inline versions) and parameters are documented inside the corresponding headers.

Recep Aslantas 1.4k Aug 4, 2022
A library for high-performance, modern 2D graphics with SDL written in C.

SDL_gpu, a library for making hardware-accelerated 2D graphics easy. by Jonathan Dearborn SDL_gpu is licensed under the terms of the MIT License. See

Jonathan Dearborn 1k Aug 10, 2022