Coverity:
CID 147021 (#1 of 1): Uninitialized scalar field (UNINIT_CTOR)i
2. uninit_member: Non-static class member m_handled is not initialized in this constructor nor in any functions that it calls.
A couple of useless members were removed too.
Also fix wnd initialization
Coverity:
CID 146955 (#1 of 1): Uninitialized pointer read (UNINIT)
18. uninit_use: Using uninitialized value wnd[i].
Coverity:
CID 146816 (#1 of 1): Calling risky function (DC.STREAM_BUFFER)
dont_call: fscanf(FILE *, char const *, ...) assumes an arbitrarily large string, so callers must use correct precision specifiers or never use fscanf(FILE *, char const *, ...)
Coverity:
CID 146846 (#1 of 1): Dereference after null check (FORWARD_NULL)
5. var_deref_model: Passing null pointer fp to fclose, which dereferences it
Without this patch, if a user initiates a recording and then cancels at the GSdx
dialog, the audio was recording anyway, which is probably highly unexpected.
However, while probably highly unexpected, it could still be useful to record
only audio, but with this patch it's now impossible.
We can reconsider if it turns out that people are actually using this "feature",
though one might as well set the video setting to be very unobtrusive (very low
resolution/bitrate) such that it uses very little CPU.
This is the internal resolution which GSdx uses and recording at this resolution
is optimal, i.e. without any dumb scaling, with all relevant pixels and without
redundant pixels.
The resulting clip still doesn't have the correct aspect ratio set, but that's
just a property which can be set to the clip afterwards, which is where the DAR
becomes useful. Since it's usually anamorphic, when muxing later with the audio
use the DAR to set the playback aspect ratio.
Fixes a cmake detection problem when compiling with clang (3.7.0 in my
case). clang outputs the error "Invalid argument '-std=c++11' not allowed
with 'C/ObjC'", which causes lzma, Xext and other things to be
considered "not found".
gsdx changes:
Remove native resolution checkbox from GUI and rework associated code
Small changes to Windows and Linux GUI
Support 8x native resolution
Fix custom resolution width less than native width use case
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.
This fixes the following issues when custom resolution is selected.
- When the width is smaller than the native resolution width, the
texture cache targets are removed on every Vsync signal, causing a
black screen issue.
- The texture cache code needs a 1 returned for the custom resolution
upscale multiplier or there'll be some really funny graphical issues.
It also removes unnecessary GetConfig (which I think unconditionally
does a a file read on Windows) calls if the width was increased - the
upscale multiplier is already stored, and the custom resolution width
and height calls are now unnecessary.
Also fix some whitespace issues.
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.
Gregory Hainaut