| |
| ▲ | amlib 6 hours ago | parent | next [-] | | And Viktor Antonov (rip) art style. 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. | | |
| ▲ | homebrewer 5 hours ago | parent | next [-] | | 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. https://gamebanana.com/tools/5391 https://github.com/seedee/SDHLT | | |
| ▲ | trashb 4 hours ago | parent | next [-] | | 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. [0] https://ericwa.github.io/ericw-tools/ [1] https://developer.vera-visions.com/d4/d50/radiant.html#autot... [2] https://github.com/VeraVisions/vmap | |
| ▲ | keyringlight 3 hours ago | parent | prev [-] | | 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. |
| |
| ▲ | l-p an hour ago | parent | prev | next [-] | | 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. | |
| ▲ | ErroneousBosh 5 hours ago | parent | prev [-] | | 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. |
| |
| ▲ | 6 hours ago | parent | prev [-] | | [deleted] |
|
