An open source re-implementation of LEGO Rock Raiders 🪨⛏



An open source re-implementation of LEGO Rock Raiders (PC). This is created by slowly implementing and replacing game functionality, while relying on the original executable and game assets for everything else.

OpenLRR is not associated with The LEGO Group or Data Design Interactive. When using the name "OpenLRR" within this project, the L must never be expanded (i.e. do not write "Open LEGO Rock Raiders").

Base game installation

See also

Related LRR projects

Similar open source projects

  • How to run

    How to run

    Hi, maybe I'm stupid but there's absolutely no documentation on how to actually run this. Can someone help me please? Simply cloning the repo into the LRR folder doesn't work, the .exe says it's missing openllr.dll (or openllr-d.dll)

    opened by mfnalex 3
  • Block Fade does not work without texture management

    Block Fade does not work without texture management

    Describe the issue

    Block Fade is an experimental feature enabled with the command line option: -flags 32768. This causes block textures to fade-transition into their new state when changed (except for roof textures).

    The feature only works as expected when paired with the -ftm option ("Force texture management").

    However when texture management is disabled, the resulting effect is a delay until the transition time is over, upon which the block texture immediately changes. (This basically looks like lag.)

    As this effect looks quite neat (especially with Power Paths transitioning their powered state), see if it's possible to fix this issue while keeping texture management disabled.

    Steps to solve

    Note: Simply having texture management on is an undesirable solution as it produces a very broken lighting experience, where only walls have lighting applied. (This in of itself may be a graphical bug that affects the Block Fade issue... or it may have been an intended limitation for Voodoo2 graphics cards).

    1. Search engine/gfx/Mesh.cpp for uses of the flag: MAIN_FLAG_DONTMANAGETEXTURES.
    2. In order to find the code that supports these transitions, try removing render/texture state change lines from texture management code blocks to see if these disable the effect.
      • Test these changes with the command line options -flags 32768 -ftm.
    3. If lines responsible for the effect are found, try moving these outside of the conditional code blocks.
      • Test these changes with the command line options -flags 32768 -nm. (-nm is usually applied by default as the opposite to -ftm, as such it is an optional argument)
    4. Confirm if the effect is visible with texture management disabled, and ensure there are no adverse effects caused by these changes.
    graphics original bug 
    opened by trigger-segfault 1
  • Always allow skipping intro videos and splashes

    Always allow skipping intro videos and splashes

    Describe the issue

    The intro videos and splash screens in LRR are incredibly slow, and unskippable by default when launching the game without -programmer options.

    Area(s) with issue?

    Videos/splashes played on boot, and videos played at the end of a level.

    Steps to fix

    Force the skippable parameter to true for all intro videos/splashes. And consider doing the same for level-end videos.

    Additionally, it may be best to add an option to remove the intros entirely, like in LRR:CE.

    alteration user interface 
    opened by trigger-segfault 1
  • NERPs speech/script freeze in Rubble Trouble

    NERPs speech/script freeze in Rubble Trouble

    Describe the issue

    A game freeze can be caused in "Rubble Trouble" by immediately skipping mission briefing, in relation to NERPs message speeches.

    Area(s) with issue?

    Levels: Level03, "Rubble Trouble"

    Although other levels (such as "Frozen Frenzy") seem to meet the same conditions for this bug, only "Rubble Trouble" has been found to trigger this freeze.

    Steps to reproduce

    1. Boot up the game: i. Either with a save game that has "Rubble Trouble" unlocked. ii. Or with the command line option: -testlevels.
    2. Enter level selection: i. Either through loading a same game. ii. Or press Start Game if using -testlevels.
    3. Navigate down to "Rubble Trouble" without triggering any level name SFX.
    4. Rapidly launch "Rubble Trouble" (again, before the level name SFX plays).
    5. Rapidly skip the mission briefing with the >> button.
    6. The game should immediately freeze (then crash? needs confirmation).

    Possible leads

    • The game freeze is triggered by SFX module passing some garbage value sound handle number to the Sound3D module, which is called during a loop in a NERPs message file handling function.
    • "Rubble Trouble" triggers a Chief speech with a vertical dropdown animation stating "You must collect 5 Energy Crystals". Immediately after the mission briefing ends.
    • The NERPs messages file has 7 sounds listed, but the seventh voice file does not exist in the game data. (Sounds\Streamed\InGame\ins307.wav)
    • The NERPs script itself varies from other similar levels (that don't trigger the bug).
    • It seems this cannot be reproduced after a level name SFX has been played. Or after starting a level for the second time(?).


    🎥 Walkthrough video

    freeze original bug 
    opened by trigger-segfault 1
  • Mouse cursor invisible over titlebar in window mode

    Mouse cursor invisible over titlebar in window mode

    Describe the issue

    The game always chooses to render its own cursor over the system cursor. When in Windowed mode, this decision also impacts the frame of the window (outside of the game client area). The cursor is not shown at all when in this area, making it frustrating to drag the window, use any buttons in the title bar, or use an attached system menu.

    original bug platform 
    opened by trigger-segfault 1
  • Window close button only works in-game

    Window close button only works in-game

    Describe the issue

    When pressing the Windows close [X] button, the game should immediately close. However, when running inside a UI loop, the exit request is stored, but not honored until the game gets back to the Main loop. Basically all UI loops are called as a subfunction nested deep inside the main loop.

    So for example, pressing close [X] during loading will have no effect. The user will then reach the Title screen, select a level, and then once loaded in, the game will immediately exit (naturally without error).

    List of UI loops

    • Loading
    • Videos, splashes, and credits
    • Front End menus
      • Title screen
      • Level select
      • Load/save select
    • Reward screen
    original bug platform 
    opened by trigger-segfault 0
  • Dynamite crashes on countdown 4

    Dynamite crashes on countdown 4

    Describe the issue

    When using dynamite, the game may crash just as the 4 in the countdown finishes . This is easily reproduced (only in OpenLRR), but the boundaries of what stop it from happening aren't as clear. Leaving the explosion and explosive user off-screen prevents the crash. The stack trace indicates that a Rock Raider's object is where the crash occurred in the code.

    The crash occurs within D3DRM IDirect3DRMFrame3->GetAppData()



    1. This seems to no longer be reproducible. The issue may have something to do with the environment. Figuring out what that was, and if it's worth investigating is going to be frustrating.
    2. Bug is now reproducible again after a system restart (which is terrifying). Testing needs to be continued to identify if this is exclusive to the trigger-develop branch.
    3. Crash reproducibility is tied to Fault Tolerant Heap (FTH) getting turned on. This needs to be disabled with Rundll32.exe fthsvc.dll,FthSysprepSpecialize when the VS debugger states FTH is being used.
    4. The crash is also reproducible in the current main branch inside a clean install folder (aside from compatibility setup). However it cannot be reproduced in the base game.

    Cause (updated)

    The cause was first misidentified as using CALL over JMP to get into the replacement WinMain function (which was assumed to be some windows dll threading nonsense), but this only solved the issue for unrelated reasons.

    The actual cause was failing to backup the EBP register before changing the stack (which happened when pushing arguments for CALL, but not directly changing functions with JMP). Not only did this cause the unexplainable D3DRM crashes, but this same mistake was also interfering with the VS Debugger, which would always give incorrect values for function arguments when breakpointing.

    Solution (updated)

    The solution includes adding/changing the following assembly instructions in the WinMain patch (for the last time now, hopefully) to preserve EBP.

    -PUSH dword ptr [ESP + 0x10]
    +PUSH dword ptr [ESP + 0x14]
    -PUSH dword ptr [ESP + 0x10]
    +PUSH dword ptr [ESP + 0x14]
    -PUSH dword ptr [ESP + 0x10]
    +PUSH dword ptr [ESP + 0x14]
    -PUSH dword ptr [ESP + 0x10]
    +PUSH dword ptr [ESP + 0x14]
     CALL dword ptr [indirectAddr]
     ADD  ESP,0x10
    +POP  EBP
     RET  0x10

    OpenLRR's detection for InjectMethod::DllStart will also need to be modified to match the new patch instructions.

    bug crash graphics 
    opened by trigger-segfault 0
  • Distributable OpenLRR executable

    Distributable OpenLRR executable

    Describe the issue

    Similar to other projects LegoRRCE.exe and OpenRCT2.exe, OpenLRR needs a proper distributable executable. This is required to solve the following:

    1. Import the openlrr.dll codebase to inject all modifications.
      • And preferably hook the WinMain function with a call to initialise OpenLRR (which avoids all race conditions caused by DllMain).
    2. Ensure all users are running the same Masterpiece executable.
    3. Enable use of VS debugger (which can't be done through Injector, due to it launching a new process).

    Currently, OpenLRR debugging has been performed by using a modified version of LegoRRCE.exe with changed imports.

    The OpenLRR executable should be buildable without relying on LRR:CE, and should be created from a fresh Masterpiece executable.

    Steps to build executable

    OpenLRR must be built from the Masterpiece executable.

    The goal is to import the OpenLRR codebase contained in openlrr.dll, and replace the original LegoRR.exe::WinMain entrypoint with a call to openlrr.dll::StartOpenLRR.

    1. Insert a new Import Directory PE section (.idataOR) after .idata and before the final section .rsrc.
    2. Append a new import for openlrr.dll and include the function StartOpenLRR.
    3. Overwrite LegoRR.exe::WinMain with a call to int __cdecl openlrr.dll::StartOpenLRR that pushes the same 4 parameters, then cleans up the stack and returns.
    4. Update the Import and Resource directory RVAs to point to their new location.
    5. Update the address offsets within .rsrc to match their new location.
    6. Replace the main icon resource with "teal-OR" and include any other desired resources.

    Note: The reason .idataOR isn't being appended after .rsrc is so that anyone can freely modify executable resources without potentially breaking our hook into openlrr.dll::StartOpenLRR. This ensures our import will be placed in a fixed position that won't unexpectedly change.

    PE fields of importance

    Fields to read

    • OPTIONAL HEADER: FileAlignment
    • OPTIONAL HEADER: VirtualAlignment

    Fields to modify

    • FILE HEADER: NumberOfSections (+1 for .idataOR)
    • OPTIONAL HEADER: SizeOfInitializedData (+file size diff of .rsrc, round up to file alignment)
    • OPTIONAL HEADER: SizeOfImage (+virtual size diff of .rsrc, and +virtual size of .idataOR, round up to virtual alignment)
    • DATA DIRECTORY[1] Import directory
      • VirtualAddress (change to address of .idataOR)
      • Size (+0x14 for added dll import openlrr.dll)
    • DATA DIRECTORY[2] Resource directory
      • VirtualAddress (+offset in address caused by .idataOR)
      • Size (+file size diff of .rscr)
    opened by trigger-segfault 0
  • -dualmouse command line option has no effect

    -dualmouse command line option has no effect

    Describe the issue

    • In LRR, the dual mouse setting is implemented as a positive option to enable the feature: -dualmouse
    • While in Gods98 source, the setting is implemented as a negative option to disable the feature: -nodualmouse

    Currently, OpenLRR mistakenly uses the -nodualmouse command line option (as per Gods98 in Figure B) while also disabling the feature by default (as per LRR in Figure A), forcing the feature to always be off.


    Figure A: Following LRR and disabling dual mouse before parsing the command line.

    Figure B: Following Gods source and checking if the user wants to disable dual mouse.

    Steps to fix

    Apply the following changes to the Figure B source line, so that OpenLRR correctly matches LRR behavior:

    1. Change the parsed command line option string to "-dualmouse".
    2. Change the flags operation on the same line to |= MainFlags::MAIN_FLAG_DUALMOUSE; to set, rather than unset, the flag.
    bug good first issue 
    opened by trigger-segfault 0
  • Blank screen in FirstPerson view after pausing

    Blank screen in FirstPerson view after pausing

    Describe the issue

    When pausing the game in first person, there's a high chance that the entire 3D space of the screen will turn a solid colour (presumably the fog colour). This issue persists in both Eye and Shoulder View, and will only reset once switching back to Topdown view.

    This issue also affects the Lego*::Levels::<name>::StartFP TRUE property, as there's a high chance the screen will be unusable when first viewing the level from first person.

    FP view after vs. before pausing


    Steps to reproduce

    The issue is very common, but not 100% consistent. It can usually be forced after 10 seconds of fiddling, if it doesn't happen on the first try.

    1. Start a level and enter any First Person view mode.
    2. Pause the game / or focus on another window if you have LoseFocusAndPause TRUE in Lego.cfg.
    3. If this does not cause the issue. Try switching view modes between first and second person, leaving to topdown view and re-entering, or walking around in FirstPerson view.
    4. Repeat until the issue takes effect.

    Notes on the issue

    This bug is also triggered by the "Freeze" mode (where the game has an update time of 0.0f, without actually using in-game pause features), meaning that it's likely related to the elapsed game time being 0.0f.

    graphics original bug 
    opened by trigger-segfault 0
  • Mesh rendering inconsistency in OpenLRR

    Mesh rendering inconsistency in OpenLRR

    Describe the issue

    When looking a Rock Raider minifigure model in-game (in OpenLRR), they seem to have a dark outline around most of their edges. When compared side-by-side with LegoRR's original rendering, it seems these outlines are the mesh extending beyond its normal bounds. Additionally, the texture is fuzzy and blurred, in contrast to the sharp texture seen in the original.

    Figure A: LegoRR (left) vs. OpenLRR (right)


    Steps to identify

    1. [x] Begin unhooking engine/gfx/ mesh-related modules until the issue seems to be resolved. If this does not solve the issue, then there may be additional problems in engine/Main, or possibly even engine/drawing/DirectDraw. (worst case may be in engine/core/Utils, where certain string parsing may be failing)
    2. [x] Once module(s) have been identified, begin slowly re-hooking functions until the source of the issue can be narrowed down.
    3. [x] Finally, the issue needs to be identified as either a bug (or difference from LegoRR) in the referenced Gods98 source, or a bug created when porting to C++ Interface calls and other conventions.


    1. Source of the bug is engine/gfx/Mesh module.
    2. (partial) One inconsistency found (ambient set to 1.0f instead of 0.0f), but it's not thecause of the issue.
    3. Source of bug is from ignoring the TFM_PIXEL_BLENDING flag during Mesh_ParseLWO (which is how the newer Gods98 source was doing things).
    bug graphics 
    opened by trigger-segfault 0
  • Add Language selection

    Add Language selection

    I would like the idea to add an option for loading the assets for the corresponding language that is selectable before the game start. I could provide the german assets if needed as I have the german version installed.

    opened by KevinCCucumber 0
  • Random crash issues with ListSet.hpp

    Random crash issues with ListSet.hpp

    Describe the issue **This is possibly a legacy bug related to the random crashes in the original game, and not specific to OpenLRR. The game crashed in a random manner, not tied to anything specific, at separate occasions. First time I had a lot of miners, some STTs and a Chrome Crusher, trying to clear the map (no creatures), second time I was observing some game behaviour, restarting the level over and over again, and at the time of the error, a monster was attacking the base. I had no vehicles, and only 5 miners.

    Note: There have been several errors with different lines/names, might be more than one culprit here. Might need some more assertion throughout the entire thing. Note 2: Luckily, one can click "Ignore" to go right past them, but it is a bit frustrating for sure.

    Steps to reproduce Since this occured in two separate scenarios and are not guaranteed, I will write down the approximate procudure I was doing: Scenario A

    1. Start playing Rocky Horror
    2. Play the level for a longer time, preferably with many units, buildings and things going on. For example, try to teleport in 20 RRs, 3 STTs, a Chrome Crusher, and drill all the walls with the CC, without opening the crystal cache.
    3. At some point, the game should give the error and crash
    4. Press "Ignore" to ignore the error/crash

    Scenario B

    1. Start playing Rocky Horror
    2. Give a few miners Laser Beams. Let them kill all monsters on the map.
    3. Let a monster attack the base by triggering an emerge.
    4. Restart the mission at some point, preferrably when a few buildings have been destroyed.
    5. Errors should appear after a while. In my experience it gave more consecutive errors
    6. Press "Ignore" to ignore the error/crash.

    Additional information

    • Time played this session: 25-30 minutes for first encounter, 15 minutes for second encounter
    • Level: Rocky Horror
    • Game speed: 100-300%
    • Graphics fix: dgVoodoo 2.55
    • Using mods: Debug keys were enabled
    • Windowed mode: Yes

    Additional context (optional) In all cases here I didn't exactly play "as intended", so you might have to play a bit differently to hit the errors. The first time I tried to clear out an entire level, the second time I was trying to observe some game behaviour to implement into MM and restarted the level many times. It is possible that restarting the level was related to some of the crashes, as crashes after several restarts appeared to have more errors pop up.

    Screenshots (optional) 1. Appeared after attempting to drill all walls in Rocky Horror with a Chrome Crusher. The Hard Rock walls are the last remaining walls, not counting the 2 walls in front of the cache. Game crashed somewhere in the process of drilling the second-to-last wall, it appears to have been shortly after the drilling started. Also seems there was a Rock Raider right in front of the Chrome Crusher that might've overlapped with it right as it happened? image

    2. New play session a day later. I tried observing how alerts reacted to creatures being killed. Appeared once after restarting the level once, while a monster was attacking the base: image

    3. Still second session. Appeared several times in a row after restarting the level a few times: image

    opened by Baraklava 0
  • Randomized sound cues always pick last sound

    Randomized sound cues always pick last sound

    Describe the issue When playing certain sound cues, only a single sound file is played while there should be several, and appear to pick the last sound in the sequence. This will, for example, make the slip-on-spider sounds be the unused voice lines rather than the ones always heard in the original LRR release.

    Expected behaviour Sound cues pick from a set of random sounds if they exist. This includes sounds like:

    • The ambient "drip"
    • Rock Raiders running from dynamite
    • Rock Raiders slipping on spiders
    • Rock Monster steps

    Steps to reproduce

    1. Start playing a level
    2. Notice that the drip sound in the background is always the same one (or try and other of the sounds above)

    Additional information

    • Time played this session: 0:01
    • Level: Any
    • Game speed: 100%
    • Graphics fix: dgVoodoo 2.55
    • Using mods: No
    opened by Baraklava 0
  • Rewrite 2D drawing APIs

    Rewrite 2D drawing APIs

    Describe the issue

    Both the Draw and Fonts modules are very poorly optimized, and can cause a massive hit in performance when overused.


    • When the Radar Map View is open.
    • When a ToolTip is showing.
    • When ObjInfo above units are showing.

    Draw module

    • Consider reorganizing the use of Draw functions, so that all drawing happens in a single buffer lock/unlock. Maybe a spritebatch like with what's used in XNA (this would need to be implemented for all drawing-based modules).
    • None Effect: Fill rect and line functions should be replaced with BitBliting a 1x1 white pixel with scaling, colorization, and rotation to match the desired output.
    • HalfTrans Effect: Can probably be replaced with an added alpha value (around 0.5?) to get a close approximation to the actual pixel operation.
    • XOR Effect: Might be natively supported by BitBlit, but it has to be checked.

    Font module

    • Optimizations for sprite fonts may be a lot trickier, since drawing is already done with BitBliting images from a sheet.
    • More research is needed to see where the bottlenecks are, and how they can be resolved.
    graphics performance 
    opened by trigger-segfault 0
  • Queuing up commands before first raider teleports down

    Queuing up commands before first raider teleports down

    Describe the issue

    At the start of levels without any Rock Raiders, time spent teleporting down the first unit is somewhat wasted because most commands that can be queued up (like drilling walls) are grayed out.

    There isn't a completely straight forward solution, since these types of options are grayed out based on the capabilities of units present in the level. For example, keeping Drill Hard Rock grayed out when no capable vehicle is present is a useful feature.

    Changes to this should be kept minimal, to reduce the amount of hardcoded unit behaviour added to the game.

    Possible solutions

    Solution A

    Unlock all capabilities (that aren't locked behind required buildings) until the first MiniFigure has been teleported down into the level. Once this happens, all inaccessible commands will go back to being grayed out.

    This should probably behave the same whenever there are no MiniFigures in the level.

    Solution B

    Keep all (basic?) MiniFigure capabilities permanently unlocked.

    The object list could also be checked to see if any MiniFigure is capable of using explosives.

    enhancement game ai 
    opened by trigger-segfault 0
  • Additional command line options

    Additional command line options

    List of commands currently in progress

    |Command|Description| |:------|:----------| |-nointro|Don't play intro videos/splashes (from LRR:CE).
    Should this include skipping level intros?| |-res <W>x<H>|Add a supported resolution mode (from LRR:CE).
    Does not fix hardcoded 640x480 resolution handling in-game.| |-log
    -nolog|Show/hide console log (from LRR:CE).| |-menu
    -nomenu|Show/hide system menu.| |-datafirst|Files in Data directory will have load-priority over those found in WAD files.| |-datadir <path>|Change path to Data directory, including the name of the directory (default: <curdir>\Data).| |-waddir <path>|Change directory where WAD files are searched for (default: <curdir>).| |-wadname <name>|Change name where WAD files are searched for (default: LegoRR).| |-gamename <name>|Change name used for root CFG property lookup (default: LegoRR, must start with Lego to match all Lego* root properties).
    This is used for .cfg, .ae, .ol, and .ptl (all CFG-like) files.| |-name <name>|Shorthand for both -wadname and -gamename (has lower priority over individual commands).|

    List of commands not yet started

    |Command|Description| |:------|:----------| |-help|Display all command line options, and maybe other info on getting OpenLRR to run.| |-scale <num>|Change startup Window Scale option (default: 1, in most cases monitors will only support a max scale of 2 or maybe 3 with 4K).| |-fullscreen|Change default display mode to fullscreen instead of windowed.| |-cfgname <file>|Change the main configuration file (default: Lego.cfg ).| |-addcfg <file>|CFG file to append to main configuration file (for overwriting individual settings without having to modify the main configuration file itself).
    Can be used more than once to append multiple files.|

    feature config 
    opened by trigger-segfault 0
  • v0.0.0.1(Feb 19, 2022)

    Running requires, placing OpenLRR.exe and openlrr.dll in a working LRR install folder. This includes standard fixes needed to run LRR, such as:

    • D3DRM.dll
    • dgVoodoo/DDrawCompat
    • Musix fix (optional)
    • And applying the standard compatibility properties when using windowed mode:

    Windowed compatibility properties:

    • [x] Reduced color mode [16-bit (65546) color       v ]

    Windowed mode is recommended, as most of the features placed into the system menu are not easily accessible from fullscreen yet. Windowed mode is the default-selected option when the Mode Selection dialog opens.


    Source code(tar.gz)
    Source code(zip) KB)
Robert Jordan
I have too many C# projects...
Robert Jordan
WinMerge is an Open Source differencing and merging tool for Windows.

WinMerge is an Open Source differencing and merging tool for Windows. WinMerge can compare both folders and files, presenting differences in a visual text format that is easy to understand and handle.

null 3.2k Aug 6, 2022
cavi is an open-source library that aims to provide performant utilities for closed hierarchies (i.e. all class types of the hierarchy are known at compile time).

cavi cavi is an open-source library that aims to provide performant utilities for closed hierarchies (i.e. all class types of the hierarchy are known

Baber Nawaz 5 Mar 9, 2022
KeyScan is a C++ open source explanation tool targeting windows operating system.

KeyScan is a C++ open source explanation tool targeting windows operating system. it allows you to send keyboard events, mouse events and capture keystrokes (keylogger).!

null 12 Jul 24, 2022
Open Source iOS 15 Jailbreak Project

Fugu Fugu is the first open source jailbreak tool based on the checkm8 exploit. UPDATE: Fugu will now install Sileo, SSH and Substitute automatically!

epeth0mus 106 Jul 31, 2022
A C library for parsing/normalizing street addresses around the world. Powered by statistical NLP and open geo data.

libpostal: international street address NLP libpostal is a C library for parsing/normalizing street addresses around the world using statistical NLP a

openvenues 3.5k Aug 11, 2022
Open Data Description Language

Open Data Description Language This is the reference parser for the Open Data Description Language (OpenDDL), version 3.0. The official language speci

Eric Lengyel 24 Jun 30, 2022
Orbit, the Open Runtime Binary Instrumentation Tool, is a standalone C/C++ profiler for Windows and Linux

Orbit, the Open Runtime Binary Instrumentation Tool, is a standalone C/C++ profiler for Windows and Linux. Its main purpose is to help developers visualize the execution flow of a complex application.

Google 2.7k Jul 31, 2022
AlleyWind is an advanced Win32-based and open-sourced utility that helps you to manage system's windows

AlleyWind AlleyWind is an advanced Win32-based and open-sourced utility that helps you to manage system's windows. AlleyWind could: Displays a graphic

KNSoft 19 Jul 28, 2022
Open-CMSIS-Pack development tools - C++

CMSIS-Pack Development Tools and Libraries This repository contains the source code of command line tools and library components for processing meta i

Open-CMSIS-Pack 27 Jul 26, 2022
A CoAP (RFC 7252) implementation in C

libcoap: A C implementation of the Constrained Application Protocol (RFC 7252) Copyright (C) 2010—2021 by Olaf Bergmann [email protected] and others AB

null 647 Aug 8, 2022
A pure C implementation of the Geohash algorithm.

libgeohash Derek Smith [email protected] A static library used for encoding/decoding geohashes. To use libgeohash just run make. Link libgeohash.a a

Urban Airship 95 Jun 17, 2022
Juice the carrots from ウマ娘プリティーダービー (Umamusume Pretty Derby) - Android implementation

Riru-CarrotJuicer Hooks the decryption function in of ウマ娘プリティーダービー (Umamusume Pretty Derby), to allow inspecting the packets. For Windows

Huang Yue 27 Aug 9, 2022
This is a simple C++ implementation of plant-like structures defined with bracketed OLsystems.

Tree Hundred This is a simple C++ implementation of plant-like structures defined with bracketed OLsystems, as described in the book The Algorithmic B

null 22 Apr 22, 2022
An implementation of yacc for the janet programming language.

janet-yacc An implementation of yacc for the janet programming language. The implementation is based heavily on Example from ./e

null 11 Nov 22, 2021
libddwaf is Datadog's implementation of a WAF engine

Datadog's WAF libddwaf is Datadog's implementation of a WAF engine, with a goal of low performance and memory overhead, and embeddability in a wide va

Datadog, Inc. 11 Jul 28, 2022
Small implementation of c++ entity component system inspired by Unity

EntityComponentSystem About This is small implementation of entity component system with C++. The API is heavily inspired by Unity ECS framework, but

Lukas Chodosevičius 2 Oct 13, 2021
Crown (formerly Crowncoin) reference implementation

Crown Core integration/staging tree What is Crown? Crown is an experimental digital currency that enables instant payments t

Crown Platform 4 May 31, 2022
GNU project's implementation of the standard C library(with Xuantie RISC-V CPU support).

GNU project's implementation of the standard C library(with Xuantie RISC-V CPU support).

T-Head Semiconductor Co., Ltd. 5 Mar 17, 2022
A basic A* implementation showing how to use C++20 modules alongside UWP and C++/WinRT.

Introduction This is a port from an old application that was original written in a mix of C++14, Java and C++/CX. Originaly the goal was to use a simp

null 9 Mar 2, 2022