Notice. Not affiliated with NVIDIA; NVIDIA, DLSS and the NVIDIA logo are NVIDIA Corporation's trademarks. The bundled NVIDIA runtimes are NVIDIA's property, included unmodified as received, research/educational use only, no warranty, use at your own risk.
Warning
NeuralScreen requires the latest NVIDIA driver. Operation with older drivers or unsupported/non-standard configurations is not guaranteed.
Important
Radeon testers wanted. The AMD build lives in a separate repository, NeuralScreen-AMD, and has not run on a real Radeon yet. Start from native/AMD.md; if it does not come up, attach the diagnostic package (Settings -> Program -> Create diagnostic package).
A hotfix for v1.16.0, which shipped earlier today. One reading was wrong, and one question about the capture could not be answered from a report - both are fixed here.
Fixes
Frame Generation was called "not processing" while NR was off, and it was working. Reported against v1.16.0 (#107). The status line checked the NR switch first and answered "not processing" as soon as NR was off, without ever looking at Frame Generation. That was correct before v1.16.0, when NR off really did mean the pipeline did nothing; after the bypass-path fix the same string became a lie, and a reporter read a working feature as broken. Measured with NR off and FG on from the first frame: [fg] displayed 264.6 FPS (real + generated, 2x). The line now follows the work rather than the switch: NR off with Frame Generation reporting a rate says "frame generation", NR off before the first rate says "frame generation starting", and NR on keeps "processing" because the neural pass remains the larger part of the picture. Both strings exist in all twelve languages, and a test fails if one is missing rather than letting a localized menu show English.
The log could not say which outputs the capture can use. A diagnostic package lists every display driver in the registry, including display-only adapters (Parsec, Cherry virtual displays), which appear there as if they were cards - while the worker enumerates adapters through DXGI, where they never appear. So a package could list a Parsec display and a log mention nothing about it, and "is NeuralScreen capturing the real monitor or the virtual one?" had no answer from either side. The capture path now names every output of the adapter it uses, with the device name and rectangle, followed by a total - and the lines are written before the output is matched, so they appear even when the requested output is not on this adapter.
A test that read the cursor once and checked it seconds later. The suite flake in the taskbar check was not the command dedup the old comment blamed: a traced failure showed the guard emitting nothing at all, so there was nothing to dedupe. The cursor has to be over the taskbar at the moment the message arrives, and the test parked it once at startup. It is now re-parked immediately before every synthetic send, and a park that cannot be made is reported instead of being skipped. Mutations then exposed two places where the test did not check what it named: a step that passed vacuously because Windows refused the foreground change it relied on (caught once in eight runs, now eight of eight), and the cursor condition from #93, which had no coverage at all.
Tests
176 checks: 176 PASS / 0 FAIL / 0 ERROR, GUI-E2E 9 of 9, autocheck all PASS, and the archive, manifest, blobs and documents verified against the tag.
New tests: the status line under every combination of NR and Frame Generation, including the reported one (5 of 5 mutations); the capture output enumeration (4 of 4); and the taskbar check, which now catches the states it previously only described (5 of 5).