Unvanquished 0.55 is now there!

It was long awaited, but now it is real! Download it now!

Fast! Fast! Fast!

The engine and the game are now much more faster than ever!

• Sky simplification: Reaper brought a cleansing fire to the archaic and bafflingly baroque sky rendering code. That old code could generate over 1000 triangles on the CPU every frame, just to draw the sky. The skybox does not need such intimate geometry: it is simply modeled as the inside of a cube. So now we draw it with just 12 triangles. Needless to say, this improves performance.
• Culling: Illwieckz optimized the generic CPU code, Slipher handcrafted SSE code for x86 architectures, and Reaper made it possible to let the GPU do it if the driver and hardware are compatible.
• Reducing IPC delays with batching & caching: This speeds-up things like particles, impact marks and shadows. Illwieckz slashed the amount of time spent waiting on inter-process communication by adding batched versions of several APIs. You can think of IPC as a postal service that carries messages between the Unvanquished game process and the Daemon engine. For the mailman, the important thing is not how many pages of text you write; it’s how many envelopes need to be delivered. So you can make their workload lighter by stuffing all your letters in one big envelope. For one use case (already delivered in 0.54.1) Slipher implemented in-game caching. To continue the metaphore, it is not needed to send the same mail again if the content is already known. On common hardware from these days, those optimizations may increase the framerate by hundreds of FPS when there are lots of particles and things like that on-screen (firebomb spam!).
• Faster float vertex code: The full float vertex implementation written by Slipher and purposed to extend compatibility to older and lower-end hardware not supporting half-float also doubled the framerate on some hardware that were already working before. The rewrite also added slight optimizations to the model code.
• Relief mapping: Reaper fixed a bug in relief mapping unlocking some hundreds of FPS on GPUs from current generations.
• Image memory usage: Illwieckz implemented the fitScreen mechanism for UI textures: it’s an alternative to the legacy noPicMip implementation from Quake 3: noPicMip was telling the engine to never downscale an image, fitScreen makes sure it is downscaled in a way that it never becomes larger than the screen. For example it means 4K level shots are no longer uploaded at their full resolution to the GPU memory just to get them rendered on a 640×480 screen anymore… Combined with the r_maxImageDimension mechanism we added in 0.52 for non-UI textures as an alternative to r_picmip, this new mechanism makes the game footprint in VRAM very small when using low screen resolutions.
• Precompute more: Illwieckz made sure many decisions previously done every frame when rendering a given surface are now taken at shader parsing time once and for all. What we call “shader” in this case is a kind of material definition used by id Tech 3 and its derivatives and produced by various mapping tools.
• SSAO: The SSAO shader has now been made slightly faster by Reaper.

The engine and the game were intensively profiled with Orbit by Illwieckz, such effort made possible identifying many bottlenecks or unoptimal code. In the end it helped us implement many optimizations in many places of the code.
Map loading was also sped up in various ways:

• The engine doesn’t checksum CRN images anymore at load time.
• The engine doesn’t compile some of the shaders that it can determine to be unused.
• In the same way we reduced the amount of shader permutations to build.
• Single-player enjoyers will appreciate our multi-threaded bot navigation mesh generation, thanks to Ishq and Slipher. This is a part of the loading phase when you play a given map for the first time in a local game. Navmesh generation used to be done on a single thread, which could take a long time for large maps. Now, it unlocks the full power of your CPU with all cores blazing. Server owners too may partake, but they must set it up using the cvar g_bot_navgenMaxThreads (using a low value makes it possible to use less memory if needed).

Then there’s a bunch non-renderer things that make the game faster:

• The “lowest” preset for very low-end devices was optimized further.
• We ship some optional low quality models – for now only for buildables, with the only difference being those models having less bones. It allows running the animations for these models on lower-end GPUs.
• It was discovered that some cvars were used by the game code to send data to the game code UI in order to print them on the screen, meaning the game was uselessly sending every frame a letter to itself through the engine… Well, it even involved two letters: one to send the data to the engine, one to retrieve the data from the engine, all of that for something already known! This horror was NUKED with extreme prejudice.
• Accessing game cvar by name string from game side now uses a local cache, reducing yet again the amount of messages the game and the engine have to exchange, speeding up the user interface by a lot.

Benchmarkers will be happy to hear that the timedemo framerate is not capped at 999 FPS anymore.

Additionaly, the curses interface version can now print the FPS.

A bright future

A video showcasing light compatibility with various legacy assets.

A long-time effort is ongoing on the renderer to display better lights in-game. Investigation started to deliver significant results in 2020 with the refining of the light compilation process. But that effort is multifaceted and involves many aspects of the production and rendering pipeline. In the recent years, Illwieckz made sure that all the different kinds of lighting were supported. This added vertex lighting to grid lighting and light mapping, so maps that mix both vertex lighting and light mapping are now rendered properly. Illwieckz also debugged the light styles mechanism, a kind of pre-computed dynamic light that blends multiple lightmaps at render time.

After that, Illwieckz re-implemented the overbright mechanism to avoid light clamping. It happens that the Quake 3 renderer had a bug that dimmed the lights as much as it brightened them… The new non-buggy code is now enabled by default. This brings some debate since the id Tech 3 engine had buggy light overbright for more than 20 years, so running a non-buggy renderer may uncover bugs mappers had never seen before, and it was possible to even introduce bugs in some production software without people noticing them! Some people may then argue that the buggy way was the way a mapper expected his map to be seen… This story is so deep that it may deserve its own dedicated blog post!

The next step on that road to better lighting will be to do proper color management and do linear light blending (something id Tech 3 never did), but this task is for the future.

Renderer fixes

A video showcasing portal and mirror recursion, blending and fading.

• Sprites: Surfaces using the autosprite2 shader keyword are now rendered correctly. This is sometimes used for displaying cylindrically symmetric effects such as a candle flame. This work was done by Slipher.
• Portals & mirrors: Reaper finished the implementation of portal and mirror recursion, implemented portal blending and alphaGen (technique to fade the portal with distance), and made it possible to have moving portals. He fixed the rotation of portals, corrected some portal bugs related to lighting, and made sure to stop alien creep 10 million times the size of observable universe from appearing in portals…
• Video: We can play videos in-game on rendered surfaces again. With time the code rotted, got broken and even got removed while it was broken. It got resurrected and received a deep rewrite by Slipher, and the feature is working now again – even better than before (with less arbitrary limits). That new implementation was delivered in 0.54.1.
  The only supported video format is the old RoQ format used by Quake 3, which, for being compatible with legacy assets, is the codec we better support before any other codec. We’re not closing the door on supporting other codecs, but for that we would need that feature to be more widely used to justify the extra effort.
• Fog: Reaper fixed the fog, which was broken in 0.54. Oops!
• Lights: Dynamic lights are now less blocky, although this issue hasn’t been completely fixed yet.
• PBR: The so-called “physically-based” texture support is now in a viable state thanks to Ishq (no more dark artifacts). It is used with the new Chaingun model. To make it great, we just need to marry it with the reflective specular (aka static reflections).

A video showcasing video playback on in-game surfaces.
By fixing the autosprite2 shader, the portal blending and the video playback, we fixed 3 regressions from the original Quake 3 renderer that were related to the support of legacy file formats and techniques. As our renderer is no longer the one used by Quake 3, sometimes fixing such regressions requires writing new code rather fixing the existing one, and that is what happened with portals.

Of course it runs Unvanquished!

On the renderer side, the minimal requirement is now OpenGL 2.1 without fancy extensions. It means the lowest hardware that can run Unvanquished includes the ATI R300, the Intel GMA 3 and 4 (on Linux) and Nvidia NV40. Sometimes even incomplete GL 2.1 can be enough!
Your graphics card is supported. If it doesn’t while the hardware is supposed to support OpenGL 2.1, that’s very likely a driver bug.

For example the VC4 from the Raspberry 3B+ can sustain up to 60 FPS on the lowest preset with tiny resolution in some maps, but some fixes on driver side seem to still required to be compatible with all maps.

Here are some optimizations done to extend the compatiblity of the engine:

• The GL_ARB_half_float_vertex extension is not required anymore. This adds to the GL_ARB_framebuffer_object extension not being required since 0.54 and other things to unlock more hardware. The rewrite done by Slipher to support either half float vertex or full float vertex has even sped up the engine a bit (more features, less code, better code!).
• 3D textures are not required anymore. That’s something that is mandatory in OpenGL 2.1, but the engine can do without it if the implementation is incomplete.
• A bunch of detection code for buggy or slow drivers and hardware was implemented, and when possible, less buggy and/or faster code is enabled at run time.

Of course all the speed-ups also help extend the compatibility by turning something that renders into something that is playable.

We also added the possibility to build and run native FreeBSD engines. The sandboxed NaCl binaries for the game code will run within the built-in Linux compatibility mode though.

One topic we may improve the engine on in the future to extend compatibility further is memory usage.

Visuals

New models for the Painsaw (by Alex Tikkoiev) and Chaingun (by extreazz) are here. They were integrated into the game by Ishq (it sounds simple but it’s a huge drag, we currently have no active modeler and animator).

The Painsaw will now also produce sparks when hitting surfaces, acting as the Great Communicator of your desire to spill some alien guts.

10 years ago, we got a nice rendering feature known as soft particles. This stops effects like smoke or acid clouds from looking bad when they touch walls. Initially the effect was configured for just a handful of shaders. Soon, lazy programmers said to themselves: configuring shaders is boring, why don’t we enable it automatically for all particles? Unfortunately, this caused some particles to become invisible! Especially weapon hit effects which tend to appear very close to walls/floors. Apparently no one noticed this for the next 9 years, until we decided to go back to manual shader configuration due to autosprite2-related architectural changes. After a review of all the particle systems in the game, we fixed, removed, or improved several graphical effects. For example, the Lucifer Cannon blasts now produce a shockwave effect, causing visual distortion. Such an effect was already there in the asset files, but it didn’t work due to a shader sorting bug. The secondary fire also produces a purplish flash on impact, which was often invisible before due to the automatic soft particles.

Reaper redesigned the medistation healing effect and made it more transparent, so that healing players can see beyond it.

Sweet added a new visual effect to the forcefield in the plat23 map. This uses the heat haze effect which was originally designed for weapon and fire graphics, but turned out to be fun for maps too. We thank Masmblr for the way he pushes us forward by demonstrating in his own community maps how it is possible to leverage in new creative ways the features we already provide!

User Interface

A long-requested-change: you can now continue to move about and generally use key binds while using the circle menus (evolve, build, and beacon; human buying is not allowed for now). In particular, this allows using the build menu while wallwalking as an Advaned Granger without falling down. You can also evolve while running and jumping, etc.

Other improvements to the menus and HUD include:

• Aesthetic redesign of the menus, thanks to Grise.
• Improved voting display with color and larger text, thanks to cu-kai.
• New options for crosshair styles, thanks to Reaper, with a nifty preview inside the menu – courtesy of Ishq.
• Something that is familiar to Quake Live players out there – weapons can now be set to “translucent”, making them less obstructive.
• You can now bail out of a download by using Escape or clicking a “Disconnect” button, thanks to Illwieckz.
• Finally fixed alignment of unlock icons on the momentum bar – no longer will you need to wonder why this or that upgrade isn’t unlocked after it’s cleared by the momentum bar.
• Dead players show up as DEAD instead of their location when chatting.

New toys

Reflection mapping (very experimental):

As our renderer moves forward, the previously completely broken static reflections are now in a much better state. When enabled, you’ll be able to glimpse your surroundings in reflective materials, like metal pipes, shiny plastics, and excessively-polished surfaces… Being static, only the stationary geometry present in the map will currently be reflected, yet it’s subtle enough for any discrepancies to not stand out too much, especially in the midst of action. Additionally, all the data for reflections will be saved and loaded from disk as long as you enable caching in graphics settings. The part of the engine responsible for selecting the reflections for each surface has also been improved, bringing with it more correct reflections and large performance improvements.

Material system (very experimental):

Another step towards modernizing the renderer is the addition of material system. On the hardware and drivers that support it, it’ll move a lot of the rendering tasks from the CPU to the GPU, creating a mostly GPU-driven pipeline. While this adds a tiny bit more work to the GPU, it eliminates a lot of the pressure from the CPU, as well as constant back-and-forthes between engine & driver and CPU & GPU. On the more CPU-heavy maps (e. g. ones with bad vis – part of the map file generated by the map compiler to determine which parts of the map should be visible from any point) this can bring more than double the framerate than the core renderer. Being far from complete, a lot more improvements to this system are to be expected.

Reaper is the one behind those impressive jobs being worked on!

To make this new code run, you need OpenGL 4.6 and the ARB_bindless_texture extension. There are, however, still some issues on specific hardware and drivers: everything should work on Nvidia, Material system and frustum culling should work on Mesa (radeonsi for AMD, etc.) when using latest Mesa release (occlusion culling not working yet, expected to crash on non-main driver, and slow otherwise), but proprietary AMD drivers fail due to driver bugs. Some workarounds for these issues are planned, but did not make it into this release.

Gameplay

• Rocket pod range has been reduced: 2000 -> 1300 (62m -> 40m).
• Can no longer de-evolve to the same class exploit refreshing of barbs. Thanks cu-kai.

Entity files

The engine now supports optional entity files. This is particularly useful for maps without a source (there are hundereds of those!). An entity file allows for some customization of how the map entities like doors, elevators or teleporters behave. Extracting the entity descriptions from a map can be done with q3map2, the resulting entity file can be edited with any text editor and is read by the engine when loading a map. The entity file can also be used to tweak how a map’s lighting is applied, resulting in a broader range of options than the dull increase of the gamma value.

Bots

One of the most noticable improvements to bots is that alien bots are now able to extinguish their burning base. Gone are the days when a single firebomb could destroy half of it. The alien bots can also use the advanced granger to reach high platforms and build there. Other improvements are more subtle. Bots can now navigate efficiently on maps of any size, since the tile size of their navigation mesh is now configurable. Mappers may also configure other aspects of their navigation. Bots will also prioritise their targets better now.

An imbalance that made the alien bots inferior to the human bots has been improved upon.

The bots also received some minor improvements and bugfixes. The wall climbing classes climb more reliably now, and the marauder’s walljump is more precise when scaling walls. Human bots now climb ladders even when low on stamina. The tyrant bots will now cancel their charge when they are close enough to their target, which makes it harder to fool them into getting stuck at some obstacle.

More to come!

The 0.55 release is not one with the most of gameplay changes we could do, as the newly released work was strongly focused on the engine. But the development has been very active on gameplay side too. Many gameplay changes ares currently hosted on modded servers, and now that 0.55 is released we want to focus on merging all this goodness.

The 0.54 version already delivered the ability to give “/tactic” commands to bots using the in-game console, we may see a user interface coming for that in future release. By playing on custom servers you may notice bots with new abilities, like them knowing how to use their jetpack! In future releases we may also include new maps and texture sets in the official game. Such maps are playable for a very long time and are very popular, and we may promote them to becoming official assets one day.