| Age | Commit message (Collapse) | Author |
|---|
|
Ranges Algorithms Modernization - Trivial
|
|
|
|
Ranges Algorithms Modernization - N
|
|
Ranges Algorithms Modernization - Find
|
|
The inequality operator is automatically generated by the compiler if `operator==` is defined.
|
|
In BTEmu.cpp, `std::mem_fn` was not necessary for the predicate to compile.
|
|
In VolumeVerifier.cpp, constructing a `std::string_view` of the volume's GameID is unnecessary, as `std::`(`ranges::`)`binary_search` supports heterogeneous lookup. The usage in GameFile.cpp is a perfect example.
|
|
|
|
|
|
+ a surprise `std::memcpy` in VolumeVerifier.cpp.
|
|
This runtime assertion was added before `std::is_sorted` became constexpr in the codebase.
|
|
|
|
A vector of length 0 can have a null data pointer, which causes UB when
passed to memcpy, so only copy when we actually have data to copy. This
caused crashes in certain cases when compiling Dolphin with Clang and
LTO enabled.
|
|
|
|
|
|
This lets us reduce the number of USE_RETRO_ACHIEVEMENTS ifdefs in the
code base, reducing visual clutter. In particular, needing an ifdef for
each call to IsHardcodeModeActive was annoying to me. This also reduces
the risk that someone writes code that accidentally fails to compile
with USE_RETRO_ACHIEVEMENTS disabled.
We could cut down on ifdefs even further by making HardcodeWarningWidget
always exist, but that would result in non-trivial code ending up in the
binary even with USE_RETRO_ACHIEVEMENTS disabled, so I'm leaving it out
of this PR. It's not a lot of code though, so I might end up revisiting
it at some point.
|
|
The offset-based overload hasn't been in use since
f754a1a548f2e599e4cc2d1d799f2d21b520076f.
|
|
Bugfix for hardcore-disabled items being disabled when hardcore was true but achievement integration was false, which should mean hardcore is effectively disabled. Now everything checks the IsHardcoreModeActive method in AchievementManager which processes the setting AND the game state to determine if hardcore mode is actually active.
|
|
We can retrieve the encompassing system instance through the
CPUThreadGuard instance instead.
|
|
The main interface for these only take in patches and iterate over them
in a contiguous sequence, so we can reasonably generify the interface.
|
|
Memory patches would be an easy way to manipulate the memory needed to calculate achievement logic, so they must be disabled. Riivolution patches that do not affect memory are allowed, as they will be hashed with the game file.
|
|
|
|
|
|
A deep-copy method CopyReader has been added to BlobReader (virtual) and all of its subclasses (override). This should create a second BlobReader to open the same set of data but with an independent read pointer so that it doesn't interfere with any reads done on the original Reader.
As part of this, IOFile has added code to create a deep copy IOFile pointer onto the same file, with code based on the platform in question to find the file ID from the file pointer and open a new one. There has also been a small piece added to FileInfo to enable a deep copy, but its only subclass at this time already had a copy constructor so this was relatively minor.
|
|
Keeping the pointer creates use-after-free opportunities, and we don't
have much reason to keep it around anyway.
|
|
CMake: Allow ignoring system packages
|
|
|
|
|
|
|
|
Common/StringUtil: Move some utilities into the Common namespace
|
|
DiscIO: Improve comments in WIARVZFileReader::Convert
|
|
|
|
Just some clarifications and typo fixes.
|
|
ESCore implements the core functionality that can also be used outside of emulation. ESDevice implements the IOS device and is only available during emulation.
|
|
|
|
|
|
|
|
system if possible.
Fixes https://bugs.dolphin-emu.org/issues/13138
|
|
|
|
|
|
DolphinQt: Properly lock CPU before accessing emulated memory
|
|
|
|
This fixes a problem I was having where using frame advance with the
debugger open would frequently cause panic alerts about invalid addresses
due to the CPU thread changing MSR.DR while the host thread was trying
to access memory.
To aid in tracking down all the places where we weren't properly locking
the CPU, I've created a new type (in Core.h) that you have to pass as a
reference or pointer to functions that require running as the CPU thread.
|
|
CMake: Actually use the include directories specified by dependencies
|
|
This is a cleaning followup for #11456.
|
|
|
|
Obsoletes these functions in favor of the standard member functions
added in C++20.
|
|
get rid of HAS_STD_FILESYSTEM
|
|
This should be a fairly easy merge, assuming I didn’t mess anything up. TL:DR no one uses it and it’s not great.
Boot from DVD Backup is an ancient feature with origins in the Megacommit. Back then, GameCube and Wii games were quite large relative to drives of the time. For example, in 2008, the most common hard drive sizes were 320GB and 512GB. On the 320GB drive I personally had at the time, as little as 42 Wii ISOs could have filled it entirely! And that’s ignoring any other files one might want to put onto a drive. Backup DVDs allowed users to burn relatively cheap DVD media and store their GameCube and Wii dumps in a Dolphin accessible way that didn’t eat into their precious HDD space. It had compromises, even then, but in 2008… I mean honestly users probably wouldn’t even notice those compromises with how Dolphin barely even worked at all back then.
Obviously, today the storage space concerns are not as big of an issue. According to seagate the average hard drive it sells today is 8TB. For typical laptops purchased now, the -minimum- selection for storage is usually 1TB. You can even buy a name brand 4TB external hard drive for $100. GC and Wii ISOs are not as big as they once were, relatively anyway. Plus flash drives and SD cards are super cheap and way faster than disc drives ever were. For anyone that has limited drive space, removable flash media can fulfill this offloading role far better than backup DVD media ever could.
Also no one has DVD drives anymore. That’s kind of an important detail.
But to see if Booting from DVD Backup even still worked, I decided to give it a try. I have an ASUS BW-16D1HT, a badass Bluray XL reading and burning drive, connected to my Windows 11 Threadripper 5975WX machine. A super fast drive on a super fast machine is as good as it possibly can get for this feature. So I bought a spindle of DVD-Rs, burned a couple of discs and gave it a try. Surprisingly, it does still work. However, as expected, it introduces a lot of stuttering. Testing Prime 1 and Prime 3, in both games stuttering was introduced whenever the DVD Drive had to suddenly seek. Spikes of 50ms occurred constantly, but I observed 150ms and even over 1000ms stutters! The worst was a three second stutter, when loading Elysia in Prime 3. I could even hear the stutters - any time the drive suddenly made a harsh seeking noise, the game would have a hard stutter. It worked but, it has some serious compromises.
Boot from DVD Backup isn’t great, using removable flash media or external hard drives is a FAR better option for anyone with limited storage space today, and no one can even use this feature anymore because their computers don’t even have disc drives. It’s time for Boot from DVD Backup to go!
So I did my best on the cleanup but I’m bound to have left some bits. Especially in translation - I didn’t get any warnings or anything there that could help point me to where to clean that up. Please review!
|
|
just use std::filesystem
|
