The core engine forked from NVidia's Q2RTX. Heavily modified and extended to allow for a nicer experience all-round.

Polyhedron - A Q2RTX Fork

A fork of the famous Q2RTX project by NVIDIA™ that strives to improve all of its other factors of what was once upon a time called Quake 2. The goal? Upgrading it bit by bit, in order to make it a more modern and modable engine than the original was before. It's nearly 2022, while the original was written in 1997. Such a nice and great renderer deserves a better and more improved game back-end.

What does it have so far?

  • The code is now converted to compile using a C++(20) compiler instead of a C compiler.
  • Tick Rate increased from 10hz to 50hz.
  • A Client Game(CLG in short) dll, which is simply put an extraction of the client side game code from Vanilla Q2RTX. This is inaccessible in the case of making a mod for the official Quake 2 RTX.
  • The Shared Game folder, were code resides that both the CLG and the Server Game(SVG) make use of. (The player move system is a momentary example of this.)
  • New and improved movement system. Borrowed from Quetoo by permission, and modified a bit here and there. There is no more bouncing off of stairs, just smooth stair stepping.
  • The Math library has been modified to remain C a-like, instead of using macros, it now makes use of inlined functions, and templated vector types. This allows for easier writing and reading of code:
vec3_t a = { 0.f, 5.f, 0.f };
vec3_t b = { 5.f, 0.f, 0.f };
vec3_t c = a + b; 
  • Game Modes classes, ie: SinglePlayer, DeathMatch, Team DeathMatch, Capture The Flag, etc.
  • An entity system which makes use of C++ features, ie, an entity is now a class instead of a set of function pointers.
  • ........
  • And way more things that you'll see for yourself if you check out the sauce!

Acquiring the Sauce

In order to acquire the sauce, one has to do a recursive submodules checkout, otherwise one is going to find himself in a land full of wonderful error warnings that share misery and pain. Keep in mind that the engine is currently still undergoing full development. We promote interested people to check out the code, and join on our Discord if you have any interests in joining forces.

Building the Sauce

Nothing more than using cmake on the Sauce root folder, or using Visual Studio's "Open Folder" which'll use CMake from there.

Windows 10 - VS2019

  1. Clone the repository and its submodules from git: git clone --recursive https://github.com/PolyhedronStudio/Polyhedron-Engine

  2. Start VS2019, and use the "Open Folder" method to open the project, as one normally would when using CMake projects.

Linux

  1. Clone the repository and its submodules from git: git clone --recursive https://github.com/PolyhedronStudio/Polyhedron-Engine

  2. Create a build folder inside your <PROJECT_ROOT> directory. Open a terminal in this location, and enter the following: cmake ../src && make

  3. If all goes well, you will now have a Polyhedron, Polyhedron_Dedicated, basepoly/clgame.so, and basepoly/svgame.so. If not, we're still looking for help in this department. Feel free to reach out to us on our Discord if interested.

Submodules

Comments
  • Adjust to 60hz or whichever tick rate is chosen.

    Adjust to 60hz or whichever tick rate is chosen.

    We'll need to come up with a method that is as easy and little annoying as possible in order to have the game run as if it were back in the day, while still being 60hz.

    For example, animations are currently stored as integers (ouch) and this becomes problematic, especially if game code depends on it. Like shooting 6 blaster bolts or so a second is really not good. (Looks funny though)

    • [X] Get viewbob and footsteps to work again.
    • [x] Get the network to play kindly with it again. Slightly related to #5
  • Client and Server side materials.

    Client and Server side materials.

    See whether we can make it fit in with the current .mat system. Seems logical to me to do so. This way, for example, a specific surface of a brush can have its own footstep style, or perhaps have them disabled. It is about control over such matters, decals for bullets that look different per material (we do not have them yet but still)

    Other example would be how much friction it gives to the player movement.

  • Fix SVG_MoveStep issue - Turned into change the edict_t(Entity) allocation over to the server.

    Fix SVG_MoveStep issue - Turned into change the edict_t(Entity) allocation over to the server.

    Physics problem with misc_exploboxes and other stepmove entities for that matter. If/when stacked and one disappears, it tends to go boom and crash on us. Seems to be related to an out of order deletion of entities. As if the server entity goes out first, and leaves the classentity pointing to invalid memory.

    It might be quite nice if we could add the option to be able to shove them off edges too. Right now it is only possible to do so on slopes/stairs.

  • Sun, night and day etc.

    Sun, night and day etc.

    Currently is controlled most often by the '/' key, however this should be done throughout the server instead. Perhaps there is room in configstrings, or we'd have to add some extra events. One way or the other, the server game has to rule over its domain where the sun may shine :)

  • Improve networking to prevent frame drops as they do today.

    Improve networking to prevent frame drops as they do today.

    As it stands, the networking can only handle so much. MTU limits are reached too often due to the transfers of high precision data(we could use quantization there, but it is not enough and can not be applied to every situation.).

    Bitpacking is another idea to make use of. However ideally replacing the netchannels with a library that does the dirty job for us with regards to sending these packets around sounds like the most solid idea.

  • Add in Spotlights suppor.

    Add in Spotlights suppor.

    A while ago spot lights had been discussed and it supposedly quite easy for Alex to add these in. I've found a good old Q2 tutorial on how to do it when it was still generating (lightmaps)[http://www.quake2.com/qworkshop/tutorials/lights.htm] tutorials

    I'd suggest we add pointAt(target): targetname_of_other_ent. This way, regular light target can still perform triggering as it should. (It does in N&C).

    Either way, this one is on our wish list which of course needs lightstyle support without a doubt.

  • Move work of the CLGame branch into master.

    Move work of the CLGame branch into master.

    Several fixes and cleaning on the client side, including proper tracing functionality. During this process also several fixes and improvements were made to SVGame.

  • Patching up from where we left off.

    Patching up from where we left off.

    First things first: Bigger picture goals.

    What started out as a Q2RTX Fork, sadly never got to be what it had to be, an engine powering a Quake 1 sequel. So now what?

    Work continues as per usual, setting out to solidify what we've got right now and patch it up to reach a usable and functional state. This'll require several things to be taken care of such as:

    • [ ] Finish work on all the remaining entities to-do in the server game lib.
    • [ ] Finish save/load and respawn related issues.
    • [ ] Finish game modes by adding TypeInfo to them and getting rid of coop and deathmatch cvars respectively by replacing them with the already existing gamemode cvar.
    • [ ] Clean up/Refactor several client game code.
    • [ ] Refactor/Research net code to allow for more data to be transfered, perhaps by packet fragmenting.
    • [ ] Interface all import/export functionalities of (game-)client/server import/export -structures.
    • [ ] Update the code with all the latest updates that Q2RTX has had in the past time.
    • [ ] Replace all basic content that is required to have a simple FPS with free content, rendering us independent from Quake 2 data, making this project a stand-alone afterwards. (Other than sharing the obvious which is parts of the code base.)
    • [ ] Add a proper weapon system framework that's easy to work with. (Support for reloading, dual wielding etc.)
    • [ ] Expand the material system as so to support it passing info to the server game and client game libs. Useful for footsteps, perhaps even custom friction and other game specific details on a per material basis.
    • [ ] Add proper 2D rendering support for RmlUI.

    This is the general gist of things that need to be done in order to actually be a usable piece of work again.

    Future ideas/wishlist to research:

    When all of the above is said and done, the goal is to get back on track with whichever ideas we got in the following list below:

    • [ ] Proper start up that displays the logo of the current game project being ran in fade-in and -out fashion.
    • [ ] Investigate and implement more functionality for IQM support.
    • [ ] OPTIONAL: Perhaps see if adding in a certain physics engine is worth all the effort. It'd add quite a bunch of powerful features that are useful for designing proper gameplay elements.

    ... Feel free to suggest any features you'd like to see here yourself! ...

    Current tasks being worked on:

    Please note that these vary and are sub tasks of the latter above, all serving a "greater purpose".

    • [ ] Fixing Client/Server respawn for single player(defaultgamemode) in the case of calling gamemap SAMEMAP again.
    • [ ] Fixing Client/Server save/load for single player(defaultgamemode).
    • [ ] BaseMover entities such as func_door, func_door_rotate, func_plat and func_rotate. (Half way there already.)
  • Merging CamelCase files branch.

    Merging CamelCase files branch.

    This still needs testing on Linux, which needs more work in general since I am not on a Linux system as we speak. Either way, we now got CamelCased files, as we like it that way.

  • Add in support for IQM Animations and a few other of its special features.

    Add in support for IQM Animations and a few other of its special features.

    Why, what for? Wasn't it already working in perfect shape?

    The IQM format comes with a framerate value per animation, and in fact also a name. This framerate aspect is currently unintegrated and is almost a requirement to use in the case of N&C if we want to make things work more nicely with the game code again. If an animation is determined by an integral value and the Hz rate is 50... you can imagine that if all other weapon code which is in return strictly based on which frame you're at goes haywire.

    Wished for/proposed solution would be that no matter the hz, it'll play the animation at the same speed. (Of course this would skip frames or just not work nicely at all in case there is a ridiculous high amount and the FPS can't take it, or visa versa.)

    There are more reasons to want to have full support, because "as above isn't like below today":

    The IQM format can be expended, it leaves room for devs to add in custom data by purpose. FTEQW engine has made great use of this, and in fact loading in what they then called a ".vvm" would be a piece of cake. A single extra structure containing a variable or two.

    This specific structure was about model events, for example, when animation "shoot" gets executed, it'd fire a local game implemented event number resulting in cool effects. An example of such a .qc script can be seen here. v_pistol.qc

    The other reason is that, should we use a head-torso-legs system like Q3 based engines do, or can we one way or the other integrate blending there? These few topics go beyond my reach on a code technical scale. (well I could do the head-torso-legs obviously but ...)

    output v_pistol.vvm
    materialprefix /textures/models/weapons/pistol/
    
    
    origin 64 -20 -24
    rotate 270 -90 0
    scale 1.5
    
    scene "iqe/v_pistol_muzzleflash.iqe" noanim 1 
    
    scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "idle1" fps 30 start 168 end 196
    
    event reset
        event 2 1337 "weapon_pistol.fire"
        event 2 1338 "muzzleflash1.vvm"
        scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "attack1" fps 30 start 2 end 10
    
    scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "attack2" fps 30 start 196 end 214
    
    event reset
        event 10 1337 "weapon_pistol.reload"
        scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "reload1" fps 30 start 10 end 56
    
    event reset
        event 135 1337 "weapon_pistol.deploy"
        scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "draw1" fps 30 start 135 end 167
    
    event reset
        event 126 1337 "weapon_pistol.holster"
        scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "holster1" fps 20 start 126 end 135
    

    Examples of the file structure I used and the models themselves can be found here in my old SchizoMania project repository:

    Notice how the names, the frame rate per second, and the specific frames out of the list in general to pick from can all be adjusted in these "scripts"? The workflow might be a bit time consuming, but it'll be our best bet at having nice animated characters, as well as nice animated weapons.

    Keep in mind that for a bullet shell to pop out, it'd just take a certain event number, modelname, and any artist can actually take control over what shell, what sound, and at what frame this has to happen.

    Right now we got IQM playing nicely, without blending (If I recall this would require Inverse Kinematics.), however it seems to lack the framerate aspect which is the highest priority right now. And of course, all the other things mentioned.

    One final example of how I did the Zombie Character back in SchizoMania, it also mentions how animations can auto loop (unless of course ever the game code tells it to go play some other animation.)

    output zombie_derrick.vvm
    materialprefix /models/characters/zombie_derrick/
    
    scene "iqe/tpose.iqe"
    
    origin 0 0 0
    rotate 0 -90 0
    
    
    scene "iqe/agonizing.iqe" fps 30
    scene "iqe/attack1.iqe" fps 55
    scene "iqe/attack2.iqe" fps 30
    scene "iqe/dying1.iqe" fps 30
    scene "iqe/dying1_fast.iqe" fps 30
    scene "iqe/dying2.iqe" fps 30
    scene "iqe/dying2_fast.iqe" fps 30
    scene "iqe/hit_react_a.iqe" fps 30
    scene "iqe/hit_react_b.iqe" fps 30
    scene "iqe/idle1.iqe" fps 30 loop
    scene "iqe/idle_hunt.iqe" fps 30 loop
    scene "iqe/idle_scratch.iqe" fps 30 loop
    scene "iqe/running1.iqe" fps 30 loop
    scene "iqe/scream.iqe" fps 30 loop
    scene "iqe/turn_backface.iqe" fps 30 loop
    scene "iqe/walking1.iqe" fps 35 loop
    scene "iqe/walking2.iqe" fps 50 loop
    scene "iqe/walking3.iqe" fps 30 loop
    

    All of this resulted in a slightly slow and somewhat limited by toolset workflow, however given the advantages and the fact that the Quake communities do keep these tools up to date (Eihrul has his own iqmtool, and Blender export/import.) Where FTEQW has its own iqmtool as well with several other improvements.

    Sources:

    Source code to the engine Tesseract src, which is messy/tricky to read, you'll see the files soon enough. He goes over the top with a BIH, Ragdolls, no physics engine for it either. That is not our goal but it might help be a reference for loading in IQM data.

  • Trenchbroom & Official Support

    Trenchbroom & Official Support

    Having spoken to some in the Trenchbroom Discord, it's not that hard to be reknown as an official project in/for their releases.

    In our case it'd mean having to implement a variety of this (which they said would be hard, but we aren't having all that Q3 shaders have nor do we need that in the editor to be displayed per se. Take a bit of a deeper look and you will see why they stated it was "hard".

    With Q2 .wal being officially supported now, and that at least being our base to begin with regarding our own materials, it makes sense that this "PolyHedronMaterialParser.cpp" would parse those content and surface flags from the .mat Other than that, it only has to tell TB to load in a .tga

    Now when it comes to .iqm support, I have no clue why nobody ever ever added that because it was quite easy for me to find some simple loading and rendering code for that... Here ] is a random one found on the web that I bet can quite easily be converted into a TB compatible loader implementation. Perhaps look at Md3Parser.cpp as a base.

    I'm curious to hear your thoughts. Of course this isn't for milestone 0.4.0 per se, we haven't even finished the material system properly yet. But if they do not mind officially supporting us, and the editor being so well known etc, I think it's a great option to go for it.

Not a big fan of git. May create a nicer repo in the future.

os My x86-64 hobby operating system. Cooperative multitasking system with no user-mode support, everything runs on ring 0 (for now). Packed with a rea

Aug 11, 2022
Signed - a 3D modeling and construction language based on Lua and SDFs. Signed will be available for macOS and iOS and is heavily optimized for Metal.
Signed - a 3D modeling and construction language based on Lua and SDFs. Signed will be available for macOS and iOS and is heavily optimized for Metal.

Signed - A 3D modeling language Abstract Signed is a Lua based 3D modeling language, it provides a unique way to create high quality 3D content for yo

Jul 4, 2022
A CUDA-accelerated cloth simulation engine based on Extended Position Based Dynamics (XPBD).
A CUDA-accelerated cloth simulation engine based on Extended Position Based Dynamics (XPBD).

Velvet Velvet is a CUDA-accelerated cloth simulation engine based on Extended Position Based Dynamics (XPBD). Why another cloth simulator? There are a

Aug 7, 2022
Open Source Cheat for Apex Legends, designed for ease of use. Made to understand reversing of Apex Legends and respawn's modified source engine as well as their Easy Anti Cheat Implementation.
Open Source Cheat for Apex Legends, designed for ease of use. Made to understand reversing of Apex Legends and respawn's modified source engine as well as their Easy Anti Cheat Implementation.

Apex-Legends-SDK Open Source Cheat for Apex Legends, designed for ease of use. Made to understand reversing of Apex Legends and respawn's modified sou

Aug 3, 2022
Speed Running and Competition Doom. For strictly vanilla speed runs and competitions - forked from CNDoom

Speed Running and Competition Doom Speed Running and Competition Doom is based on Chocolate Doom and aims to accurately reproduce the original DOS ver

May 24, 2022
Pdfmm - A C++ PDF manipulation library forked from PoDoFo

pdfmm What is pdfmm? Requirements String encoding API Stability TODO Licensing No warranty Contributions Authors What is pdfmm? pdfmm is a s a free po

Aug 10, 2022
legacy Botnets source code Forked from github.com/malwares

Legacy-Botnets-Source-Code-Collection github.com/malwares None of these were made by me and I take no resonsibility for anything done with the code. T

Jun 4, 2022
Arduino core for GD32 devices, community developed, based on original GigaDevice's core
Arduino core for GD32 devices, community developed, based on original GigaDevice's core

GD32 Arduino Core (New) This is a Arduino core is based off of the original GigaDevice core that was provided by the company in early June 2021 (see h

Jul 20, 2022
Obfuscator refactored and extended from OLLVM.
Obfuscator refactored and extended from OLLVM.

OLLVM++ Obfuscator refactored and extended from OLLVM. Environment Ubuntu 18.04.5 LTS LLVM 12.0.1 Clang 12.0.1 CMake 3.21.1 Usage Compile Obfuscation

Aug 9, 2022
Extended kalman filter implementation.
Extended kalman filter implementation.

EKF (Extended Kalman Filter) This project is a C++ implementation of EKF.For the related principles of EKF, please check this tutorial (TODO). Project

Jun 26, 2022
Half-Life : Extended main branch for developing purposes
Half-Life : Extended main branch for developing purposes

Half Life : Extended SDK Source Code of Half Life : Extended as a open source modbase for everyone publicly, make your own mod with alot of features e

Jun 21, 2022
Xtl - eXtended Template Library

eXtended Template Library Open Hub Linux Windows Coverage Technical Debt Code Quality License Contribute with Gratipay Contribute with Beerpay View th

Feb 17, 2020
Invariant-ekf - C++ library to implement invariant extended Kalman filtering for aided inertial navigation.
Invariant-ekf - C++ library to implement invariant extended Kalman filtering for aided inertial navigation.

inekf This repository contains a C++ library that implements an invariant extended Kalman filter (InEKF) for 3D aided inertial navigation. This filter

Aug 5, 2022
A small XM (FastTracker II Extended Module) player library.

libxm A small XM (FastTracker II Extended Module) player library. Main features: Small size in mind; many features can be disabled at compile-time, or

Jul 16, 2022
Creating sepia, reflection, grayscale, and blur filters from scratch and returns a modified image

image-filter Created sepia, reflection, grayscale, and blur filters from scratch and returning a modified image Directories: images: contains sample i

Oct 14, 2021
This is a library that can fix the crash on android 5.0 and 5.1 caused by modified utf8 converting.

FixModifiedUtf8ConvertError This is a library that can fix the crash on android 5.0 and 5.1 caused by modified utf8 converting. What's this On Android

Nov 23, 2021
Sensirion Mass Flow Sensor Arduino library, modified from MyElectrons and Nabilphysics Arduino repositories for SFM3300 Digital Mass Flow Sensor
Sensirion Mass Flow Sensor Arduino library, modified from MyElectrons and Nabilphysics Arduino repositories for SFM3300 Digital Mass Flow Sensor

Sensirion Mass Flow Sensor Arduino library, modified from MyElectrons and Nabilphysics Arduino repositories for SFM3300 Digital Mass Flow Sensor. When the sensor data gets stuck, the library has a hard reset function to ensure that it is read continuously.

Apr 11, 2022
Bungie's Oni modified so it compiles with Microsoft Visual Studio 2019.

OniFoxed What's this? This is a modified variant of the recently leaked Oni source code so that it compiles under Microsoft Visual Studio 2019 with so

Jul 16, 2022
I modified the colmap,when it reconstructs from known pose ,only let it optimize rotation ,fixing position!

Mapping-base-lidar-pose-or-vslam-pose I simply modified the colmap,when it reconstructs from known pose ,only let it optimize rotation ,fixing positio

Jun 20, 2022