cristicbz's comments

Thanks! Uh, I'm not good at writing/saying things that are not checked by a compiler. But I'll try to write a blogpost about it.

> AST based, hygenic macros, instead.

Well and generics & traits. 99% of the places where C++ programmers use templates, they would use generics in Rust. `template std::vector<T>` <-> `Vec<T>` etc.

It's only the niche metaprogramming ability of C++'s templates that would be replaced with macros.

You can still trigger plenty of undefined behaviour in C++11 with no raw pointers. Just one example--iterator invalidation:

    auto v = std::vector<int> {1, 2, 3}
    for (auto x : v) {
        if (x > 0) {
            v.push_back(-x);
        }
    }

The above may segfault, do what you expect it to, run forever etc. Unchecked indexing, branching on uninitialized data etc.

Rust frees you from _all_ of these things and offers a bunch of further advantages, most notably: data race freedom. You can actually share data between threads and keep your sanity.

I mean, the camera handling code is just the tip of the iceberg.

I am hoping it will eventually cover game mechanics, see "Goals (subject to change)". Pull requests welcome!

> How long have you worked on only this project?

It's hard to quantify how much time _this_ project took, since when I started a year ago I knew nothing about Doom or Rust. If I started writing it now from scratch, I could probably hammer it out in a working week. A better programmer could probably do it in a weekend. It's neither very big nor very hard.

But that's not how programming works, is it? In fairness, you'd need to count some of the time I spent working on a lot of other random Rust side projects and reading blog posts over the last year, while only spending a couple of hours ever other week or so on rust-doom.

> Certainly wrestled with the ownership system for a while

I think my background in modern C++ helped me a lot with this, since the "one owner per thing, move semantics" model is how you're supposed to write C++ too.

That said, figuring out the cleanest design is not easy and I'm still wrestling with it today. The code was an absolute mess last year and now it's better, but still needs plenty of work: just yesterday I decoupled WAD parsing from the rest of the code properly (https://github.com/cristicbz/rust-doom/pull/53).

I'm still learning a lot a year after dedicating all my free-time programming to Rust.

I'm the author, no poo-poo-ing taken. You're completely right. The rendering code is shamelessly unoptimized indeed: doing frustum culling naively actually slows down the code because of the extra draw calls. I could probably get a boost in frame rate--by for instance memcpy-ing chunks into a dynamic buffer and keeping the single draw calls---although it already runs at 300 FPS on the integrated intel card of my laptop. So I'd rather add more features, testing and documentation than worry about perf just yet.

It's the same project, I just been keeping it up to date and removed all the unsafe code. It never _needed_ unsafe code, but it was my first Rust project and I didn't know what the hell I was doing---it's now much cleaner, safer and faster than the incarnation you saw last year :)

Code which is meant to be piped into bash is generally written as:

    #!env bash
    f () {
      ...code
      ...code
      ...code
    }
    f

Hence a partial stream will do nothing (syntax error, missing brace to be precise).

I agree with many of your points actually. But I wrote the Doom renderer in rust at https://github.com/cristicbz/rust-doom and it's not a port, it's written from scratch based on specs, so maybe your argument is correct in general, but it really doesn't apply to it: it has very little unsafe code, some which really shouldn't be:

1. A tiny function which loads textures. I was fooling around with optimising load speeds. The actual speedup I got was insignificant and I really should revert it to safe code.

2. A silly getter on the transformation matrix---another misguided attempt at a speedup; no reason to use UnsafeCell instead of RefCell. Should revert.

3. Casting buffers from files as structs. This is safe for any buffer the same size as a Copy struct, std offers no such function, so I do. Unsafety is isolated in two small functions (one for T and one for Vec<T>), all its callers are safe.

4. Interacting with OpenGL. Fair enough, this happens all over the place, but it's not actually unsafe. The OpenGL bindings library didn't take much care to only mark unsafe operations as such, and all GL calls are marekd unsafe---which is why I wrap them up in a macro which peforms the operation in an unsafe block and panics on any error. I should port my code to glium and then this would go away as well.

*better formatting

Doom I/II suggests the whole game is implemented, which isn't. But I am working on it!

You're welcome! :D