On some systems creating the entire set of available pipeline states is very time consuming. We'll only use a few of them in any given program, so we'll just create them on demand.
Fixes https://github.com/libsdl-org/SDL/issues/7634
Add missing guards around use of physicalInputProfile.
Add explicit import of Foundation which seems to be needed on some
systems to get the NSArray definition.
Add __unsafe_unretained to ObjC types in struct so the compiler doesn't
complain about that not being allowed with ARC.
Closes: #8979
We either need to explicitly test using the sRGB colorspace or update the tests for HDR10 color conversion. We'll just disable them for now, as these formats aren't commonly used in games.
The renderer will always use the sRGB colorspace for drawing, and will default to the sRGB output colorspace. If you want blending in linear space and HDR support, you can select the scRGB output colorspace, which is supported by the direct3d11 and direct3d12
These originally checked for expected ± EPSILON as logged, but since
commit 880c6939 they check for expected ± max_err, where max_err may
need to be greater than EPSILON for very large expected results like
the ones in exp_regularCases().
Also, EPSILON is so small that the default precision of the %f format
(6 decimal places) would never actually have shown its effect, so log
it in scientific notation instead.
Fixes: 880c6939 "testautomation_math: do relative comparison + more precise correct trigonometric values"
Signed-off-by: Simon McVittie <smcv@collabora.com>
While looking at the other tests in this file, I noticed that instead
of checking for a result in the range of expected ± FLT_EPSILON as I
would have expected, these tests would accept any result strictly less
than expected + FLT_EPSILON, for example a wrong result that is very
large and negative. This is presumably not what was intended, so add
the SDL_fabs() that I assume was meant to be here.
Fixes: 474c8d00 "testautomation: don't do float equality tests"
Signed-off-by: Simon McVittie <smcv@collabora.com>
If the magnitude of the expected result is small, then we can safely
assume that the actual calculated result matches it to 10 decimal
places.
However, if the magnitude is very large, as it is for some of our exp()
tests, then 10 decimal places represents an unrealistically high level
of precision, for example 24 decimal digits for the test that is
expected to return approximately 6.6e14. IEEE 754 floating point only
has a precision of about 16 decimal digits, causing test failure on
x86 compilers that use an i387 80-bit extended-precision register for
the result and therefore get a slightly different answer.
To avoid this, scale the required precision with the magnitude of the
expected result, so that we accept a maximum error of either 10 decimal
places or 1 part in 1e10, whichever is greater.
[smcv: Added longer commit message explaining why we need this]
(cherry picked from commit 880c69392ae10c726fc97f17b6e5e2173f70b62f)
In the Steam Runtime 1 'scout' environment, when compiling for i386
using the default gcc-4.6, Exp(34.125) matches the desired value to the
precision shown in the log (6 decimal places) but is not an exact match
for the desired value.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Sam Lantinga
meyraud705
SDL Wiki Bot
Omar Rashwan
Wohlstand
Joshua Root
Simon McVittie
Anonymous Maarten