A multi core friendly rigid body physics and collision detection library suitable for games and VR applications.


CLA assistant Build Status Quality Gate Status Bugs Code Smells

Jolt Physics Library

A multi core friendly rigid body physics and collision detection library suitable for games and VR applications.

Ragdoll Pile
A YouTube video showing a ragdoll pile simulated with Jolt Physics.

For more demos and videos go to the Samples section.

Design Considerations

So why create yet another physics engine? First of all, this has been a personal learning project and secondly I wanted to address some issues that I had with existing physics engines:

  • In games we usually need to do many more things than to simulate the physics world and we need to do this across multiple threads. We therefore place a lot of emphasis on concurrently accessing the physics simulation data outside of the main physics simulation update:
    • Sections of the world can be loaded / unloaded in the background. A batch of physics bodies can be prepared on a background thread without locking or affecting the physics simulation and then inserted into the world all at once with a minimal impact on performance.
    • Collision queries can run in parallel with other operations like insertion / removal of bodies. The query code is guaranteed to see a body in a consistent state, but when a body is changed during a collision query there is no guarantee if the change is visible to the query or not. If a thread modifies the position of a body and then does a collision query, it will immediately see the updated state (this is often a problem when working with a read version and a write version of the world).
    • It is also possible to run collision queries in parallel to the main physics simulation by doing the broad phase query before the simulation step. This way, long running processes (like navigation mesh generation) can be spread out across multiple frames while still running the physics simulation every frame.
  • One of the main sources of performance problems we found was waking up too many bodies while loading / unloading content. Therefore, bodies will not automatically wake up when created and neighboring bodies will not be woken up when bodies are removed. This can be triggered manually if desired.
  • The simulation runs deterministically, so you could replicate a simulation to a remote client by merely replicating the inputs to the simulation.
  • The simulation of this physics engine tries to simulate behavior of rigid bodies in the real world but makes approximations in the simulation so should mainly be used for games or VR simulations.

For more information see the Architecture section.


  • Simulation of rigid bodies of various shapes using continous collision detection:
    • Sphere.
    • Box.
    • Capsule.
    • Tapered-capsule.
    • Cylinder.
    • Convex hull.
    • Compound.
    • Mesh (triangle).
    • Terrain (height field).
  • Simulation of constraints between bodies:
    • Fixed.
    • Point.
    • Distance (including springs).
    • Hinge.
    • Slider (also called prismatic).
    • Cone.
    • Smooth spline paths.
    • Swing-twist (for humanoid shoulders).
    • 6 DOF.
  • Motors to drive the constraints.
  • Collision detection:
    • Casting rays.
    • Testing shapes vs shapes.
    • Casting a shape vs another shape.
    • Broadphase only tests for quickly determining which objects may intersect.
  • Sensors (trigger volumes).
  • Animated ragdolls:
    • Hard keying (kinematic only rigid bodies).
    • Soft keying (setting velocities on dynamic rigid bodies).
    • Driving constraint motors to an animated pose.
  • Game character simulation (capsule), although many games may want to implement characters just using collision tests for more control over the simulation.
  • Vehicle simulation of wheeled and tracked vehicles.
  • Water buoyancy calculations.

Supported Platforms

  • Windows (VS2019) x64
  • Linux (tested on Ubuntu 20.04) x64/ARM64
  • Android (tested on Android 10) x64/ARM64
  • Platform Blue (a popular game console) x64

Required CPU features

  • On x86 the minimal requirements are SSE4.2 but the library can be compiled using FP16C, AVX or AVX2.
  • On ARM64 the library requires NEON with FP16 support.


  • The library has been tested to compile with Cl (Visual Studio) and Clang 10+.
  • It uses C++17 and only depends on the standard template library.
  • It doesn't make use of compiler generated RTTI or exceptions.
  • If you want to run on Platform Blue you'll need to provide your own build environment and PlatformBlue.h file due to NDA requirements (see Core.h for further info).

For build instructions go to the Build section.


The project is distributed under the MIT license.

  • Character Controller ground detection problems

    Character Controller ground detection problems

    The way the character controller checks for the ground state has a few problems.

    It simply makes an overlap check with the character shape at the current location to determine which bodies it touches. Unfortunately, this is very unreliable. In many cases there will be no overlap at all, simply because after the simulation the CC is standing ON the ground, but not PENETRATING the ground and thus the check may or may not return the ground body, depending on floating point accuracy I'd guess.

    Simply debug drawing the ground position of the CC and the ground state shows that it flickers between different states. It becomes very apparent when you want to apply the ground velocity (moving platforms), which randomly slide away beneath the CC.

    One way I have attempted to fix this, is to move the ground check artificially 1cm downwards. This fixes the ground detection BENEATH the CC. However, the 'sliding' state is equally affected by this. Once you jump into a wall, the overlap check may or may not return the wall object and thus vary between 'sliding' and 'in air'. To prevent the player to be able to pin the CC to a wall by walking/flying into it, I want to clamp the input velocity against the touched surface. So I need to reliably know when the CC touches a wall. Here I can't use the 'move a tiny bit downwards' tricky though. Instead, the CC shape would need to be expanded slightly. Since the user provided CC shape is used for the overlap check, I currently don't see how this could be accomplished inside Jolt.

    At the moment I think my best bet would be to copy&paste the Jolt CC ground detection code into my code, and adjust it with my own (known) expanded capsule shape. Not a horrible solution actually, but maybe you have an idea how to make this more usable for everyone.

    opened by jankrassnigg 18
  • WIP: Support for 32-bit platforms

    WIP: Support for 32-bit platforms

    I've been writing an implementation of the Source Engine's physics library (VPhysics which uses IVP/Havok) used in games such as Half-Life 2, Portal 2, L4D2, Garry's Mod, etc with Jolt.

    There are some engine branches that are 64-bit and 32-bit, and I would like to provide support for both. I also have a few friends who are integrating Jolt into older games (such as Quake 2) or mods (for games such as Half-Life 1), most of which are 32-bit, to learn more about it.

    I completely understand if you don't want to deal with having this upstream or at least being officially supported.

    Leaving this as a draft as it is not complete yet, but I figured I'd start the conversation now. As of me making this, it can at least run the samples + game physics (albeit with some complaints in Debug).

    opened by Joshua-Ashton 17
  • Add Debug draw helpers for ShapeCast & CastRay

    Add Debug draw helpers for ShapeCast & CastRay

    It would be really helpful for debugging to have the ability to ->Draw a ShapeCast or RayCast wiuth the same params as a CastShapeVsShape or CastRay.

    Obviously one can do their own with pShape->Draw, but for debugging sanity it would be really helpful to have a simple way to visualize individual traces and rays going on without any potential mess ups in the app's code getting the CentreOfMass offsets wrong, rotations/inverse rotations etc.

    Right now in our code, that is what we are doing, with a little picture in picture window showing all the traces, but obviously it would be super nice to validate against exactly what Jolt is seeing.

    opened by Joshua-Ashton 17
  • MotorSettings could use more in-depth documentation

    MotorSettings could use more in-depth documentation

    All physics engines I've worked with (PhysX, Bullet, Havok) expose some values that require some deep understanding of how physics solvers work (which I totally don't have). Surprisingly, the documentation for these values is always very shallow, I guess because the people writing the docs are also missing that deep understanding - your chance to be better! ;-)

    I'm currently applying a motor to a hinge constraint.

    In MotorSettings what is the min force/torque limit? Does this have to do with the direction into which it goes? Or is "min" literally the minimum force/torque that is applied (that wouldn't make sense with the symmetric values though).

    Why is there a distinction between torque and force? As far as I can tell, you always only drive one thing, right? Wouldn't that mean that every drive uses exclusively one value or the other, but never both? In that case, I'd simplify the struct (maybe always call it "force" and mention in the comment that this is a torque for rotational things).

    For position targets, what exactly do mFrequency and mDamping do? Especially mFrequency doesn't tell me much. And can mDamping be larger than 1 ? Maybe give an example for when to set these values differently.

    Also "position" is a bit of an overloaded term, when driving a hinge to a target angle, it is not immediately obvious that this is a "position" (I first thought this might rather apply to slider constraints).

    I am also looking up a lot at implementation details to figure some stuff out. For example to see what "Set symmetric force limits" exactly means and under which conditions "IsValid" actually returns true/false.

    Finally, why is driving a hinge to a target angle so weak?? I have set both force and torque limit to 10000 but it just stops when it encounters any resistance. However, driving the velocity instead, using a limit of 100 is already pretty strong and will push the same object easily out of the way.

    opened by jankrassnigg 15
  • Various mesh shape questions

    Various mesh shape questions

    I recently got triangle meshes and convex meshes up and running in my engine. It's all working, but there were a couple of things I'd like to ask about.

    1. How exactly am I supposed to serialize and deserialize baked/cooked meshes? If I understand it correctly, ConvexHullShapeSettings and MeshShapeSettings are kind of the "mesh resources", meaning the shared mesh state that is referenced by the individual shape instances. For the time being I just serialize the mesh data out myself and when I read the data, I create a new MeshShapeSettings or ConvexHullShapeSettings object from it, passing the data to their constructors. I would assume that this is not the most efficient way to do things. With other physics engines I made the experience that baking physics meshes can take quite some time, and I would prefer not to spend it during loading.

      I saw that the settings classes are derived from SerializableObject but from there on I didn't see an easy way to use this. I think I saw something about std::istream, which, to be frank, completely put me off, since I personally absolutely dislike the std stream stuff.

      Usually I would expect a lightweight reader / writer base class, that literally just needs a virtual "ReadBytes" and "WriteBytes" function, that I can derive from and implement.

    2. Convex hull generation is something that I guess can go wrong? At least in PhysX it could because it had a vertex limit of 255 (which is why I ended up writing my own anyway). Can that potentially happen in Jolt? And if so, how is that communicated through the ConvexHullShapeSettings interface?

    3. For tooling and debugging I have a component that can visualize a collision mesh. Since I don't want to store the mesh data twice, just for visualization purposes, I prefer to query the mesh data from the physics engine on demand instead. Here is what this looks like in the editor:


      For this I found Shape::GetTrianglesNext(), which is a pretty cool function and I just gave it a huge AABB to retrieve everything. Still, I need to create a dummy shape for this, and I get the data in chunks. For the convex hull and triangle meshes, IF the data is somehow available as a vertex list and triangle index list, it would be nice to get direct access to that.

    4. Material pointers are set on the *Settings object and not on the *Shape object, as far as I can see. That makes sharing the same shape (usually convex hull) across different bodies with different materials difficult. E.g. when I create my "ice" boulder and my "rock" boulder, they can't use the same convex hull mesh, because the PhysicsMaterial can't be different, unless I somehow find another way to retrieve material parameters, but then the whole material idea would be pointless.

    5. Shape::Stats gives me the number of triangles in a shape, but not the number of (shared) vertices. If that information is available, would be nice to have.

    6. MeshShapeSettings takes vertices as FLOAT3 (VertexList), ConvexHullShapeSettings as Vec3 (which are actually __m128 and thus need different treatment).

    Okay...that's all I got about that topic for the moment :)

    opened by jankrassnigg 15
  • Serialize whole PhysicsSystem + shapes + constraints?

    Serialize whole PhysicsSystem + shapes + constraints?


    I was interested in being able to dump the game's physics system and add a loader to the Samples to be able to play around with it there. It's also useful for viewing in the viewer.

    Same goes for being able to report some issues with constraint stability in some instances, I wanted to dump my phys env so I could easily demonstrate how it's stable to start, then after playing around with it enough it will go crazy and fly all over. (There's lots of constrained convex objects interacting.)

    There's a few paths I have tried for doing something like this, one was calling SaveState on PhysicsEnvironment, this doesn't seem to save the shapes that I can tell.

    The other path is using the PhysicsScene, but this suffers from not replicating constraints as I have to convert it to use the the BodyCreationInfo.

    Am I missing something?

    opened by Joshua-Ashton 13
  • Bodies can still go through other bodies with linear cast if velocity is applied before every simulation

    Bodies can still go through other bodies with linear cast if velocity is applied before every simulation

    Not super sure what's going on here.

    If I have a body and set it's velocity before every simulation, eventually it goes through the world.

    I'm using LinearCast, but have also tried increasing substeps to 4 + setting the LinearCastThreshold to 0.

    opened by Joshua-Ashton 10
  • Add SSE2 codepath

    Add SSE2 codepath

    Add an SSE2 codepath to Jolt by providing a C++ implementation for all functions that use SSE4.1 instructions. This enables Jolt to run on all x64 processors.

    The SSE2 codepath is ~10% slower than the SSE4.2 codepath on average in the PerformanceTest tests.

    opened by jfpoole 10
  • Locking two bodies at the same time (joint setup)

    Locking two bodies at the same time (joint setup)

    I am trying to create a joint between two bodies.

    ConstraintSettings::Create expects two writable body references. I only have body IDs, so I'm trying to use two BodyLockWrite to lock both bodies and then create the joint. However, an assert fires, telling me that another write lock has already been taken.

    In the samples I couldn't find anything similar, there the joints are always created in the same code that also creates the bodies, so it just holds pointers to those around for the needed duration.

    What's the recommended way to do this?

    opened by jankrassnigg 8
  • Support broader range of CPUs like Intel Core 2 series by using SSE4.1

    Support broader range of CPUs like Intel Core 2 series by using SSE4.1

    Because popcnt is the only instruction from SSE4.2 that used in project, I add a software implementation for it and add cmake options for more flexible builds. All options are ON now and project builds like before. If all options set to OFF then project will be compatible with SSE4.1. I only test it with Clang. I couldn't test it with Visual Studio so I didn't implement cmake options for it.

    Resources related to popcount implementation: https://stackoverflow.com/questions/109023/how-to-count-the-number-of-set-bits-in-a-32-bit-integer https://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallel https://godbolt.org/z/qGdh1dvKK

    Tests Results: SSE4.1:

    Running scene: ConvexVsMesh
    Motion Quality, Thread Count, Steps / Second, Hash
    Discrete, 1, 243.629, 5716752184027160728
    Discrete, 2, 422.97, 5716752184027160728
    Discrete, 3, 582.053, 5716752184027160728
    Discrete, 4, 714.728, 5716752184027160728
    Discrete, 5, 791.58, 5716752184027160728
    Discrete, 6, 858.247, 5716752184027160728
    Discrete, 7, 920.468, 5716752184027160728
    Discrete, 8, 950.534, 5716752184027160728
    LinearCast, 1, 247.095, 4650164293306922608
    LinearCast, 2, 427.573, 4650164293306922608
    LinearCast, 3, 577.239, 4650164293306922608
    LinearCast, 4, 665.414, 4650164293306922608
    LinearCast, 5, 793.486, 4650164293306922608
    LinearCast, 6, 858.8, 4650164293306922608
    LinearCast, 7, 922.867, 4650164293306922608
    LinearCast, 8, 967.974, 4650164293306922608


    Running scene: ConvexVsMesh
    Motion Quality, Thread Count, Steps / Second, Hash
    Discrete, 1, 245.164, 5716752184027160728
    Discrete, 2, 432.407, 5716752184027160728
    Discrete, 3, 588.171, 5716752184027160728
    Discrete, 4, 669.855, 5716752184027160728
    Discrete, 5, 816.022, 5716752184027160728
    Discrete, 6, 888.699, 5716752184027160728
    Discrete, 7, 925.805, 5716752184027160728
    Discrete, 8, 990.85, 5716752184027160728
    LinearCast, 1, 250.708, 4650164293306922608
    LinearCast, 2, 432.997, 4650164293306922608
    LinearCast, 3, 591.494, 4650164293306922608
    LinearCast, 4, 666.552, 4650164293306922608
    LinearCast, 5, 810.698, 4650164293306922608
    LinearCast, 6, 874.057, 4650164293306922608
    LinearCast, 7, 944.47, 4650164293306922608
    LinearCast, 8, 998.861, 4650164293306922608

    All options ON:

    Running scene: ConvexVsMesh
    Motion Quality, Thread Count, Steps / Second, Hash
    Discrete, 1, 259.555, 17307524469906541054
    Discrete, 2, 451.237, 17307524469906541054
    Discrete, 3, 602.937, 17307524469906541054
    Discrete, 4, 692.069, 17307524469906541054
    Discrete, 5, 791.086, 17307524469906541054
    Discrete, 6, 922.998, 17307524469906541054
    Discrete, 7, 970.262, 17307524469906541054
    Discrete, 8, 1039.1, 17307524469906541054
    LinearCast, 1, 259.9, 14934805612666754675
    LinearCast, 2, 437.229, 14934805612666754675
    LinearCast, 3, 609.016, 14934805612666754675
    LinearCast, 4, 710.129, 14934805612666754675
    LinearCast, 5, 838.243, 14934805612666754675
    LinearCast, 6, 900.946, 14934805612666754675
    LinearCast, 7, 982.597, 14934805612666754675
    LinearCast, 8, 1025.07, 14934805612666754675
    opened by mrezai 7
  • Constraints should have a flag whether to ignore collisions between joined objects

    Constraints should have a flag whether to ignore collisions between joined objects

    AFAIK all other physics engines by default ignore collisions between joined objects. This is quite sensible, since the abstract physics shapes would otherwise often collide with each other, or it's quite difficult to setup physics shapes that don't touch while joined. For ragdolls this is particularly tricky.

    I know that it may be possible to use the collision group filters to do this, but I haven't figured out yet how I would set things up such that two joined bones don't collide, but otherwise collide with the rest. I also can't imagine, that it is particularly efficient to use these filters everywhere.

    If there is an easy way to set this up, I'd be interested to know. But I would still just prefer a flag on the constraints to disable collisions.

    opened by jankrassnigg 7
  • Constraints can sometimes go whacky mode

    Constraints can sometimes go whacky mode

    Sometimes having a system of fixed constraints can go crazy and fly all over if you prod them enough.

    I have attached a repro case





    I had to change the LoadSnapshotTest to account for my object layers:

    	Ref<PhysicsScene> scene = result.Get();
    	for (BodyCreationSettings &settings : scene->GetBodies())
    		if (settings.mObjectLayer == 0 || settings.mObjectLayer == 1)
    			settings.mObjectLayer = Layers::NON_MOVING;
    			settings.mObjectLayer = Layers::MOVING;

    It's also marginally annoying that mUp points the wrong way too, but not the end of the world.


    opened by Joshua-Ashton 13
  • MeshShape integration issues / data ingress

    MeshShape integration issues / data ingress

    I'm trying to integrate mesh shapes into an existing code base and I ran into performance regressions with MeshShape, and I had a few thoughts about the interface.

    Right now you fill a MeshShapeSettings, which has std::vector<>s for vertices and indices, and pass that to the MeshShape constructor. Bullet, on the other hand, provides an interface through which the caller can expose read-only views into vertex and index data, which is a much better interface: https://github.com/bulletphysics/bullet3/blob/master/src/BulletCollision/CollisionShapes/btStridingMeshInterface.h#L53

    • With MeshShape, I need to create, fill, and destroy STL containers, even though I might have the data right here in memory from a decompressed file on disk usually
    • Bullet lets me specify vertex stride, supporting packed formats and alignment padding
    • Bullet allows u16 and u32 indices, while MeshShapeSettings use the latter, so small meshes (and custom collision meshes) which are the majority need a processing step. Bullet handles existing index format via PHY_* types.
    • Bullet supports multi-part meshes which are common in some scenarios esp in editor

    What's a good path to enable MeshShape to directly access existing data and avoid copies / etc?

    opened by sherief 6
  • Double-precision support?

    Double-precision support?

    Does Jolt supports double-precision? I tried Godot Engine physics and it does support it, I was able to simulate physics normally while 1000Km away from the origin. However, my use case involves creating a lot of mesh colliders at runtime and I'm a concerned about several performance issues with Godot's physics engine, so I was considering giving Jolt a go at some point.

    opened by Zylann 9
  • Broadphase and ObjectLayer filters are missing context

    Broadphase and ObjectLayer filters are missing context

    I'm currently looking into how to implement collision filtering.

    So far I have found these filtering options:

    • in the broadphase via ObjectVsBroadPhaseLayerFilter
    • pair-wise via 16 bit "layer" information through ObjectLayerPairFilter
    • pair-wise via 32 bit "group IDs" and CollisionGroup / GroupFilter

    I'm trying to figure out which of these I should use for what. I assume I should use the broadphase filter to separate static/dynamic objects and maybe stuff like "query shapes" (kinematic bodies that are only used for raycasts but not for simulation - e.g. for character hit boxes). Anything else that makes sense to separate in the broadphase? Triggers maybe?

    I guess the GroupFilter is the most flexible, but also the slowest one. Not sure exactly when this is really needed, maybe for very special cases like the player object ?

    I would like to use the object layer filter to do a quick bitmask check to see whether layer1 objects should collide with layer2 objects. However, the 16 bit layer value is not sufficient for this, so I would need to look up the collision matrix somewhere else.

    Unfortunately PhysicsSystem::Init only takes a raw C function pointer for ObjectVsBroadPhaseLayerFilter and ObjectLayerPairFilter, which means all collision filtering information would need to be hard-coded in those functions (or global).

    Interestingly, NarrowPhaseQuery::CastRay already does a similar thing, but that one takes BroadPhaseLayerFilter and ObjectLayerFilter as interfaces, so that I can pass along context information.

    It would be great if PhysicsSystem::Init would also take interfaces instead.

    opened by jankrassnigg 2
Bounce is a 3D physics engine for games.

Bounce Welcome! Bounce is a 3D physics engine for games. Features Common Efficient data structures with no use of STL Fast memory allocators Built-in

Irlan Robson 64 Jun 25, 2022
This repository is about a school project about games with physics, written in C++.

Eight Ball Pool ?? A game about playing physics-based eight ball pool. ?? Table of Contents About Getting Started Usage Built Using About the creators

Valeri Ivanov 17 May 22, 2022
Box2D is a 2D physics engine for games

Build Status Box2D Box2D is a 2D physics engine for games. Contributing Please do not submit pull requests with new features or core library changes.

Erin Catto 5.7k Jul 2, 2022
A tool to render half life's collision hulls

Overview This is a tool that computes and renders the collision hulls of GoldSrc maps (BSP version 30), such as Half-Life 1 and Opposing Force maps. T

Cristhian Grundmann 3 Mar 17, 2022
This is a list of different open-source video games and commercial video games open-source remakes.

This is a list of different open-source video games and commercial video games open-source remakes.

Ivan Bobev 79 Jun 27, 2022
Ultralight is an ultra-fast, ultra-light, standards-compliant HTML renderer for applications and games.

Ultralight is an ultra-fast, ultra-light, standards-compliant HTML renderer for applications and games. It supports most modern HTML5, CSS, and JavaScript features while still remaining light in binary size and memory usage.

Ultralight 3.9k Jun 26, 2022
SKR_Physics is a lightweight and easy to use 2D physics engine which is written in C++.

SKR_Physics SKR_Physics is a lightweight and easy to use 2D physics engine which is written in C++. Features Rectangle based collision system Very sim

Şükrü 0 Mar 8, 2022
A game with basic physics and platforming.

Physgun A simple game with basic physics and platforming. Planned features Work in progress: Physics engine. Swept AABB collision algorithm. Elastic a

Bad Games Studio 24 Dec 17, 2021
Godot bindings for the Rapier3D physics engine

Godot bindings for the Rapier3D physics library How to use There are two parts: A Godot module which must be compiled with the engine.

David Hoppenbrouwers 23 Jun 20, 2022
Sequential impulses physics engine made for learning purposes

A 3D physics engine that uses Separating Axis Test for collision detection, the clipping method for generating contact manifold, contact point reducti

Ahmad Saleh 1 Nov 24, 2021
Source code for Game Physics Cookbook

Game Physics Cookbook Website Facebook Twitter This book is a comprehensive guide to the linear algebra and collision detection games commonly use, bu

Gabor Szauer 612 Jun 27, 2022
A C math library targeted at games

Kazmath Kazmath is a simple 3D maths library written in C. It was initially coded for use in my book, Beginning OpenGL Game Programming - Second editi

Luke Benstead 502 May 25, 2022
A single-header C++ library for making simple 2D games

A single-header C++ library for making simple 2D games PLATFORM: Windows LANGUAGE: C++ ENVIRONMENT: Visual Studio Why? Learning C++ is often seen as d

Sumo Digital Academy 41 Jun 16, 2022
C++ Library to connect games with Game Jolt

Game Jolt API C++ Library Game Jolt is a host for free independently developed computer games. As a gamer you are able to play every game on this site

Martin Mauersics 8 Jun 18, 2022
C library for Wordle-like games

libwordle Open this project in 8bitworkshop. This is a C library for making Wordle-like games for 8-bit systems. Platforms supported: C64 (cc65) Wordl

Steven Hugg 4 Jan 31, 2022
RPC Network Library for Multiplayer Games

Game NET - A Simple RPC Network Library (C++11) Write a simple server / client RPC system in just 10+20 lines of code. Write a multiplayer game with c

Spacerat 73 Jun 3, 2022
OGRE is a scene-oriented, flexible 3D engine written in C++ designed to make it easier and more intuitive for developers to produce games and demos utilising 3D hardware.

OGRE (Object-Oriented Graphics Rendering Engine) is a scene-oriented, flexible 3D engine written in C++ designed to make it easier and more intuitive for developers to produce games and demos utilising 3D hardware. The class library abstracts all the details of using the underlying system libraries like Direct3D and OpenGL and provides an interface based on world objects and other intuitive classes.

null 2.8k Jun 29, 2022
Distributed server for social and realtime games and apps.

Distributed server for social and realtime games and apps. Features Users - Register/login new users via social networks, email, or device ID. Storage

Heroic Labs 6k Jun 22, 2022
3D games console based on RP2040 and iCE40 UP5k

PicoStation 3D This is an unfinished, untested project to develop a 3D games console based on an RP2040 microcontroller and an iCE40 UP5k FPGA. Quick

Luke Wren 35 Jun 5, 2022