vector push_back causes a SIGILL signal on a Nehalem (SSE4.2) QEMU VM
when compiled with GCC 6.1.1.
However, an empty constructor causes illegal instruction exceptions to be
generated on a Windows VM.
So here's an inbetween that looks stupid but works on what I've tested.
patches and cheats are exactly the same (pnach style patch line) but we
stored two sets of them depending on their source: "patches" for
GameIndex.dbf patches, and "cheats" for all the rest (cheats, widescreen,
etc).
Unify patches and cheats and keep only "patches", cleanup and rename the
public API at Patch.h, and add documentation.
Also: add some console messages on invalid "place" value, and when we skip
searching cheats_ws.zip because a pnach file was found at cheats_ws dir.
Also: removed checks before applying different kinds of patches/cheats
because we don't need them (we didn't have disabled patches loaded anyway).
The checks removal _shouldn't_ have any effect, except that the checks were
wrong and accidentally prevented loading widescreen hacks which have a place
value of 0. No one probably noticed it since all the widescreen patches
which I looked at have a place value of 1. So now ws patches with place=0
would load correctly too. If we'll ever have such.
This commit doesn't change any behavior, but documents the "places" value
of the patch structure ("place" is 1 in patch=1,... and 0 in patch=0,...)
and also uses an enum to make its use explicit.
If cheats are enabled and loaded (pnatch files from the cheats folder, or
from the cheats_ws folder, or from cheats_ws.zip), then they were still
applied for some time while rebooting the emulation after a game is already
loaded (e.g. start pcsx2, boot fast, play, boot full). This could cause
the reboot to fail if some patches were applied (e.g. widescreen patches).
It seems that the offending application of the cheats happens at
SysCoreThread::VsyncInThread(), which possibly runs before the config
change event is handled (and re-load the cheats for the current crc).
So reset/invalidate the cheats when the VM is reset.
This should improve issue #851, but ultimately not fully fix it, since
the patches (from games db) are not reset yet with this commit, and we
don't have a function to do so. For now the non-cheats patches are only
reset/reloaded when a configuration change is being handled.
It would probably be a good thing if we can unify patches/cheats.
Not tested
* rumble
Save/load state will be implemented in the next commit
v2:
* Print current deteced pad mode
* fix dpad button tranmission
close#366
Fix#1457 (GTA)
The game uses a depth format for a pure color buffer (cokes do ravage
in gaming industry)
However I'm really afraid that it migth break another effect in other games.
==18373== Conditional jump or move depends on uninitialised value(s)
==18373== at 0x825CC9B: CtrlMemView::render(wxDC&) (CtrlMemView.cpp:277)
==18373== by 0x825DA19: CtrlMemView::paintEvent(wxPaintEvent&) (CtrlMemView.cpp:138)
==18373== by 0x81F3A5F: Pcsx2App::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) (AppMain.cpp:614)
==18373== by 0x40BC50B: wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const (in /usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0.2.0)
==18373== by 0x426C654: wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (in /usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0.2.0)
==18373== by 0x426C752: wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) (in /usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0.2.0)
Reported by gcc too
Fix valgrind issue:
==3560== Conditional jump or move depends on uninitialised value(s)
==3560== at 0x81F7949: CtrlRegisterList::OnDraw(wxDC&) (CtrlRegisterList.cpp:291)
==3560== by 0x47826DE: wxAnyScrollHelperBase::HandleOnPaint(wxPaintEvent&) (in /usr/lib/i386-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==3560== by 0x4785969: wxScrollHelperEvtHandler::ProcessEvent(wxEvent&) (in /usr/lib/i386-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==3560== by 0x426CA0E: wxEvtHandler::SafelyProcessEvent(wxEvent&) (in /usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0.2.0)
==3560== by 0x4710BAE: wxWindowBase::HandleWindowEvent(wxEvent&) const (in /usr/lib/i386-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==3560== by 0x44EF67D: wxWindow::GTKSendPaintEvents(_GdkRegion const*) (in /usr/lib/i386-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
Use portaudio devel build for devel config - it fixes a warning that
occurs due to incompatible linker settings (incremental vs whole program
optimisation)
Also add 64-bit configurations.
I'm not sure to understand why Valgrind reports it as we populate the buffer
during the ReadAsync. Maybe Valgrind doesn't like async IO from the kernel.
In doubt, the init will avoid those warnings
==19897== Thread 6 EE Core:
==19897== Conditional jump or move depends on uninitialised value(s)
==19897== at 0x80FE9E1: BlockdumpFileReader::DetectBlockdump(AsyncFileReader*) (BlockdumpFileReader.cpp:40)
==19897== by 0x8109EE5: InputIsoFile::Open(wxString const&, bool) (InputIsoFile.cpp:229)
==19897== by 0x810939E: ISOopen(char const*) (CDVDisoReader.cpp:57)
==19897== by 0x810194E: DoCDVDopen() (CDVDaccess.cpp:359)
==19897== by 0x80B651C: SysCorePlugins::OpenPlugin_CDVD() (PluginManager.cpp:1219)
It is a pseudo leak as it is a global object. Nevertheless it pollutes
the valgrind log.
v2:
* use an array of unique pointer
* use ArraySize instead of a constant
Gregory Hainaut