You could make some weird impossible geometries by just superimposing sections. Two sections could occupy the exact same coordinates, but movement and rendering were done across edges shared by sections and did not care about if there was some other section in the same space. As long as there was never a way to see those sections at the same time.

I miss the customizability of that game. Early bungie works were up there with early blizzard or early valve. They sold a tool for fun instead of casting a bait for profit.

I know nothing about this stuff, but when I saw in-game I was really impressed. You can even break the screens into shards, and the little pieces still maintain the effect when they’re lying on the floor or flying through the air.

Can you provide a source? As I understand it DF is based on the (pre release?) Tie Fighter engine, and DF began production before Doom released. That's why for example DF has some non-textured 3D models like the turrets and mouse droids. I follow The Force Engine (reverse engineered fan port) and Dev Game Club (hosts worked at LA).

Supposedly DF devs did see Doom (perhaps even a pre release version), but already had their own tech working by that point.

> Apparently, the final release of DOOM cut a lot of engine features to gain speed.

Doubt. There's a lot of interviews with the ID guys, and I don't recall anyone saying they cut significant technical features. They made Doom in only 13 months, minus almost a month to port Wolf3D to SNES. Maybe Carmack -- or the released alphas and betas -- can clarify? Or perhaps you are confusing some of the Doom porting efforts, which did cut down levels and sometimes features significantly.

They were referring to Prey (2006).

Giant open space. A baron, way off barely visible, throws a firebolt. Takes like 30sec to get to me.

What doom mapmaking needs is higher level tools. Like a tunnel kit. Just plug together pipes and fittings. Or crank out mazes generatively.

There's a lot of "smearing" as a result. It's not just you, it's how newer rendering techniques in the Unreal Engine end up being perceived by most people.

You'll notice that quake textures are very similar to PS1 textures in that they are pixelated and use a limited number of colors, whereas N64 textures have more of a smooth gradient.

Likely also there are differences in the lighting systems as well. This is why I think people compare Quake II or even Quake III Arena to UE1. The OG quake really was a hack just to be the first that did 6 degrees of freedom textured 3D graphics on a PC, which I think they were the first for those exact constraints. My history is a little fuzzy, SEGA certainly had them beat by multiple years on arcade boards but those were all custom, and other games that had 6 degrees of freedom were not textured. It was a busy time !

If you’re thinking more about the smoothness & framerate of the game, then that’s entirely subjective. UE1 did not prevent choppiness or make things fast, and neither does UE5. That’s entirely at the discretion of the game developer. If you use fewer polygons and use simple shaders, the game will be fast and smooth. If you use more than the hardware & engine can handle, then your game will be choppy.

There are a lot of advancements in real-time lighting today, which means that the look doesn’t necessarily change, but is computed at run time. Most of the nice lighting in UE1 was baked into textures or vertex data, and could not change during the game. Today with shaders and global illumination algorithms running in real-time, the lighting can change in response to a moving sun, moving objects & characters, changing materials, etc.