wxWidgets 3.0 seems to have a different default device context alpha
channel handling on Windows, which makes the screenshot function
unusable.
As a incomplete fix, remove the alpha channel information from the final
image on Windows. Screenshots degrade slightly.
Visual Studio flags wxCore30 as being out of date because it can't find
the rcdefs.h header file. Use the arch dependent pathname so it is
located correctly.
The "Other Hacks" and "microVU Hacks" checkbox descriptions are
truncated in both Windows and Linux. Use sizer flags so the descriptions
show up properly.
The custom scroll event handler increments/decrements the slider value
by one when a click event is detected. It also propagates the event to
the wxWidgets3.0 built in slider scroll event handler, which repeats the
same action. This causes the slider to add/subtract 2 whenever it is
clicked on Windows.
Remove the custom function.
The code was restoring the defaults with hardcoded values. This patch
restores the values however they're defined as defaults for AppConfig.
The code still uses hardcode values to set the highlights (bold) of the
default radio button text - using SetDefaultItem.
Note that other than these two panels, the speedhacks panel is the only other
which has a restore-defaults button, and it already does so programatically.
It's probably not worth trying to unify these three restore-defaults button
into a single system.
Intially GSBlendStateOGL was an alias of the m_blendMapD3D9 array
The object was replaced by an index in the array. Save 2k of memory duplication.
And too much useless code.
v2: push/pop blending state in DATE stuff
v3: remove m_state which is useless now
I used to disable the RT but it doesn't work well with 50cents. It seems
texture writes weren't propagated correctly to the depth buffer. Besides
the game write an alpha value whereas depth is 24 bits only...
Commit message edited by Gregory.
Comment below from Jonathan Li
On my system, /dev/input/event13 (evdev interface) and /dev/input/js0 (joystick interface) correspond to the DS3 on my system. User/group ownership are both root.
With /dev/input/event13 at 0640 and /dev/input/js0 at 0644 - SDL2 detects no pad, SDL1 detects a 19 button, 27 axis pad
With /dev/input/event13 at 0666 and /dev/input/js0 at 0644 - Both SDL1 and SDL2 report a 19 button, 4 axis pad.
SDL2 only uses the evdev interface, SDL1 uses the evdev interface but if that fails, it uses the joystick interface.