Eh, I don’t really think that this is an “or” situation. I think that this is an “and” situation. The last time that I set up Xash3D FWGS, I had to copy files from the version of Half-Life that I own on Steam into a different folder so that those files could be loaded by Xash 3D FWGS. I haven’t tried Xash 3D FWGS in a while, but it looks like you still have to do that [1]. Also, are you sure that the Steam version of Half-Life is Windows only?
Yeah Apple's latest round of breaking changes hasn't been addressed (and seemingly won't be).
The Linux and Mac ports happened in 2013 or so (presumably getting one working went a lot of the way to getting the other working, though there is some speculation that Apple poured in some money to help make it happen).
Super interesting! I'm curious what the purpose is, though?
Edit to answer myself: Looks like this is more of an offshoot of the FreeHL projects by the same author, which rewrite GoldSrc game logic to QuakeC to get those games to run on open source engine stacks, where the utility is more obvious. I guess it was just fun to see how hard it'd be to get HL2 content running.
A bit similar to the OpenMW project working on Oblivion and Skyrim content loading on the side, though perhaps that's a more obvious future vector for that project.
It means they didn't reference any existing or decompiled code from the original client. None of it is directly infringing on any copyright, though it may be doing so indirectly since there have been plenty of lawsuits for tools that contain no copyrighted information can but can used to facilitate infringement (e.g. a tool that decompiles a game ROM)
As long as the assets dont contain code, they're kind of fair game. The rule of thumb is you cannot redistribute them, but if the person owns a legal copy you can point to them on their local system. It is not up to you to figure out if they're pointing to a pirated copy or a legitimate copy mind you.
I assume you, the player, have to provide the assets yourself, and the game won't run without them. Since the code does not contain the assets, there is no copyright infringement.
Interesing, there's more here including HL1 (a.k.a "valve")
Funnily enough the looks of this HL2 through this engine makes it flow more with HL1 than I could expect; an interesting reverse Half Life: Source / Black Mesa / demake of sorts.
Even simple Half-Life 1 mods built on textures and models from Half-Life 2 look much closer to 2 than one would expect. For example this mod, but not only:
You won't confuse it with modern Half-Life 2, but the original HL2 engine had far worse graphics than the latest version. Makes you realize how much of the difference between HL2 and HL1 is due to different textures and level design.
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.
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.
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.
Interesting, I loved both HL1 and 2. Some games never die, brought to mind the Black Mesa remake of HL1 with the HL2 engine that gave it new life.
https://www.youtube.com/watch?v=sKutLsub-80
Yeah, but Half Life 2's Source engine was itself a continuation of Goldsrc which was itself a continuation of the Quake 1 engine. The lineage is there but beyond a certain point it's not really Quake anymore.
GZDoom/UZDoom is a similar grey area, it is built on the original Doom codebase but they've added so many features that it's practically its own distinct engine now. Those forks can even render arbitrary 3D models, which OG idTech couldn't do until Quake.
We'd have to come up with definition of quake :-) FTE has a lot bolted on it but the focus us in Quake, quake mods, lifting some limitations and making mod dev convenient.
But it is the same overall code structure, the same game, etc.
All these oss quake engines, are they quake? Ironwail, quakespasm vkQuake?
> 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 :)
Qames/quake from 9front =). It can run LibreQuake with Malice as a MODs, and that's it. Quake, Quakeworld and everything for vanilla, no modern changes like QuakeSpasm or worse, DarkPlaces. If someone backported HL2 to the original Quake with reduced physics and still run under a Pentium III fast enough, it would be something astonishing.
I see impressive stuff with reimplementations such as Surreal Engine, but they will require far more powerful machines.
If Surreal had a software renderer (not requiring AVX or similar) running under an SSE2 machine, that would yield even more respect, because if your reimplemented engine runs in legacy machines the portability would explode. Just have a look on Scummvm on how many platforms and OSes can it run. Or the Super Mario port for PC, where some fork supports even 3DFX under DOS, and GL 1.2. Thus runnable under TinyGL with no 3D accelerators and even under Plan9/9front with custom tweaks.
Seems like you or someone upstream of you uses a Zyxel brand device that has some kind of dns content filtering enabled. You should be able to get around this on a given machine by configuring an alternate dns provider (dns over https, cloudflare's 1.1.1.1, google's 8.8.8.8, quad9's 9.9.9.9, etc.) or doing something similar at your own router/dns resolver/dhcp server if it's not the thing doing this.
I certainly don't get that cert. I'm seeing a LetsEncrypt cert for idtech.space with various SANs.
# host code.idtech.space
code.idtech.space is an alias for idtech.space.
idtech.space has address 192.99.32.215
idtech.space has IPv6 address 2607:5300:60:47d7::
De-makes are interesting because they continuously seem to show what may have been possible long ago in ancient engines if teams pushed them even further.
Then again maybe that level of detail even in idtech1 would have required more computing than was available for many years.
I do suspect this would not run well on a 75 Mhz Pentium 1. It would be very surprising if Quake 1 was actually the pinnacle of what as possible on the hardware of the time, though. id made exactly one game targeting that generation of hardware, and then their next game had meaningfully higher system requirements despite coming out only a year later. The hardware capabilities were changing so fast that there simply wasn't time to iterate on a specific target.
If you want to play Half-Life today I highly recommend Xash3D FWGS (yes its a super awkward name)
https://github.com/FWGS/xash3d-fwgs
Easy to use Mac build here: https://www.macsourceports.com/game/halflife
Or, can still be purchased on Steam for $0.99, during sales. Windows only though.
Eh, I don’t really think that this is an “or” situation. I think that this is an “and” situation. The last time that I set up Xash3D FWGS, I had to copy files from the version of Half-Life that I own on Steam into a different folder so that those files could be loaded by Xash 3D FWGS. I haven’t tried Xash 3D FWGS in a while, but it looks like you still have to do that [1]. Also, are you sure that the Steam version of Half-Life is Windows only?
[1]: <https://github.com/FWGS/xash3d-fwgs/blob/f0342763547d9bcf486...>
What's the point of using this xash thing then?
> Also, are you sure that the Steam version of Half-Life is Windows only?
You're right! It looks like Linux has a native build too. Apparently the Windows version, through Proton, runs better though (not that it matters).
the windows version is playable on macos through wine. Even modern version, I got it running on a m2 mac mini on Macos 15 sequoia
EDIT: this was for HL1 I’m not sure about HL2
Its ported to Linux just like cs 1.6. Not sure how good Mac build is though.
Steam version: This product is not compatible with macOS 10.15 Catalina or above.
Yeah Apple's latest round of breaking changes hasn't been addressed (and seemingly won't be).
The Linux and Mac ports happened in 2013 or so (presumably getting one working went a lot of the way to getting the other working, though there is some speculation that Apple poured in some money to help make it happen).
Super interesting! I'm curious what the purpose is, though?
Edit to answer myself: Looks like this is more of an offshoot of the FreeHL projects by the same author, which rewrite GoldSrc game logic to QuakeC to get those games to run on open source engine stacks, where the utility is more obvious. I guess it was just fun to see how hard it'd be to get HL2 content running.
A bit similar to the OpenMW project working on Oblivion and Skyrim content loading on the side, though perhaps that's a more obvious future vector for that project.
Speaking of:
https://openmw.org/2024/from-bsp-to-esp-how-s3ctor-abused-qu...
What does clean room mean in this context? They built it from the assets with the game as a reference , but didn't look at the engine source code?
It means they didn't reference any existing or decompiled code from the original client. None of it is directly infringing on any copyright, though it may be doing so indirectly since there have been plenty of lawsuits for tools that contain no copyrighted information can but can used to facilitate infringement (e.g. a tool that decompiles a game ROM)
How about the assets?
As long as the assets dont contain code, they're kind of fair game. The rule of thumb is you cannot redistribute them, but if the person owns a legal copy you can point to them on their local system. It is not up to you to figure out if they're pointing to a pirated copy or a legitimate copy mind you.
I assume you, the player, have to provide the assets yourself, and the game won't run without them. Since the code does not contain the assets, there is no copyright infringement.
Not related to the engine, but it reminded me of a demake of Half-Life 2 in Quake https://www.youtube.com/watch?v=FhuXHGb_4vU
>The game is not playable from start to finish. You can play deathmatch and other odd modes.
Impressive, given how old Q1 engine is. It brings back memories of Paranoid Doom mod: https://www.doomworld.com/idgames/levels/doom2/Ports/p-r/par...
Interesing, there's more here including HL1 (a.k.a "valve")
Funnily enough the looks of this HL2 through this engine makes it flow more with HL1 than I could expect; an interesting reverse Half Life: Source / Black Mesa / demake of sorts.
Even simple Half-Life 1 mods built on textures and models from Half-Life 2 look much closer to 2 than one would expect. For example this mod, but not only:
https://moddb.com/mods/half-life-dark-future
You won't confuse it with modern Half-Life 2, but the original HL2 engine had far worse graphics than the latest version. Makes you realize how much of the difference between HL2 and HL1 is due to different textures and level design.
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.
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.
https://gamebanana.com/tools/5391
https://github.com/seedee/SDHLT
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
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.
The Z from ZHLT ended up working for Gearbox Software.
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.
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.
Interesting, I loved both HL1 and 2. Some games never die, brought to mind the Black Mesa remake of HL1 with the HL2 engine that gave it new life. https://www.youtube.com/watch?v=sKutLsub-80
FTE barely qualifies as a pure Quake engine at this point though, it does tons of stuff.
It does a lot, yes, but also is very much a continuation of the original codebase - i've spent quite some time tinkering with internals of it.
Yeah, but Half Life 2's Source engine was itself a continuation of Goldsrc which was itself a continuation of the Quake 1 engine. The lineage is there but beyond a certain point it's not really Quake anymore.
GZDoom/UZDoom is a similar grey area, it is built on the original Doom codebase but they've added so many features that it's practically its own distinct engine now. Those forks can even render arbitrary 3D models, which OG idTech couldn't do until Quake.
We'd have to come up with definition of quake :-) FTE has a lot bolted on it but the focus us in Quake, quake mods, lifting some limitations and making mod dev convenient.
But it is the same overall code structure, the same game, etc.
All these oss quake engines, are they quake? Ironwail, quakespasm vkQuake?
There already is a term: Quake Source Port
https://quake.fandom.com/wiki/Source_port
I think the litmus test is weather they are backwards compatible with old maps/campaigns from the original engine/game.
Half-Life 2 sure won't play quake maps nor will it play hl1 maps.
> 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 :)
Qames/quake from 9front =). It can run LibreQuake with Malice as a MODs, and that's it. Quake, Quakeworld and everything for vanilla, no modern changes like QuakeSpasm or worse, DarkPlaces. If someone backported HL2 to the original Quake with reduced physics and still run under a Pentium III fast enough, it would be something astonishing.
I see impressive stuff with reimplementations such as Surreal Engine, but they will require far more powerful machines.
If Surreal had a software renderer (not requiring AVX or similar) running under an SSE2 machine, that would yield even more respect, because if your reimplemented engine runs in legacy machines the portability would explode. Just have a look on Scummvm on how many platforms and OSes can it run. Or the Super Mario port for PC, where some fork supports even 3DFX under DOS, and GL 1.2. Thus runnable under TinyGL with no 3D accelerators and even under Plan9/9front with custom tweaks.
Is this the way we can have HL3 also?
SSL_ERROR_BAD_CERT_DOMAIN
Seems to be using a dnsft.cloud.zyxel.com certificate. Is this a home router?
https://community.zyxel.com/en/discussion/23595/why-i-get-bl...
Seems like you or someone upstream of you uses a Zyxel brand device that has some kind of dns content filtering enabled. You should be able to get around this on a given machine by configuring an alternate dns provider (dns over https, cloudflare's 1.1.1.1, google's 8.8.8.8, quad9's 9.9.9.9, etc.) or doing something similar at your own router/dns resolver/dhcp server if it's not the thing doing this.
I certainly don't get that cert. I'm seeing a LetsEncrypt cert for idtech.space with various SANs.
Maybe you are MITM`d?
Ah. Looks like it is being blocked by my corporate software.
Thx for the replies.
Half-Life 2 looks incredible in Quake 1, what gives?
Quake's engine is open source and for example nvidia used it in some more recent tech demos, although this one's for Quake 2: https://www.nvidia.com/en-us/geforce/news/quake-ii-rtx-v1-2-...
Quake 2 was when they added multi-colored lighting - it's really aged well.
De-makes are interesting because they continuously seem to show what may have been possible long ago in ancient engines if teams pushed them even further.
Then again maybe that level of detail even in idtech1 would have required more computing than was available for many years.
I do suspect this would not run well on a 75 Mhz Pentium 1. It would be very surprising if Quake 1 was actually the pinnacle of what as possible on the hardware of the time, though. id made exactly one game targeting that generation of hardware, and then their next game had meaningfully higher system requirements despite coming out only a year later. The hardware capabilities were changing so fast that there simply wasn't time to iterate on a specific target.
Would it work under vanilla quake 1? Ah, no. I can't check it out.
Good job keeping me away with Anubis, btw.
Are you a LLM?
No, just a 9front user with a web browser, Netsurf. I shouldn't need JS to read an article you know.