Live data from Hacker News

Build your own old-school 3D shooter in a weekend

github.com

21–30 of 105 posts

Re: Build your own old-school 3D shooter in a weekend

#21
post #10
post #4

The readme mentions it but I think it's worth pointing out that this is a very particular (and quite dated) method for sort-of-3D rendering. It's the same type of engine used in the original Wolfenstein. It's definitely a lot of fun to implement (and I recommend trying if you've never done it before) but it's very different and much more limited than what we expect from a 3D engine nowadays.

> the original Wolfenstein. Well, the original Wolfenstein 3D, the third game in the series. https://en.wikipedia.org/wiki/Castle_Wolfenstein https://en.wikipedia.org/wiki/Beyond_Castle_Wolfenstein

Brilliant! Much of my early teens was "wasted" playing Castle Wolfenstein on a green screen Apple II. Great memories.

Re: Build your own old-school 3D shooter in a weekend

#22
post #19
post #11

Unity give away a complete 6DOF FPS with multiplayer. All source and assets included https://unity.com/fps-sample

Sometimes you want to make chili from scratch instead of going out to eat Peking duck.

Yeah, but the recipe isn't the same as when the conquistadores discovered America.

Re: Build your own old-school 3D shooter in a weekend

#24
post #12
post #10

Earlier quoted context omitted.

> the original Wolfenstein. Well, the original Wolfenstein 3D, the third game in the series. https://en.wikipedia.org/wiki/Castle_Wolfenstein https://en.wikipedia.org/wiki/Beyond_Castle_Wolfenstein

Uh, I had never heard about these games before. I always thought Id created the franchise. Thank you for that bit of videogame history.

I read "Id" as " i'd " and thought this was the the most bizarre sarcastic comment. Time for more coffee

Re: Build your own old-school 3D shooter in a weekend

#25

I think leaving the "old-school" out of the title doesn't do this justice. My first thought was, with modern engines, or even raw OpenGL that isn't that hard... I did it in a weekend for my "Advanced Computer Graphics" elective in college using OpenGL and that was 2008. But this is kind of cool... it's more of a tiny ray tracer and... well to borrow the title... old-school arcade game.

[deleted]

Re: Build your own old-school 3D shooter in a weekend

#28

I'm way out of practice with C++. (It's been since like 2006.) Framebuffer clear function appears to allocate a new vector. Does std::vector automatically handle the memory releases? This is called every frame, so I wanted to check here to see if I'm crazy or not.

> Does std::vector automatically handle the memory releases?

Yes. What is going on here is that "img" is being assigned. The "old vector" will have its destructor called, which will call the destructor of all of its elements by default.

-------

I assume you're talking about this code: https://github.com/ssloy/tinyraycaster/blob/master/framebuff...

    void FrameBuffer::clear(const uint32_t color) {
        img = std::vector(w*h, color);
    }
Which seems inefficient to me. But it is correct code, even if it is inefficient. There's no memory leak here, but the code probably would be way more efficient if it were instead a simple memset.

    memset(&img[0], color, w*h*sizeof(uint32_t));
This memset is likely easier to understand, since it doesn't rely upon destructors / constructors / assignment C++ Magic. And its more efficient to boot. Vectors are guaranteed to be contiguous in memory, which is why it is compatible with memset.

EDIT: Hmmm... the img is never initialized. You'd also have to do "img = std::vector(w*h, color);" somewhere.

----------

The rectangle is also inefficient.

    for (size_t i=0; i
If i and j were reversed, the draw rectangle function would be more efficient. As it is, "j" iterates in the wrong direction with regards to cache lines...

    // This would be faster!
    for (size_t j=0; j
Overall though, efficiency isn't a goal at all. Its designend to be a quickie project to get things done as soon as possible. Thinking about all of these details slows down development, so there's something to be said about "just getting it done"

Re: Build your own old-school 3D shooter in a weekend

#29

I'm way out of practice with C++. (It's been since like 2006.) Framebuffer clear function appears to allocate a new vector. Does std::vector automatically handle the memory releases? This is called every frame, so I wanted to check here to see if I'm crazy or not.

Yes std::vector owns the underlying continuous array of memory and will free it on the destructor call of vector.

" img = std::vector(w*h, color); "

What is more interesting if you have been away from c++ is that the assignment is not a copy! The vector in this case is a temporary and it dies on assignment. Thus img takes the guts of this new vector.

Re: Build your own old-school 3D shooter in a weekend

#30

I'm way out of practice with C++. (It's been since like 2006.) Framebuffer clear function appears to allocate a new vector. Does std::vector automatically handle the memory releases? This is called every frame, so I wanted to check here to see if I'm crazy or not.

Yes std::vector owns the underlying continuous array of memory and will free it on the destructor call of vector. " img = std::vector (w*h, color); " What is more interesting if you have been away from c++ is that the assignment is not a copy! The vector in this case is a temporary and it dies on assignment. Thus img takes the guts of this new vector.

Movement semantics actually existed for vector assignment since the original C++98 STL specification.

Movement semantics didn't exist in the language per se, but they were supported back then by std::swap and std::auto_ptr. Today, it is far easier to represent movement semantics with RValues, std::move, and std::unique_ptr.

But yeah, std::vector's assignment operator was originally at least std::swap based and therefore efficient.

Post reply on HN