The data is still unit-aligned, but it's no longer XMM-aligned.
This tests the "before and after" code for non-XMM-aligned data.
Code coverage changes:
Before:
lines......: 22.8% (10415 of 45634 lines)
functions..: 22.9% (896 of 3907 functions)
After:
lines......: 22.8% (10415 of 45634 lines)
functions..: 22.9% (896 of 3907 functions)
This *should* have improved coverage, but something's being weird...
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.
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.
NOTE: Crowdin's .rc script commits take all the non-string data from the
source file, rp-en_US.rc. This means other languages won't have custom
dialog sizing. I'll have to merge those manually for now.
TODO: Make the dialogs automatically resize somehow? Or, just move all
of the strings to the .po files?
These are reduced to 8-bit for ARGB32.
ImageDecoder_ETC1.cpp: Renamed decodeBlock_ETC2_alpha() to
T_decodeBlock_EAC() and templatized the byteOffset parameter to allow
it to be used to decode alpha (regular), or R or G (EAC).
FIXME: Still need to figure out why NPOT S3TC textures are screwy.
I'm not sure if this is specific to the Godot 4 version or if it happened
with Godot 3 textures, too.
