Previously it was saving the display name to the config but trying to restore
according to the friendly name.
Now store and restore according to the "displayName" which is more unique than
"friendlyName" since it includes GUID[s], and handle it consistently as _bstr_t.
Before this patch, when recording Progressive (frame) mode, it recorded all
the frames correctly but set the clip's fps property to 25/29.97, so when
played back it played at half the speed (but was fine when played at double speed).
This patch does not affect the number of frames recorded per second, but rather
only sets the resulting clip fps property to the correct one (double than before).
Also fixes a bug that in a non-managed window in progressive mode, the title
displayed "200%" speed when it should have displayed 100% speed.
Fixes#832
In order to flush data with some delay after save-to-memory-card, the code was
calling sioNextFrame() on each frames (60 times/s) continuously as long as the
emulation is active, regardless if FMC is in use or if memory cards in general
are in use.
Further to that, each call to sioNextFrame calls 8 times into the memory card
plugin even if FMC is not in use, resulting in overall ~500 calls/sec with the
sole goal of facilitating delayed flush after MCD save with folder memory cards.
This patch is a hack to call it once per second instead of 60 per second, but we
need to remove this call completely.
The delayed flush will now happen after 60-120 frames instead of exactly 60.
I'm not sure if it breaks the state of the folderMemoryCard (FMC) or not, but
at least it doesn't hang PCSX2.
Might need followup to make sure the state ends up valid.
What this PR primarily does is to sort out the PAL-E mess.
Some have used PAL-E for Englsh, others for Europa (PAL-M5), and others still for España.
With this PR all PAL-E should refer to English, while the ones referring to Europa have PAL-M5 or something as a code, and the ones referring to España have PAL-S as a code.
Generally only one letter is used for the more common languages; English etc.
So is the case in this PR.
For some PAL-M2 entries in particular, though maybe also for some PAL-M3 entries, there can be 2 or more discs of the same game having this code; it's not necessarily a disc specific code - it only tells how many languages the disc supports.
So is the case in this PR.
Language codes used:
E - English
G - German
I - Italian
S - Spanish
F - French
P - Portuguese
R - Russian
DU - Dutch
NO - Norwegian
SE - Swedish
DA - Danish
FI - Finnish
CZ - Czech
PL - Polish
HR - Croatian
HI - Hindu
When a custom PAL/NTSC frame rate is used, PCSX2 respects it for PAL and NTSC,
but disrespected it for NTSC-progressive mode (used hardcoded 30/60). Fixed.
Also, when a custom rate was used, the console message displayed half the rate
which was configured. Now print the actual rate.
The FPS has been Indicated in Paranthesis whereas Speed would provide the Integer percentage value based on the FPS limit for NTSC, PAL games. (59.94, 50)
Thanks to avih for the suggestions.
This could have caused issues where e.g. Fixed100(59.94) differed from
Fixed100::fromString("59.94") due to precision compilation flags
(the former could, and did on Devel builds, end up with Raw == 5993, which
differs from the value constructed from the string at the ini file,
and then it would be incorrectly identified as a custom rate).
Rounding seems the more likely intention when effectively decreasing the
precision of a value.
Unlikely that we have code which depends on truncating behavior, though not
impossible.
Out-of-bounds memory is no longer accessed if the realloc size is larger.
If reallocation fails, the old memory will not be freed and a memcpy
will not take place.
This should match the Windows _aligned_realloc behaviour, except that an
extra parameter is used.
All refer to memcpy, and only memcpy_fast is used, so there's no point
keeping them.
Also remove the _memset16_unaligned function prototype since there's no
function definition for it.
- It currently fails to detect a 64bit git.
- It currently breaks with a TZ left of the Greenwich meridian.
- The output of git show -s can cause compilation errors pipe to NUL.
- Pipe the two can't find the git command error messages to NUL too.
Both fields are 10 bits but the ~ operation apply on the 32 bits.
Therefore msb bits were always '1' and the condition always false.
Code is only used on the interpreter but it could explain some hangs
* Greatly reduce the number of clut read (factor 10x)
* Avoid to get wrong TEXA texture in the cache.
* Fix "jump depends on uninitialized variable" Valgrind warning.
Fix#748
I try my best to avoid any breakage of DX but please test it too.
* add lengthly comment to explain the format
* Likely reduce the number of shader permutation
* Avoid slow AEM (on GPU)
Expect regressions because TC needs some fixes
v2: fix palette mode
CID 146917 (#1 of 1): Untrusted array index read (TAINTED_SCALAR)
tainted_data: Using tainted variable cdvd.Result[1] as an index into an array mg_zones
CID 146912 (#1 of 1): Sizeof not portable (SIZEOF_MISMATCH)
suspicious_sizeof: Passing argument recConstBuf of type u32 * and argument 131072U /* RECCONSTBUF_SIZE * sizeof (recConstBuf) */ to function memset is suspicious. In this case, sizeof (u32 *) is equal to sizeof (u32), but this is not a portable assumption.
CID 146833 (#2-1 of 2): Division or modulo by zero (DIVIDE_BY_ZERO)
divide_by_zero: In expression this->m_width / this->m_upscale_multiplier, division by expression this->m_upscale_multiplier which may be zero has undefined behavior.
CID 146835 (#1 of 1): Division or modulo by float zero (DIVIDE_BY_ZERO)
50. divide_by_zero: In expression (float)(end - start) / (float)frame_number, division by expression frame_number which may be zero has undefined behavior
CID 146728 (#1 of 1): Buffer not null terminated (BUFFER_SIZE_WARNING)
buffer_size_warning: Calling strncpy with a maximum size argument of 128 bytes on destination array mod.name of size 128 bytes might leave the destination string unterminated
Gregory Hainaut