Miles crashed trying to do sample rate conversion on a wave file – possibly a file with incorrect headers, but I've played every sound included with the game without seeing a problem. A wave format with 32-bit samples could cause this, or just a corrupt/partial file on disk.
Interestingly though this part of the Miles mixer code doesn't actually get used for most gameplay sounds anymore specifically because it has issues processing ADPCM samples. It should only still be in use in looping environmental emitters and microphone playback. Do you remember what map this was on to see if it was an issue with one of the files used for its background audio?
It's possible to remove use of this resampler entirely in a later update if it still has issues.
There is a specific issue that some of us have experienced where the game will "stutter" when zooming. The issue can be described as:
1) Press the zoom key
2) Brief stutter, where the game freezes (half a second at most)
3) Then everything continues fine.
I would generally say that this is occurring once per zoom for a specific direction. For example, if I face a specific direction, and I zoom + stutter, and then I go back to normal view, and then I immediately press zoom again without moving, I will not stutter again. In other words, it's like the game has to take time to briefly load something. However, once loaded, everything is okay.
However, the moment you move again or face another direction, you'll stutter again when zooming. I also feel this is more impactful with maps with a larger viewing distance.
All of the above said, after experimenting with various settings, I believe I narrowed it down to the Textures => Terrain Texture Detail slider. If I put the slider all the way to the right for the max value, then I experience the above issue. However, if I move the slider slightly to the left, then the zoom issue completely disappears. I attached a screenshot with my setting. I'd make a recording, but it'd be impossible to tell when I'm actually pressing the zoom key.
At least two other people were experiencing this same issue, and making this adjustment seems to have fixed it for them as well.
Oh, that's mipmap generation on dozens of baked terrain sector tiles being generated and selected all in the same frame. It wasn't meant to be left on, I was tuning the detail scaling while writing the new terrain renderer.
If you have a modern gpu you can try enableHybridTerrain(1); for now to bypass the OG baked texture blending and do the composition realtime on the GPU.
I used to be able to change my audio source in t2 on the fly by minimizing and selecting audio source through speaker in taskbar but now after the patch this no longer works. The audio will switch in Windows but remain the same in Tribes. It's sort of annoying cause sometimes I like to start playing with my speakers then put my headphones on when I get on Discord comms.
Thanks. I confirm that running enableHybridTerrain(1); fixes the issue, even when I have Terrain Texture Detail at maximum.
Follow-up: Is there any advantage to setting enableHybridTerrain(1); vs not? I ask, because if so, I'll just script it to turn on when I start T2 each time.
(Piggyback: I also have the same issue as fnatic's last post about the audio source. It would be nice if there was a "default" option, where it just defaulted to whatever windows is using. The biggest issue is that, after you join a match, you can't change the audio source again. You have to quit T2 fully, and then select the source before rejoining.)
enableHybridTerrain moves the bulk of the terrain rendering work from the CPU to the GPU.
The original renderer generates all of the terrain geometry you see on screen on the CPU dynamically every single frame, and the textures you'd see were all software blended and cached in memory, combining each material and the lightmaps for large areas in batches of what blocks are expected to be visible. The patch by default already accelerates terrain rendering with a number of optimizations and replaces the software blender with a faster GPU implementation of the same process, but at its heart it still works the same way; every time terrain is rendered, a stack of new meshes are generated and submitted to the GPU, textures are generated if not in the cache, and the higher the view distance and tiles needed, the more work the CPU needs to do, the more memory needed, the more state changes and data communicated to the GPU, and dozens if not hundreds of draw calls depending on enabled features. It's not always the biggest blocker per frame, but it can consistently lock up the main thread for a few milliseconds on a larger map or with a slower CPU.
The hybrid terrain renderer generates a single grid mesh on the CPU and saves it in GPU memory, and only submits new textures (materials, the height map, light maps, or splat maps) when that data changes. This essentially means when terrain needs to render, the CPU only needs to submit a minimal amount of changed state data per frame (e.g. dynamic lights), and can render the entire terrain in one or two draw calls. The GPU does the work of calculating the height of each vertex, and combining the various textures on the fly every frame. Because a modern GPU can do this work in parallel extremely fast, it should almost always be faster than the traditional renderer on newer hardware. On iGPUs with shared memory and older systems though, it's not a sure thing, especially on the version included in that release.
It'll need to be optimized further and certain features used shortcuts that aren't available on all drivers for the earlier pass – the cutouts for empty holes for example may or may not work on your system. Once that's done it'll be added to the options menu somewhere, but if it appears to work fine now, it's fine to use. Running the command sets a client pref, so you don't necessarily need to add the command elsewhere, although opening the editor would currently disable it and require running the command again.
I believe the Miles output selection was an issue with an old API it selected automatically, I'll have to check the startup code for it again
Comments
Miles crashed trying to do sample rate conversion on a wave file – possibly a file with incorrect headers, but I've played every sound included with the game without seeing a problem. A wave format with 32-bit samples could cause this, or just a corrupt/partial file on disk.
Interestingly though this part of the Miles mixer code doesn't actually get used for most gameplay sounds anymore specifically because it has issues processing ADPCM samples. It should only still be in use in looping environmental emitters and microphone playback. Do you remember what map this was on to see if it was an issue with one of the files used for its background audio?
It's possible to remove use of this resampler entirely in a later update if it still has issues.
@Krash
There is a specific issue that some of us have experienced where the game will "stutter" when zooming. The issue can be described as:
1) Press the zoom key
2) Brief stutter, where the game freezes (half a second at most)
3) Then everything continues fine.
I would generally say that this is occurring once per zoom for a specific direction. For example, if I face a specific direction, and I zoom + stutter, and then I go back to normal view, and then I immediately press zoom again without moving, I will not stutter again. In other words, it's like the game has to take time to briefly load something. However, once loaded, everything is okay.
However, the moment you move again or face another direction, you'll stutter again when zooming. I also feel this is more impactful with maps with a larger viewing distance.
All of the above said, after experimenting with various settings, I believe I narrowed it down to the Textures => Terrain Texture Detail slider. If I put the slider all the way to the right for the max value, then I experience the above issue. However, if I move the slider slightly to the left, then the zoom issue completely disappears. I attached a screenshot with my setting. I'd make a recording, but it'd be impossible to tell when I'm actually pressing the zoom key.
At least two other people were experiencing this same issue, and making this adjustment seems to have fixed it for them as well.
Oh, that's mipmap generation on dozens of baked terrain sector tiles being generated and selected all in the same frame. It wasn't meant to be left on, I was tuning the detail scaling while writing the new terrain renderer.
If you have a modern gpu you can try
enableHybridTerrain(1);for now to bypass the OG baked texture blending and do the composition realtime on the GPU.I used to be able to change my audio source in t2 on the fly by minimizing and selecting audio source through speaker in taskbar but now after the patch this no longer works. The audio will switch in Windows but remain the same in Tribes. It's sort of annoying cause sometimes I like to start playing with my speakers then put my headphones on when I get on Discord comms.
Thanks. I confirm that running
enableHybridTerrain(1);fixes the issue, even when I have Terrain Texture Detail at maximum.Follow-up: Is there any advantage to setting
enableHybridTerrain(1);vs not? I ask, because if so, I'll just script it to turn on when I start T2 each time.(Piggyback: I also have the same issue as fnatic's last post about the audio source. It would be nice if there was a "default" option, where it just defaulted to whatever windows is using. The biggest issue is that, after you join a match, you can't change the audio source again. You have to quit T2 fully, and then select the source before rejoining.)
enableHybridTerrain moves the bulk of the terrain rendering work from the CPU to the GPU.
The original renderer generates all of the terrain geometry you see on screen on the CPU dynamically every single frame, and the textures you'd see were all software blended and cached in memory, combining each material and the lightmaps for large areas in batches of what blocks are expected to be visible. The patch by default already accelerates terrain rendering with a number of optimizations and replaces the software blender with a faster GPU implementation of the same process, but at its heart it still works the same way; every time terrain is rendered, a stack of new meshes are generated and submitted to the GPU, textures are generated if not in the cache, and the higher the view distance and tiles needed, the more work the CPU needs to do, the more memory needed, the more state changes and data communicated to the GPU, and dozens if not hundreds of draw calls depending on enabled features. It's not always the biggest blocker per frame, but it can consistently lock up the main thread for a few milliseconds on a larger map or with a slower CPU.
The hybrid terrain renderer generates a single grid mesh on the CPU and saves it in GPU memory, and only submits new textures (materials, the height map, light maps, or splat maps) when that data changes. This essentially means when terrain needs to render, the CPU only needs to submit a minimal amount of changed state data per frame (e.g. dynamic lights), and can render the entire terrain in one or two draw calls. The GPU does the work of calculating the height of each vertex, and combining the various textures on the fly every frame. Because a modern GPU can do this work in parallel extremely fast, it should almost always be faster than the traditional renderer on newer hardware. On iGPUs with shared memory and older systems though, it's not a sure thing, especially on the version included in that release.
It'll need to be optimized further and certain features used shortcuts that aren't available on all drivers for the earlier pass – the cutouts for empty holes for example may or may not work on your system. Once that's done it'll be added to the options menu somewhere, but if it appears to work fine now, it's fine to use. Running the command sets a client pref, so you don't necessarily need to add the command elsewhere, although opening the editor would currently disable it and require running the command again.
I believe the Miles output selection was an issue with an old API it selected automatically, I'll have to check the startup code for it again