Update dr_wav to 0.14, adapting to API changes

[musicinmybrain]

Version 0.14.0 of dr_wav 0.14.0 was recently released, with a breaking API change that affects EasyRPG Player.

My motivation for this PR is that I maintain the dr_libs package in Fedora, and our easyrpg-player package is currently built with the system copy of dr_wav – something we want to do whenever possible. I am preparing to update dr_libs to provide dr_flac 0.13.0, dr_mp3 0.7.0, and dr_wav 0.14.0, and I need to either patch dependent packages to work with the new versions (this PR is my attempt to do that), adjust them to go back to using bundled copies (with an explicit justification and upstream issue link), or request and maintain a compat package for the previous versions (preferably not indefinitely).

In dr_wav 0.14, the function drwav_init_ex gains a callback parameter drwav_tell_proc onTell. I added a new GetPosition() method to Filesystem_Stream::InputStream and used it to implement this callback. I think I’ve done this correctly, and tests seem to be passing (assuming I’m running them correctly), but review and testing by someone familiar with the code would certainly be appreciated.

[Ghabry]

Thanks! Looks good to me (and made a quick play test to verify).

(I only added a conditional in case a system-wide installed dr_wav is still 0.13.x, but that one is also not relevant for Fedora obviously)

[musicinmybrain]

Thanks! Looks good to me (and made a quick play test to verify).

(I only added a conditional in case a system-wide installed dr_wav is still 0.13.x, but that one is also not relevant for Fedora obviously)

Thanks! This is a reasonable idea, and it is actually slightly helpful for Fedora, because it means that the patch based on this PR, or a future release containing this PR, could be safely merged back to stable releases (currently, Fedora 41/42) even though the breaking dr_wav update will only be shipped in Fedora Rawhide and released in Fedora F3 and later.

---

Looking at 9345243#diff-665f37409ef2960f9a676f6f9b75ae6423071d6d310b3d2ed8ba99f614180bebR1540,

// EasyRPG modification {
#elif defined(WORDS_BIGENDIAN)
    return DRWAV_FALSE;
// }

it seems like this plumbs in the build system’s endianness check,

Player/CMakeLists.txt

Lines 891 to 902 in 14f9507

	# Endianess check
	if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.20)
	if(CMAKE_CXX_BYTE_ORDER STREQUAL "BIG_ENDIAN")
	target_compile_definitions(${PROJECT_NAME} PRIVATE WORDS_BIGENDIAN=1)
	endif()
	else()
	include(TestBigEndian)
	test_big_endian(WORDS_BIGENDIAN)
	if(WORDS_BIGENDIAN)
	target_compile_definitions(${PROJECT_NAME} PRIVATE WORDS_BIGENDIAN=1)
	endif()
	endif()

but in the case where we are using a system copy of dr_wav.h without the “EasyRPG modification,” we just fall back to

    int n = 1;
    return (*(char*)&n) == 1;

which should give the same result, potentially at the cost of a few extra instructions, or possibly optimized to the same machine code as return DRWAV_FALSE. Therefore, there should be no practical disadvantage to using a system copy without this modification. Am I missing anything?

[Ghabry]

Yeah that EasyRPG modification is not necessary. It works without. We only have it in for our homebrew platforms.

Because you find this commit useful I will split it in two so that "modification" is separate and you can pick the other part easier.

[musicinmybrain]

Thanks! This is great.