A Doom Renderer written in Rust.

Cristi Cobzarenco

Last update: Jan 1, 2023

Related tags

Games game rust opengl rendering retro doom glutin glium wad

Overview

Rust Doom

A little Doom 1 & 2 Renderer written in Rust. Mostly written while I was learning the language about 2 years ago, so it might not the best example of Rust code! PR-s are welcome.

The code is mostly based on the endlessly useful Doom Wiki and the Unofficial Doom Specs. It is not a port of the original Doom C source code into Rust; I've been doing my best to make the code as idiomatic as possible and have not looked at the original in a long time.

Note: You need a WAD file to try this. Get a shareware one if you don't own the game.

Screenshots

Build Instructions

Rust Doom should always build on the latest stable version of Rust (but is also tested on beta and nightly), which you can install using any of the methods described on the Rust website.

To build, run cargo in the project's root (where Cargo.toml is):

cargo build --release

Note that you'll need a WAD file (which contains the game's levels and art assets). If you own the game (or are willing to buy it for a few quid/bucks), you'll find the WAD in your game folder. If not, you can use the shareware ones floating around on the interwebs. Or, though I would not know of such things, you may be able to obtain the originals for free in less.... savoury parts of the internet.

Copy the WAD file to the repo root (where Cargo.toml is). Then, to run:

target/release/rs_doom --iwad your_wad_file.wad

Without any flags it will try to load the first level of 'doom1.wad'. You can specify which level to load, FOV and resolution preferences using the flags. Run with '-h' for a list of options.

Goals

(subject to change)

Modern OpenGL 3+ renderer. No immediate mode shenanigans: it's all VBO-s and shaders. Unlike some GL ports, the floors are actually rendered as convex polygons computed from the BSP. The downside of this (or upside depending on your perspective) is that some visual glitches (like slime trails) don't show up.
Correct 256 color palette. Uses the original palette and colormaps to replicate the original lighting effects (mostly you'll notice things get darker in visible steps and they also get greyer as they get darker). Doing 256 color palette lookups in a fragment shader is wonderfully anachronistic.
Free flying camera. Mouse & keyboard control for full 6 degrees of freedom.
100% safe code. No pesky unsafe blocks anywhere.

Todo

Comments

Impossible to find -lSDL2 for /usr/bin/ld
Hi,

I've got a compilation error with the SDL2 library - i use ElementaryOS 0.3.1 and i've already install libsdl2-dev.

I've got this error when i try to build your work:

note: /usr/bin/ld: cannot find -lSDL2 /usr/bin/ld: cannot find -lSDL2 collect2: error: ld returned 1 exit status error: aborting due to previous error Could not compile `rs_doom`.

Can anybody here explain to me what to do please?

I try to googling this thing but solutions doesn't work here... :-/

Thank you!
invalid compat
opened by k0pernicus 14
"Could not create GL context" error on startup for GL 3.0
Since commit 65dbb735249badebce7298ba97a8490d2bc20506 , when I try to run rs_doom, compiled with nightly rustc (1.6.0-nightly (8ca0acc25 2015-10-28)), I get this message:

$ target/debug/rs_doom rs_doom: graphics error: SDL: SDL error: Could not create GL context

I'm on Ubuntu 14.04 x86_64, running on this laptop with the following specs:

CPU: Intel Core i3-2328M GPU: Intel Sandybridge Mobile

the mesa driver supports Opengl 3.0 and 3.1(core profile), if it might help.
compat
opened by edward-san 13
Improved lighting model

Walls and flats now use the same lighting model code and appear much closer to the original Doom style.

Your shaders were using different code to calculate light levels and thus had different light level scales causing lighting effects on flats to be inconsistent with their surrounding walls in the same sector. The pre-clamped v_light * 2.0 / 31.0 scalar combined with the clamping for flats was causing more subtle lighting effects on the LSBs to be lost entirely, e.g. the glowing effect on the final teleport pad in doom1.wad e1m7. The scalar was reduced back to 1.0 / 31.0 as it should have been for both flats and walls, and clamping was removed in flats in favor of your superior wall-lighting code.

I also fixed flat texture lookup by inverting xz coords, e.g. see the final teleport pad's textures in doom1.wad e1m7. The goat skull texture appeared incorrectly without inverting the coords. This also fixes a few other floor/ceiling texture alignment issues.
enhancement

opened by JamesDunne 11

Error on ubuntu 14.04 with the Rust nightly

Hi Cristi, sorry to bother but I'm having trouble using rust-doom so i thought to give you a feedback.

To give you some context I'm using a linux box with Ubuntu 14.04 and this kernel:

    Linux druzbox 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

libsdl2 is installed:

$ dpkg -l | grep libsdl2-dev
ii    libsdl2-dev    2.0.2+dfsg1-3ubuntu1.1    amd64    Simple DirectMedia Layer development files

The version of rust and cargo (both installed with rustup script) is:

$ rustc --version
rustc 0.13.0-nightly (adb44f53d 2014-10-12 00:07:15 +0000)
$ cargo --version
cargo 0.0.1-pre-nightly (5c5255f 2014-10-10 15:05:22 +0000)

When i run cargo test i get this output:

$ cargo test
   Compiling khronos_api v0.0.1 (https://github.com/bjz/gl-rs#feed7be3)
   Compiling rust-xml v0.1.0 (https://github.com/netvl/rust-xml#f86f02b3)
   Compiling sdl2 v0.0.1-alpha.1 (https://github.com/cristicbz/rust-sdl2?ref=static_to_const#c8c36cb6)
   Compiling toml v0.1.0 (https://github.com/alexcrichton/toml-rs#8a3ba4c6)
   Compiling gl_generator v0.0.1 (https://github.com/bjz/gl-rs#feed7be3)
   Compiling gl v0.0.1 (https://github.com/bjz/gl-rs#feed7be3)
   Compiling rs-doom v0.0.7 (file:///home/druznek/workspace/rust/rust-doom)
<std macros>:8:12: 95:21 error: cannot apply unary operator `!` to type `&'static str`
<std macros>:8         if !$cond {
<std macros>:9             fail!($($arg),+)
<std macros>:10         }
<std macros>:11     );
<std macros>:12 )
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task 'rustc' failed at 'index out of bounds: the len is 12 but the index is 12', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libsyntax/lib.rs:1


Could not compile `rs-doom`.

If i compile with cargo build --release it goes without errors and produce the rs-doom binary:

$ cargo build --release
Compiling toml v0.1.0 (https://github.com/alexcrichton/toml-rs#8a3ba4c6)
Compiling rust-xml v0.1.0 (https://github.com/netvl/rust-xml#f86f02b3)
Compiling sdl2 v0.0.1-alpha.1 (https://github.com/cristicbz/rust-sdl2?ref=static_to_const#c8c36cb6)
Compiling khronos_api v0.0.1 (https://github.com/bjz/gl-rs#feed7be3)
Compiling gl_generator v0.0.1 (https://github.com/bjz/gl-rs#feed7be3)
Compiling gl v0.0.1 (https://github.com/bjz/gl-rs#feed7be3)
Compiling rs-doom v0.0.7 (file:///home/druznek/workspace/rust/rust-doom)

But when i launch it i get the following output:

$ ./target/release/rs-doom -i doom1.wad
task '<main>' failed at 'called `Result::unwrap()` on an `Err` value: Could not create GL context', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libcore/result.rs:808

Sorry but I'm still not that fluent with rust to help you understand the issue, but i hope i helped you narrow it down (if it's a bug and not a problem of mine, of course).

Have a nice day! :)

compat

opened by druzn3k 8

Arm GLES / OpenGL 1.x compatibility

Any chance of having GLES rendering? Or just to test if the app's working, software OpenGL 2.0 using Mesa?

On older x86 hardware it would be useful to have OpenGL 1.x compatibilty which, in addition, would instantly enable those gles arm devices that get accelerated OpenGL 1.x through the glshim wrapper.
enhancement compat

opened by MagaTailor 6
Err value: couldn't open file'

I'm getting this error now. I think it may have something to do with the WAD files, but I've made sure they are both a+rw accessible. I used both doom1 and doom2 WADs that have proper checksums.

doom1.wad: f0cefca49926d00903cf57551d901abe Validated to: http://doomwiki.org/wiki/DOOM1.WAD

Command: ./rs-doom --iwad doom1.wad OS: Jessie with Nvidia latest

Error: task '
' failed at 'called Result::unwrap() on an Err value: couldn't open file', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libcore/result.rs:808
invalid

opened by jadbox 6

GLSL version 300 not supported

Pulled your latest changes in master and am now getting shader compilation errors on OS X:

    task '<main>' failed at 'called `Result::unwrap()` on an `Err` value: Vertex shader compilation failed:
    ERROR: 0:1: '' :  version '300' is not supported
    ERROR: 0:1: '' : syntax error #version
    ERROR: 0:2: '' :  #version required and missing.
    ERROR: 0:4: '0' : syntax error syntax error
    ', /Users/jaymz/rust/src/libcore/result.rs:808

compat

opened by JamesDunne 6

cargo crate registry error: 'SDL' linked with two different versions.

The whole message is (rust stable 1.5):

native library `SDL2` is being linked to by more than one package, and can only be linked to by one package

  sdl2-sys v0.7.0
  sdl2-sys v0.6.2

or (rust nightly 1.7):

native library `SDL2` is being linked to by more than one version of the same package, but it can only be linked once; try updating or pinning your dependencies to ensure that this package only shows up once

  sdl2-sys v0.7.0
  sdl2-sys v0.6.2

This can be reproduced by removing .cargo and rerunning cargo build on clean git tree. Then, the registry is updated, the crates are downloaded and then the message appears.

opened by edward-san 5

Need to add "fake contrast"

Hi, I just checked out this project finally, and I'm impressed at how faithful it looks! But one thing I've noticed: in Doom, all walls that are perfectly "vertical" (constant x component) are effectively brightened by 16, and all walls that are horizontal (constant y component) are darkened by the same amount. This is especially obvious in a level like E2M2 (-iwad doom.wad -l 10) where the crate maze looks pretty blah without it.
enhancement

opened by linguica 5
Signed distance of Line2

Analyzing different sources (wiki and wolfram math docs) I get information that signed distance is calculated as n cross (point - origin) and that conflicts with code implemented here: https://github.com/cristicbz/rust-doom/blob/2efa6aebdfb2c625e24188150357872f01f403ef/math/src/line.rs#L42 The question is this right or should be written as: to.to_vec().perp_dot(self.displace) - self.origin.perp_dot(self.displace.to_vec())

opened by r4v3n6101 4
Cannot move (mouse on mac)

Console: executed in GitHub/rust-doom

target/release/rs_doom --iwad Doom1.WAD ERROR:wad::visitor: Unknown linedef special type: 48 <- this line multiple times.

opened by JohnMeyerhoff 4
SIGABRT when using Wayland

To reproduce, just use Wayland, build rust-doom, and run it. It works fine if I set WAYLAND_DISPLAY=''. I've ran cargo update and rebuilt, too, but it didn't change anything.

opened by orowith2os 0
Feature: "screenshot map" command
Not sure whether this is along the lines of where you want to take this project, but I've been wanting a proper tool for taking the kinds of level shots on this page:

http://ian-albert.com/games/doom_maps

(but for a program that's open source, actively maintained, more flexible, eventually works with vanilla PWADs etc)

Here's what it seems like such a command would entail:

use an ortho view projection instead of perspective

disable distance-diminished lighting (but still draw sector lighting)

zoom and position view to frame level extents + a margin

write screenshot to image at a resolution proportional to world scale (something like the maps linked above, ie larger maps result in larger images, up to a reasonable maximum) - not sure if this is easy to get to from a non-offline renderer like this one, though

Again, no idea if this is something you find interesting and/or want to do with this project, but I think lots of people in the Doom community would find this useful. Users could probably even rig it up into an auto-generated map generator for doomwiki + the idgames archive.

This project is really cool, keep up the good work!
enhancement
opened by JPLeBreton 1