Package Details: pcsxr-pgxp-git 1.9.94.r1731.62467b86-1

Git Clone URL: https://aur.archlinux.org/pcsxr-pgxp-git.git (read-only, click to copy)
Package Base: pcsxr-pgxp-git
Description: A Sony PlayStation (PSX) emulator based on the PCSX-df Project with Parallel/Precision Geometry Transform Pipeline
Upstream URL: http://ngemu.com/threads/pcsxr-pgxp.186369/
Licenses: GPL
Conflicts: pcsxr, pcsxr-pgxp
Provides: pcsxr, pcsxr-pgxp
Submitter: loathingkernel
Maintainer: loathingkernel
Last Packager: loathingkernel
Votes: 5
Popularity: 0.29
First Submitted: 2018-03-05 14:41
Last Updated: 2019-11-26 22:33

Latest Comments

1 2 Next › Last »

loathingkernel commented on 2019-11-28 21:47

@noabody thanks for testing it, I didn't test it at all other than building it to be honest. I have changed it to default to legacy.

noabody commented on 2019-11-26 08:58

fix-pango.patch contains line: +set(OpenGL_GL_PREFERENCE GLVND) Which disables libpeopsxgl.so/cfgpeopsxgl (OpenGL video plugin) in Manjaro 18.1.3

The line should be: +set(OpenGL_GL_PREFERENCE LEGACY) Which allows a native 64-bit build to use the OpenGL plugin.

Running pcsxr from a terminal displays this error (GLVND) as soon as the plugin configuration is selected:

$HOME/.pcsxr/plugins/libpeopsxgl.so: undefined symbol: glXDestroyContext

Regular configuration without a GLVND/LEGACY preference gives this warning:

FindOpenGL found both a legacy GL library:

    OPENGL_gl_LIBRARY: /usr/lib/libGL.so

  and GLVND libraries for OpenGL and GLX:

    OPENGL_opengl_LIBRARY: /usr/lib/libOpenGL.so
    OPENGL_glx_LIBRARY: /usr/lib/libGLX.so

scanelf shows that the GLVND selection doesn't use a combination of libraries that actually contains the necessary symbols. I'm surprised no linker errors occur.

scanelf -l -s glXDestroyContext | grep glXDestroyContext

ET_DYN glXDestroyContext /usr/lib32/libGLX.so.0.0.0 
ET_DYN glXDestroyContext /usr/lib32/libGL.so.1.7.0 
ET_DYN glXDestroyContext /usr/lib32/libva-glx.so.2.500.0 
ET_DYN glXDestroyContext /usr/lib/libwx_gtk3u_gl-3.0.so.0.4.0 
ET_DYN glXDestroyContext /usr/lib/libGLX.so.0.0.0 
ET_DYN glXDestroyContext /usr/lib/libwx_gtk2u_gl-3.0.so.0.4.0 
ET_DYN glXDestroyContext /usr/lib/libgstgl-1.0.so.0.1601.0 
ET_DYN glXDestroyContext /usr/lib/libfltk_gl.so.1.3.5 
ET_DYN glXDestroyContext /usr/lib/libglut.so.3.11.0 
ET_DYN glXDestroyContext /usr/lib/libwebkit2gtk-4.0.so.37.39.2 
ET_DYN glXDestroyContext /usr/lib/libgdkglext-x11-1.0.so.0.0.0 
ET_DYN glXDestroyContext /usr/lib/libGL.so.1.7.0 
ET_DYN glXDestroyContext /usr/lib/libva-glx.so.2.500.0 

I tried to add ${OPENGL_glx_LIBRARY} to plugins/peopsxgl/CMakeLists.txt target_link_libraries but it simply generates another error:

$HOME/.pcsxr/plugins/libpeopsxgl.so: undefined symbol: glDrawPixels

scanelf -l -s glDrawPixels | grep glDrawPixels

ET_DYN glDrawPixels /usr/lib32/libOpenGL.so.0.0.0 
ET_DYN glDrawPixels /usr/lib32/libOSMesa.so.8.0.0 
ET_DYN glDrawPixels /usr/lib32/libGL.so.1.7.0 
ET_DYN glDrawPixels /usr/lib32/libGLX_mesa.so.0.0.0 
ET_DYN glDrawPixels /usr/lib/libOpenGL.so.0.0.0 
ET_DYN glDrawPixels /usr/lib/libOSMesa.so.8.0.0 
ET_DYN glDrawPixels /usr/lib/libfltk_gl.so.1.3.5 
ET_DYN glDrawPixels /usr/lib/libGL.so.1.7.0 
ET_DYN glDrawPixels /usr/lib/libGLX_mesa.so.0.0.0 

Feels like GLVND is just a rabbit hole we don't want to go down.

loathingkernel commented on 2019-08-26 10:15

@avallac_h In this case I am the maintainer of the linux upstream too. Sadly I haven't had the time to look into this. Hopefully in the next few weeks I will have a look, but main upstream is not always available to accept pull requests on time. I will update the package when I have a fix for this issue.

avallac_h commented on 2019-08-10 14:55

Fix build with pango>=1.44.1-1:

diff --git a/PKGBUILD b/PKGBUILD
index 9bb63e2..6806bfc 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -21,6 +21,7 @@ pkgver() {

 prepare() {
   cd "${pkgname/%-git/}"
+  sed -i '/include_directories(${CMAKE_SOURCE_DIR})/a include_directories(/usr/include/harfbuzz)' CMakeLists.txt
   if [[ -d build ]]; then
     rm -rf build
   fi

pegasusearl commented on 2019-04-09 15:22

@loathingkernel the one that doesn't detect 32bit plugins which is to be expected

loathingkernel commented on 2019-04-06 19:27

@pegasusearl, you can modify the PKGBUILD to build for multilib systems. Arch doesn't provide a 32-bit version for ffmpeg though and you will have to build it with lots of its dependencies, as they are mostly aur packages. You will also need to modify the dependencies to their multilib counterparts. Do you care to elaborate how x86_64 affects the audio plugin? Or do you mean that it doesn't detect 32bit plugins which is to be expected?

pegasusearl commented on 2019-04-04 11:19

doesn't detect plugin, the default audio plugin kinda.. uh how do I say it,... I heard there is something to do with 64bit build. How do I build for 32 bit?

Oczkins92 commented on 2018-10-26 09:47

Thanks man!Finally i can normally play psx game without low perfomance

loathingkernel commented on 2018-07-18 19:01

FFMpeg support has nothing to do with OpenGL, FFMpeg is used for cdaudio decode and playback mostly, that is why it is optional too.

Here it works correctly, ie it builds and runs the OpenGL plugin as expected. I can't know why it can't find OpenGL from the partial log you posted. Please post the full build log in a gist or pastebin and link it here.

chrispaul commented on 2018-07-18 16:43

So then why is the OpenGL video plugin missing??? Its there on Void Linux but not on Arch derivatives...