This should fix a bunch of STFSes that previously claimed an encryption
key was missing because they were unable to decompress LZX data correctly.
TODO:
- Create a SparseDiscReader instead of reading the entire file into memory.
- Handle non-contiguous files. (Unlikely in packages; more likely in
save files.)
Sonic the Fighters has a value '3', which isn't defined in Xenia's enum
for ACB. Rework it such that G=0,1; PG=2,3; M=4,5; MA15+=6,7.
TODO: Need to verify this with more titles.
These are supposed to use the "hybrid metadata pointer", but some older
DLLs have a separate machine type instead.
EXE_PE.cpp: Change "CHPE" to "CHPEv1".
Fixes#439: Missing ARM64 machine type IMAGE_FILE_MACHINE_CHPE_X86
Reported by @pivotman319-owo.
This caused asserts when using libstdc++ debug mode.
wiiu_application_types: "Game Update" should be after "Game DLC".
This broke "Super Smash Bros. for Wii U (USA) (Update)".
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_algo.h:1970:
In function:
_FIter std::lower_bound(_FIter, _FIter, const _Tp&, _Compare) [with
_FIter = const LibRomData::WiiUData::WiiUApplicationType*; _Tp =
unsigned int; _Compare =
LibRomData::WiiUData::lookup_application_type(uint32_t)::<lambda(const
LibRomData::WiiUData::WiiUApplicationType&, uint32_t)>]
Error: elements in iterator range [first, last) are not partitioned by the
predicate __comp and value __val.
Objects involved in the operation:
iterator "first" @ 0x7fffffffc578 {
type = LibRomData::WiiUData::WiiUApplicationType const* (constant iterator);
}
iterator "last" @ 0x7fffffffc570 {
type = LibRomData::WiiUData::WiiUApplicationType const* (constant iterator);
}
disc_publishers_noregion: Three disc publishers were out of order.
This broke "NES REMIX (USA)" and "NES REMIX 2 (USA)".
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_algo.h:1970:
In function:
_FIter std::lower_bound(_FIter, _FIter, const _Tp&, _Compare) [with
_FIter = const LibRomData::WiiUData::WiiUDiscPublisher*; _Tp = unsigned
int; _Compare = LibRomData::WiiUData::lookup_disc_publisher(const
char*)::<lambda(const LibRomData::WiiUData::WiiUDiscPublisher&,
uint32_t)>]
Error: elements in iterator range [first, last) are not partitioned by the
predicate __comp and value __val.
Objects involved in the operation:
iterator "first" @ 0x7ffc13befb38 {
type = LibRomData::WiiUData::WiiUDiscPublisher const* (constant iterator);
}
iterator "last" @ 0x7ffc13befb30 {
type = LibRomData::WiiUData::WiiUDiscPublisher const* (constant iterator);
}
Remove lblCredits from the .ui file and create it manually after creating
the QComboBoxes. This eliminates the need to use setTabOrder(), which
wasn't working properly when trying to set lblCredits to after the final
QComboBox that was created by createComboBox().
FIXME: Tab ordering still has the label itself as a tab stop, in addition
to the two links...
d->pvr3Header hasn't been initialized at this point.
This broke when PowerVR3 was extended to handle PowerVR 2.0 textures.
Most PowerVR3 files are little-endian, so the usual case of x86/amd64/arm
wouldn't have caused a problem. On PowerPC, the files weren't detected.
This fixes a regression from commit f5a099d169.
([librptexture] PowerVR3: Preliminary support for PowerVR v2.0 files.)
This fixes ImageDecoderTest's PowerVR3 tests.
Affects: v2.4 - v2.4.1
Also, un-indent PowerVR3Private.
This was already done in the GTK and KDE UI frontends, but not in
Win32, which results in PSP Minis showing a gigantic banner because
they have a 310x180 background image that's used as a banner.
Also, remove RP_ShellPropSheetExt_Private::rescaleImage(). This was
copied to DragImageLabel in commit c234c6cf36
([win32] DragImageLabel: Copied image sizing, including rescaleImage(), to DragImageLabel.)
because it was still used for the banner code, but was never removed.
NOTE: Prior to DragImageLabel, the banner was unconditionally resized
to 96x32. This would have prevented the giant image issue, but it's
the wrong aspect ratio for PSP Minis. (310x180 -> 55x32)
Also, icons were previously unconditionally resized to 32x32, which
usually works, unless something has a non-square icon.
Fixes#433: [Bug Report] The ROM type is not displayed correctly for some PSP Mini ROMs
Reported by @xxmichibxx.
Affects: v1.5 - v2.4.1
This somehow managed to mostly work on Windows 7, and even for a while
on Windows 10. Starting with commit 59c3d23285
in v2.4, opening the ROM Properties tab would usually crash for EXE/DLL
files due to the Import and/or Export tabs, which have RFT_LISTDATA.
I wasn't able to reproduce this in any Debug builds, but it showed up on
Windows 10 in Release builds with MSVC 17.6.5. The effects were seemingly
random, depending on what code I moved around; sometimes it'd crash, other
times it'd cause the column titles to show up as garbage. Using a TCHAR[]
buffer instead of a tstring seemed to have fixed the problem, until the
garbage titles showed up. (This merely moved the problem around due to
the stack layout.) Making the TCHAR[] buffer static made the problem
worse, since it *removed* stuff from the stack.
In the end, the problem was really very obvious once I saw it. Disabling
LvData's sorting functions caused everything to "just work". When I looked
at the functions, I saw Header_GetItem() called immediately after the
HDITEM variable was declared. HDITEM, like LVCOLUMN, has a mask field which
*must* be filled in for both Set and Get. Otherwise, it might try reading
text into whatever's in HDITEM::pszText, which is likely the cause of the
crashes. The garbage text could be explained by somehow getting through
Header_GetItem(), only to have garbage text set by Header_SetItem().
Fixes#432: [Bug Report] EXE/DLL files causes a crash
Reported by @xxmichibxx.
Affects: v2.4 - v2.4.1 (Windows only), but it's entirely possible that
older versions could have random glitches as well.
Main differences between NUS and extracted formats, besides packaged
being in .app files and extracted being extracted:
- Extracted might not have ticket and/or TMD.
- Extracted should have the three XML files. Note that certain titles
*might* be missing some of the XMLs; this will need to be checked
later.
- Extracted doesn't have an FST content, so everything that checks
for FST presence has been updated to not check for FST.
- WiiUPackagePrivate::open() still checks for an FST in NUS format.
- WiiUPackagePrivate::open(): For extracted format, open the file
directly using RpFile and the package path.
Fixes#430: Add support for extracted WiiU games
Requested by @Masamune3210.
RP_ExtractImage::Load() needs to return E_FAIL, not S_OK, if the directory
is unsupported. Otherwise, Windows will show a regular directory icon,
without thumbnailing the directory's contents.
Fixes#427: No Thumbnails after install
Reported by @Conan179.
Specify -DENABLE_NIXOS=ON to enable the workarounds.
- Using CMAKE_INSTALL_PREFIX in paths causes a double-path issue.
This only seems to happen on NixOS.
- std::locale's constructor ends up calling getdents64(), so this
syscall needs to be whitelisted. Only on NixOS though, since other
Linux distros don't need it...
Fixes#406: Building on NixOS returns "invalid system call"
Reported by @Whovian9369.
I used a test image from an old version of Angry Birds for iOS,
which uses the ABGR4444 pixel format.
TODO:
- Support compressed formats.
- Test more uncompressed formats.
- Handle vertical flip.
"Magical Hat no Buttobi Turbo! Daibouken" has a ROM title encoded using
JIS X 0208 instead of Shift-JIS. This is a 7-bit double-byte encoding.
iconv doesn't seem to support JIS X 0208 directly, but if converted to
EUC-JP by setting the high bit on each byte, it can be decoded as EUC-JP.
Windows also supports EUC-JP as Code Page 20932. (Tested on Windows 7.)
A simple heuristic is used to determine if the title is potentially
encoded as JIS X 0208: The first character must be between 0x21-0x24,
and all characters must have the high bit unset.
This fixes title decoding for "Magical Hat no Buttobi Turbo! Daibouken".
- Before: "$^$8$+$k%O%C%H$N$V$C$H$S%?!<%\!*BgKA81"
- After: "まじかるハットのぶっとびターボ！大冒険"
This also affects "Madagascar (R)", which appears to have the exact same
title in the ROM header.
[libromdata/tests] Update MegaDrive test results.
[librptext] conversion.hpp: New wrapper function cp1252_sjis_jisx0208_to_utf8().
conversion_iconv.cpp, conversion_win32.cpp, cpN_to_utf8():
- If TEXTCONV_FLAG_JIS_X_0208 is specified, use the JIS X 0208 heuristic
before attempting Shift-JIS decoding.
Some early Wii Utitles use CA04-XS09 and CA04-CP0a, which matches the
3DS dpki issuer. At some point between OSv9 and OSv10, these were
changed to CA04-XS0f and CA04-CP10. Both sets of issuers use the same
debug keys.
Analogue Pocket is mostly GBC-compatible, but it has a different header
logo and some different register definitions. For our purposes, the only
difference that matters is the header logo.
This broke when rp_image was switched to shared_ptr<> because img and
iconAnimData are no longer in a union.
write_IDAT_APNG(): Check iconAnimData instead of img.
This fixes a regression from commit 44689d0aa8.
([librptexture] rp_image: Use shared_ptr<> instead of RefBase.)
Affects: v2.3
initString(): For RFT_STRING_MULTI, count newlines for *all* strings
instead of just assuming 0 newlines.
initStringMulti(): Pass nullptr instead of _T("") so initString() will
actually count newlines.
updateMulti(): Convert from Unix newlines (LF) to DOS newlines (CRLF).
Fixes#416: Win32 UI frontend: Localized multi-line strings aren't displayed correctly
(was: Line feeds not working in descriptions for GameCube titles with BNR2 banner)
Reported by @rctgamer3.
NETTLE_FOUND may be used to determine if libnettle should be
linked to other libraries and/or executables.
This fixes a regression from commit 22189ea4db.
([cmake] CheckNettle2or3.cmake: Convert the macro to a function.)
This fixes a seemingly-empty ListView for e.g. Win32 export/import tables
and a bunch of assertions in the debug build.
Initialize hListView (and optionally pField) in the LvData constructor
using explicit constructor arguments.
RP_ShellPropSheetExt_Private::updateMulti(): Check for a non-NULL pField
instead of hListView, since hListView is always set now.
It *may* have been introduced in commit 8cf01a10a3.
([win32] RP_ShellPropSheetExt: Initial RFT_LISTDATA sorting functionality)
Affects: v1.8 - v2.2.3 (Windows only)
Fixes#413: Exports/Imports table in win32 shell ext page showing blank rows
Reported by @ksharperd.
This broke the "Convert to PNG" menu item, since it was returning *false*
if the scheme matched "file".
This fixes a regression from commit 70cf0687ab.
([gtk] Split common stuff from NautilusMenuProvider and ThunarMenuProvider into MenuProviderCommon.c.)
Affects: v2.2.1 - v2.3
Debian 8 has GTK+ 3.14.5, so this caused the build to fail.
Check for GTK+ [3.15.8, 3.21.5). If it's anywhere in that range,
use gtk_popover_set_transitions_enabled(); otherwise, don't.
On LE, we need to rotate the channels value right by 8 bits.
On BE, we need to rotate the channels value *left* by 8 bits.
Remove be32_to_cpu() and adjust the SWZ_CH_? values to use the big-endian
values (B=3,G=2,R=1,A=0) on both BE and LE.
This fixes the following (and only) test failures on RomHeaderTest
on Debian 8 on PowerPC (via qemu):
[ FAILED ] 3 tests, listed below:
[ FAILED ] DDS_Blender/ImageDecoderTest.decodeTest/DDS_Blender_tex_cmp_bc3nm_dds_gz_Image, where GetParam() = DDS_Blender/tex_cmp_bc3nm.dds.gz
[ FAILED ] DDS_Blender/ImageDecoderTest.decodeTest/DDS_Blender_tex_cmp_bc3rxgb_dds_gz_Image, where GetParam() = DDS_Blender/tex_cmp_bc3rxgb.dds.gz
[ FAILED ] KTX2/ImageDecoderTest.decodeTest/KTX2_luminance_alpha_reference_u_ktx2_gz_Image, where GetParam() = KTX2/luminance_alpha_reference_u.ktx2.gz
The byteswapping code was checking for SYS_LIL_ENDIAN, which means it
was only compiled in on little-endian systems, not big-endian systems.
The le*_to_cpu() macros are no-ops on little-endian systems, so it
didn't cause a problem on LE, but it broke on BE.
This fixes the following (and only) test failures on RomHeaderTest
on Debian 8 on PowerPC (via qemu):
[ FAILED ] 4 tests, listed below:
[ FAILED ] DreamcastSave/RomHeaderTest.Text/BIOS002_VMS, where GetParam() = BIOS002.VMS
[ FAILED ] DreamcastSave/RomHeaderTest.Text/SONIC2C_VMS, where GetParam() = SONIC2C.VMS
[ FAILED ] DreamcastSave/RomHeaderTest.JSON/BIOS002_VMS, where GetParam() = BIOS002.VMS
[ FAILED ] DreamcastSave/RomHeaderTest.JSON/SONIC2C_VMS, where GetParam() = SONIC2C.VMS
This *usually* didn't cause any problems when using Windows Explorer,
but Directory Opus appears to do its own subclassing. The end result
is Directory Opus crashes when selecting the rom-properties tab in
file properties.
NOTE: Since it's a dialog procedure, it needs to return FALSE instead of
calling DefWindowProc, and definitely not DefDlgProc.
As per MSDN: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-defdlgprocw
The **DefDlgProc** function must not be called by a dialog box procedure;
doing so results in recursive execution.
Fixes#405: Crash when used inside Directory Opus
Reported by @Kugelblitz360.
kdeinit6 doesn't exist, but we can check KDE_SESSION_VERSION instead.
This variable has been set since KDE 4.
Without this change, rp-config would always use the KF5 version on
KF6 because it couldn't find any matching kdeinit process.
TODO: Only check KDE_SESSION_VERSION instead of checking processes?
NEWS.md: Mention this.
There's a bit of weirdness with Intellivision due to its unusual word
size. The General Instrument CP1610 is a 16-bit CPU, but uses 10-bit
opcodes. Because of this, Mattel used 10-bit ROMs. Some of the fields
in the ROM header use 16-bit addresses, split up into two 10-bit words.
The ROM file uses 16-bit big-endian for words, so in order to decode
these addresses, we have to take two 16-bit big-endian values, read
the low 8 bits of each, and combine it into a 16-bit value.
NOTE: ROM images must have a .int or .itv file extension, since the
Intellivision ROM header doesn't have a magic number.
On GTK3 at least, "standard sorting" is case-insensitive. This may or
may not be changed in future versions, so implement it ourselves.
sort_funcs.c: New function sort_RFT_LISTDATA_standard().
Some SDK tools generate save files with no icon or comment. The icon
or comment addresses in this case is 0xFFFFFFFF.
Also, split the comment code into a separate function, getComment().
Based on loadFieldData()'s version, which has a union+struct to
separate the desc and file sections.
Reported by RedBees.
ARM64EC was added at the same time as general amd64 emulation in
Windows 11 build 21277 (actually 21262, a leaked build).
On Windows 10, don't register for either amd64 or arm64ec.
See #398: Installing on ARM64 shows an error that the AMD64 version
of the DLL couldn't be registered
Reported by @kristibektashi.
On Windows 10, only install for amd64 if using build 21277 or later,
since that's when amd64 emulation was added.
Fixes#398: Installing on ARM64 shows an error that the AMD64 version of
the DLL couldn't be registered
Reported by @kristibektashi.
Instead of requiring each RomData subclass (GameCube, PSP, etc.) to
explicitly handle various sparse disc formats, have RomDataFactory
check for sparse disc images itself. That way, if one is found, the
appropriate SparseDiscReader subclass can be opened and the disc read
as if it's a flat disc image.
Among other things, this adds support for ZISO and PSP CISO formats
for PS2 loaders. It also technically allows those formats to be used
for GameCube and Wii disc images, though it doesn't make much sense.
Tested by converting a GameCube disc image to multiple formats,
including GameCube CISO, GCZ, PSP CISO, JISO, ZISO, and DAX.
Fixes#397: Could you add support for PS2 ISO's compressed to zso and cso?
Reported by @60fpshacksrock.
hMyKey was never destroyed in the CTR path; only the ECB and CBC path.
Also: s/EBC/ECB/
Not too noticeable, since this would only show up if a user attempted to
view an encrypted Nintendo 3DS ROM image on Windows XP. (On Windows Vista
and later, AesCAPI_NG is used instead.)
There's no way to wait for the user to select the "ROM Properties"
section, since NautilusPropertiesModel is an abstract model, not an
actual GtkWidget.
This CPU type is used by the old MSVC for Mac.
0x01F2, the CPU type for Xbox 360, is now "PowerPC (big-endian; Xenon)".
FIXME: Subsystem version on the test DLL is "1024.32768". Byteswapping
this results in "4.128", which is still not quite right. Import and
export tables aren't showing up either, which probably means some
fields are in big-endian that are normally in little-endian.
Fixes#396: PE machine value 0x0601 == PowerPC big-endian (classic Mac)
Reported by @Wack0.
It was incorrectly using the battery-backed PRG RAM size for both
fields.
Also, show PRG RAM before CHR RAM for consistency with PRG ROM and
CHR ROM.
Found using ubsan:
src/libromdata/Console/NES.cpp:1079:24: runtime error:
shift exponent -1 is negative
This has been broken since NES 2.0 PRG RAM fields were added in
commit 6e9206b03e.
([libromdata] NES: Added NES 2.0 PRG RAM fields.)
Affects: v1.1 - v2.2.1
Re-generated the NES test files.
The table needs MD_IOSH_* values, but a few were using MD_IO_*:
- Team Player
- Light Gun
- Activator
- Tablet
- Paddle
Re-generated MD, 32X, and Pico test files.
NOTE: Some Pico games have 'V' (Paddle), which doesn't make sense because
the Pico doesn't have a detachable controller...
Found using ubsan in RomHeaderTest:
src/libromdata/Console/MegaDrive.cpp:307:15: runtime error:
shift exponent 52 is too large for 32-bit type 'unsigned int'
This fixes a regression from commit 7fe699aae4.
([libromdata] MegaDrive::parseIOSupport(): Use an index-based lookup table.)
Affects: v2.0 - v2.2.1
