GBM Video Driver - Retro Gaming - Tinkering Image Howto

[MysteryScience]

Hi all fellas,

First of all thanks for this amazing guide from @AreaScout

I have a problem trying to compile reicast into the odroid XU4, I thinks is because the lastest changes in the makefile and maybe the sources code.

When I run this the instruction (after applying the patch manually, because its failed chunck 2 and 3)

Code: Select all

platform=odroid ARCH=arm make -j7

i got to this part

Code: Select all

gcc    -marm -mfloat-abi=hard -DNO_ASM -DARM_ASM -frename-registers -ftree-vectorize -mcpu=cortex-a15 -mtune=cortex-a15.cortex-a7 -mfpu=neon-vfpv4 -mvectorize-with-neon-quad -c  -frename-registers -fno-strict-aliasing -ffast-math -ftree-vectorize -mfloat-abi=hard  -marm -mfloat-abi=hard -DNO_ASM -DARM_ASM -frename-registers -ftree-vectorize -mcpu=cortex-a15 -mtune=cortex-a15.cortex-a7 -mfpu=neon-vfpv4 -mvectorize-with-neon-quad -DARM_HARDFP -DHOST_CPU=0x20000002 -fopenmp -D__LIBRETRO__ -DNO_VERIFY -fno-builtin-sqrtf -DNO_MMU -DNDEBUG -flto -DRELEASE -funroll-loops -DHAVE_TEXUPSCALE -DHAVE_OPENGLES -DHAVE_OPENGLES2 -DTARGET_NO_JIT -DFLAC__HAS_OGG=0 -FLAC__NO_DLL -DHAVE_LROUND -DHAVE_STDINT_H -DHAVE_STDLIB_H -DHAVE_SYS_PARAM_H -D_7ZIP_ST -DUSE_FLAC -DUSE_LZMA -O3 -c -fno-strict-aliasing -ffast-math  -I./core/libretro -I./core/ -I./core/deps -I./core/deps/picotcp/include -I./core/deps/picotcp/modules -I./core/libretro-common/include -I./core/deps/flac/include core/rec-ARM/ngen_arm.S -o core/rec-ARM/ngen_arm.o

something fail with the 'core/rec-ARM/ngen_arm.o'

and it wont continue, it does not give an error neither a warning, its just sit there doing nothing

Please any help guys?, and thank you very munch for everthing, this guide is awesome

Kind regards.

[AreaScout]

I have a problem trying to compile reicast into the odroid XU4, I thinks is because the lastest changes in the makefile and maybe the sources code.

That's right the patch does not apply anymore, I think the only thing mainline reicast libretro is missing is HAVE_LTCG := 0 on line number 11, please change it from 1 to 0 and retry

RG

[MysteryScience]

That's right the patch does not apply anymore, I think the only thing mainline reicast libretro is missing is HAVE_LTCG := 0 on line number 11, please change it from 1 to 0 and retry

RG

Hi, @AreaScout

Many thanks for the fast reply

Checking the new Makefile, looks like most of the changes from the patch aren't needed. Only the with the glsm.h header, that gives you an error (cuz GLfloat its declare like a GLdouble, etc, etc)

testing with

Code: Select all

HAVE_LTCG     := 0

and its work!! , but its takeeesss to long to build, so hope this helps those people with the same problem.

Again @AreaScout many thanks you are a very nice person.

Can i make a request? you need something especial (like a patch or something) to install mupen64 (or Mupen64plus from libretro), still I dont try it myself, just starting this proyect since yesteardy

Thanks in advanced and kind regards.

[bullghost]

hi all,
i try compile and install os and ppsspp with success and speed are awesome,
but i have problem on compiling kodi ,using kodi 18.0RC2 get from release page,
here the error log show on terminal

Code: Select all

[ 90%] Building CXX object build/windowing/gbm/CMakeFiles/windowing_Gbm.dir/DRMLegacy.cpp.o
[ 91%] Building CXX object build/windowing/gbm/CMakeFiles/windowing_Gbm.dir/DRMAtomic.cpp.o
[ 91%] Building CXX object build/windowing/gbm/CMakeFiles/windowing_Gbm.dir/OffScreenModeSetting.cpp.o
[ 91%] Building CXX object build/windowing/gbm/CMakeFiles/windowing_Gbm.dir/WinSystemGbmEGLContext.cpp.o
[ 91%] Building CXX object build/windowing/gbm/CMakeFiles/windowing_Gbm.dir/WinSystemGbmGLESContext.cpp.o
[ 91%] Linking CXX static library windowing_Gbm.a
[ 91%] Built target windowing_Gbm
Scanning dependencies of target rendering_gles
[ 91%] Building CXX object build/rendering/gles/CMakeFiles/rendering_gles.dir/RenderSystemGLES.cpp.o
[ 91%] Building CXX object build/rendering/gles/CMakeFiles/rendering_gles.dir/__/MatrixGL.cpp.o
[ 91%] Building CXX object build/rendering/gles/CMakeFiles/rendering_gles.dir/GLESShader.cpp.o
[ 91%] Building CXX object build/rendering/gles/CMakeFiles/rendering_gles.dir/__/MatrixGL.neon.cpp.o
/tmp/cctYAVH3.s: Assembler messages:
/tmp/cctYAVH3.s:32: Error: VFP single precision register expected -- `vldmia r0,{ q8-q11 }'
/tmp/cctYAVH3.s:33: Error: selected FPU does not support instruction -- `vmul.f32 q0,q8,d8[0]'
/tmp/cctYAVH3.s:34: Error: selected FPU does not support instruction -- `vmul.f32 q1,q8,d10[0]'
/tmp/cctYAVH3.s:35: Error: selected FPU does not support instruction -- `vmul.f32 q2,q8,d12[0]'
/tmp/cctYAVH3.s:36: Error: selected FPU does not support instruction -- `vmul.f32 q3,q8,d14[0]'
/tmp/cctYAVH3.s:37: Error: selected FPU does not support instruction -- `vmla.f32 q0,q9,d8[1]'
/tmp/cctYAVH3.s:38: Error: selected FPU does not support instruction -- `vmla.f32 q1,q9,d10[1]'
/tmp/cctYAVH3.s:39: Error: selected FPU does not support instruction -- `vmla.f32 q2,q9,d12[1]'
/tmp/cctYAVH3.s:40: Error: selected FPU does not support instruction -- `vmla.f32 q3,q9,d14[1]'
/tmp/cctYAVH3.s:41: Error: selected FPU does not support instruction -- `vmla.f32 q0,q10,d9[0]'
/tmp/cctYAVH3.s:42: Error: selected FPU does not support instruction -- `vmla.f32 q1,q10,d11[0]'
/tmp/cctYAVH3.s:43: Error: selected FPU does not support instruction -- `vmla.f32 q2,q10,d13[0]'
/tmp/cctYAVH3.s:44: Error: selected FPU does not support instruction -- `vmla.f32 q3,q10,d15[0]'
/tmp/cctYAVH3.s:45: Error: selected FPU does not support instruction -- `vmla.f32 q0,q11,d9[1]'
/tmp/cctYAVH3.s:46: Error: selected FPU does not support instruction -- `vmla.f32 q1,q11,d11[1]'
/tmp/cctYAVH3.s:47: Error: selected FPU does not support instruction -- `vmla.f32 q2,q11,d13[1]'
/tmp/cctYAVH3.s:48: Error: selected FPU does not support instruction -- `vmla.f32 q3,q11,d15[1]'
build/rendering/gles/CMakeFiles/rendering_gles.dir/build.make:134: recipe for target 'build/rendering/gles/CMakeFiles/rendering_gles.dir/__/MatrixGL.neon.cpp.o' failed
make[2]: *** [build/rendering/gles/CMakeFiles/rendering_gles.dir/__/MatrixGL.neon.cpp.o] Error 1
CMakeFiles/Makefile2:11536: recipe for target 'build/rendering/gles/CMakeFiles/rendering_gles.dir/all' failed
make[1]: *** [build/rendering/gles/CMakeFiles/rendering_gles.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2

please anyone know did i miss something ?
thanks in advance

[AreaScout]

please anyone know did i miss something ?
thanks in advance

You probably missed that part before compiling it

Code: Select all

export CPPFLAGS="-mfloat-abi=hard -marm -mtune=cortex-a15.cortex-a7 -mcpu=cortex-a15 -mfpu=neon-vfpv4 -ftree-vectorize -mvectorize-with-neon-quad -ffast-math"
export CXXFLAGS=$CPPFLAGS
export CXX_FLAGS=$CXXFLAGS

RG

[bullghost]

@AreaScout thanks, you were right,
silly me i forgot that three line -_-!
test youtube and enable whitelist resolution list work fine so far .

[MastaG]

Regarding Reicast, yeah I sent the changes of the patch upstream after refactoring it a bit.
However I couldn't figure out why we should disable link time optimization (HAVE_LTCG := 0), because it works great when its enabled.
Only the compile time takes a bit longer..

[MastaG]

@AreaScout
Regarding Kodi, with the following changes to the source:

Code: Select all

diff --git a/xbmc/windowing/gbm/DRMUtils.cpp b/xbmc/windowing/gbm/DRMUtils.cpp
index df46ad4bdc..5a4bf58306 100644
--- a/xbmc/windowing/gbm/DRMUtils.cpp
+++ b/xbmc/windowing/gbm/DRMUtils.cpp
@@ -346,13 +346,13 @@ drmModePlanePtr CDRMUtils::FindPlane(drmModePlaneResPtr resources, int crtc_inde
       {
         drmModePropertyPtr p = drmModeGetProperty(m_fd, props->props[j]);
 
-        if ((strcmp(p->name, "type") == 0) && (props->prop_values[j] != DRM_PLANE_TYPE_CURSOR))
+        if (strcmp(p->name, "type") == 0)
         {
           switch (type)
           {
             case KODI_VIDEO_PLANE:
             {
-              if (SupportsFormat(plane, DRM_FORMAT_NV12))
+              if (SupportsFormat(plane, DRM_FORMAT_NV12) || SupportsFormat(plane, DRM_FORMAT_XRGB8888))
               {
                 CLog::Log(LOGDEBUG, "CDRMUtils::%s - found video plane %u", __FUNCTION__, plane->plane_id);
                 drmModeFreeProperty(p);
@@ -529,7 +529,7 @@ bool CDRMUtils::OpenDrm(bool needConnector)
 
   for (auto module : modules)
   {
-    m_fd.attach(drmOpenWithType(module, nullptr, DRM_NODE_PRIMARY));
+    m_fd.attach(open("/dev/dri/card0", O_RDWR | O_CLOEXEC));
     if (m_fd)
     {
       if(!GetResources())
@@ -556,7 +556,7 @@ bool CDRMUtils::OpenDrm(bool needConnector)
 
       CLog::Log(LOGDEBUG, "CDRMUtils::%s - opened device: %s using module: %s", __FUNCTION__, drmGetDeviceNameFromFd2(m_fd), module);
 
-      m_renderFd.attach(drmOpenWithType(module, nullptr, DRM_NODE_RENDER));
+      m_renderFd.attach(open("/dev/dri/renderD128", O_RDWR | O_CLOEXEC));
       if (m_renderFd)
       {
         CLog::Log(LOGDEBUG, "CDRMUtils::%s - opened render node: %s using module: %s", __FUNCTION__, drmGetDeviceNameFromFd2(m_renderFd), module);

It seems to work without modifying the kernel.
At least I think so, the debug log now says:

Code: Select all

19:01:27.529 T:2949085376   DEBUG: CDRMUtils::FindConnector - found connector: 35
19:01:27.530 T:2949085376   DEBUG: CDRMUtils::OpenDrm - opened device: /dev/dri/card0 using module: i915
19:01:27.530 T:2949085376   DEBUG: CDRMUtils::OpenDrm - opened render node: /dev/dri/renderD128 using module: i915
19:01:27.553 T:2949085376   DEBUG: CDRMUtils::FindConnector - found connector: 35
19:01:27.553 T:2949085376   DEBUG: CDRMUtils::FindEncoder - found encoder: 34
19:01:27.553 T:2949085376   DEBUG: CDRMUtils::FindCrtc - found crtc: 33
19:01:27.553 T:2949085376   DEBUG: CDRMUtils::FindPlane - found video plane 27
19:01:27.554 T:2949085376 WARNING: CDRMUtils::FindPlane - could not find plane
19:01:27.554 T:2949085376   DEBUG: CDRMUtils::FindPlane - found gui plane 30
19:01:27.554 T:2949085376   DEBUG: CDRMUtils::FindPreferredMode - found preferred mode: 1920x1200 @ 60 Hz
19:01:27.554 T:2949085376 WARNING: CDRMUtils::InitDrm - failed to set drm master, will try to authorize instead: Permission denied
19:01:27.554 T:2949085376  NOTICE: CDRMUtils::InitDrm - successfully authorized drm magic
19:01:27.554 T:2949085376   DEBUG: CDRMAtomic::InitDrm - initialized atomic DRM
19:01:27.554 T:2949085376   DEBUG: CWinSystemGbm::InitWindowSystem - initialized DRM
19:01:27.554 T:2949085376  NOTICE: Found resolution 1920x1200 with 1920x1200 @ 60.000000 Hz

So according to the log the video plane seems 27 and the gui plane would 30?
Am I now using two planes for Kodi?
How could I test this? would it be more smooth using two planes?

[memeka]

@MastaG:

Code: Select all

/dev/dri/card0 using module: i915

you don't need to hardcode /dev/dri/card0 or /dev/dri/renderD128, you need to add exynos in the list of supported drm modules (e.g. search for i915 and add exynos in the list where you find it).

[AreaScout]

you don't need to hardcode /dev/dri/card0 or /dev/dri/renderD128, you need to add exynos in the list of supported drm modules (e.g. search for i915 and add exynos in the list where you find it).

I know this for a long time and was trying it also with just adding 'exynos' string to the list but as Exynos is an experimental API in libdrm and I have seen strange GUI effects with using drmopen I highly recommend not using it. There is a reason why I am not using it, that was the first thing I was trying every time I compiled a new Kodi version to see if it's working ok now with drmopen but it didn't, maybe things are better now with the use of the render node but it was worse before.

@MastaG

Yes as the log says you are now using two XRGB planes and one should be a cursor plane thought If that is stable on your system I would say go for it, I have seen Kodi having problems sometimes when choosing planes with this configuration, again I always found that with kernel patch it works best.

RG

[MysteryScience]

Regarding Reicast, yeah I sent the changes of the patch upstream after refactoring it a bit.
However I couldn't figure out why we should disable link time optimization (HAVE_LTCG := 0), because it works great when its enabled.
Only the compile time takes a bit longer..

Its a good idea to leave

Code: Select all

HAVE_LTCG := 0

?

I was able to compile both option (

Code: Select all

HAVE_LTCG := 0

and

Code: Select all

HAVE_LTCG := 1

), its takes some time, but yes both option compile just fine (i think := 1 gives you some warnings, but dont remember irght now).

Now Im just test a couple of game

Shenmue 1, still it goes some sluggish (but i think is more for the emulator and not the hardware)

Sonic Adventure 2, freezes and locks up (just test it onces)

I will try more games and try to compile versatile commodore today.

and check later about mupen64

[AreaScout]

Its a good idea to leave

Code: Select all

HAVE_LTCG := 0

?

I got link time errors with it ...

Shenmue 1, still it goes some sluggish (but i think is more for the emulator and not the hardware)

Sonic Adventure 2, freezes and locks up (just test it onces)

I will try more games and try to compile versatile commodore today.

and check later about mupen64

I found the official RetroArch website very informative about reicast core game compatibility and newest features, you can back browse older posts from there, quite helpful if you haven't heard about it

If you have any VICE compile problems please report

RG

[MysteryScience]

I found the official RetroArch website very informative about reicast core game compatibility and newest features, you can back browse older posts from there, quite helpful if you haven't heard about it

If you have any VICE compile problems please report

RG

I will try today to compile it again, with both option (HAVE_LTCG := 0 and HAVE_LTCG := 1) and see what happens. In another side i made some Tweaks with the core options from your recommendations

reicast_framerate = "normal"
reicast_enable_rttb = "enabled"
reicast_threaded_rendering = "enabled"

and it was really helpful, plus I overclock the XU4 RAM and it really run better.

About Vice everything goes smoothly.

But I have a problem with PPSSPP, it runs in a corner of the screen and I cant made it run in full screen on my TV any idea why its this @AreaScout?

Again many thanks and kind regards.

[AreaScout]

About Vice everything goes smoothly.

Good to hear, I am about to add a menu entry in vice to enable or disable the border and will make an PR on github soon

But I have a problem with PPSSPP, it runs in a corner of the screen and I cant made it run in full screen on my TV any idea why its this @AreaScout?

Again many thanks and kind regards.

It could be that there is another SDL2 library installed on your system now, it came most likely with one of the package dependencies from the Kodi Howto and it's stored under /usr/lib/arm-linux-gnueabihf/ and the one from my tutorial is stored under /usr/local/lib/, you can check which library is used if you use ldd on the binary ldd PPSSPPSDL if it's really the case that it's now using SDL2 from the package archive it would explain why it runs in a corner of the screen because it would not use the HW accelerated OpenGL ES, but normal desktop OpenGL which is not HW scaled but SW scaled

To solve it, you have to enable to use our custom SDL2 library in the library search hierarchy before the one from the package servers with export LD_LIBRARY_PATH=/usr/local/lib after that start ppsspp again and it should work


edit: sorry that doesn't help, I have just tried it for myself, something has changed and you have to start PPSSPP with fullscreen switch like ./PPSSPPSDL --fullscreen or add MOBILE_DEVICE to cmake (untested)

RG

[bullghost]

hi all,
i think i break my SDL2 GBM and GLES when i want to compile Emulationstation its need libsdl2-mixer-dev
when i install libsdl2-mixer-dev from repo i see bunch of other library are included
after i install my PPSSPPSDL is broken with error undefined symbol: eglQueryString
and i try recompile successful but cannot run it throw error failed graphic backend : 0.all.all , all graphic backend failed.
is there anyway other way to install libsdl2-mixer-dev without include other library?
or can we compile from source ?

[AreaScout]

hi all,
i think i break my SDL2 GBM and GLES when i want to compile Emulationstation its need libsdl2-mixer-dev
when i install libsdl2-mixer-dev from repo i see bunch of other library are included
after i install my PPSSPPSDL is broken with error undefined symbol: eglQueryString
and i try recompile successful but cannot run it throw error failed graphic backend : 0.all.all , all graphic backend failed.
is there anyway other way to install libsdl2-mixer-dev without include other library?
or can we compile from source ?

Yes that's a problem, those packages have so much dependencies it will break your Mali user space libraries because they install Mesa once and it will break SDL2

My best bet on this would be to compile those libraries for your own and do not install it by the package manager as you already pointed out, so the most common used SDL2 projects other then SDL2 library itself are:

SDL2_mixer
SDL2_image
SDL2_ttf

I think that all three are needed by EmulationStation, you would do something like this (untested and only a suggestion)

Code: Select all

hg clone http://hg.libsdl.org/SDL_mixer
cd SDL_mixer
./configure
make -j7
sudo make install

Code: Select all

hg clone http://hg.libsdl.org/SDL_image
cd SDL_image
./configure
make -j7
sudo make install

Code: Select all

hg clone http://hg.libsdl.org/SDL_ttf
cd SDL_ttf
./configure
make -j7
sudo make install

RG

[MysteryScience]

edit: sorry that doesn't help, I have just tried it for myself, something has changed and you have to start PPSSPP with fullscreen switch like ./PPSSPPSDL --fullscreen or add MOBILE_DEVICE to cmake (untested)

Hi @AreaScout

Yes, launching ./PPSSPPSDL --fullscreen now works in full screen, but the speed in GOW, its no so good like in your video, i mean, Its keeps most of the time 100%, but dunno is no the same like in your video that most of the time goes smoothly.

In another side, i recompile reicast with HAVE_LTCG := 1 and HAVE_LTCG := 0, and looks like there was some mayor changes in the core because now Sonic Adventure 2 its full playable (not missing artifacts) and runs very well.

I dont recommend HAVE_LTCG := 1, its compile but gives you a lot of warnings, so maybe its no a good signal.

Maybe need to change a litlle the patch @AreaScout, because still you need to comment a line in glsm.h header and change HAVE_LTCG := 1 to HAVE_LTCG := 0

kind regrads

[AreaScout]

Hi @AreaScout

Yes, launching ./PPSSPPSDL --fullscreen now works in full screen, but the speed in GOW, its no so good like in your video, i mean, Its keeps most of the time 100%, but dunno is no the same like in your video that most of the time goes smoothly.

In another side, i recompile reicast with HAVE_LTCG := 1 and HAVE_LTCG := 0, and looks like there was some mayor changes in the core because now Sonic Adventure 2 its full playable (not missing artifacts) and runs very well.

I dont recommend HAVE_LTCG := 1, its compile but gives you a lot of warnings, so maybe its no a good signal.

Maybe need to change a litlle the patch @AreaScout, because still you need to comment a line in glsm.h header and change HAVE_LTCG := 1 to HAVE_LTCG := 0

kind regrads

Hi MysteryScience

Thank you for confirming that the fullscreen switch is working, consider the GOW speed, when I was testing it two days ago on my TV with 1080p resolution the first Game sequences are playing fine without stutters or anything, PPSSPP has changed a lot since then and it should be even better then worse, I will test more in the new year also I will update the reicast howto

edit: last time I forgot to paste the link for the official reicast info blog, with lots of information whats new https://www.libretro.com/index.php/category/reicast don't forget to back browse older posts too

Happy new Year to all

[bullghost]

Yes that's a problem, those packages have so much dependencies it will break your Mali user space libraries because they install Mesa once and it will break SDL2

My best bet on this would be to compile those libraries for your own and do not install it by the package manager as you already pointed out, so the most common used SDL2 projects other then SDL2 library itself are:

SDL2_mixer
SDL2_image
SDL2_ttf

I think that all three are needed by EmulationStation, you would do something like this (untested and only a suggestion)

Code: Select all

hg clone http://hg.libsdl.org/SDL_mixer
cd SDL_mixer
./configure
make -j7
sudo make install

Code: Select all

hg clone http://hg.libsdl.org/SDL_image
cd SDL_image
./configure
make -j7
sudo make install

Code: Select all

hg clone http://hg.libsdl.org/SDL_ttf
cd SDL_ttf
./configure
make -j7
sudo make install

RG

@AreaScout thanks, i try compile from that source its work fine.
there is troublesome for sdlimage, it use automake 1.16
there is another thing it might break it, it was libglvnd.

[bullghost]

Patching Kodi

Code: Select all

git clone https://github.com/xbmc/xbmc.git
cd xbmc
wget -O kodi.patch https://pastebin.com/raw/mzAiCU2Q
patch -p1 < kodi.patch

the coding patching break MPEG4 it show black screen but playing the file, where if it warp-in avi divx file
so i need to remove this code
+ case AV_CODEC_ID_MPEG4:
+ pCodec = avcodec_find_decoder_by_name(MPEG4_FFMPEG_CODEC);
+ break;

[MysteryScience]

Hi MysteryScience

Thank you for confirming that the fullscreen switch is working, consider the GOW speed, when I was testing it two days ago on my TV with 1080p resolution the first Game sequences are playing fine without stutters or anything, PPSSPP has changed a lot since then and it should be even better then worse, I will test more in the new year also I will update the reicast howto

edit: last time I forgot to paste the link for the official reicast info blog, with lots of information whats new https://www.libretro.com/index.php/category/reicast don't forget to back browse older posts too

Happy new Year to all

Hi there AreaScout,

Many thanks for all, I hope you enjoy a wonderful new year! and warmest wishes to everyone here, may your holidays be filled with lots of happiness, peace, and love

[AreaScout]

the coding patching break MPEG4 it show black screen but playing the file, where if it warp-in avi divx file
so i need to remove this code
+ case AV_CODEC_ID_MPEG4:
+ pCodec = avcodec_find_decoder_by_name(MPEG4_FFMPEG_CODEC);
+ break;

I can't say that this is a general problem, all DIVX encapsulated MPEG4 video files I have testet are working, here is an example https://cinelerra-cv.org/footage/morgen-20030714.avi there are more examples to download from here https://cinelerra-cv.org/footage.php

RG

[AreaScout]

In another side, i recompile reicast with HAVE_LTCG := 1 and HAVE_LTCG := 0, and looks like there was some mayor changes in the core because now Sonic Adventure 2 its full playable (not missing artifacts) and runs very well.

I dont recommend HAVE_LTCG := 1, its compile but gives you a lot of warnings, so maybe its no a good signal.

Maybe need to change a litlle the patch @AreaScout, because still you need to comment a line in glsm.h header and change HAVE_LTCG := 1 to HAVE_LTCG := 0

kind regrads

Aloha MysteryScience

I have just compiled libretro reicast and the patch is not needed anymore, even the glsm.h doesn't need to be changed maybe you need the newest khronos headers, the latest once show a modification date from 20181230, I have changed the tutorial with a note to the patch and I leave it up to the user to take parts of it for it's personal configuration usage. The tutorial is working again and the reicast config within RetroArch is still needed.

RG

[MysteryScience]

Aloha MysteryScience

I have just compiled libretro reicast and the patch is not needed anymore, even the glsm.h doesn't need to be changed maybe you need the newest khronos headers, the latest once show a modification date from 20181230, I have changed the tutorial with a note to the patch and I leave it up to the user to take parts of it for it's personal configuration usage. The tutorial is working again and the reicast config within RetroArch is still needed.

RG

Aloha AreaScout

Hope you had a nice turn of the year. And that are good news, to be true the last time y compile the Reicast core was like hmm December 25 ... maybe 26, but its nice that you dont need the patch anymore

I have a doubt regard with the ppsspp, its running like 75% of speed for me (when it gets heavy graphically, like in the main sequence), dunno if its the HDMI cable or if I have Auto frameskip on (if I turn off its runs better but you cannot see the subtitles, that its weird dude). I double check all the step's guide and everything looks Ok, I check too with another SD, i will try with another HDMI cable today.

Any suggestion AreaScout ?, again many thanks for this splendid guide and for answering all doubts

Kind regards

[AreaScout]

I have a doubt regard with the ppsspp, its running like 75% of speed for me (when it gets heavy graphically, like in the main sequence), dunno if its the HDMI cable or if I have Auto frameskip on (if I turn off its runs better but you cannot see the subtitles, that its weird dude). I double check all the step's guide and everything looks Ok, I check too with another SD, i will try with another HDMI cable today.

Any suggestion AreaScout ?, again many thanks for this splendid guide and for answering all doubts

Kind regards

Yeah that's pretty unique to this game, nearly all others are running faster with 'Auto frameskip ON' while GOW Olympus does not, the flickering subtitle is normal with this settings ... sadly

75% speed hmmm, that is really too little, please make sure to not use to much devices on the USB ports, i.e I use a USB hub with external power, if you don't that could pull to much current from the board and thus slow things down, it even can cause some other strange effects.

Please also try to disable or enable PluseAudio and see if this makes a difference.

RG

[AreaScout]

@MysteryScience

Also take a look in your retroarch.cfg if there is a default or stock shader setting defined for the value video_shader = it should be set to zero "" otherwise this shader will slow things down + it will be added on top of each shader program configured, so it will slow down shader programs too

RG

[AreaScout]

@MastaG

Just to let you know that there is a new pull/commit for Kodi which speeds up the frame renderer that much that 1080p streaming with libwidevine is possible without stutters

https://github.com/xbmc/xbmc/pull/15286/commits

RG

[MysteryScience]

@MysteryScience

Also take a look in your retroarch.cfg if there is a default or stock shader setting defined for the value video_shader = it should be set to zero "" otherwise this shader will slow things down + it will be added on top of each shader program configured, so it will slow down shader programs too

RG

@Aloha AreaScout

Sorry for no reply early, i was on vacations

Many thanks dude I will test it this weekend, in another events I compiled SDL2_image, SDL2_mixer and SDL2_ttf in this project, because im working in some frontend from scratch (not so big like retropie but still), to give you an idea its like the SNES mini frontend (with C++ and SDL2).

I will post later how to compile SDL2_image, SDL2_mixer and SDL2_ttf, because you have to modified some thing here and there (mostly with SDL2_image and SDL2_ttf).

Kind regards.

[rooted]

@MastaG

Just to let you know that there is a new pull/commit for Kodi which speeds up the frame renderer that much that 1080p streaming with libwidevine is possible without stutters

https://github.com/xbmc/xbmc/pull/15286/commits

RG

Very interesting, I may have to repurpose one of my XU4 to media duties.

[mad_ady]

One of these days you guys are going to figure out how to make it output 4k

[MysteryScience]

Alright guys, time to compile some SDL things

SDL_mixer its the most easy because you dont need to touch anything beside just run ./configure && make

Code: Select all

hg clone http://hg.libsdl.org/SDL_mixer
cd SDL_mixer
./configure
make -j7
sudo make install

that was easy enough, now will turn the difficulty up with SDL_image

Code: Select all

hg clone http://hg.libsdl.org/SDL_image
cd SDL_image
touch --date="`date`" aclocal.m4 Makefile.am configure Makefile.in
./configure
make -j7
sudo make install

if you run the command ./configure without the touch --date ... you gonna get an error message like this

@WARNING: 'aclocal-1.16' is missing on your system. You should only need it if you modified 'acinclude.m4' or 'configure.ac' or m4 files included by 'configure.ac'. The 'aclocal' program is part of the GNU Automake package: http://www.gnu.org/software/automake It also requires GNU Autoconf, GNU m4 and Perl in order to run: http://www.gnu.org/software/autoconf http://www.gnu.org/software/m4/ http://www.perl.org/ make: *** [aclocal.m4] Error 127@

looks like some files are out-of-date (which may only be the case of screwed-up timestamps which you can fix by touching them)

Now for the grand finale SDL_ttf

Code: Select all

hg clone http://hg.libsdl.org/SDL_ttf
cd SDL_ttf
touch --date="`date`" aclocal.m4 Makefile.am configure Makefile.in
./configure
make -j7
sudo make install

most like the last SDL but there is one thing you need to do and that its comment a few lines in SDL_ttf.c and need to look for this flag

Code: Select all

textbuf->flags |= SDL_MEMALIGNED;

and the lines are 1060, 1124, 1221

Really dunno if this can bring some problems, but I tested with a program that I making in C++ with SDL2 and everything works fine.

If someone could make a patch so dont need to manually change this lines it would be nice, still I dont have the knowledge to do this but i will try it later.

Last thing, if you have some problem with the dynamic libraries, like libSDL2_image-2.0.so.0 run this command

Code: Select all

sudo ldconfig

to refresh de library cache

Thanks guys and keep the good work

PD.

Here a little video

[AreaScout]

Hi MysteryScience

Maybe SDL_image and SDL_ttf needs a ./autogen.sh before doing a configure, have you tried that ?

RG

[MysteryScience]

Hi MysteryScience

Maybe SDL_image and SDL_ttf needs a ./autogen.sh before doing a configure, have you tried that ?

RG

konnichiwamy my dear friend

Sorry but using ./autogen.sh didnt work, give you the next error when you run the make -j7

cd . && /bin/bash /home/odroid/supplementary/SDL_image/missing automake-1.16 --foreign
/home/odroid/supplementary/SDL_image/missing: line 81: automake-1.16: command not found
WARNING: 'automake-1.16' is missing on your system.
You should only need it if you modified 'Makefile.am' or
'configure.ac' or m4 files included by 'configure.ac'.
The 'automake' program is part of the GNU Automake package:
<http://www.gnu.org/software/automake>
It also requires GNU Autoconf, GNU m4 and Perl in order to run:
<http://www.gnu.org/software/autoconf>
<http://www.gnu.org/software/m4/>
<http://www.perl.org/>
Makefile:487: recipe for target 'M

you need to get the automake and autoconf packages before it (sudo atp-get install automake autoconf), too mucho hassle, better to stick with the touch command

Kind regards

[AreaScout]

Ahoy sailor

Yes that's true ./autogen.sh needs automake and autoconf, so one who needs to compile it knows for sure now how he can archive his task, with or without -> great !

RG

[MysteryScience]

Hallo Freund

That its one of things that I love most of Linux, always there is more than one way to accomplish the same goal

King regards

[MysteryScience]

Ahoy sailor

Yes that's true ./autogen.sh needs automake and autoconf, so one who needs to compile it knows for sure now how he can archive his task, with or without -> great !

RG

Hi hi my capitan

I trying to do everything from the begining and now when you run the next command to configure retroarch

Code: Select all

./configure --enable-opengles3 --enable-opengles --enable-neon --enable-floathard --enable-freetype

gives you the next error

"Build assumed that __ARM_NEON__ is defined, but it's not. Exiting..."

I think that RA mess something :/

If I remove --enable-neon it works.

another mistery my capitan

Kind regards.

[AreaScout]

I trying to do everything from the begining and now when you run the next command to configure retroarch

Code: Select all

./configure --enable-opengles3 --enable-opengles --enable-neon --enable-floathard --enable-freetype

gives you the next error

"Build assumed that __ARM_NEON__ is defined, but it's not. Exiting..."

I think that RA mess something :/

If I remove --enable-neon it works.

Hmm, either the arm neon makro definition in gcc has changed or it's an configure bug and the -mfpu=neon is not added on compile time, you could build with make -j7 V=1 to get verbose output and see if the mfpu switch is added, but most of the time it's juts a mistake and will get fixed soon

RG

[MysteryScience]

Hmm, either the arm neon makro definition in gcc has changed or it's an configure bug and the -mfpu=neon is not added on compile time, you could build with make -j7 V=1 to get verbose output and see if the mfpu switch is added, but most of the time it's juts a mistake and will get fixed soon

RG

here is the output my capitan

https://justpaste.it/2qdbv

looks like there is none -mfpu=neon, Iike you say @AreaScout maybe they will fix it soon.

Kind regards

[AreaScout]

@MysteryScience

Today I had the same problem, this is how I could get around that problem

Code: Select all

diff --git a/qb/config.libs.sh b/qb/config.libs.sh
index 1a698f4c45..4f0d4b5d4e 100644
--- a/qb/config.libs.sh
+++ b/qb/config.libs.sh
@@ -507,7 +507,7 @@ if [ "$HAVE_MENU" != 'no' ]; then
    fi
 fi

-check_macro NEON __ARM_NEON__
+#check_macro NEON __ARM_NEON__

 add_define MAKEFILE OS "$OS"

plus I had to fix egl.pc and glesv2.pc pkgconfig files, it's time for a new mali-x11-gbm package file, I think I will make one

RG

[MysteryScience]

@MysteryScience

Today I had the same problem, this is how I could get around that problem

Code: Select all

diff --git a/qb/config.libs.sh b/qb/config.libs.sh
index 1a698f4c45..4f0d4b5d4e 100644
--- a/qb/config.libs.sh
+++ b/qb/config.libs.sh
@@ -507,7 +507,7 @@ if [ "$HAVE_MENU" != 'no' ]; then
    fi
 fi

-check_macro NEON __ARM_NEON__
+#check_macro NEON __ARM_NEON__

 add_define MAKEFILE OS "$OS"

plus I had to fix egl.pc and glesv2.pc pkgconfig files, it's time for a new mali-x11-gbm package file, I think I will make one

RG

Many thanks Capitan =))

That its great, dunno how you could figure out all those things but I love to learn and this thread its pure awesomeness

Please could you share what you modified in the fix egl.pc and glesv2.pc pkgconfig files, to keep learning =))

Kind regards and please keep with the good work Capitan @AreaScout

[AreaScout]

@MysteryScience

The versioning in those *.pc files is not compatible anymore with the latest Makefile from RetroArch it seems, the solution is to install the mesa packages so the *.pc files will be overwritten libegl1-mesa-dev libgles2-mesa-dev

RG