Fixes the edge case where a texture is reusable but has modified usage
parameters (e.g., `GL_TEXTURE_WRAP_S`). Prior to this change, texture
parameters would be cached permanently until the texture was recreated.
Fixes#1034
There is no requirement that a surface and texture using the same VRAM address
match with respect to size (in particular pitch). This change prevents
incorrect reuse of a surface binding in the event that the texture size does
not match.
Fixes#1127
Interprets the value written to the `NV_PVIDEO_STOP` register in a manner more
consistent with hardware. Specifically, if the low bit of the value is not set,
the PVIDEO overlay should remain active.
Fixes#1049
[Test](https://github.com/abaire/nxdk_pgraph_tests/blob/main/src/tests/pvideo_tests.cpp)
Note that, as this is testing video behavior, this test is interactive and
the value passed to the final SetPvideoStop call needs to be mutated and the
behavior observed.
ds_dx and dt_dy describe how the PVIDEO content should be scaled to fit the
output area. Each is calculated via `((in - 1) << 20) / (out - 1)`, this
commit calculates the full frame scale (in / out) and applies that when
determining the texture coordinates for the overlay.
`NV_PVIDEO_SIZE_IN` is set to 0xFFFFFFFF during initialization and teardown
of the PVIDEO overlay. In some cases this can happen before the overlay is
explicitly stopped, leading to an assert. On hardware SIZE_IN values larger
than SIZE_OUT are capped (content is not scaled).
Fixes#330
[Test](https://github.com/abaire/nxdk_pgraph_tests/blob/main/src/tests/pvideo_tests.cpp)
This code was added ~7 years ago in
[this commit](97be3f5986)
From what I can see from the [HW test results](https://github.com/abaire/nxdk_pgraph_tests_golden_results/wiki/Results-Fog_coord_vec4)
the behavior on nv2a is more subtle than the cited `NV_vertex_program`
documentation.
In practice the register more or less retains its value until it is explicitly
modified.[The test](4cff2b2ebe/src/tests/fog_tests.cpp (L432))
renders something with an explicitly set oFog.x, then renders again with a
shader that does not modify oFog.x but references it in the pixel shader. The
value carries over rather than being forced to 1.0.
Interestingly, this test is apparently not hermetic; running the other
vec4_coord test (that explictly set various components of oFog) lead to unusual
behavior where the fogging effect is not uniform across all vertices, despite
never being set. Even more interestingly, re-running the test once it's in this
state will often produce variations as to which vertices are apparently using
a stale/incorrect fog value.
wutno