== DETAILS
So, basically this back-and-forth is because we used fixed-size
data types (i.e. `uint32_t`) which maps to different primitive data
types on different platforms. So `uint32_t` might be a `long` on some
platforms (e.g. Wii U), while it's just a plain integer on others (PC).
And the format specifier works off primitive data type, not data type
size.
So, to resolve this, we:
- keep `%lx` as the format specifier
- cast the parameter to printf to unsigned long
This is better than the alternatives that could cause problems trying to
cast a long down to an int.
== DETAILS
These changes fall into a few broad categories:
1. Explicitly undefine things we want to re-define due to conflicts with
the version of devkitpro we're using
2. Clean up hex format specifiers to use `%lx` or `%lX` when working with
long integers
3. Move variables inside the ifdef they're used in to squelch "unused variable"
messages
4. Add parenthesis to make Wii U shader declarations stop complaining
And then there's a weird "misleading indent" warning that I fixed by just
rewriting a block of code to use a switch statement instead of if-then-else.
These changes work fine on Wii U, but we'll need to keep an eye on CI/CD to see
if other platform builds break.
* Fix for warning and fix for incorrect comment
* Fixed contrast to be more correct - now scales from 0-10 linearly and behaves more the way you'd expect it to - changed name to ditch legacy settings users may have
Added ability to skip inverse tonemapper to the shader via the constant buffer using 'inverse_tonemap' - set to 0.0f to skip
Fixed potential bug when swapping between hdr and sdr and the bit depth not being set correctly
Fixed dx11's blend, rasterizer and topology states not being set to the sames when using hdr and leaving the menu - caused issues with PCSX2's Shadow of the Colossus
Added numerous helper functions to help create the correct values to colour the UI - normally the white UI elements should be rendered at paper white not max brightness for various reasons
* Fix stylistic issues - * Don't use camelcase for variables and function names * Use '(void)' for function declarations instead of () in C code * Declare variables at the top of a function or code block * Make sure functions that return a value always have a default return path that is not encapsulated by an else block * Use more unique names for retro_math functions which are less likely to overlap with other libraries' function symbols
Co-authored-by: twinaphex <libretro@gmail.com>
twinaphex