We don't have any interfaces that rely on the c++ abi. Makes our builds more portable.
Means that our builds in Sniper can be used on games that are still forcing the old C++03 string abi.
FEX would like clean symbols for experimenting with making thunks down the line.
We also just shouldn't be exporting a bunch of random crap -- sadly -fvisibility=hidden doesn't help with a bunch of stuff :(
For reference, RADV also does this.
Viewport depth range in D3D9 is clamped at 0-1, same as OpenGL.
Drivers like RADV, etc support VK_EXT_depth_range_unrestricted,
which makes the regular UB of this actually work -- which isn't what
we want.
We also don't enable VK_EXT_depth_range_unrestricted, so we shouldn't
be setting depth ranges outside of the 0-1 bounds anyway.
Closes: #2960
This may reduce internal fragmentation with very large resources.
We previously changed behaviour to not do this in order to reduce memory
pressure in the average case, however by trying to suballocate from existing
chunks and falling back to a dedicated allocation on failure, rather than
allocating a new chunk, we can mostly avoid that situation.
When Vertex declaration is created by CreateVertexDeclaration
and SetFVF is not called then GetFVF returns 0.
This code change implements mapping of D3D declarations to FVF mask
and sets it if FVF was not set previously.
During the translation of the Crs opcode to SPIR-V there is an assumption that the result type is a composite type. This is not always true. If the result is a scalar type the translation adds an OpCompositeConstruct with a scalar result type. This is a spec violation.
This change checks if the result type is a composite type and does not add the OpCompositeConstruct in case of scalar types.
Doesn't appear to match Windows behaviour, but there may be scenarios
when we can't query the current monitor. Statistics still need to be
consistent in this case.
See #2933.
This is a bit embarrassing. Added this config few days ago to counter the animation breakages, but now Return of Reckoning devs patched the executable on their side to cap the framerate by default. So the workaround is not needed anymore.
