Fixes a logic bug I introduced as part of #4942. We were not
handling the "read past EOF" case correctly, which caused
requested_read_length to underflow in some cases.
Also fixes a comparison (though this is unlikely to change anything).
This changes the read request handler to work just like IOS:
* To make things clearer, we now return early from error conditions,
instead of having nested ifs.
* IOS does an additional check on the requested read length, and
substracts the current seek position from it, if the read would
cause IOS to read past the EOF (not sure what the purpose of this
check is, but IOS does it, so we should too).
* The most significant one: IOS does *not* return the requested read
length, or update the file seek position with it. Instead, it uses
the *actual* read length.
As a result of simply doing what IOS does, this fixes _Mushroom Men_.
The game creates a save file, reads 2560 bytes from it, then
immediately writes 16384 bytes to it. With IOS, the first read does not
change the seek position at all, so the save data is written at
offset 0, not 2560. With Dolphin, the read erroneously set the
seek position to 2560, which caused the data to be written at
the wrong location.
Behavior confirmed by comparing IPC replies with IOS LLE and by looking
at the FS module in IOS.
- There's no clear definition of what it means for a GC/Wii game
to be compressed. GC games in GCZ are obviously compressed,
but what about formats like WBFS and CISO that just discard data?
- Hardcoded colors might have bad contrast with the used theme.
- It feels Windows XP to me.
YYCJ is one of the last titles to be completely broken in Dolphin.
It would hang right after the Wii remote screen. Looking at the
game's debug messages reveals that it was failing to find some of
its files.
IOS LLE booted the game just fine, which confirmed that it was an issue
with IOS HLE.
By comparing the ioctlv requests and responses with IOS, it turns out
that one of the very first ES replies was different between IOS HLE and
IOS: there was a mismatch for the content fd returned by ES.
Changing the initial content FD to what IOS returns fixes the issue.
IOS
000000: 00 00 00 08 00 00 00 00 00 00 00 07 00 00 00 09 ................
000010: 00 00 00 01 00 00 00 00 01 38 66 f0 00 00 00 20 .........8f....
000020: 00 00 00 00 00 00 00 00 00 00 00 00 81 36 d3 18 .............6..
000030: 81 36 d3 18 00 00 ff ff ff ff ff ff ff ff ff ff .6..............
Dolphin
000000: 00 00 00 08 06 00 00 00 00 00 00 07 00 00 00 09 ................
000010: 00 00 00 01 00 00 00 00 01 38 66 f0 00 00 00 20 .........8f....
000020: 00 00 00 00 00 00 00 00 00 00 00 00 81 36 d3 18 .............6..
000030: 81 36 d3 18 00 00 ff ff ff ff ff ff ff ff ff ff .6..............
So where did 0x6000000 come from?
4bd5674 changed "Wiimote" to "Wii Remote" in the GUI
(intentionally) but also did the same change for two INI
keys (seemingly unintentional, breaks backwards compatibility,
and is inconsistent with the INI's filename). This commit
reverts the INI keys but not the GUI strings.
This commit uses the same approach as cbd539e used for GameCube
sticks (but I made sure to avoid the bug that 56531a0 fixed).
We (the Microsoft C++ team) use the dolphin project as part of our "Real world code" tests.
I noticed a few issues in windows specific code when building dolphin with the MSVC compiler
in its conformance mode (/permissive-). For more information on /permissive- see our blog
https://blogs.msdn.microsoft.com/vcblog/2016/11/16/permissive-switch/.
These changes are to address 3 different types of issues:
1) Use of qualified names in member declarations
struct A {
void A::f() { } // error C4596: illegal qualified name in member declaration
// remove redundant 'A::' to fix
};
2) Binding a non-const reference to a temporary
struct S{};
// If arg is in 'in' parameter, then it should be made const.
void func(S& arg){}
int main() {
//error C2664: 'void func(S &)': cannot convert argument 1 from 'S' to 'S &'
//note: A non-const reference may only be bound to an lvalue
func( S() );
//Work around this by creating a local, and using it to call the function
S s;
func( s );
}
3) Add missing #include <intrin.h>
Because of the workaround you are using in the code you will need to include
this. This is because of changes in the libraries and not /permissive-
This adds memory values for IOS11, 20, 30, 50, 51, 52, 60 and 70.
Unfortunately, IOS40 (in its working version) is not present on NUS, so
constants for that one are still missing.
This is something I removed by mistake. It didn't break anything in
most titles, but the Mii Channel *requires* write requests to
/dev/usb/kbd to succeed before exiting, so this commit readds the stub.
The latest version has tons of security fixes (which is expected for a
library such as mbedtls).
Updating also allows getting rid of a few deprecation warnings.
Turns out it is completely unneeded and it actually works better
*without* it.
Just try launching the system menu from the HBC; in current master, it
will disconnect the remote and not connect it automatically again. With
this change, it will.
The recent IOS initialization changes caused the Bluetooth device to
no longer exist before "starting" IOS (as it should be…), which meant
that Core could not activate Wii remotes during the boot process
anymore.
But that is actually completely useless, because we can just have the
emulated Bluetooth code itself activate Wii remotes as appropriate,
at the right moment.
