Compare commits
merge into: ndepoel:master
ndepoel:console
ndepoel:master
ndepoel:readme
pull from: ndepoel:readme
ndepoel:console
ndepoel:master
ndepoel:readme
1 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
|
|
47e9ffe6a7 |
Initial WIP readme
|
4 years ago |
1 changed files with 62 additions and 0 deletions
-
62README.md
@ -0,0 +1,62 @@ |
|||||
|
## What is this? |
||||
|
|
||||
|
## Is this a Unity remake? |
||||
|
No. I did not rebuild the entirety of Quake in Unity. |
||||
|
|
||||
|
This source mod is still running the original Quake engine code with all of its original game logic, physics, maps, models, textures and audio assets. But instead of the Quake engine being self-contained, it is now running as a plugin for Unity with various hooks between the two. This allows Unity to manage Quake's resources and game loop, while Quake will send information to Unity about art assets being used and updates about the game state. |
||||
|
|
||||
|
Unity uses the information received from Quake to recreate the scene described by the engine, which then allows Unity's rendering pipeline to output graphics using a modern platform-native graphics API, such as Direct3D12 or Vulkan. The only parts I 'remade' were the shaders that mimic Quake's original look and feel, and the particle effects which are close but not quite perfect yet. |
||||
|
|
||||
|
## What's the point? |
||||
|
There's a lot of debate and confusion... |
||||
|
|
||||
|
Write once, run anywhere (while Quake is considered very portable, ...) |
||||
|
|
||||
|
Besides all that, this is simply an idea that I've had in my head for a while and that I needed to get out of my system. |
||||
|
|
||||
|
## How do I use it? |
||||
|
Compiling engine code -> DLL's copied to Plugins dir |
||||
|
Build Debug (Portable) for Editor and Development builds, Release for Release builds (due to which FMOD library is linked) |
||||
|
-> if sound is mysteriously not working, or the game crashes during sound initialization, be sure to check this! |
||||
|
You can recompile the engine while keeping the Unity Editor open |
||||
|
|
||||
|
Place ID1 and any mod directories in LocalLow (persistent data path) |
||||
|
|
||||
|
## How does it work? |
||||
|
|
||||
|
|
||||
|
These are some of the key features: |
||||
|
|
||||
|
- Dynamic loading and unloading of the Quake engine as a native plugin library through custom function binding and data marshaling code. This allows for easy iterative development (no need to restart Unity after recompiling the plugin) as well as making some neat tricks possible, like being able to load multiple instances of the Quake engine simultaneously for split-screen support! |
||||
|
- Completely rewritten audio engine using FMOD. Not only does this take care of all modern cross-platform OS and hardware support in one fell swoop, it also makes Quake sound as crisp and clear as it ever has, and it gives you features like 7.1 surround sound support basically for free. I've taken special care that it stays true to Quake's original soundscape and to my veteran ears it sounds 100% authentic. |
||||
|
- Maps and models are converted on-the-fly to Unity mesh formats. Map surfaces are batched together for optimized rendering, while Quake's vertex-animated models are replicated using Unity's blend shape system. Because this conversion process happens during the normal loading process, no data preprocessing steps are necessary and support for third-party mods with custom assets remains excellent. |
||||
|
- Rendering using Unity's Universal Rendering Pipeline (URP) allows support for any modern graphics API, with custom shaders to closely replicate Quake's original look. It also makes possible all sorts of customization of the game's visual style, with examples of Software and GLQuake rendering styles included in the project. |
||||
|
- Reimplemented Quake's various particle effects using Unity's particle system. These were hand-crafted to closely match Quake's bespoke software-driven particle system, though some effects prove difficult to replicate perfectly and there is still room for improvement. |
||||
|
|
||||
|
## Would this work on consoles? |
||||
|
Yes and as a matter of fact, it does! |
||||
|
|
||||
|
At the time I was making the initial proof of concept, I had access to multiple console devkits and made working builds for all of them to test the "write once, run anywhere" principle. And it proved successful; it only took a few hours per console platform to set up the build parameters for the engine code and make a few tweaks to the Unity project in order to make the whole thing build and run. |
||||
|
|
||||
|
Unfortunately I can't share much more information here since console development falls under a strict set of NDA's, but I can tell you that UniQuake worked exactly as expected on all consoles I tested it on and with excellent performance. |
||||
|
|
||||
|
## What about licensing? |
||||
|
This is a bit of a tricky subject. Quake's engine source code was opened to the public under the GPLv2 license. This license requires that any published modifications are also open sourced under a license compatible with GPL, *including* any libraries that are linked to the code either statically or dynamically. This is simplifying things somewhat and there is a lot of debate about where exactly the boundaries are, but I am assuming the strictest of interpretations here. |
||||
|
|
||||
|
UniQuake uses dynamic linking to couple Unity, Quake and FMOD together. Both Unity and FMOD are closed source systems published under a proprietary license, so these do not meet these requirements from GPLv2. This is why UniQuake is published as source only; I do not need to publish any linked binaries that risk violating GPL, while you can do the linking yourself without the need to publish anything. |
||||
|
|
||||
|
This would not have been a problem if the Quake source had been published under a slightly more permissive license such as LGPL or BSD, and even John Carmack himself has stated that in hindsight he wished he had[^jctweet], but alas it is what it is. |
||||
|
|
||||
|
## What's next? |
||||
|
UniQuake in its current form is only a proof of concept. It is missing many obvious features and is very much an unfinished project. I don't know if or when I will continue to work on it, but I do have a long list of ideas where the project could be taken in the future: |
||||
|
|
||||
|
- Sky and water shaders |
||||
|
- Use a visual shader programming system (e.g. Amplify or Shadergraph) |
||||
|
- 2D elements (sprites and HUD) |
||||
|
- Input |
||||
|
- FMOD advanced features: reverb, occlusion |
||||
|
- Porting lightmap updates to the GPU. Currently dynamic lighting and lightmaps are handled completely on the CPU within the Quake engine code. Modified lightmap textures are sent to Unity and uploaded to VRAM from there. This setup is fine for the original Quake levels and map packs from the same era. However some newer map packs like Arcane Dimensions will push over 100 lightmap updates per frame in some situations, which absolutely tanks performance right now. By moving dynamic lighting to Unity and performing lightmap calculations on the GPU using compute shaders, this could be sped up dramatically and possibly even outperform most other Quake source ports out there. |
||||
|
- Multiplayer (local split-screen, new networking layer) |
||||
|
- Advanced graphics: per-pixel lighting, shadows, ambient occlusion, motion blur, ray tracing? |
||||
|
|
||||
|
[^jctweet]: Insert description here [Link syntax](https://twitter.com/ID_AA_Carmack/status/1412271091393994754) |
||||
Write
Preview
Loading…
Cancel
Save
Reference in new issue