Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Graphics Like it's 1993

staniks.github.io

Post reply on HN
Print view View original

141–150 of 169 posts

Re: Making Graphics Like it's 1993

#141

Post by NBJack »

Grumbledour wrote: post #9
rob74 wrote: post #2

This is taking a lot of inspiration from Doom, but the actual raycasting engine is more like Doom's predecessors, the most well-known of which is probably Wolfenstein 3D: perpendicular walls, constant floor and ceiling height. Wolf3D didn't have textured floors and ceilings because of performance reasons, but several other similar games had them. Doom and IIRC Duke Nukem as well used a BSP engine which was much more…

Later on, in Shadow Warrior, you could even do that, i think they used portals to implement it and i remeber it was a pain to set up in the editor.

Don't forget the optional voxel models! They did some really cool stuff with Build. I loved some of the creative uses of things like controllable vehicles (sometimes with guns!).

Re: Making Graphics Like it's 1993

#142

Post by Panzerschrek »

> Catlantean 3D is a traditional raycaster. The map consists of tiles which are all identical in size;

It's sad. That's why I never finished playing Wolfenstein 3D - it looks too boring. In the other hand I enjoy playing Doom, mods for it and games using its engine.

I hope the author can still add some improvements to allow such boring look typical for raycaster engines.

Re: Making Graphics Like it's 1993

#143

Post by Panzerschrek »

> We then choose the number of shade levels (32 in my case) meaning each color needs 31 darker variants

I suggest to use not only darker variants, but also brighter ones - for bright map areas and maybe for some lighting effects like flashlight.

Re: Making Graphics Like it's 1993

#144

Post by Panzerschrek »

> The generation pipeline takes several inputs: > a heightmap that defines the surface relief > this is actually just used to generate the normal map, which is then used to bake in simple lighting and shadows

I don't think someone used this approach in 1993. Textures were drawn by hand. But I think it's still fine to use such modern way of generating textures, since it may produce better-looking result.

Re: Making Graphics Like it's 1993

#145

Post by kmill »

canyp wrote: post #137
kmill wrote: post #125

Earlier quoted context omitted.

I'd be surprised if the compiler didn't make that optimisation on its own.

Possibly, but always check the assembly. The even faster version, opts aside, would be to initialize the pointer at y*screenRect.w and ++ at every loop to avoid the addressing arithmetic.

Certainly check the assembly, but loop invariant code motion and strength reduction are basic optimizations. C compilers tend to be good at optimizing indexing patterns even at -O1.

Take a look, GCC and Clang go further than these suggestions by adding screenRect.w to the pointer each iteration to avoid the multiplication: https://godbolt.org/z/YfroqK7T6

Writing anything but pixels[y*screenRect.w + x] in an attempt to be faster, without checking the assembly first, is obfuscation.

(For what it's worth, you can beat the compiler by using *pixels++. I didn't profile the code to check it actually was faster in practice however.)

Re: Making Graphics Like it's 1993

#146

Post by ant6n »

I personally am not a big fan of the banding effect due to small number of light levels. One way to reduce that would be to introduce a 2x2 dithering matrix grid across the whole screen that introduces small “luxel” deltas like 0.5, -0,5; 0.5, -0.5. Some pixels will be brighter, some darker, reducing the banding. Could also try different matrices.

Re: Making Graphics Like it's 1993

#147

Post by Agentlien »

This is a cool project and I really like the author's technical and aesthetic choices of how to limit themselves.

But what really stood out to me is this line.

> a linear frame buffer where each pixel was represented by a single byte indexing into a palette of 256 colors.

Of course this is nothing new, but it just really struck me because I've been working on a blog post about texture representation on modern consoles and it is crazy how complex it has gotten: texture tiles, block compression, non-linear texel ordering (e.g. Morton order), ...

Re: Making Graphics Like it's 1993

#148

Post by ant6n »

bananaboy wrote: post #140
ant6n wrote: post #117

Earlier quoted context omitted.

The funny thing is that looking backwards, I would never use a grid of squares for a raycaster like wolfenstein3d did. If I were to do a raycaster today, I would use convex sectors with portals, basically like duke nukem, but constant wall heights. You can do drawing very simply by just doing a linear pass across the sector, recursively stepping into other sectors. Then you can at least do arbitrary level geometries.

A grid of squares makes sense for the target hardware at the time though (286 or better CPU)

It really doesn't. I would argue that convex sectors with portals could be quicker than casting rays across a grid for every pixel column, except for some degenerate cases. This is because for any pixel column in-between the boundaries of wall segments, there's virtually no work to be done (O(1)), compared to the work of casting a ray along the grid O(n).

Btw, 286 played wolfenstein rather poorly. The 386 is rather more appropriate.

Wolfenstein was built in a couple of months by a then 21-year-old Carmack. He didn't focus on optimizing levels until Doom.

Re: Making Graphics Like it's 1993

#149

Post by torginus »

tadfisher wrote: post #109
torginus wrote: post #100

Earlier quoted context omitted.

That would only be true if a row (by which I mean a scanline) would be equidistant in view-space depth across its whole length, which is not quite true. While a column of pixels for a wall is (as long as you dont tilt the camera).

The code exists! https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.... And it looks to me like we are mapping each row with a constant y, calculating the "distance" (thus scale factor) only once using just the vertical slope for the row.

Yeah sorry, you are right - I got it mixed up.

Re: Making Graphics Like it's 1993

#150

Post by torginus »

badsectoracula wrote: post #15
rob74 wrote: post #2

This is taking a lot of inspiration from Doom, but the actual raycasting engine is more like Doom's predecessors, the most well-known of which is probably Wolfenstein 3D: perpendicular walls, constant floor and ceiling height. Wolf3D didn't have textured floors and ceilings because of performance reasons, but several other similar games had them. Doom and IIRC Duke Nukem as well used a BSP engine which was much more…

> Duke Nukem as well used a BSP engine The Build engine didn't use BSP, it treated connections between sectors as portals and rasterized the walls as (90 degree rotated) trapezoids while performing clipping against those portals. This allowed it to have dynamic wall geometry (e.g. moving trains, rotating light fixtures, etc) as well as "room-over-room" setups as long as you couldn't see both rooms at the same time (i…

Though it must be said that Duke's flexibility came with a tradeoff - while BSPs will find a leaf node in log(n) time, no such guarantee exists for Duke and its up to the mappers to optimize the maps so that the renderer doesn't need to traverse a large amount of sectors.
Post reply on HN