The ironic thing is that each subscriber now has a dedicated computer many times more powerful than what ISPs had back in the day for hosting ALL those websites sitting in the most privileged part of their network, being online 24h and begging to be used for small hosting tasks like this: their ISP provided router. It even serves it's configuration panel through html and a webserver for crying out loud!
Unfortunately reality is such that those are closed systems with historically abhorrent security and ISPs usually forbids the user from properly providing their own choice of router.
The upstream bandwidth sure improved but ISPs are still hostile to self-hosting by limiting ports, resetting connections every x days and not providing an ipv4 for a reasonable charge.
> Half-Life 2 sure won't play quake maps nor will it play hl1 maps.
Not without modifications but Half-Life: Source is essentially a tech demo to show that they can be ported easily (if you are OK with dropping some pesky features like randomized wall textures).
AFAIK hl1 maps needs to be open in hammer, tweaked a bit and then recompiled to function in hl2. You also better have those originals .rmfs rather than a .map or a even worse, a .bsp :)
edit: there is also the fact that map compilers for gold source games have advanced far beyond what they could do back in 1999. The lightmaps and light sources alone can be far more intricate nowadays than what you would get from the official valve ones in 1999.
The other thing though is that Original Quake Back In The Day ran on a Pentium 75 (needed the maths co-processor) with a dumb framebuffer. All the rasterising of polygons was pure software, as was all the geometry processing. Running GLQuake was a huge improvement but it required an expensive add-in card that piggybacked onto your VGA card, and a whole different binary.
Now you can just kind of pile it into a block of RAM, aim a chunky ASIC at it, and pull the trigger every frame.
In the late 90s a mate of mine did a phenomenal video of a Quake demo (you could record all player movements and camera positions as a "dem file") that he'd rendered out, raytraced in POVRay. I printed it to VHS for him as part of a showreel, and never thought to keep a copy myself.
While lighting is important, not using halflife.wad and going above the
original budget of 500 polys per "scene" is what makes modern works look much
better.
Most of the original textures are under 128×96 px and some suffer from awful
palletisation artefacts with purple and orange halos.
We still cannot use more than 8 bpp but we can use 512×512 textures and do a
better job at reducing to 256 colours. I use pngquant for that.
In GoldSrc lightmaps cannot get more intricate though, they're tied to the
texture scale so you cannot get a finer lightmap unless you also make larger
textures and scale them down, and these two combined will wreck your
"AllocBlock" budget in which all your textures and lightmaps must fit.
ericw-tools and its dirtmapping are still welcome improvements over the
"traditional" *HLT compilers.
> In GoldSrc lightmaps cannot get more intricate though, they're tied to the texture scale so you cannot get a finer lightmap unless you also make larger textures and scale them down, and these two combined will wreck your "AllocBlock" budget in which all your textures and lightmaps must fit.
AFAIK some of the improvements include much better light bouncing techniques, transmission of surface colors like source does, more accurate lights, spotlights that emulate what source spotlights does and faster compilation (computers also got faster and MT support helps a lot). That alone allows level designers to be more ambitious by taking advantage of faster iteration and place even more lights.
I do agree that there are likely dozens if not hundreds of reasons why maps can and usually do look way better today than what could be done in the past. Hell, even level designer proficiency with the tools as time goes is also surely a reason.
I used to do a bit of mapping back then (nothing that survived to this day, thankfully); as I recall, practically nobody used official map compilers. As it often happens, the community wrote replacements that were much faster for debug "-O0" builds, and generated lightmaps of a significantly higher quality for the release "-O2" builds.
It was either ZHLT or VLHT, or something like that; looks like more alternatives have been written since then.
The lighting is one of the main area's that really improved a lot.
For standard Q1 mapping ericw tools [0] is great (the page has some nice previews).
This project seems to use Nuclide for building which by default uses vmap compiler [1][2]. Which is really Q3 but I think FTE handles that well internally as the newer format has some more modern features.
> Powerful BSP compiler. Use VMAP to bake levels like you're used to from similar engine technology, with high quality lightmaps, cubemap-based environment mapping and adjustable vertex colors on spline-based meshes.
There was a similar path with Unreal3. The early games (2006) lighting looks quite harsh by modern standards, one of the highlights of Mirror's Edge (2008) was DICE using third party Illuminate's "beast" lighting, then Epic moved to "lightmass" around 2009 with the public UDK toolset.
A shame to only now learn of Victor Antonov's passing. His work on HL2 and Dishonored remain some of my favorite examples of video game world building of all time. These places felt real and lived in, in a way few other video games have matched for me.
GNOME devs operates more like benevolent dictators. It sure is oppressive and you better be glad for what you are getting, but what they put out with so few resources is leagues above what microsoft can do nowadays.
Maybe the general population will be willing to have a more constructive discussions about this tech once the trillion dollar companies stop pillaging everything they see in front of them and cease acting like sociopaths whose only objectives seem to be concentrating power, generating dissidence and harvesting wealth.
Weirdly it only has 8GB of internal storage...
reply