Problem with Tribes 2 Visuals - Flickering screen / tearing artifacts
I've been trying to find a fix for a screen tear(?) / map tear(?) issue I've been having in game for the past couple months to no avail
I've had Tribes 2 run on previous computers and current computer fine with no problems at max settings, min settings, fullscreen, windowed, and honestly anything in-between. I can't pinpoint whether it was a Windows Update (Win10), Driver Update, some gamefile update via Tribes Next, or a broken installation (which has been both uninstalled and reinstalled, as well as repaired) with no fixing of the issue. I was wondering if any of the system or graphics gurus of the forums would be able to assist me with finding a possible fix for this as it may be an unknown issue just popping up recently that others have come to deal with
I did also learn that I had 2 installations of Tribes 2 on my computer, both in separate drives and both uninstalled just to be sure one wasnt messing with another. I've also changed settings in my graphics card program (AMD/Adrenalin) relating to OpenGL, as D3D does fix the issue but the game runs at around 15 frames at any given moment.
Any help would be appreciated, especially for others who may be experiencing this but dont have an account to post about it.
Edit literally after posting because I just remembered: This only appears after a certain height is reached either in spectator mode or in character; below that specific threshold, everything is fine
Comments
Sorry, I'd fixed this last year when the problem was introduced in AMD's beta drivers and given it out to a few people who'd asked... but must've neglected to get the info up here as I'd assumed AMD were going to make changes before they pushed the new code to the stable release channel. They had just done a new freshly rewritten OpenGL implementation (which does have some improved performance), but unfortunately introduced a problem with how the rewritten version of an extension behaves, wherein the artifacts you're seeing manifest in Tribes 2 immediately after the first time the game attempts use of it, and continue regardless of it being disabled afterwards until the context is destroyed.
Specifically, when the driver reports support of the "EXT_compiled_vertex_array" OpenGL extension, the game enables portions of the code that try to use it; nominally "locking" to indicate that the driver should cache the transform results of the currently active vertex array for subsequent draw calls (where those vertices are being used for multiple passes e.g. fog, damage decals, shiny environment maps on players), then "unlocking" when done. This in itself actually works as intended on the elements it's being used to render -- although there'd be no performance benefit to speak of using it on modern cards with the very limited number of vertices being processed here -- but the problem is that any use of this extension whatsoever is persisting something in the context state, affecting later draw calls it shouldn't ever be touching. You can see a clearer version of what's happening to those vertices if you open the editor and look at object outlines flipping around.
Short version: there's an unnecessary OpenGL extension that isn't working with the current AMD video drivers.
A permanent fix will go in with some other QOL things planned in the near future, but for the moment you can just drop the attached script file in your
GameData/base/scripts/autoexec/directory:Cool, thank you! I'm honestly not surprised it was possibly an AMD only kind of thing and had a sneaking suspicion that it was some OGL Rendering issue through our cards.
Glad it is just as simple as a script edit, though sucks that it's not a fix AMD has already gotten around to but I'm assuming most people probably didnt run into the artifacts in other older game as they dont play or just didnt have the issue at all
Had some help adding an AMD check so it can be distributed. I only have an nvidia card, so my testing isn't comprehensive...
YMMV depending on the caching setup in the driver's OpenGL implementation, but there's unlikely to be a measurable performance benefit to leaving the compiled vertex array extension enabled under modern GPUs from any vendor. Transform matrix calculations are extremely trivial common parallel operations in the render pipeline, and on most cards from the past maybe 15 years or so it's not entirely outside the realm of possibility the minor overhead in using this extension at all actually exceeds the potential time saved due to the (very) limited number of vertices being processed - particularly if it introduces CPU-GPU sync points handling memory before proceeding with each batch. These aren't vertex buffers persisted between frames, it's effectively just a system for multiple subsequent draw calls on the same data to reuse computations of where the vertices are ultimately going to be projected on your screen... and the game generally isn't actually written to take advantage of this, nor to even use multi-pass rendering at all where multi-texture blending is possible to be used instead.
It may still be of benefit to cards from the fixed-function pipeline era, but even there, I wouldn't necessarily expect much difference.
Makes sense. I wonder if it's possible to benchmark the performance difference. I thought that playing back a demo would be a good way to measure, but that does have slightly different codepaths to a real instance of the game, so maybe two benchmarks per card would be required.
I thought I was being tricky when I found $pref::OpenGL::disableEXTCompiledVertexArray = 0; setting gOpenGLDisableCVA to false. Then I realised that gGLState.suppLockedArrays is used in a few spots where gOpenGLDisableCVA isn't checked.
Eh, properly benchmarking something like this (and most optimizations on a coupled fixed pipeline GL renderer in general) would be a bit of an impractical mixed bag: the function calls and OpenGL driver ops constituting the added overhead are on the CPU, the potential benefit could only be observed with GPU timing, and any potential added sync points blocking could muddy whether it's helping at all. The standard "fps" variables in the game aren't appropriate for profiling use; they're reflecting an eased representation of the (very) approximate CPU time between each loop iteration, with very limited direct relationship to render times.
It is technically possible to hook in better timers, and to profile the actual time spent on the card producing a frame by adding GL timer queries, but it's honestly not worth the effort for this case: spitballing it I'd have to guess the extension would be within margin of error on there being no difference whatsoever. Can't honestly say I've tested them on anything that would bother with them though, I only noticed the issue with the extension because I was replacing their calls to facilitate the use of modern-ish VAO/VBOs.
Assuming on a ten year old integrated gpu you'd be looking at saving at most a few nanoseconds per vertex, even best case doing multiple draw passes and re-using say 2 of 3 cached transforms on hundreds of meshes (generally being a few hundred verts) you'd save maybe a few dozen microseconds per frame... and that's if the driver has a well designed implementation working as intended.
CVA is very much a mid-90s optimization which today could conceivably qualify as a micro-optimization for games of this era if following the use pattern as follows:
For everything other than the terrain however, what's attempted when using multi-pass rendering is:
As you can imagine... the latter pattern isn't going to do anything useful, so it's effectively only being used on terrain. And while the terrain is by far the heaviest part of the game to render, it's predominantly due to time spent on the CPU, with the visible polygons being procedurally generated and resubmitted every frame, and software blending of all textures and shadows that haven't yet been cached. With late 90s hardware and multi-pass this is absolutely where I'd be using CVA and any other optimizations available to make it work, but these days the course correction is to reduce that CPU usage as much as possible and let the GPU do the work instead, and that's been the general goal in my own progress with improving the renderer.
With T2 (and most classic games), neither the time spent on the GPU nor bus speed is realistically ever going to be the bottleneck on modern hardware, particularly not to the point of needing to save microseconds. If it's not rendering fast enough, it's in almost every case because it's waiting on the CPU side. Granted, the game doesn't start drawing to the back buffer at all until after the sim is calced and the scene images are sorted (i.e. you're striking up to a few milliseconds from your frame budget off the bat), but even after that point the driver's only able to queue up the state changes and commands to be submitted to the GPU at the rate they come in from the main thread, so it's ultimately constrained on how quickly it can produce a frame -- it's being drip-fed the data it needs, completing its work and spending most of its time idle.
Howdy gents, searched high and low for a solution for this... Running an OG install of Tribes 2 here. However, after dropping the file in the directory, I'm still getting artifacts in OpenGL and D3D runs like garbage. Any suggestions? For one brief moment - I get no artifacts. Then the HUD goes all glitchy and the rest follows.
Running an AMD 7900 XTX with latest drivers... And this did not start happening until the OpenGL driver rewrite.
P.S. I noticed a file called disableLockedArraysChecked.cs.dso already in the directory. Any ideas?
You'll need have the TribesNEXT patch installed for this script to have any effect.
Ah thanks! I got the Patch from Downloads and applied it to my existing game. I hope it was OK that I applied it to a patched up OG game install (had si_tribes2_update_21570-24834_25034 installed). Seems to have taken, cheers!
Yep, as long as the game's updated 25034 it's golden. Any QOL work is based on reverse engineering the main binary, so it just requires that specific version of the game as the vanilla base.
For the moment it can be a little bumpy to set up if you run into issues like this one, but I do intend to put together a new install package to fix and simplify things when there's enough free time.