Real-time oriented physics engine and library that's currently best suited for 2D games.

Overview

PlayRho

A way to play with physical behaviors like the conservation of momentum.

PlayRho is a real-time oriented physics engine and library that's currently best suited for 2-D games. The project name is the composition of the verb play with the noun rho where rho is the Greek letter often used to represent physical quantities like momentum.

Background

PlayRho started off as a port by Louis Langholtz of the Box2D 2.3.2 physics engine to "modern C++". It's evolved into a derivative work by Louis and other contributors to the code base. Like its predecessor, PlayRho is also licensed under a Zlib License.

Some general goals of this project are:

  • Supporting value semantics over reference semantics. Values are in and pointers are out!
  • Conforming to the C++ Core Guidelines, particularly in regards to things like avoiding global variables, preferring concrete types, and preferring pure functions.
  • Using and supporting newer features of the C++ language standards up to C++17;
  • Openness to contributions including pull requests with new features; and
  • Providing a continuous integration backed, build automation supported, unit test validated, and benchmark assessed, project.

Continuous Integration Status

iOS Linux CMake macOS Xcode Windows VS2017 Coverage CodeQL
Build Status Build Status Build Status Build status Coverage Status CodeQL

Additional Resources

Issues
  • Improvements and ideas

    Improvements and ideas

    From @Genbox on April 2, 2017 11:46

    Hi Louis,

    I've seen you active around the Box2D project, and it seems like you are keen to improve it and add features. I'm working on Velcro Physics, which is a Box2D port in C#, but extended with many new features such as path generators, better performance, concave polygons etc.

    I'm interested in your port as it seems like you made some improvements and new features, but I have a hard time going through hundreds of files and look for them, so could we have a discussion here on what improvements you have made?

    Copied from original issue: louis-langholtz/Box2D#12

    Enhancement Help Wanted 
    opened by louis-langholtz 65
  • Boxes in Tumbler Testbed too squishy?

    Boxes in Tumbler Testbed too squishy?

    From @louis-langholtz on January 7, 2017 22:42

    Here's a screenshot showing the current state and issue:

    tumblerboxestoosquishy

    Copied from original issue: louis-langholtz/Box2D#3

    Bug Help Wanted Question 
    opened by louis-langholtz 25
  • Can't build Testbed on Windows using CMake; missing PKG_CONFIG_EXECUTABLE

    Can't build Testbed on Windows using CMake; missing PKG_CONFIG_EXECUTABLE

    Expected/Desired Behavior or Experience:

    I would like to be able to build using CMake on Windows so I can address the unit test linking issue #1.

    Actual Behavior:

    CMake returns with the following errors (after specifying the glew library location correctly):

    PLAYRHO_REALNUM_TYPE=float
    CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
      Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
    Call Stack (most recent call first):
      C:/Program Files (x86)/CMake/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE)
      C:/Program Files (x86)/CMake/share/cmake-3.9/Modules/FindPkgConfig.cmake:36 (find_package_handle_standard_args)
      Testbed/CMakeLists.txt:4 (find_package)
    

    Steps to Reproduce the Actual Behavior:

    I found this behavior while following the old CMake setup instructions. I've installed pkg-config using information found in the answers to this question (along with the necessary .dll files, verifying that the program runs), and adding PKG_CONFIG_EXECUTABLE=C:\path\to\pkg-config.exe in the CMake GUI. When I configure, it deletes the entry and reports the same error as above.

    Enhancement Windows CMake 
    opened by NauticalMile64 19
  • Fix for issue #16

    Fix for issue #16

    Description - What's this PR do?

    Fixes issue #16.

    Impacts/Risks of These Changes?

    When glfw has been installed using vcpkg this correctly includes and links glfw. Will behave in the original way when the find_package method fails.

    How should this be tested?

    Generate build using CMake and build the project.

    opened by NauticalMile64 14
  • Runtime polymorphic shapes

    Runtime polymorphic shapes

    Description - What's this PR do?

    Redesigns the shape classes as a single Shape class that is runtime polymorphically configured by shape configuration classes. This new design:

    • Does away with all the Shape sub-classes. Just call Body::CreateFixture(x) where x is a shape configuration class (like for disks, polygons, etc.).
    • Promotes shape Conf classes to toplevel configuration classes (DiskShapeConf, PolygonShapeConf, ChainShapeConf, EdgeShapeConf, and MultiShapeConf respectively).
    • Does away with all the ShapeVisitor classes in favor of directly using any std::function<void(const std::type_info& ti, const void* data)> compatible code. So the visitor can use code like if (ti == typeid(DiskShapeConf)) DoIt(*static_cast<const DiskShapeConf*>(data)); (and doesn't need to use dynamic_cast which can be slower). Note however that free functions on Shape get much of the same information just in a generic form.
    • Will make coding up of new or simplified shape configuration types easier than it was before when having to subclass Shape.
    • Shifts shapes from publicly using reference semantics to instead using value semantics. Users no longer use std::make_shared nor need to know anything about std::shared_ptr.
    • Paves an appealing way forward for simplified Joint and Contact constraints.
    • Seems to have better synergy with builder types.

    Related Issues

    • Issue #217.
    • Issue #223.
    Enhancement 
    opened by louis-langholtz 12
  • WrongState format simplification

    WrongState format simplification

    Expected/Desired Behavior or Experience:

    Easy to use <throw WrongState("reason")>

    Actual Behavior:

    Have to manually look current function's name and write <throw WrongState("ClassName::FunctionName reason")>

    Steps to Reproduce the Actual Behavior:

    Look here to see such cases

    Solution is to use FUNCTION macro inside WrongState defenition

    This solution uses FUNCTION but also provides CLASS name on compiletime.

    Enhancement 
    opened by Hexlord 11
  • Rewrite manual as online user guide.

    Rewrite manual as online user guide.

    Expected/Desired Behavior or Experience:

    A user guide would be available from https://louis-langholtz.github.io/PlayRho/ that basically provides the information found in Documentation/manual.docx. This should not be in DOCX format but a web page format like HTML (preferably from markdown).

    Actual Behavior:

    Documentation/manual.docx currently applies to Erin Catto's Box2D from 2.3.2. While many of the concepts may be the same, most - if not all - of the API names have changed. Also much of the interface's inputs, outputs, and I/O parameters have changed.

    Steps to Reproduce the Actual Behavior:

    See Documentation/manual.docx.

    Enhancement Help Wanted Docs 
    opened by louis-langholtz 11
  • Unit tests don't link on Windows w/ MSVC2017 CMake build

    Unit tests don't link on Windows w/ MSVC2017 CMake build

    Migrated here from my Box2D fork issue #24.

    At last check, the project's library and the unit tests all build on Windows. But the unit tests aren't linking with everything it needs.

    Mismatch of link options. Part built with MDd and other with MTd if memory serves me.

    Incidentally, I've updated the MSVS solution and project files and gotten the Testbed and its dependents to all build and link and run under MS VS2017.

    Bug Help Wanted Windows 
    opened by louis-langholtz 11
  • Questions about migration to PlayRho!

    Questions about migration to PlayRho!

    Some questions i have about the project (esp. in relation to Box2D) that @louis-langholtz or someone else might just know the answer to, in order to spare me writing tests and possibly pointless reintegrations.

    • How does the performance of the 32/64/fixed32/fixed64 version compare to it's counterparts? Is using the fixed-point implementation on worlds containing roughly (low)hundreds of bodies at all feasible?

    • How do the float-types impact maximum scale ratios between bodies in this engine? Can this get me beyond Box2D's 0.1m - 10m rule for bodys' sizes and maybe even beyond 0.1m - ~1000m?

    • Apart from namespacing and renaming - what are the most obvious pitfalls one might encounter migrating from Box2D to PlayRho in an existing project?

    • Are there any plans to implement liquidfun's additions to Box2D in PlayRho? (ParticleSystems)

    • I read about 3D in the issues - will this project move away from a pure 2D engine? and if so will the API for the 2D usage as well as the 2D performance of the engine change/suffer due to that change?

    My hopes are that i can more or less drop in PlayRho as a replacement for Box2D and get a similar performance but stronger determinism (syncing Box2D over network is... tedious to say the least) on a larger range of scale.

    Question 
    opened by ninnghazad 10
  • Undefined behavior with UnitTests on Linux x86_64

    Undefined behavior with UnitTests on Linux x86_64

    Undefined behaviour on archlinux x86_64. Built with cmake -DPLAYRHO_BUILD_TESTBED=On -DPLAYRHO_BUILD_UNIT_TESTS=On -DPLAYRHO_INSTALL=On .. && make -j8 image

    image

    image

    Expected/Desired Behavior or Experience:

    All tests has to complete fine.

    Actual Behavior:

    Tests can't even be completed.

    Steps to Reproduce the Actual Behavior:

    I just built project and started to run tests. I run them for 3 times to get stack smashing.

    Bug 
    opened by Megaxela 10
  • What user resources should we create?

    What user resources should we create?

    Expected/Desired Behavior or Experience:

    Users of every level should be able to easily locate official information to help them understand and use PlayRho effectively.

    Actual Behavior:

    The documentation is present, and the testbed is working on all platforms, but there isn't much other useful information for introductory users.

    I know this is a broad and ill-defined issue, but early discussion can help us create a user experience which leads the user to the desired information as directly as possible (e.g. minimize flipping back and forth between the user manual, testbed, forums, and documentation to try and understand something).

    The key here is that there are many different ways we can communicate how the library works, each with their own advantages / disadvantages:

    | Source | Clarity | Readability | Visuality | Tactility | Audibility | Maintainability | | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | | Source Code | Highest | Very Low | None | None | None | N/A | | Code Comments | Moderate | Moderate | None | None | None | Moderate | | Docs | Moderate - Very High | High | None | None | None | Easy | | Developer Guide | Low - High | Moderate | Low | None | None | Difficult | | User Guide | Low - High | High - Very High | Moderate - High | None | None | Moderate | | Testbed | Low | Moderate | Very High | Moderate | None | Moderate | | Examples | Moderate | Moderate | None - Moderate | None - Moderate | None | Moderate - Difficult | | Tutorials | Low | Very High | None - Moderate | None - Moderate | None - High | Moderate - Difficult | | External Forums or Mailing List | Moderate - High | Low - Very High | None - Low | None | None | Moderate - Very Difficult | | email maintainers | Very High | Low - Moderate | None - Low | None | None | Very Difficult |

    These are all the common ways I can think of to get information about a software library. Are there any that I'm missing? Are there any categories I've not rated well?

    All categories vary from None - Highest with the exception of Maintainability, which varies from Easy to Very Difficult.

    | Label | Description | | --- | --- | | Clarity | How precisely the channel communicate the capabilities of the library to the user | | Readability | How easy is it for the user to understand the code or text present | | Visuality | The degree to which the source communicates the library capabilities through diagrams, screenshots, animations, and live demonstrations | | Tactility | The degree to which the user can interact with components of the library and see the results of their inputs, including sliders, fields, mousejoint usage, etc... | | Audibility | The degree to which auditory channels are used to communicate the library capabilities to the user | | Maintainability | How difficult is it to create and maintain the source. Factors affecting this scale include:

    • The depth of understanding of the library the content creator is required to have
    • The skills required to create the content (e.g. clear writing ability for documentation, good presentation skills for a video tutorial)
    • The amount of content required
    • How quickly the content is likely to become obselete
    Note I've rated the documentation Easy because it should be created whenever new code is added; the onus is clearly on the code author to do this, and it should be straightforward for them to describe the interface to their new code. |

    Given this information, which resources should we focus on creating?

    Steps to Reproduce the Actual Behavior:

    View the Github page and documentation so far.

    Enhancement Help Wanted Question Docs 
    opened by NauticalMile64 9
  • PlayRho and LiquidFun

    PlayRho and LiquidFun

    I just discovered this project through LiquidFun. It seems to me a necessary initiative. Thank you for undertaking it and lots of encouragement!

    I would like to know how the "integration" of LiquidFun into PlayRho is going. I know that this intention existed in 2017... but I don't know how far it has been possible to go?

    Thanks in advance!

    DJuego

    opened by DJuego 0
  • UnitVec isn't generalized to N dimensions

    UnitVec isn't generalized to N dimensions

    Currently the unit vector type is only available for 2 dimensions as ::playrho::d2::UnitVec. This issue is to generalize the unit vector type to N dimensions.

    Enhancement Library 
    opened by louis-langholtz 0
  • Multiple sources of project's version

    Multiple sources of project's version

    Expected/Desired Behavior or Experience:

    There's only a single source for what the project's version is or is supposed to be.

    Actual Behavior:

    There are multiple sources of the project's version:

    1. CMakeLists.txt.
    2. Documentation/Doxyfile.
    3. PlayRho/Common/Version.cpp.
    4. UnitTests/Version.cpp.
    5. git itself is also a source of the version via git tags.

    This obviously complicates versioning which in turn complicates making new releases.

    Enhancement Help Wanted 
    opened by louis-langholtz 2
  • Testbed doesn't support Vulkan graphics API

    Testbed doesn't support Vulkan graphics API

    Expected/Desired Behavior or Experience:

    Testbed uses the Vulkan graphics API on supporting platforms.

    Actual Behavior:

    Only OpenGL is currently supported.

    Related Info:

    Enhancement Windows Testbed 
    opened by louis-langholtz 1
  • Testbed doesn't support Apple's Metal API

    Testbed doesn't support Apple's Metal API

    Expected/Desired Behavior or Experience:

    Testbed uses Apple's Metal on supporting platforms.

    Actual Behavior:

    Only OpenGL is currently supported.

    Related Info:

    • https://en.wikipedia.org/wiki/Metal_(API)
    • https://www.raywenderlich.com/9211-moving-from-opengl-to-metal
    Enhancement macOS Testbed 
    opened by louis-langholtz 1
Releases(v1.1.0)
  • v1.1.0(Apr 24, 2021)

    Here's a summary of the more noteworthy commits that went into this release:

    • Fixes issue with building project on Windows using GCC.
    • Updates links to travis-ci in project's README file from the .org domain to the .com domain.
    • Restores functionality of pull requests getting checked by Travis-CI.
    • Fixes link issue when building with Xcode 12.3.
    • Applies clang-format to more files.
    • Changes for building more easily with boost units support using newer boost releases - specifically boost 1.75.
    • Fixes an out of bounds array access when firing bullets in the RayCast demo in the Testbed.
    • Adds more == and != support for BodyConf, Acceleration, FixtureConf, Sweep, and Body classes.
    • Adds a C++23 like to_underlying template function to the playrho namespace.
    • Replaces uses of the UnderlyingValue template function with the to_underlying template function.
    • Deprecates the UnderlyingValue functions.
    • Updating the release/version/tag to 1.1.0!
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0(Nov 30, 2020)

  • v0.14.0(Nov 29, 2020)

    Here's a summary of the commits that went into this release:

    • Adds == and != support for joints.
    • Removes the following unnecessary and undesirable declarations: JointType alias, UnderlyingType aliases, Voidify class, and the VoidT alias.
    • Adds constexpr to more constant declarations and recognizes more non throwing functions with noexcept.
    • Improves the underlying dynamic tree code to provide the strong exception guarantee more.
    • Improves handling of Joint and Shape construction to provide better compile time messages for any missing required functionality.
    • Improves Doxygen documentation to provide better API documentation.
    • Adds more unit test coverage.
    Source code(tar.gz)
    Source code(zip)
  • v0.13.1(Nov 10, 2020)

    Beta release of PlayRho.

    Compared to v0.13.0, this release:

    • Adds the CodeQL CI action and a CodeQL badge.
    • Adds more unit test coverage.
    • Improves Doxygen documentation of the API.
    • Polishes some unit test code.
    • Applies Clang formatting to more files.

    Note that per semantic versioning for a major version of zero (which this still is), anything may still change at any time and the public API should not be considered stable.

    Source code(tar.gz)
    Source code(zip)
  • v0.13.0(Nov 9, 2020)

    Updates:

    • Polishes Doxygen documentation.
    • Adds more unit test coverage.
    • Moves velocity Cap function from Body.{hpp,cpp} to Velocity.{hpp,cpp}.
    • Applies clang-format to more files.
    • Updates version to 0.13.0.
    Source code(tar.gz)
    Source code(zip)
  • v0.12.1(Nov 7, 2020)

    Polish towards release 1.0...

    • Updates handling of version information to reduce the number of places it comes from.
    • Adds Get*Range & IsDestroyed* interfaces for consistency & contract recognition
    • Removes unmaintained and unused premake LUA file.
    • Updates copyright year.
    • Updates .gitignore to ignore more irrelevant files.
    • Adds more unit testing.
    • Updates documentation.
    Source code(tar.gz)
    Source code(zip)
  • v0.12.0(Nov 4, 2020)

    First beta candidate release.

    This release fixes issue #370 and some other problems as well. Additionally, it also did more towards slimming down the World interface and made improvements for CMake and unit testing.

    Source code(tar.gz)
    Source code(zip)
  • v0.11.1(Nov 2, 2020)

  • v0.11.0(Nov 1, 2020)

    This is the tagged Alpha release 0.11.0.

    With 0.11.0, the World class interface has been significantly trimmed down and brings the Slim Down World Class project much closer to its finish line.

    More specifically, the World class interface to each of the physical entity concepts - bodies, fixtures, joints, contacts - has been reduced down to only create, read, update, and delete (CRUD) member functions along with associated enumeration member functions. Those along with miscellaneous member functions of World, are the basis to all the functionality with non-member, non-friend (free functions), providing the primary API interface, additional functionality, and increased convenience.

    Only a few member function of World still remain in question. In particular, the World::GetShapeCount, World::GetBodiesForProxies, and World::GetTree functions are remaining candidates for removal. These are more implementation dependent functions which may still be removed. One thing holding that up is deciding what alternative(s) to go with to still be able to access their functionality while minimizing the implementation exposed by the World class.

    Other changes this release/tag brings are things like improved synchronization of state like when sleeping/awakening contacting bodies or when changing the filter or sensor properties of contacting fixtures.

    Source code(tar.gz)
    Source code(zip)
  • v0.10.0(Oct 23, 2020)

    This is the tagged Alpha release 0.10.0.

    This release introduces many changes since tag v0.9.1 including switching from a reference semantics design to a value semantics design. Pointers to things like bodies created by the world have been replaced by strongly typed indexes to bodies that are now internal to the world. User code still has access to properties of bodies, fixtures, contacts, and joints like it did before but goes through functions of the world instance to access them. This allowed for storage savings and performance optimizations resulting in faster simulations.

    Source code(tar.gz)
    Source code(zip)
  • v0.9.1(Jun 17, 2018)

  • v0.9.0(Oct 20, 2017)

Owner
Louis Langholtz
Software coder/programmer/craftsman/engineer, addresser of elephants in the room, and occasional entrepreneur.
Louis Langholtz
BEST Robotics Code for BEST Robotics - RedShift Robotics

RedShift_BEST_2021 BEST Robotics Code for BEST Robotics - RedShift Robotics Sourced From RedShift Robotics Engineering Notebook: Software Design Every

null 1 Nov 6, 2021
Fortnite Cheat thats internal, will be updating

Fortnite-cheat-source-internal-self-leak Here is my fortnite internal cheat source. I will maybe update this every update. Features Box ESP FOV Change

Micca 23 Jun 21, 2022
Defold Engine integration with Yandex.Metrica to track your games on Yandex.Games.

Yandex.Metrica for Defold Yandex.Metrica is a free of charge web analytics tool for websites, that's the reason why we can use it for HTML5 games. Yan

Indiesoft LLC 6 Jan 20, 2022
Updates the Wii's current system time with the real world time.

Fix Wii System Time This is a homebrew tool I made for the Wii a while ago. It updates the current system time with the real world time via worldtimea

Puzzle 2 Dec 21, 2021
Filament is a real-time physically based rendering engine for Android, iOS, Windows, Linux, macOS, and WebGL2

Filament Filament is a real-time physically based rendering engine for Android, iOS, Linux, macOS, Windows, and WebGL. It is designed to be as small a

Google 14.3k Jul 1, 2022
My first Real-Time 3D Game Engine learning project written in C++.

EyeEngine-Cpp FOA, sry for my poor English. What is Eye Engine? Eye Engine is my first Real-Time 3D Game Engine learning project. There are two editio

F-seeeye 5 Apr 6, 2022
Lightweight Peer-to-Peer networking engine for real time applications

Club A lightweight Peer-to-Peer networking engine for real time applications written in C++14. Motivation Real time applications such as Online games,

Peter 187 Mar 3, 2022
Open source C++ physics engine library in 3D

ReactPhysics3D ReactPhysics3D is an open source C++ physics engine library that can be used in 3D simulations and games. www.reactphysics3d.com ?? Fea

Daniel Chappuis 1k Jun 30, 2022
Tactile-Arcade-Games - Wrote a C program comprised of four separate games that run in a loop using the PSoC 5LP board and Cypress IDE.

Tactile-Arcade-Games - Wrote a C program comprised of four separate games that run in a loop using the PSoC 5LP board and Cypress IDE. Used two potentiometers, two ADCs to convert their voltages to digital values, a PWM to drive two servos, an 8x8 RGB LED matrix, 40 digital output pins and 8 power MOSFETS to control the matrix, and a character LCD display.

null 2 Dec 24, 2021
Emergency alert and tracer for realtime high-performance computing app (work in progress, currently supported env is only Linux x86-64).

HPC Emerg Emergency alert and tracer for realtime high-performance computing app (work in progress, currently supported env is only Linux x86-64). Exa

Ammar Faizi 7 Jan 19, 2022
tiny_csg is a C++ library that generates meshes from brush-based level data and supports incremental updates (real-time CSG).

tiny_csg is a C++ library that generates meshes from brush-based level data and supports incremental updates (real-time CSG). It is intended to be used as a backend in 3d level editors and/or generators.

Luka Aleksić 26 Jun 3, 2022
A place to collaborate on code for the Embedded.fm book club. Currently reading "STM32 ARM Programming for Embedded Systems".

Welcome to the Book Club Code site! This is a place for the Embedded.fm book club to collaborate and learn together. Repo Structure Guide Top-level fo

Peter Griffin 10 Jan 13, 2022
Open Redragon drivers for Linux. Currently only supporting some mice.

OpenDragon Open Redragon drivers for Linux. Currently only supporting some mice. Table of contents Support Installation Building from source Usage Sou

Alexa Ognjanovic 70 May 19, 2022
Show the world what you are currently listening to in Zune

ZuneDiscordRPC Show the world what you are currently listening to in Zune! Features Show Aritist, Album, Title in Discord Show Album Cover in Discord

Lars 5 May 24, 2022
Read file to console, automatically recognize file encoding, include ansi, utf16le, utf16be, utf8. Currently output ansi as gbk for chinese text search.

rgpre A tool for rg --pre. Read file to console, automatically recognize file encoding, include ansi, utf16le, utf16be, utf8. Currently output ansi as

null 3 Mar 18, 2022
An easy to build CO2 Monitor/Meter with Android and iOS App for real time visualization and charting of air data, data logger, a variety of communication options (BLE, WIFI, MQTT, ESP-Now) and many supported sensors.

CO2-Gadget An easy to build CO2 Monitor/Meter with cell phone App for real time visualization and charting of air data, datalogger, a variety of commu

Mariete 19 Jun 23, 2022
2D physics header-only library for videogames developed in C using raylib library.

Physac Physac is a small 2D physics engine written in pure C. The engine uses a fixed time-step thread loop to simluate physics. A physics step contai

Víctor Fisac 218 Jun 24, 2022
Best practices, conventions, and tricks for ROS. Do you want to become a robotics master? Then consider graduating or working at the Robotics Systems Lab at ETH in Zürich!

ROS Best Practices, Conventions and Tricks Best practices for ROS2 in the making. See the Foxy branch in the meanwhile. This is a loose collection of

Robotic Systems Lab - Legged Robotics at ETH Zürich 1.1k Jun 24, 2022
A hobby and performance-oriented Linux® distribution that provides aesthetics and practical functionality.

Heiwa/Linux A hobby and performance-oriented Linux® distribution that provides aesthetics and practical functionality.

Heiwa/Linux 26 Apr 29, 2022