Enable r_lightGridPreload by default or expose it in menu

[wiibur]

This took a lot of searching to find, but r_lightGridPreload defaulting to zero was causing massive frametime spikes on my system that far exceeds the recommended specs. Enabling the preload caused a negligible increase to the up-front loading time and made the game enjoyable to play. This setting is covered in the documentation, but it took me a while to find and I almost gave up. Consider enabling the preload by default to avoid this potential stutters, or at the least expose this setting in the menu so users can find it more easily when troubleshooting performance issues. Thanks!

[themuffinator]

The setting should have been easier to find. Streaming is still a useful default on memory-constrained hardware, while your result shows that preloading can be much better on systems where first-use atlas uploads cause visible pauses.

#152 adds Settings > Display > Post FX > Preload Light Grids. Its localized help says that it smooths area changes at the cost of longer loads and more video memory, and that the change applies on the next map load. r_lightGridPreload remains available in the console, and the default remains off.

The extra row is covered by the Settings registry and localization tests, and its expanded full/compact scroll ranges keep the display-sizing controls below it reachable. I also rendered the Post FX pane through the engine screenshot path and exercised map startup on OpenGL and Vulkan. I’ll close the discussion when the PR lands.

[themuffinator]

The discoverable preload option has now merged in #152. I’m closing this as implemented. It will be available in the next build from current main under Settings > Display > Post FX > Preload Light Grids.

[wiibur]

Thanks for taking this under review and implementing it, but you should enable this by default since modern systems incur only a negligible performance impact when loading the map, but the stutters when not using preload are VERY disruptive to gameplay. The whole point of this project is playing this game on modern systems that are more than capable of running the game.

[themuffinator]

Thanks for following up. I looked into why streaming hitches, and found two things.

• The memory cost is small. On the maps that ship a packed light grid, a map's full set of light-grid atlases is at most about 26 MiB, with a median of around 10 MiB. Streaming also never unloads what it has loaded (r_lightGridResidencyFrames defaults to 0). So once you've walked a map, streaming holds about as much memory as preloading would.
• Streaming loads on the main thread. When a new area comes into view, its atlases are read and uploaded right there, with no per-frame budget. On maps whose grid ships as a pack (airdefense2 and the multiplayer maps), each read also seeks inside a compressed pk4 entry. That seek decompresses the pack from its start up to the area's data, so an area costs more the further into the pack it sits.

The second point is a problem in its own right, and it also makes preloading slower than it needs to be, so it's worth fixing at the source. Until then, Settings > Display > Post FX > Preload Light Grids (r_lightGridPreload 1) is the right setting for anyone who sees these hitches.

[themuffinator]

Following up on this properly � you were right to push back, and the situation has changed since you wrote that.

When you reported the spikes, streaming really was expensive, and not for the reason I assumed. The light-grid packs ship deflated inside pak1.pk4, and every packed atlas was being read with an open-plus-seek on the pack. Seeking inside a deflated ZIP entry means reopening it and inflating from byte zero, so each of an area's three atlases paid for its own offset in the file. On game/airdefense2 (18.6 MiB, 29 areas) a single area cost up to ~200 ms, and walking into a spot that revealed several areas at once held a frame for half a second. That is exactly the disruption you described.

That was fixed on 18 September (97fb3ea). The pack is now read once, sequentially, into memory, and every atlas comes from that copy. Measured by teleporting through every area of a map, three interleaved runs per side:

	before	after
airdefense2, streaming � worst frame in the tour	491 ms	23 ms
airdefense2, streaming � slowest area	169 ms	4 ms
airdefense2, preload � total	3,948 ms	84 ms
q4dm1, streaming � worst frame in the tour	434 ms	21 ms

On OpenGL the read now happens while the map is loading, so the first area to come into view does not pay for it at all.

So the honest answer to "why not default it on" is that the gap it was closing has mostly closed by itself. Preloading is now ~84 ms instead of ~3.9 s, and streaming's worst frame is ~23 ms instead of ~491 ms. Defaulting to preload would still spend memory that constrained machines need, to buy a difference that is now near the noise floor on a system like yours.

I would rather have your measurement than my reasoning, though. If you get a build from current main and streaming still stutters for you, please say so here and I will flip the default � you found the original problem, and if there is a second one left I would like to know.