How did I make this absurdly large map fit Half-Life? news

Hi everyone, how're you doing? I'm still alive(.mp3), been better though.

I had recently received a complaint about performance one player was having on an average "old" PC. I clearly remember that at the time of Half-Life 1 the best thing you could reasonably afford was Pentium II, so, I was puzzled: how could anyone have worse experience than I do?

So, I took a 7yo laptop and made some measurements...

A few words about the map. ForestXL is unique and actually a VERY large and GoldSource-UNfriendly map (yes, opposite to friendly). I started making it under influence of the Gothic RPG (there was this semi-open world with really smooth location transitions). Map spans beyond allowed field of 8192 by 8192 units (actually it's a cube, but the overall layout is fairly horizontal). Why so? Well, let's say I just wanted more immersion: usually maps gets enclosed with walls or a skybox, which looks pretty ugly most of the times. I extended BSP architecture beyond engine limits which is technically acceptable. You see, there's a limit of coordinates players and most objects may have: -4096 to +4096. But visual aspect is bound by different laws, so static architecture may be placed well beyond. And some projectiles and effects may also be forgiven for trespassing into this no-flight zone. So I made a fictitious invisible wall for players that is presented as a force-field which stays just at the limits, and the forest - ground, trees, stones, glowing balls - continues far past that.

Almost everything is always visible. All decorations like trees and bushes are made of studio models using XDM RenderSystem (because otherwise engine definitely runs out of limits and crashes halfway through). Global particle system adds to already enormous scene complexity. And when players join, polycount just skyrockets.

I made quite a few tricks to regain performance, but Half-Life just hates open spaces! I think many games rely on some of these tricks, but here I had to use everything possible and impossible to make things playable (but, as you see, they're still not). Half-Life is a definitely old and low-poly game. Even slightest overload takes it down. But at that time Unreal was more capable! I want absurdly large and beautiful maps too!

So, here's what I did with this map.

1. Limited number of resources like textures and models used: most textures are tiling, models repeating varying in size and placement.
2. Cut the maximum visible distance (server-side culling, most important).
3. Minimized number of polygons and luxels (lightmap pixels) beyond playable area by stretching poorly visible textures and removing EVERY single possible triangle not visible by players from inside the map.
4. Added some dividing elements like large rocks, it helps in not drawing things behind them.
5. Used only func_details (which are not entities at all) to avoid world polygon divisions
6. Painting all "glued" faces with SOLIDHINT texture that allows compiler to handle merging of complex edges better with less errors and subdivisions.
7. Limited number of entities: there's actually only THREE weapons, TWO longjumps and ONE brush entity which is invisible. Weapons are added to players using start-time equip.
8. Cut water brush shape and size to not generate any invisible yet VERY expensive polygons (water is handled directly by the engine and is always impacts performance in extremely devastating ways).
9. Made some effects optional (e.g. falling glowing particles).
10. Exported and compiled with special parameters to increase calculation precision, which again helps avoiding artifacts and limits rendering distance.

This is all I remember for now. But even after all of that... well, you see the shots.

So, the long-awaited "benchmarking" details:

Testing was performed on AMD A4-5000 APU with Radeon(TM) HD Graphics, 8Gb DDR-3 12800 RAM, a really good SSD, Windows 7 x64 and lots of patience. XDM was running on Half-Life v1110 with 31 bots, which is maximum.

The results are msaddening: while the native Windows performance was already below acceptable, 10 FPS (remember though: 32 bots!), emulating the exact same copy of game on Linux via WINE cut even that IN HALF resulting in average 5 Frames Per Second. Terrific.

What led to this? Slow hardware aside, GS is just sucks at rendering. Poly-by-poly is not a thing for at least 20 years now and moder drivers and GPU architectures are not cut out for this kind of job. And, while being optimized extremely well, XDM still adds a ton (probably metric) of heavy load with its hi-def models and crazy special effects. Actually, disabling those made the FPS go significantly higher! That's why I made them optional. And it pays, some 20 years later :D

To be fair, UT2004 runs only a tad better here and its rendering mechanisms are far better optimized. I'm looking forward to benchmarking Xash3D next time, but it requires some fixing on their side.

This is life. Half-Life. See you next time. Any questions?