Live data from Hacker News

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

github.com

61–70 of 105 posts

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

#63

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…

>As it is, "j" iterates in the wrong direction with regards to cache lines

I always wondered 'what if' someone released Doom like FPS game in 1993 that required you to flip monitor on its side ;-). Both Ray-casting and Mode-X work best in vertical plane, while video memory access is only efficient when done linearly. Some quick back of a napkin calculations lead me to believe you could deliver 400x320 at the speed of Dooms 320x200.

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

#64
post #16

Earlier quoted context omitted.

> it's more of a tiny ray tracer It's a ray caster, where the rays are sent out from the camera to intersect the map. With ray tracers, the rays are sent out from the light source, IIRC. Your point on OpenGL is valid, but that just removes all the learning from it. OpenGL does so much of the grunt work for you. This kind of old-school game engine is a great learning experience.

> With ray tracers, the rays are sent out from the light source, IIRC. Are there any implementations which send rays from the light source(aka. forward ray tracing)? This is astoundingly inefficient, as most rays will not intersect the camera. I've never seen one, other than in brief academic discussions. What you can use forward ray tracing for is to compute shadows.

I had considered making a ray tracer that worked that way, but with the slight difference that rays didn't have to hit the camera, but would just have to hit a point within line of sight of the camera. Obviously there would be massive gaps between pixels, but I would fill it in with a Voronoi diagram [0], or perhaps shaded with Delaunay Triangulation [1]. This renderer would be nothing more than a toy or proof-of-concept, and not intended for real usage.

The classic FOSS ray tracer, POV-Ray, can actually do this. You can define a light and define an object, and it will shoot rays from the light to the object and trace each ray through refraction and reflection. With this, you can simulate the way ripples in a pool concentrate light on the floor of the pool [2] or bending and refracting [3], without manually calculating it and adding extra light sources.

[0] https://en.wikipedia.org/wiki/Voronoi_diagram

[1] https://en.wikipedia.org/wiki/Delaunay_triangulation

[2] http://www.antoniosiber.org/bruno_pauns_caustic_en.html

[3] http://www.povray.org/documentation/view/3.6.2/424/

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

#67

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.

Title was edited later to include "old school" and my original comment now makes no sense.

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

#68
post #16

Earlier quoted context omitted.

> it's more of a tiny ray tracer It's a ray caster, where the rays are sent out from the camera to intersect the map. With ray tracers, the rays are sent out from the light source, IIRC. Your point on OpenGL is valid, but that just removes all the learning from it. OpenGL does so much of the grunt work for you. This kind of old-school game engine is a great learning experience.

> With ray tracers, the rays are sent out from the light source, IIRC. Are there any implementations which send rays from the light source(aka. forward ray tracing)? This is astoundingly inefficient, as most rays will not intersect the camera. I've never seen one, other than in brief academic discussions. What you can use forward ray tracing for is to compute shadows.

There are two-pass approaches that do this, such as photon mapping. In the first stage, light is emitted from light sources and allowed to to scatter throughout the scene, and each "hit" of a photon on a medium is stored in a large data structure. Then in the second pass rays are traced out from the camera, and on each medium the ray intersects, nearby "hits" are used to estimate the light coming from that spot. This produces effects like caustics efficiently.

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

#69
post #58

Earlier quoted context omitted.

This kind of engine is great as a starting place for programmers, I think, but Unity is probably what you want for the kind of thing you're doing. There's also Godot if you want to stay in Open Source land, but it probably isn't as good and certainly doesn't have the same level of coverage in tutorials and documentation. Or there's the time-tested path to gamedev: modding existing games.

i wanted to like unity but not having low level access to the rendering and physics internals is intolerable.

1. What aspect of the rendering did you feel you didn't have control over with your own vertex, fragment, and compute shaders?

2. You can hook into most if not all of the physics internals by overriding Update() and FixedUpdate() functions.

Unity is definitely less flexible and powerful than rolling an AAA 3D engine and editor.. But that takes years, and 95% of the time there's a way to solve the problem in Unity.

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

#70
post #69
post #58

Earlier quoted context omitted.

i wanted to like unity but not having low level access to the rendering and physics internals is intolerable.

1. What aspect of the rendering did you feel you didn't have control over with your own vertex, fragment, and compute shaders? 2. You can hook into most if not all of the physics internals by overriding Update() and FixedUpdate() functions. Unity is definitely less flexible and powerful than rolling an AAA 3D engine and editor.. But that takes years, and 95% of the time there's a way to solve the problem in Unity.

Yes, but given what we're talking about, a basic old-school first person shooter, you could do it in far fewer than "years" with C++, SDL2 and OpenGL.
Post reply on HN