Split code in 2 parts
* Base class (GSWndEGL) that implement the core EGL and GL context
* Derived class (GSWndEGL_X11/GSWndEGL_WL) that implement the backend to handle native resources
Note: Most backend code is only useful for GSopen1/PS1 mode. GSopen2 only requires
the AttachNativeWindow implementation
Code is based around EGL_EXT_platform extension that allow to select the platform at runtime.
Note: I think the extension was integrated in EGL 1.5
The X11 backend was mostly converted to XCB
The wayland backend is only a placeholder for future code
I don't know if MS windows is/could be supported with EGL_EXT_platform API
Code validated on Mesa. Proprietary drivers aren't yet tested.
This reverts commit 99180f5afb.
Unfortunately Mint/Arch got segmentation fault in Xlib mutex locking...
Sadly Xlib will be back to thread-unsafe mode.
I'm cooking another solution based on EGL
* prefix remaining member with m_
* Use array for m_effect_id
* Properly Destroy/Close Haptic/Joystick/Game Controller
(except on older SDL versions which are buggy)
Initialise pointers to nullptr, move the LoadLibrary code into the try
block (where it should have been in the first place), and use Close()
to cleanup if an exception occurs. Also initialise/destroy the critical
section in the base class constructor/destructor.
This should avoid resource leaks if an exception occurs.
Instead of creating a separate message function, just reuse what() and
pass the string to the std::runtime_error constructor instead.
Also catch a reference to a std::runtime_error instead, since it'll
allow for simpler cleanup.
Moved a CRC hack to Aggressive that can cause or fix VRAM and RAM spikes.
This way people can switch between each config if they experience problems with either.
Varies on userconfig , game version and maybe hardware.
Added missing CRC game version for GT4 pal.
Note: The issue might be the same on GT3 and GTConcept , the code might
need to be removed for those games as well.
X11 isn't thread safe by default. It make sense in 1990 but it is ugly nowadays.
The trick is that is must called before any X11 function. So the only
safe place is at the start of the main. Pcsx2App::OnInit() is the
sooner that I've found.
Hack was used to remove garbage data rectangles from popping up on screen when objects and characters were added to or removed from the world.
This issue is now being handled by OI_DoubleHalfClear in GSRendererHW.cpp, so the hack is no longe necessary and has been removed.
Moves Resident Evil 4 hack to Aggressive level as it is no longer
required to fix any issues, but does offer a decent speed boost.
Moves The Getaway & The Getaway Black Monday CRC hack to Full level, as the issue can be resolved
when using the OpenGL Hardware renderer.
Fixes an issue where the game will either boot the wrong CDVD source or
fail to boot if the current CDVD option doesn't match the option
specified in the command line.
The legacy version is the version 1.3
The new version is the version 2.0. It would be based on SDL2 only
Distribution information.
If you link wxWidget with SDL, you will need to be sure it is SDL2 or upgrade.
You can build wxWidget with SDL2 with the following trick
export SDL_CONFIG=/usr/bin/sdl2-config
./configure --with-sdl .....
Improved the video mode detection code by also detecting the DVD variant video modes of NTSC & PAL, PSX mode actually make use of these specific variants, as well as the BIOS. Previously, I just had them as a single bios video mode due to laziness. (I know, my bad)
After further research, it seems that these DVD variant modes have their own individual VSync timing values similar to the standard NTSC & PAL video modes, dealing with those timer codes might be essential in getting timing accuracy of the PSX mode games. (I kept it to default NTSC/PAL values for now, interested people can mess with it later)
I had planned to do this before but there some were concerns that two different video modes make use of 0x73 gate in SetGsCrt, which was rather weird (how the heck could two video modes be used in a single param value?)
0x73- DVDPAL ( 720 x 480 @ ??.???Hz)
0x73- DVD480P ( 720 x 480 @ ??.???Hz)
Hence, we had decided to use the CMOD bit from SMODE1 (AKA color subcarrier frequency) to detect whether it's an analog or digital video mode and update the necessary timing values but seems like it's no longer necessary, after further discussions from some PS2 developers, we've come to the conclusion that only DVDPAL is possible via 0x73 in SetGsCrt. (So I assume the DVD480p init possibility was fake info from Blue and those other GSM guys who were reverse engineering the PS2)
Gregory Hainaut