Pi3 image

[dougan78]

Ok recompiled on my setup and tested and it does seem faster.  I would say it is not as fast as my cab with my Retrospin Static theme but works in general.  I do have a few issues with artwork not showing up. That I fixed as it was a linux CaSEseNsiTIVe thing.   And the videos do not play for me yet on the system menu.  The main menu videos are playing fine.  Not sure why it is the items in my include.txt match the video file names  in the video folder.  Need to figure that out.

[progets]

It's better but still runs 100% CPU with the default Aeon Nox. I still see a reduced CPU usage when using specific gstreamer packages vs. the gstreamer full compile.

@Pieter - Did you determine which specific gstreamer package(s) you are using? Are you confident that the gstreamer install isn't a factor?

[Pieter Hulshoff]

It's better but still runs 100% CPU with the default Aeon Nox. I still see a reduced CPU usage when using specific gstreamer packages vs. the gstreamer full compile.

@Pieter - Did you determine which specific gstreamer package(s) you are using? Are you confident that the gstreamer install isn't a factor?

No, I'm not at all confident that the gstreamer packages aren't a factor; I know they can be a huge factor. Which specific packages reduce your CPU usage?

The videos should run much smoother now though; that's at least what I expect from the latest fixes.

[MisterB]

So, I'm finally back to working on my installer script for RetroPie.  The info in this thread has been very helpful in driving some changes!

Regarding the RetroPie gstreamer requirements, I also wanted to avoid installing the full package.  Right now, I've whittled the full list of dependencies on RetroPie down to the following, which now supports video and the video sound.  I'm not sure that this setup would be considered CPU optimized...overall utilization across the 4 cores is only like 30%, but it totally maxes out a full core on occasion (retrofe process total cpu 70-150%)

Code: [Select]

tortoisehg g++ cmake dos2unix zlib1g-dev libsdl2-2.0-0 libsdl2-mixer-2.0-0 libsdl2-image-2.0-0 libsdl2-ttf-2.0-0
libsdl2-dev libsdl2-mixer-dev libsdl2-image-dev libsdl2-ttf-dev libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev
gstreamer1.0-libav zlib1g-dev libglib2.0-0 libglib2.0-dev sqlite3 gstreamer1.0-plugins-good gstreamer1.0-alsa

I suspect I can remove libgstreamer-plugins-base1.0-dev, but I haven't tried it yet.

[MisterB]

Getting back to the script development... I want to make the RetroFE integration into RetroPie as seamless as possible, and I feel like the biggest challenge is the naming convention.  RetroPie has this concept of "short" platform names and a corresponding full name, which are defined in the platforms.cfg files (~/RetroPie-Setup/platforms.cfg and /opt/retropie/configs/all/platforms.cfg).  I think it would be easiest and most "native" to RP if this naming convention was carried over to the RFE collections.  My concern is that  the metadata for RFE is coming from the HyperSpin XML files, which follow a different system naming format.  The mismatch between the metadata system names and the RP-native platform names means that we won't pull back any metadata for the games.

So I guess I have 2 questions....

- Do folks agree that it would be easier for users if the RetroFE collections on a RetroPie setup were following the RP "short name" convention?  Personally, I like the idea of consistency between the names shown in the RP "roms" directory, and the RFE collection names.  Paths can then be standardized.  This can simplify the collection configs, and probably also simplifies the sharing of artwork assets between RP FE's as we move forward as well.

- If we can agree on the above, should we consider a config option in the collection's settings.conf that explicitly defines the collection's metadata source name, optionally overriding the use of the collection's directory name?

Thank you for your consideration....

[Pieter Hulshoff]

Yes, I agree that it would be wise to follow the RetroPie setup, and the feature you're looking for for the meta already exists; just look at the Arcade collection (settings.conf).
The only thing the directory name really impacts is the printed (text) name of the collection, but we may be able to overwrite that from the info.conf file.

Sent from my SM-G920F using Tapatalk

[Pieter Hulshoff]

Question: How exactly does gstreamer-omx fit into all of this? Is it just a plugin, to be used automatically if the videos fit the supported decoder or do I have to do something special in the code to make it work? I've been looking around via Google, but I haven't found much help in that area yet.

[Pieter Hulshoff]

Yes, I agree that it would be wise to follow the RetroPie setup, and the feature you're looking for for the meta already exists; just look at the Arcade collection (settings.conf).
The only thing the directory name really impacts is the printed (text) name of the collection, but we may be able to overwrite that from the info.conf file.

I just checked: it can indeed be overwritten from settings.conf or info.conf, simply by setting the title variable there. In short: I see no reason not to use the RetroPie default naming.

[progets]

Does anyone have issues with a controller/joystick/gamepad controlling the RetroFE frontend after launching and playing a game? Once I return from playing the first game in RetroFE the gamepad no longer controls RetroFE and only a keyboard works.

[Pieter Hulshoff]

Does anyone have issues with a controller/joystick/gamepad controlling the RetroFE frontend after launching and playing a game? Once I return from playing the first game in RetroFE the gamepad no longer controls RetroFE and only a keyboard works.

I haven't checked that part to be honest, but I'll give it a try. It's quite possible I forgot to reinitialize the controllers after closing down and restarting SDL.

[Pieter Hulshoff]

Found the issue; trying to fix it by adding hot-pluggable functionality. That was on the to-do list anyway. 😀

Sent from my SM-G920F using Tapatalk

[Pieter Hulshoff]

Does anyone have issues with a controller/joystick/gamepad controlling the RetroFE frontend after launching and playing a game? Once I return from playing the first game in RetroFE the gamepad no longer controls RetroFE and only a keyboard works.

Try the latest code; I've hopefully added hot-pluggability, which should also fix this issue.

[progets]

Does anyone have issues with a controller/joystick/gamepad controlling the RetroFE frontend after launching and playing a game? Once I return from playing the first game in RetroFE the gamepad no longer controls RetroFE and only a keyboard works.

Try the latest code; I've hopefully added hot-pluggability, which should also fix this issue.

Having issues with the new build. I haven't had a lot of time to test but here's what I see for now.

Code: [Select]

pi@retropie:~/retrofe $ cmake --build RetroFE/Build
[  2%] Building CXX object CMakeFiles/retrofe.dir/Control/UserInput.cpp.o
/home/pi/retrofe/RetroFE/Source/Control/UserInput.cpp: In member function ‘bool UserInput::update(SDL_Event&)’:
/home/pi/retrofe/RetroFE/Source/Control/UserInput.cpp:302:72: error: ‘SDL_JoystickFromInstanceID’ was not declared in this scope
         SDL_JoystickClose( SDL_JoystickFromInstanceID( e.jdevice.which ) );
                                                                        ^
CMakeFiles/retrofe.dir/build.make:158: recipe for target 'CMakeFiles/retrofe.dir/Control/UserInput.cpp.o' failed
make[2]: *** [CMakeFiles/retrofe.dir/Control/UserInput.cpp.o] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/retrofe.dir/all' failed
make[1]: *** [CMakeFiles/retrofe.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
pi@retropie:~/retrofe $


[Pieter Hulshoff]

Does anyone have issues with a controller/joystick/gamepad controlling the RetroFE frontend after launching and playing a game? Once I return from playing the first game in RetroFE the gamepad no longer controls RetroFE and only a keyboard works.

Try the latest code; I've hopefully added hot-pluggability, which should also fix this issue.

Having issues with the new build. I haven't had a lot of time to test but here's what I see for now.

Code: [Select]

pi@retropie:~/retrofe $ cmake --build RetroFE/Build
[  2%] Building CXX object CMakeFiles/retrofe.dir/Control/UserInput.cpp.o
/home/pi/retrofe/RetroFE/Source/Control/UserInput.cpp: In member function ‘bool UserInput::update(SDL_Event&)’:
/home/pi/retrofe/RetroFE/Source/Control/UserInput.cpp:302:72: error: ‘SDL_JoystickFromInstanceID’ was not declared in this scope
         SDL_JoystickClose( SDL_JoystickFromInstanceID( e.jdevice.which ) );
                                                                        ^
CMakeFiles/retrofe.dir/build.make:158: recipe for target 'CMakeFiles/retrofe.dir/Control/UserInput.cpp.o' failed
make[2]: *** [CMakeFiles/retrofe.dir/Control/UserInput.cpp.o] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/retrofe.dir/all' failed
make[1]: *** [CMakeFiles/retrofe.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
pi@retropie:~/retrofe $


Seems like the SDL version of RetroPie is out of date; you need 2.0.5 for this feature to work. I had the same issue under Windows where I had to update SDL2. I'd already updated mine in order to compile the latest MAME.

[progets]

Does anyone have issues with a controller/joystick/gamepad controlling the RetroFE frontend after launching and playing a game? Once I return from playing the first game in RetroFE the gamepad no longer controls RetroFE and only a keyboard works.

Try the latest code; I've hopefully added hot-pluggability, which should also fix this issue.

Having issues with the new build. I haven't had a lot of time to test but here's what I see for now.

Code: [Select]

pi@retropie:~/retrofe $ cmake --build RetroFE/Build
[  2%] Building CXX object CMakeFiles/retrofe.dir/Control/UserInput.cpp.o
/home/pi/retrofe/RetroFE/Source/Control/UserInput.cpp: In member function ‘bool UserInput::update(SDL_Event&)’:
/home/pi/retrofe/RetroFE/Source/Control/UserInput.cpp:302:72: error: ‘SDL_JoystickFromInstanceID’ was not declared in this scope
         SDL_JoystickClose( SDL_JoystickFromInstanceID( e.jdevice.which ) );
                                                                        ^
CMakeFiles/retrofe.dir/build.make:158: recipe for target 'CMakeFiles/retrofe.dir/Control/UserInput.cpp.o' failed
make[2]: *** [CMakeFiles/retrofe.dir/Control/UserInput.cpp.o] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/retrofe.dir/all' failed
make[1]: *** [CMakeFiles/retrofe.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
pi@retropie:~/retrofe $


Seems like the SDL version of RetroPie is out of date; you need 2.0.5 for this feature to work. I had the same issue under Windows where I had to update SDL2. I'd already updated mine in order to compile the latest MAME.

I ran "bash <(curl -s https://bitbucket.org/phulshof/retrofe/raw/default/Scripts/Raspi2/install.sh)" tonight. Doesn't this install SDL2 from source? If so, how can I get a "newer" version?

Update - I see that the script only calls for SDL2 2.0.3 now.

Update 2 - Once I compiled SDL2 2.0.5 I was able to compile the latest RetroFe. The controller issue has been resolved with this RetroFE build. Great work Pieter!