Duke Nukem 3D Mirror Universe
twitter.com
twitter.com
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
It still is, e.g. how shadows are done with shadow maps.
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?
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.
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:
https://en.wikipedia.org/wiki/Photon_mapping
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.
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.
Maybe when it becomes documented or otherwise supported?
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.
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.
Heck even yanking a floppy out to avoid a death was not uncommon with some games.
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.
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.
https://www.gamasutra.com/view/feature/131641/adding_languag...
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.
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...
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?
Should be quite easy to test in a multiplayer game.
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.
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.
But yeah, the ideas some people come up to make something work are pretty amazing.
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.
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.
He answered everything and even gave me some tips/hacks about using the 3D level editor.
And with Carpets, apparently ~ Gross.
The book store in the next level isn't a regular book store either. I never noticed that as a kid.
What was the book store?
The wiki page calls it a porn store.
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"
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?
Edit: or maybe I'm misremembering what portals did? Here is a really detailed article by Fabien Sanglard about the engine: https://fabiensanglard.net/duke3d/build_engine_internals.php
This made a lot of sense to my teenage brain : )
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.
Alley anyone?
For example, there was a room above a room, and a moving hole in the floor/ceiling between them.
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.
Also played around with the level editor and later with the Half-Life level editor.
Many tricks and hacks were done. Good times.
Turns out programming is just the generalization of what I did there, so I became a coder later, haha.
Many many huors/days/weeks were spent playing multiplayer DN3D over a null-modem serial cable too
But we played Quake after computer science class in shool.
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.
I wish people would still make them instead of going full 3D!
EDIT: Thanks for the game recommendations everyone!
Also check out Ion Fury if you haven’t yet:
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.
https://store.steampowered.com/app/562860/Ion_Fury/
https://store.steampowered.com/app/1000410/WRATH_Aeon_of_Rui...
* well, sourceports of the engines.
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.
Prodeus does something similar as well. In fact, you can switch between 2D sprites and 3D models on the fly.
Prodeus is more like an Amiga64 https://www.youtube.com/watch?v=AUN7t2RyMSs
This is really cool from a cultural evolution perspective to see fads and nostalgia fold back on itself.
Are voxels the one piece jump suit of video games?
I saved a few Youtube channel for these kinds of things:
pagb666: (DOOM mods and wads) https://www.youtube.com/channel/UCgYF9U_IDn77we6eSs-QYDw
Sinatar: (General classic game channel) https://www.youtube.com/channel/UC3_uzHYOPYZOyIYd6nGN3VA
dumptruck_ds: (Quake mapping) https://www.youtube.com/channel/UCF502yOYr_olPaw6xgnYmaQ
tatsurdcacocaco: (DOOM wads and mods) https://www.youtube.com/channel/UCBhdYANRJZiG6JmnqR7h3yw
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.
I also open sourced an early prototype of the engine: https://github.com/gh123man/Portal-Raycaster
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.
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.
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 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.
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.
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.
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!
And in total honesty, my machine could not run Quake and I only caught up with the true 3D era with Unreal.
Looking at it with the editor was an unholy mess of sprites and scripts.
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.
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)
IIRC it's on that room [1].
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.
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.
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.
The way Build mirrors work is to copy the level geometry across the mirror plane. Recursion or moving the mirror would not be possible.
I think it's funny.
I think his tweets are fair given how absolutely toxic some posters on here can be.
In fact, in the time since Foone posted that followup, several people did in fact post comments complaining about Twitter: https://news.ycombinator.com/item?id=26515506 https://news.ycombinator.com/item?id=26515604 https://news.ycombinator.com/item?id=26516435
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.
We detached this subthread from https://news.ycombinator.com/item?id=26514848.
> The following media includes potentially sensitive content
What the hell is going on at twitter?
https://i.imgur.com/Y4argxH.png
They omit all the relevant parts (which you were trying to highlight), and instead show a rant about morse code.
Twitter is truly unintelligible.
We detached this subthread from https://news.ycombinator.com/item?id=26516818.
specifically to annoy foone
It's slowly ruining the internet.
On the other hand I’m equally surprised by the number of weird little websites that just fail to die.
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.
Wolfeinstein 3D was the last major FPS to use raycasting.