That's one of the things I loved most about games in the 90s. Everything is a pile of hacks and tricks.
I remember doing "reverse engineering" on a bunch of those as a kid and I can definitely attribute my passion for software to those experiences.
I was actually feeling a bit disconnected from my career at the moment and reading this thread awakened some of the excitement that was sleeping inside me! The 90's are a huge source of nostalgia for me.
> That's one of the things I loved most about games in the 90s. Everything is a pile of hacks and tricks.
Command and Conquer: Red Alert had a rules.ini file you could tweak pretty much anything on. You could give an infantry unit rapid-firing cruiser artillery cannons that'd lay waste to anything within a couple screens in seconds. Much fun was had.
One of Red Alert's hacks was making dogs (the unit) distinct from dogs (the projectile). That is, a dog was a dog until it began its attack. At that point it transitioned into a dog projectile, which looked like a leaping dog but wasn't targetable. Then when it collided with the enemy (infantry only), the enemy was insta-killed and the dog transitioned back into an interactible unit.
What this meant is that you could use rules.ini to make an anti-infantry submarine that launched dogs, if you so desired. Or a dog artillery. Or a dog man that used his dog gun to shoot dogs at men.
I took advantage of that to defeat a hacker in an online game once.
the hacker had changed his infantry so they were very cheap, and fired different weapons. he planned to win by building a barracks and spamming out his super soldiers. but there's one thing he hadn't counted on: dogs.
not only did they have the dog projectile behaviour, but infantry also had a behaviour where they had a few seconds when emerging from a barracks where they had a running animation, we're targets, but couldn't fire.
by spamming dogs, and sitting one directly outside each barracks he built, I effectively plugged each inflow of super soldier, as the dog would turn into a projectile and instantly kill all emerging infantry.
good times. and that was a particularly satisfying rage quit...
I would have thought the multiplayer code would
assume deterministic consistent calculations on all clients, and only share human inputs with a cycle delay to mask the network delays. If that were the case, though, then things would get weird very quickly, and likely end with a failed assertion somewhere and the game erroring out.
Perhaps instead all calculations are performed on one client, and the full game state is transfered to the rest, perhaps with some sort of delta encoding? That seems like a fairly high bandwidth approach for the 90s, but I suppose it depends on how clever they were with the state representations.
Explicitly sharing one client's rules.ini would of course be a reasonable hypothesis. Maybe there was a good reason for that during development, perhaps so that gameplay designers could quickly iterate without having to copy files back and forth with coworkers?
As I remember, for direct-dial-up games, both players had to have an identical rules.ini file or the game would instantly announce a desync error when the second player joined the game.
sorry, was what, 20 years ago now? can't remember the details (or how the multiplayer aspect/engine worked back in the day) other than the
story. I do remember I probably wasn't hosting, but I also didn't have insight into what the hacker was doing except what could be observed in-game :(
You could do a similar style of hacking in Dark Forces 2, which had "cog files" that were controlled client side and let you change the projectile of any weapon. At first it was fun to replace your pistol bullets with rockets, or have your rocket launcher shoot light sabers.
Eventually we realized you could actually make structures like bridges and stairs shoot out of your weapon, so it created this minecraft/gary's mod meta game of building platforms and structures out of your weapons, a decade before those came out. Fun times and definitely helped me on my career towards software.
This was my main gateway drug into programming. I would love disclose some of the best hacks that I came up with someday! This game was one of the best FPS games ever.
Doom was configurable like that with a tool called Dehacked. I remember mod packs for the tool, doing things like "mine layer", which set the rocket speed to 0 and made it cloaked, so that you could lay a minefield and then make the monsters walk into it. Or make the rocket launcher shoot lost souls, make chaingunners fly and many many more.
Wow I’d forgotten all about hacking rules.ini! That and hacking around with QuakeC and Quake level editors are fond memories of the earlier days of gaming :)
One of the things I miss about those days is that the graphics and physics was done in software. That meant that the features weren't determined by industry standard APIs and what sort of hardware accelerators your customer had, they were just something you make up as you go along. Resolution and/or framerate were usually abysmal, but on the other hand you might try out some new game and it would do something weird and surprising that you didn't even know was possible.
There's something satisfying about knowing that someone could just start with a blank editor and create a whole world from first principles, and that's how a lot of games were made.
I still remember 1999's Outcast with its software-rendered voxel engine, and level of detail absolutely outclassing every other game of that era:
https://www.youtube.com/watch?v=6QgVGBqsJMA
I've been working on a game and I've realized it's still all just a bunch of tricks. I think any art where you're trying to recreate/honor something in the real world in some way is all tricks and techniques. Everything from brushstrokes on a painting to plots in novels to special effects in movies and acting in movies is all just a bunch of tricks to make something look real. The better the trick, the less suspension of disbelief is required.
There is a possibility that software engineers 50 years from now will continue to appreciate "shrinkwrapped" products from the late 20th century. There are less hacks and tricks these days because codebases are perpetually changing.
If a company releases a tomorrow, and one week later a player discovers an exploit, it will likely get patched, repaired, and redeployed. So which version is "gold": the day 1 sale, or patch 1.01a? Obviously, it's a classic thought experiment, but games are a form of art where such revisionism is so prevalent.
I agree. But it does raise an interesting philosophical question: At what level of advancement does a hack stop being a hack.
Like most would agree that Ray-Tracing is the "real deal" relative to shadow mapping, but with how far shadow mapping has come can it really be considered a "hack" still?
> Like most would agree that Ray-Tracing is the "real deal" relative to shadow mapping, but with how far shadow mapping has come can it really be considered a "hack" still?
Even ray tracing isn't the real deal and isn't trying to closely simulate reality. You need to use hacks in ray tracing for soft vs sharp shadows, for light patterns on glass objects like wine glasses (caustics), to get illuminated surfaces to spread their colour to other objects (colour bleeding) and more.
Phonton mapping gets closer but is even more expensive:
Phonton mapping is trying to model the path of all photons being emitted from light sources back to the camera vs ray tracing that works backwards by tracing rays out of the camera back to the light sources i.e. ray tracing is an optimisation.
You seem to think that ray tracing as a very limited thing. I guess it stems from the fact that the nomenclature has become a bit murky in recent years. Ray tracing often is used to refer to the initial algorithm developed by Whitted. This has pretty much all these limitations you mention, but it is an obsolete method. What usually gets mixed in with ray tracing in marketing and non-expert discussions is also path tracing and its various variations. These methods are capable of solving the rendering equation exactly for a huge range of scenarios. Unfortunately, some variants deal with certain situations better than with others and there is no overall best algorithm. But you can most certainly trace absolutely perfect soft shadows or complex caustics with these methods. Color spills are a walk in the park even for simple unidirectional path tracing. The main limiting factor right now is that these are all Monte Carlo methods and need to draw high numbers of samples for each pixel to converge. This is why fast and accurate denoisers are such a huge deal at the moment. They are another hack, a last one that ideally fades away as the number of rays per second increases. Beyond that, it "just" comes down to modelling surfaces and materials accurately enough to get a photorealistic image.
As you mention photon mapping: it has pretty severe limitations, notably around the handling of specular paths and the biased artifacts created by the filter kernel (loght leaks, certain SDS-type paths aren't covered). There are some improvements like (A)PPM which converge to unbiased solutions with infinite runtime. At that point, path tracing based methods become more attractive w.r.t. runtime, memory requirements and implementation complexity.
> You seem to think that ray tracing as a very limited thing.
My point was mainly that ray tracing is still a hack like polygon based rasterization is, that's a combination of clever tricks to get something to look good enough with modest resources.
I'd advise you to be more precise in your wording. The terminology is a bit tricky. Path tracing (which I assume you're actually referring to) as a an algorithm isn't a hack at all. It's a direct Monte Carlo solution to the rendering equation which has a pretty straight, albeit long, derivation from Maxwell's equations. Ray tracing hardware (that is, hardware accelerated ray-geometry intersection computation) is still quite constrained computationally. That's why we see little actual path tracing in real time renderers at this time and more of the slightly more correct rasterization based hacks that include ray intersection queries instead of screen space/cubemap based guestimates. Calling them ray tracing is technically somewhat misleading in my opinion.
You got that backwards, photon mapping is a hack in the same sense as shadow mapping while ray trasing is the real deal (although implementations will likely resort to hacks for perfromance reasons). Soft shadows are simply a matter of making light sources have a non-zero volume and while tracing rays from the camera instead of the lights is an optimization, it is a valid one that (given infinite rays) produces the correct result and is not a hack.
Here's where it gets tricky. I do a lot of modeling and simulation work that is often incorporated in interactive 3D environments and the conversation I have over and over where people fail to realize is that you're always taking shortcuts to simulate some aspect of reality.
The point of games is to get as close to reality that people suspend disbelief and can immerse themselves into the virtual reality you've created. Sometimes enough realism and immersion can be had at cheaper computational costs so these hacks (gross simplifications) are the way to go. Sometimes though, you realize if you can better model aspects of reality more accurately, you can get even better immersion a d suspension of disbelief.
In the world where more sophisticated computational models are utilized in these environments because the results are important, used beyond suspension of disbelief and actually need to map reality because the simulation is trying to accurately represent some aspect of reality for a real world decision to be made, you still have to take clever computational shortcuts. As far as we know that will always be true unless you build a simulation environment that can fully represent our reality which might never be possible from an engineering or even scientific standpoint.
So the discussion I often have is: what deviations from reality are we willing to tuck into our models and simulations? We already can't do all of existing science and we can't do what's beyond existing science so what tradeoffs can we accept in the subset of science for our simulation.
Even raytracing doesn't go far enough because it takes a lot of shortcuts with reality. Pretty much none of these engines take into account relativistic distortions of light (some work has been done) and they frankly don't need to for almost every application outside of visualizing gravitational lensing and black holes accurately. In sure some bright physicist reading this is aware of even more faults in light and photon models and simulation approaches I'm completely unaware of. The onion peels quite far. The most obvious missing aspect for all environments is that we always simplify the actual geometry of the space because we have to.
Well, there is a very obvious limit to the fidelity of your simulation if presence is your goal: human perception. You don't need to crank up any details beyond what you can possibly perceive when using the simulation. Gravitational space distortions are the least worrisome effects in that regard. Light diffraction and polarization play a much larger role in our environment, although not often and if it happens, the untrained eye tends not to notice. I am talking about things like birefringent materials (quartz crystals) and diffraction effects like light reflected off of a CD or shining through a thin piece of cloth.
You can repeat the same process with each kind of sensory input a human can perceive and get to pretty hard limits on the requirements to get "perfect" realism. Human perception hasn't been researched in enough detail yet to give accurate bounds in all cases, but this is actively being worked on. The known bounds are mostly really conservative ones.
I wonder if there's a problem where, in a realistic enough simulation, people could find or build objects that should be equivalent to instruments like telescopes and microscopes, and then expect them to work properly! (Or more generally, instruments that enhance their senses, like an ear trumpet or parabolic microphone.)
Missing features in most game engines include spectral rendering (supported in some programs) and diffraction effects/Fourier optics (I think only really supported in radar design programs, not visual renderers).
This starts drifting way off topic, but hacks are typically characterized by being "clever". Which is hard to define, but is usually surprising in some way.
I think it stops being a hack when the surprise is gone - when you've explored the mechanism, understand the tradeoffs, where it does make sense and doesn't, etc.
I'd say a hack is a technique with caveats that let's you work around a limitation. Ray tracing is still too computationally expensive so the current raster pipeline is all a hack to work around that fact. It's also an incredibly well established and close to ground truth hack but there are lots of caveats where things go astray. Off the top of my head transparency is still largely problematic.
I think when we talk about something being a hack, we have a context in mind and a goal in mind, and the "hack" is just the way we achieved this goal that wasn't immediately obvious within this context. Of course, once this non-obvious solution becomes well-known, it's incorporated into the context and thus is no longer thought of as a "hack."
It still is. Everything is. If an individual or company is working at a level that feels comfortable then what they're doing is easy now and anyone can do it. Everyone has to work at the level where it all feels like a hack because if you don't, someone else will.
Ah, I remember decompiling Quake mods, and learning about how the AI worked, A* search etc. At that time I was still on dialup, and there was a fraction of what's available now on the Internet available - it was really useful for learning, and game mods was a big part of keeping me interested in computing.
oh I think it was far earlier, I remember disk doctor days and editors letting you change values if not finding hidden commands to give you more power.
Heck even yanking a floppy out to avoid a death was not uncommon with some games.
> it turns out those are more explosive-barrel sprites, just squished down real thin. It turns out the Build engine was designed so that if you make sprites super thin, they just don't render.
A small correction. If I remember correctly, this was a special property of that specific sprite - possibly hard coded in the engine, not sure.
But only those specific gas bottles were rendered invisible if you reduced their width. Most likely specifically to make it possible to do effects like the exploding fan.
Other sprites could be thin and render just fine - you can see that with palm stalks, traffic sign poles and things like that. Those are often just very elongated sprites.
I've been in a few British houses where the bathrooms had carpets. We even rented one as students.
I can assure you it was the grossest thing ever, and clearly an idea of someone who doesn't pee while standing. But apparently in 80/90s Britain it was still considered "cozy"
In college, I rented a studio apartment in Utah that had 70's shag carpet in the entire bathroom! My first week there I hadn't gotten a bath map and it was super weird stepping out of the shower onto shag carpet.
I have fond memories of torturing this level editor. I made a spiral staircase between two levels, and a building with a rooftop swimming pool with glass walls that let you see through to the top floor. I have less fond memory that the editor would tend to crash as soon as you got a little too cute with the overlapping rooms.
Really cool, I also remember poking around in the internals of Duke Nukem 3D and making levels a lot.
One cool thing about die Build engine is portals, you can build two different rooms and identify a wall in one with another wall in the other and "glue" the rooms together, IIRC. I think that is what is behind most of the "teleportation". I always thought that the mirror was just a wall portaled to itself, I wonder why the "physical" mirror space is necessary?
I'm fairly sure portals in that case only refers to how the Build engine determined potentially visible areas. As far as I know there was no mechanism to seamlessly connect far-away parts of a map in that way. If there was, I'd be pissed, because I never used that to built my own maps and it would allow neat non-euclidean geometry (like in Antichamber) :-)
Yeah, you are right. I think the engine I recall was the successor of Genesis3D, some ActiveX-thing from WildTangent. Whole different beast. I remember making a Stargate using that feature :-D. Must have been around 2000.
I was always got a kick of out of the swimming sections simply being teleporters. Step on top of the water a get teleported to a room filled with water and then swim to the top of the room to get teleported back to the area around the pool.
The BUILD trio (DN3D, Blood and SW) are all excellent games. I recommend anyone who has tried to at least try out Blood (IMO the best of the trio).
Other than that, if you are a FPS fan but haven't touched the 90s scene, please give yourself a favor by purchasing DOOM 1/DOOM 2/BUILD trio/QUAKE 1/QUAKE 2/UNREAL GOLD and more importantly download modern engine improvements, play the games and even more important, find communities and download the top quality mods/mappacks and play all of them.
Seriously I think it will take one years to go through the whole process, even limited to top quality mods/mappacks.
Duke was particularly good in multiplayer because all the guns were useful and balanced. For example, the starting gun was deadly at distance. The shrinker would give you an instant frag if you could catch the little guy. The rocket launcher was quite slow. etc.
I can remember staying after hours to edit the .ini file on each lab computer to give overwhelming power to the pistol and weakening the rocket launcher. So that during multiplayer my opponents would be rushing to upgrade to the launcher and then were confounded by its lack of effect...
Shadow Warrior used a further iteration of the same Build engine. It came with a huge map that had all the map effects demoed, and there were a lot of them, something like fifty (so if you were building a map, you could copy an effect).
For example, there was a room above a room, and a moving hole in the floor/ceiling between them.
As different as the mirror universe was, my favorite part of Duke Nukem 3D will always be the laser triggered mines.
Why? You could stick them to anything. Including other players. Sneak up behind someone, put a mine on their back, the next time someone walks directly behind them they explode.
I made several Doom2 maps as a college student. The tools were quite good so there were tons of them online.
I remember when Quake came out a lot of the scene died because nobody had computers powerful enough to render Quake levels. It could take literally hours of rendering to discover that you made an error and had to start over again. But the same people didn't want to go back to Doom because Quake was obviously the future.
90's shooters have such a special air about them. I liked DN3D enough to have created a custom level with the office building and the surrounding area - complete with moving street car you could ride in. (Remember putting an especially gruesome monster in the boss' office.)
I remember learning that Build didn't support structures on top of other structures. You could go up a staircase, but you couldn't end up on top of other level geometry. The level design in that game was so good I never noticed, and would have sworn it wasn't true.
There's quite a few retro shooters like that nowadays.
Prodeus, Ion Fury, Amid Evil, Project Warlock, Project Downfall, Hedon, Viscerafest... and those are just the ones I know about. If you include retro 3D (think mid-90s style) there's even more!
There's also a lot of mods and TCs for some classic games, like Doom or DN3D.
You should follow some gaming channels on YouTube that focus on retro shooters, they're a good source of new ones to play. I'd recommend ICARUSLIV3S and GmanLives if you'd like to find more.
I love this renaissance the genre is having, combining older aesthetic with better art design and lighting. Valheim comes to mind. I hope janky looking games but that are as deep as Deus Ex aren't far behind.
>And what I love about them is that they're able to just use the original engines* from decades ago
DUSK is a great exception to that, where they actually used a very heavily modified version of Unity to get something similar to ioquake or the early DOOM engines. IIRC most of the graphics programming was actually done to stop Unity from making the game "look better" :)
Amid Evil is another notable exception that I can think of of the top of my head: it uses Unreal4.
Oh man, Amid Evil is pretty crazy in that regard. All the game elements are sprites with depth mapping, so they react somewhat realistically to level illumination.
Prodeus does something similar as well. In fact, you can switch between 2D sprites and 3D models on the fly.
Other than games others recommend, maybe check out the mod community of those games you love. There are TONS of mods, and I mean top quality mods of classic FPS, enough to spend a whole year or more to play all of those through.
I saved a few Youtube channel for these kinds of things:
I actually designed and built a (modern?) game like this!
If you have an iPhone you can check it out. It's sort of "Portal meets Doom" https://blog.sb1.io/gateescape/
I used some screenspace shaders for the controls and color blending, but the engine itself is an oldschool raycaster. Building it posed a lot of interesting problems like how to recessively render sprites through portals and things like that.
For something a little different, check out Sonic Robo Blast 2. It's a third person 3D Sonic the Hedgehog fan game based on the Doom Legacy engine, and it's surprisingly quite decent. Certainly better than some of Sonic Team's efforts.
There are some out there. I was working on a game using the original Rise of the Triad engine which did 2D sprites, but the idea evolved to larger than that engine could really support. I'm now making a modern engine but keeping some of the philosophy to target low spec machines, so some of my "models" are 2D sprites.
Get FreeDoom and PrBoomPlus for PC, it's a vanilla Doom/Doom2 compatible Iwad which will allow you to play any Doom2 PWAD out there (and get an amazing shooter for free by itself, too).
For background Duke Nukem 3D came out the same year as Quake. Quake had a far better engine that absolutely revolutionized shooters. It could do so much more than the 2.5D engines. Duke Nukem competed by having lot of character in the level design, enabled by a pile of hacks like these.
Yeah, but you could play Duke on a 486, while Quake really needed a Pentium to get playable framerates.
It blows my mind how well those games ran on such primitive hardware. DOOM ran at 320x200, which is 64K pixels. On a 66 Mhz 486, that means you only got 34 clock cycles to render each pixel to maintain 30 fps, and that doesn't even include time for dealing with game logic!
You had direct access to video memory back then. Now, everything is abstracted away. I'm not even sure you could create an engine that rendered individual pixels while still maintaining solid framerates.
After all Quake was the demo tech wow factor for your spoiled friend and his 3dfx :)
Yeah Duke3d was running fine on any computer and most of all, it was FUN, both as a single and multiplayer game.
The map editor was amazing. I remember using all the tricks highlighted in this Twitter thread, following tutorials from PC magazines and having the docs printed in a folder I may still have somewhere... You could also quite easily break your maps with too much trickery.
Quake also had multiplayer on par with anything out today thanks to the great net code. I remember people playing at the university on some kinda fiber or cable and 10-20ms pings. I was jealous but able to play with my dial up
Quake’s perspective correct texture mapping used the pentium’s floating point math for every 16th pixel.
Most games at the time did perspective correct flat floors and walls, which can be done mostly with affine texture mapping. Sloped floors, which Quake had a lot of, must be done with more accurate Perspective correct texture mapping.
Perspective correct texture mapping technically requires a distance division at every pixel. Since it was too slow to do this at every pixel while rasterizing, Quake did the distance division at every 16th pixel, and used affine texture mapping between (linear interpolation).
On the Pentium you had fast floating point division which could run in parallel with the cpu doing the integer math. So they actually utilized both the floating point unit (for distance division) and integer unit (for affine texturing) concurrently, and in that way got rendering of each pixel down to <10 cycles.
Unfortunately, the 486s floating point math was not fast enough. So this trick makes everything worse on the 486, which is one of the reasons Quake didn’t run well on the 486 — the texture mapper was optimized for the fpu on the Pentium.
Mike Abrash wrote about this in his series of articles about Quake development which I highly recommend! I remember reading them during development of Quake in 1995-96 and implementing a lot of it myself (Bsp trees, shadow maps, texture mapping, sorted edge rasterize).
I actually implemented perspective correct texture mapping with integer division myself, and it was a bit slower on the Pentium, but a lot faster on the 486.
Funny, how just a few years later all of this became obsolete when GPUs arrived.
The character wasn't just in the level design. It had Duke's goofy monologue, toilet humor, hookers, and some semblance of plot. It had an attitude factor that played well to a lot of people in the time of No Fear t-shirts, eXtreme sports, and the WWF/WWE Attitude Era.
Quake was more of a technical marvel, but was aimed at a more alternative aesthetic that saw it use vague murky levels, Nine Inch Nails collab, and a Lovecraftian end boss.
Yeah, I find Quake boring, as an European Quake's environment is something not to far from a Iberian village, or the old town from any major city. It looks like a "slice of life" in Summer holydays plus monsters.
OFC not so "bricky" and "stoney", but Roman/Gothic walls, gates, doors and such architecture items can be found everywhere, in any remote village, town or the old part of cities, so it was, indeed, mundane.
And yes, for Americans these oldish environments are astounding and marvellous, I agree.
To me, the American urban environment was more exotic and "alive", something like a Hollywood movie with cops, cars, buildings and so on. That's why I loved every bit of DN3D, and most of highly detailled and interactive urban games.
> Quake was more of a technical marvel, but was aimed at a more alternative aesthetic that saw it use vague murky levels, Nine Inch Nails collab, and a Lovecraftian end boss.
That was pretty much the whole genre back then, which is what gave Duke 3D's level design the aforementioned "character", as it was one of the very few examples trying to depict more realistic environments vs the usual Doom mazes with very fictionalized settings/visuals.
One thing that I love about the “worse” engines is the neat tricks you can do which can’t be done in the “better” engines.
Tier Drops[0], for example, could not exist in the Quake engine. It relied heavily on the tricks that simply didn’t exist in Quake. And it was loads of fun!
Duke Nukem had this particular ambiance that IMO Quake lacked. And I sharply remember that mirror: what an excitement at the time! A mirror! Which we can break!
And in total honesty, my machine could not run Quake and I only caught up with the true 3D era with Unreal.
As someone who played a lot with DN3D level editor, yes, the mirrors were a huge hack. But then came Shadow Warrior, a fun game, a bit less successful, that re-used most of DN3D game engine and added yet another layer of hacks: They had a level with reflective floor... AND A MIRROR ON A WALL!
Looking at it with the editor was an unholy mess of sprites and scripts.
So crazy this is trending. I was just talking about how great and silly this game was with a complete stranger I had met yesterday!
Synchronicity also came up as a topic...
Is there a way to play DN3D or Shadow Warrior multiplayer anymore (that isn't super janky)? Obviously touch of nostalgia reading this twitter thread...
There's a remaster on Duke3D on Steam and console. It stays true to the original in a lot of ways but fixes a lot of the really annoying stuff you'd get if it were just a straight port. I haven't played multiplayer on it for a couple years but it was pretty fun.
I remember taking the "How to make a mirror in the Build engine" tutorial many many moons ago. Also fun, if you wanted to create a shadow cast onto the walls you'd just create the 3D geometry for the shadow and paint it darker.
Also also fun: building in the 3D engine involved walking around in 3D, drawing bounding boxes, and using page up / page down to change the height.
I remember fondly that I was toying around with the level editor of Duke Nukem 3D as a kid. Now I understand why it wouldn't really work out the way I assumed it would. Not only did I not understand much of english back then, but it was actually confined to 2.5D ...
There were a few other places in the first level that had "room above room" hacks that only work if you can't see overlapping areas of both rooms at the same time.
In the movie theatre there is a projector room up high, and the theatre exit below BUT the theatre exit has a wall centered in the middle where the overlap would be. There is also a spiral staircase going up to the projector room which has 2 or 3 levels of overlap, but as it is enclosed you don't view 2 levels at the same time.
Interesting stuff - and like many others have commented, I remember playing around with the Build editor and learning about these random hacks.
EDIT: and just now I'm remembering that submerging in water was another hack - you would actually teleport to another room on the map. In Duke3d the water was opaque, but in the later Shadow Warrior i remember it having some transparency (I assume probably using similar mirror hacks as D3d)
Same thing for water. You had to create 2 different rooms. When you passed the water you essentially got teleported to the other room.
If I remember correctly the programmer was like 14 years old when he created the build engine.
Played this a lot with my friends in 1997-98. That Hollywood holocaust is the best map the game has to offer. It has a TON of secrets and small places with valuable stuff, especially in deathmatch. One could be accessed by jumping on a light pole and then walking along the ledge.
Off the top of my head, I recall looking into how this was done in the first bathroom of silent hill 2. Mirror universes were, I imagine, pretty common. This one is a lot more interesting though as it seems like the sprites in the mirror aren't actually on the other side?
I had Duke Nukem for Mac back then, so a bit after the PC release, but my grammar school had a Mac computer lab, an afterschool program, and a lab teacher who let me and my peers install Duke on the school computers and stick around after school for an hour and half
Portal rendering [1] was actually a well-known hidden-surface removal method long before the game Portal, right there with Quake-style BSP trees. It's actually somewhat surprising that it took so long for someone to turn them into an actual game mechanic rather than just an implementation detail, though I do believe some games used them to create non-Euclidean topologies…
The way Portal works was to render the world from two different camera angles, one at the portal exit, and the player view, and then combine them with a stencil buffer. This allows for recursion if desired. It also allows for moving portal entrance/exits without performance degradation.
The way Build mirrors work is to copy the level geometry across the mirror plane. Recursion or moving the mirror would not be possible.
No, not really. The engine needed a lot of help from the map designer to make mirrors work at all, and those weren't even traversable without cheat codes, nor were they more than the flex foone describes them as - that's the reason you see one early on in the first level, and very rarely thereafter.
Arbitrarily placed, see-through, traversable, Portal-style portals probably would not have been beyond the skill of the engine implementers. But to make them work smoothly, along with everything else in the game, under the constraints of the hardware on which the game had to run? I find it hard to imagine anyone being able to pull that off, tbh.
As a 3D engine programmer from the era, I feel like portals could have been pulled off with relative ease. It's more a matter of wanting to do it. Someone today could demake Portal to a nineties era engine I'm sure.
Dark Forces (a Star Wars 2.5D FPS from the 90's) used portal rendering. This let you create impossible geometry, like making a doorway that appeared to be for a small room on the outside was actually a portal to a larger room on the inside (think the Tardis from Doctor Who).
I think the trick would be to realize that the texture on the mirror or portal represents the same screen height and position, just at the virtual screen location of the mirror/portal player behind it. So you render the screen space column as the flipped/mirror column but move the camera, avoiding overdraw, and use the fact that back faces on the wall/mirror texture are invisible from out-of-bounds. Something like that.
If you can lie to the engine and say that the flipped/portal camera is still inside the sector that the player is in (even if that's clearly wrong by the camera coords) then maybe your engine culls walls/floors/sprites not visible and you don't need to reserve an empty void for the mirror/portal camera to render from, so that level geometry can occupy the back side and make the illusion convincing.
To your point, I think that you could generate the duplicate geometry pretty easily but the issue would be making sure no overlapping sectors were visible at the same time, as that would cause glitches in the Build engine.
You might be able to subdivide the build engine's sectors into visleaves (borrowing terminology from Source) and clip all sectors in the mirror-verse according to the aperture + view-frustrum. To work correctly you'd need to do this every frame, probably an unthinkably huge task for the hardware at the time.
I remember the Descent map where there was a very large room you could fly out of and into a corridor. The corridor looped around and went through the center of the big room, but the room in question didn't have a big column through the middle of it. So you were sort of in the room but also not when flying through the corridor. I seem to recall that while other players couldn't see or collide with you, they could shoot you if they somehow figured out where you were.
Unclear why he's complaining about the non-existent complaining. No comment here is whining about the format except in jest. The comment you replied to is doing exactly what he suggests: using software to make it readable as a blog for those who prefer it.
The complaining may not be present in this thread, but historically there's at least 5 or so upvoted comments complaining about the format the content is posted in or complaining about the website used to host the content.
I think his tweets are fair given how absolutely toxic some posters on here can be.
Note that Foone’s rant didn’t specifically reference any comments on this submission, but rather as a general occurrence whenever their content gets posted to HN. Which is definitely a valid observation: from what I’ve seen, nearly every Twitter thread that hits the front page gets the tedious “I don’t like Twitter” and “this should be a blog post” comments (whether or not the thread is from Foone).
He mentions getting pinged by multiple HN scraping bots, and he's unable to block his content from being uploaded to HN. It sounds like he's just kind of annoyed and prefers a different communication medium.
I live in one of the regions of the world where Twitter has never been popular. According to surveys, only 11% of Quebecers are on Twitter (compared to 77% for Facebook).
I have never created an account and, for me, the format of the threads is strange.
So I always have a thread reader application in my bookmarks bar for when I need to explore the platform. I even put that link through the application in order to read it so the jokes fell flat. Even what I understand to be one letter per tweet came across well.
I don't understand why they complain. They enjoy the platform because it allows them to write quick messages. I enjoy the platform because I can easily read it using third-party software. Everyone is winning here.
Sharing the threadreaderapp link to my local friends who are not on twitter means I am sure they read it all. Otherwise, most people just read the first message.
Edit: This comment was written when this thread was under my parent comment.
Please don't go there. The number of off-topic threads that argument has generated is ridiculous and has even spawned an entire pointless metadrama. There are a bunch of collapsed subthreads at the bottom of this page if anyone really wants details.
That's what makes it so terrible for long form threads. I use Threadreaderapp but it's not ideal. Long heavily fragmented threads like this are literally headache inducing.
At the very least if the link is a threadapp, it's kinda fine. The issue is when the twitter UI stops showing half the thread and you have to keep clicking. I don't mind the bite sized sections personally.
Nitter [0] makes twitter tolerable. I never browse Twitter directly, I find the UI atrocious, and most tweets self-aggrandize or worthless.
There are some gems occasionally, like OP (Duke Nukem 3d was awesome).
There are extensions to redirect from twitter to nitter sites [1]. For example, the main site is not very responsive right now, but the alternative instances [2] are very responsive.
I'm just sad that once Twitter inevitably disappears in few years, all this cool content like this will be lost. I can still find and read HTML 1.0 pages from 25 years ago, but good luck ever finding this random Twitter thread unless somone specifically puts in the effort of preserving it.
To be honest implementing a mirror in a raycasting engine is not really that much of a technical feat - I bet the id guys thought "why didn't we think of that?!" when they saw it. But nice attention to detail though that walking through a mirror sent you back to where you came from instead of to the other side of the wall...
That’s not how it works at all. Foone explains quite clearly that the “mirror” is actually just a duplicate copy of the room on the other side of the wall, and walking through the mirror sends you to that glitchy duplicate room, not back where you came from.
The first Rise of the Triads was also a raycaster. Now there was plenty of tech transfer between id and apogee, so it might be they just heavily modified the wolf3d engine
I remember doing "reverse engineering" on a bunch of those as a kid and I can definitely attribute my passion for software to those experiences.
I was actually feeling a bit disconnected from my career at the moment and reading this thread awakened some of the excitement that was sleeping inside me! The 90's are a huge source of nostalgia for me.
Edit: It reads better in a thread reader such as https://threadreaderapp.com/thread/1372766463556083715.html