Also ENABLE_OPENMP in appveyor.cmd.
Note that it doesn't actually do anything right now, since we're not
doing OFF/ON builds in AppVeyor anymore due to taking too long and
timing out after 1hr.
Note that the ASTC container parser is still available even if ASTC
decoding is disabled, since it can at least get metadata, e.g. the
image dimensions.
This broke reading RPFs because the range-based `for` loop did not skip
the first entry. The original iterator version *did* skip the first entry.
This reverts commit d1b8a1e99e.
Affects: v2.4 - v2.4.1
It seems 32-bit ARM NEON doesn't have 128-bit vtbl instructions.
TODO: Figure out if this is in fact the case, and it's not just
MSVC rejecting the intrinsics for 32-bit ARM.
TODO: Actually test the 32-bit ARM version.
TODO: uint8x8x4_t for 32-bit, and uint8x16x2_t for 64-bit?
There's currently only one flag defined:
RP_CPUFLAG_ARM_NEON == CPU supports NEON
RP_CPU_Flags_arm_Init() currently initializes RP_CPU_Flags_arm to
RP_CPUFLAG_ARM_NEON on arm64 and 0 on arm.
...except on Windows, which *requires* NEON on ARM.
TODO: OS-specific NEON detection for 32-bit Linux and others.
Nothing in this file is useful on non-x86 CPUs.
It may have made sense to only protect the flag definitions if the file
would be used for more than just x86, but we're better off using separate
files for different CPU architectures.
NOTE: Don't skip the GTEST_SKIP() if GTEST_FLAG_GET(brief) is set.
GTEST_SKIP() will print a "Skipped" message, which can be annoying,
but the test will be marked as PASSED instead of SKIPPED if we don't
skip it.
It's only supported by glibc on Linux (and possibly some of the BSDs),
and it adds a lot of complexity. The regular C dispatch functions only
have a few instructions of overhead in most cases.
Adding ARM NEON would have complicated things:
- 32-bit ARMv7: Needs a check on Linux and Android; on Windows, it's
guaranteed to be present.
- 64-bit ARMv8: Always exists.
For ARM64 only at the moment.
Tested on my Pixel 8 Pro:
Android 15, arm64, clang-19.1.7, release build, no LTO
16-bit C unalign0: 61ms
16-bit NEON unalign0: 21ms
16-bit C unDWORD: 48ms
16-bit NEON unDWORD: 21ms
32-bit C unalign0: 27ms
32-bit NEON unalign0: 20ms
32-bit C unQWORD: 27ms
32-bit NEON unQWORD: 23ms
16-bit C unalign2: 44ms
16-bit NEON unalign2: 21ms
32-bit C unalign4: 27ms
32-bit NEON unalign4: 23ms
NOTE: The 32-bit C unalign4 test was disabled for some reason.
I re-enabled it now.
TODO:
- Add the ARM NEON functions to the dispatch functions.
- Add support for 32-bit ARMv7. (Requires runtime deteciton!)
- Test the MSVC build.
Added a length parameter, with -1 indicating C string.
Add checks to remove the trailing NULL byte when using C strings.
A2U8(): Added an std::string wrapper and the length parameter.
Can't use librpfile because it causes rp-download to pull in
fmt-11.dll.
With this fix, rp-download no longer depends on fmt-11.dll.
TODO: Make a common "Mini U82T" header for anything that needs
these functions.
This gets rid of rp-download's libfmt.so dependency on Linux, though
the Windows build is still pulling in fmt-11.dll for some reason.
Note that only a single fmt::format() invocation was used...
This effectively reverts commit dab0cc4c08.
([libcachecommon] Use libfmt instead of printf()-style functions.)
..except for the fprintf() to fputs() change in FilterCacheKeyTest.cpp,
which was kept.
Added a new static library rptext-noi18n that lacks formatting.cpp.
[rp-download] Link to rptext-noi18n on Windows.
This gets rid of the libgnuintl-8.dll dependency, but something is still
pulling in fmt-11.dll. Specifically, it's pulling in this function:
fmt::v11::vformat
NOTE: This function is also being pulled in on the Linux build...
Since adding DependentLoadFlags, rp-download no longer runs on Win10 1607+.
rp-download's text output is for debugging only, so just revert all of the
libfmt changes and go back to printf().
rp-download currently has two incorrect DLL dependencies:
- fmt-11.dll
- libgnuintl-8.dll
Not sure why it's depending on libgnuintl-8.dll, since nothing's being
localized here.
fmt-11.dll is still showing up as a dependency, even though rp-download
no longer uses it.
This reverts commit c5017c5fb0.
Conflicts:
src/rp-download/rp-download.cpp
For Tracker v1, add a date object, which takes a time_t directly.
For Tracker v2 and v3, use the set_gvalue() function with a GValue
that has a GDateTime object added to it.
Tested with a ColecoVision ROM image (ReleaseYear) and a GameCube
save file (CreationDate).
NOTE: GCN save file should probably be "ModificationDate", but that
property isn't present in KDE. Not sure if it's present in Windows
or KDE...
Besides having better error checking, glibc's atol() is simply a
wrapper around strtol() anyway. (Unsure about MSVC, but it's
probably similar.)
Among other things, with _ttol(), "-xJ" would end up being interpreted
as "-x0", since _ttol() returns 0 for an invalid number.
[lcoale] es.po, pt.po: Remove incorrect localizations for this code.
This ensures UTF-8 is decoded properly.
Tested on Windows XP (where it doesn't work), Windows 7 (works), and
Windows 10 (works). Not tested on Windows Vista, but I think it
should work there.
NOTE: The console output codepage is persistent, even after the program
exits. An atexit() handler is registered to restore the original console
output codepage.
std::string_view has less overhead than std::string, since it doesn't
have to copy the whole string.
CMakeLists.txt: TODO: Does CHECK_CXX_SOURCE_COMPILES() ignore
CMAKE_CXX_STANDARD? Need to test this on a gcc version that
supports C++17 but not by default.
