Open palmerj opened 3 years ago
palmerj
commented
2 years ago Oh wow! Does this work still?
I got it to compile last year, but the performance was terrible with videos (I had avi files from memory), and I never got time to further debug. I haven't tried with the latest codebase. Give it a try and see.
I'm stuck before compiling at:
Did you install the packages via brew I documented in the readme?
phulshof
commented
2 years ago My apologies for never getting back to you on this one. I cannot verify these changes, since I don't run MacOS, but if you create a new merge pull request I will review the changes, and add them to the code base.
2V3EvG4LMJFdRe
commented
2 years ago Did you install the packages via brew I documented in the readme?
Yup. It's weird, it seems they are on the path:
sdl2-config
Usage: /usr/local/bin/sdl2-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--cflags] [--libs] [--static-libs]Just don't seem to get picked up by cmake.
Indeed, it compiles if I remove the # Setup some variables to help find external libraries requirements from CMakeLists.txt with some errors:
In file included from /Users/redacted/RetroFE/RetroFE/Source/Graphics/Component/VideoComponent.cpp:21:
/Users/redacted/RetroFE/RetroFE/Source/Graphics/Component/../../Video/GStreamerVideo.h:22:10: fatal error: 'gst/gst.h' file not found
#include <gst/gst.h>
^~~~~~~~~~~
1 error generated.
make[2]: *** [CMakeFiles/retrofe.dir/Graphics/Component/VideoComponent.cpp.o] Error 1
make[1]: *** [CMakeFiles/retrofe.dir/all] Error 2
make: *** [all] Error 2What does sdl2-config --prefix return? Do you have Macports installed?
palmerj
commented
2 years ago Here's a compiled build (from a re-resync with phulshof:master) from my intel mac if that helps you. https://drive.google.com/file/d/1JI1USj6KJtETLRITZCKjR2ONVHRtww7m/view?usp=share_link
I would be interested to know how it works for you. I have troubles with videos after some period of time. I think there is some sort of memory leak.
Note you may need to set the GST_PLUGIN_SYSTEM_PATH environment variable to get videos working. In this case using homebrew that would be GST_PLUGIN_SYSTEM_PATH="/usr/local/lib/gstreamer-1.0". You can also run the process from the command line like GST_PLUGIN_SYSTEM_PATH="/usr/local/lib/gstreamer-1.0" ./retrofe. Ideally I think we should use frameworks included in the bundle to remove all of these issues, but that a lot more work.
palmerj
commented
2 years ago My apologies for never getting back to you on this one. I cannot verify these changes, since I don't run MacOS, but if you create a new merge pull request I will review the changes, and add them to the code base.
@phulshof no worries at all. I have brought the PR up-to-date with master so this is good to merge now.
2V3EvG4LMJFdRe
commented
2 years ago What does sdl2-config --prefix return? Do you have Macports installed?
/usr/local
echo $PATH
/Users/redacted/opt/miniconda3/bin:/Users/redacted/.nvm/versions/node/v17.4.0/bin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/3.9/bin:/Library/Frameworks/Python.framework/Versions/3.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/VMware Fusion.app/Contents/Public:/opt/X11/bin:/Users/redacted/.mongodb/bin:/Users/redacted/n/binIt's really frustrating because I can read on that forum thread I made that I had the exact same error last time, but it's not written how I resolved it. From what I remember it, it had to do with the path, maybe along the line of export LIBRARY_PATH or PATH= but nothing I try changed anything about that outcome unless I delete the requirements.
Sadly I'm running High Sierra so your kindly compiled app doesn't work. The thing is that I had crashes with video too from what you can read on that thread last time I compiled, but I know Emumovies is changing to mp4 or mkv so if it's an issue with .avi (which I also had) then it'd possibly be sorted out from now on.
palmerj
commented
2 years ago It's really frustrating because I can read on that forum thread I made that I had the exact same error last time, but it's not written how I resolved it. From what I remember it, it had to do with the path, maybe along the line of export LIBRARY_PATH or PATH= but nothing I try changed anything about that outcome unless I delete the requirements.
Yeah it will be something to do with your OS, xcode version, and libraries installed. Note looking at your path, the system seems pretty polluted with many installed applications and libraries! Sorry, but I can't really help much more here cause I don't have access to High Sierra or your setup. All I can recommend is trying to build from a fresh install and if possible, a newer OS.
Sadly I'm running High Sierra so your kindly compiled app doesn't work.
Ah sorry about that. I have added the following the CMake config to build for 10.12 and higher, so hopefully, the binary has a better chance of running on your OS now.
cmake_minimum_required (VERSION 2.8)
if(APPLE)
set(CMAKE_OSX_DEPLOYMENT_TARGET "10.12.0" CACHE STRING "Minimum OS X deployment version")
endif()
project (retrofe)Please give it another try: https://drive.google.com/file/d/1JI1USj6KJtETLRITZCKjR2ONVHRtww7m/view?usp=share_link
Note the binary is linking against the following homebrew libraries, so you will need them installed on your local machine too:
❯ otool -L retrofe
retrofe:
/usr/local/opt/gst-plugins-base/lib/libgstvideo-1.0.0.dylib (compatibility version 2004.0.0, current version 2004.0.0)
/usr/local/opt/gst-plugins-base/lib/libgstaudio-1.0.0.dylib (compatibility version 2004.0.0, current version 2004.0.0)
/usr/local/opt/gstreamer/lib/libgstbase-1.0.0.dylib (compatibility version 2005.0.0, current version 2005.0.0)
/usr/local/opt/gstreamer/lib/libgstreamer-1.0.0.dylib (compatibility version 2005.0.0, current version 2005.0.0)
/usr/local/opt/glib/lib/libgobject-2.0.0.dylib (compatibility version 7401.0.0, current version 7401.0.0)
/usr/local/opt/glib/lib/libglib-2.0.0.dylib (compatibility version 7401.0.0, current version 7401.0.0)
/usr/local/opt/gettext/lib/libintl.8.dylib (compatibility version 12.0.0, current version 12.0.0)
/usr/local/opt/sdl2/lib/libSDL2-2.0.0.dylib (compatibility version 2401.0.0, current version 2401.2.0)
/usr/local/opt/sdl2_image/lib/libSDL2_image-2.0.0.dylib (compatibility version 601.0.0, current version 601.2.0)
/usr/local/opt/sdl2_mixer/lib/libSDL2_mixer-2.0.0.dylib (compatibility version 601.0.0, current version 601.2.0)
/usr/local/opt/sdl2_ttf/lib/libSDL2_ttf-2.0.0.dylib (compatibility version 2001.0.0, current version 2001.1.0)As mentioned before, we should look to bundle the libraries or frameworks, but that's for another day.
The thing is that I had crashes with video too from what you can read on that thread last time I compiled, but I know Emumovies is changing to mp4 or mkv so if it's an issue with .avi (which I also had) then it'd possibly be sorted out from now on.
The interesting thing is I tested the newly compiled retreofe today and mp4 videos work! I have yet to try mkv. But I was getting issues with mp4 earlier in the year and gave up due to time - so this is positive news. So either @phulshof has improved the codebase to help us MacOS, or the support libraries (e.g gstreamer) have fixed something.
palmerj
commented
2 years ago In file included from /Users/redacted/RetroFE/RetroFE/Source/Graphics/Component/VideoComponent.cpp:21: /Users/redacted/RetroFE/RetroFE/Source/Graphics/Component/../../Video/GStreamerVideo.h:22:10: fatal error: 'gst/gst.h' file not found
include <gst/gst.h>
Sorry I should have mentioned this before but do you have the following header installed (file and symlink)?
❯ realpath /usr/local/include/gstreamer-1.0/gst/gst.h
/usr/local/Cellar/gstreamer/1.20.4/include/gstreamer-1.0/gst/gst.hNote looking at your path, the system seems pretty polluted with many installed applications and libraries!
You're right. A couple of those paths are from apps I have uninstalled. I guess it's a good idea to test out a cleaner instance on a VM mmm
Please give it another try: https://drive.google.com/file/d/1JI1USj6KJtETLRITZCKjR2ONVHRtww7m/view?usp=share_link
Thank you kindly for keeping up with me. It's compatible with High Sierra now, although I still get a crash from incompatible libraries:
Dyld Error Message:
Library not loaded: /usr/local/opt/gst-plugins-base/lib/libgstvideo-1.0.0.dylib
Referenced from: /private/var/folders/*/RetroFE.app/Contents/MacOS/retrofe
Reason: Incompatible library version: retrofe requires version 2004.0.0 or later, but libgstvideo-1.0.0.dylib provides version 1803.0.0
Binary Images:
0x1029ba000 - 0x102b81fff +com.retrofe.RetroFE (0.7.20 - 0.7.20) <AD4C80D2-77A4-3E6D-8C0F-EFAF1D7EFA06> /var/folders/*/RetroFE.app/Contents/MacOS/retrofe
0x10d092000 - 0x10d0dcadf dyld (551.5) <CB9BFB56-4511-36F1-A546-891FF770C01C> /usr/lib/dyldWas that brew install gstreamer?
Sorry I should have mentioned this before but do you have the following header installed (file and symlink)?
I don't know how to check these, sorry. The first path exists, the second one doesn't. I have /usr/local/Cellar/gstreamer/1.18.2/include/gstreamer-1.0/gst/gst.h instead. brew install gstreamer or brew install gstreamer --HEAD won't update it further than 1.18.2.
The interesting thing is I tested the newly compiled retreofe today and mp4 videos work! I have yet to try mkv. But I was getting issues with mp4 earlier in the year and gave up due to time - so this is positive news. So either @phulshof has improved the codebase to help us MacOS, or the support libraries (e.g gstreamer) have fixed something.
Wow, that's great news! I'm thinking gstreamer was the culprit since the name appears time and time again on these issues.
palmerj
commented
2 years ago Was that brew install gstreamer?
I think that the libgstvideo library is part of gst-plugins-base. Looks like your OS doesn't support brew packages with as high as a versions as I'm using.
I have /usr/local/Cellar/gstreamer/1.18.2/include/gstreamer-1.0/gst/gst.h
Seems your compiler should find the header if you have /usr/local/include/gstreamer-1.0/gst/gst.h. I would run make VERBOSE=1 and check the include paths to see if /usr/local/include/gstreamer-1.0 is there. If not, then that needs to be fixed in the CMakefile.txt config.
palmerj
commented
2 years ago So I had more free time today and started looking at how to build retrofe against MacOS frameworks. I've uploaded a test package https://drive.google.com/file/d/1JI1USj6KJtETLRITZCKjR2ONVHRtww7m/view. Give it a try.
Run RetroFE.app for a fully contained MacOS bundle that should work on MacOS 10.11 and up. The binary is now linked to the following libraries and frameworks:
RetroFE.app/Contents/MacOS/retrofe:
@rpath/SDL2.framework/Versions/A/SDL2 (compatibility version 2601.0.0, current version 2601.0.0)
@rpath/SDL2_image.framework/Versions/A/SDL2_image (compatibility version 3.0.0, current version 601.2.0)
@rpath/SDL2_mixer.framework/Versions/A/SDL2_mixer (compatibility version 3.0.0, current version 601.2.0)
@rpath/SDL2_ttf.framework/Versions/A/SDL2_ttf (compatibility version 15.0.0, current version 2001.1.0)
@rpath/GStreamer.framework/Versions/1.0/lib/GStreamer (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.32.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)The frameworks are installed in the bundle, so you don't need to install any more dependencies now.
Also, note that the retrofe binary in the root of the directory can be run if you have the following frameworks installed in /Library/Frameworks:
I would only use that option if you don't want to use the app bundle.
2V3EvG4LMJFdRe
commented
2 years ago That's excellent! That app bundle runs and seems to work well from what I can tell on first impressions. The performance is much improved from the already working Wine setup I was had. I've migrated my files immediately, just need to make the appropriate changes to my config to see what works and what doesn't.
One thing I will suggest if you can manage it is moving all the folders into the app bundle - under "Contents/Resources" perhaps. I believe that in compliance with macOS standards for apps. Bit of an OCD thing too, the only apps I have foldered are multi-platform programs that I'm always on the lookout to replace 😅
palmerj
commented
2 years ago That app bundle runs and seems to work well from what I can tell on first impressions
Awesome!! I would be really interested to see how it goes. I have it working ok with basic layouts and configs, but I have yet to test more advanced features and setups with scripts.
One thing I will suggest if you can manage it is moving all the folders into the app bundle - under "Contents/Resources" perhaps. I believe that in compliance with macOS standards for apps. Bit of an OCD thing too, the only apps I have foldered are multi-platform programs that I'm always on the lookout to replace 😅
Yeah, I was thinking about that for sure (I'm a little OCD too) - it's definitely not the MacOS way, but I wanted to ensure it worked for your first. AFAIK there are two approaches to this.
Contents/Resources inside the bundle. As you pointed out, I feel it is best to go with option one. @phulshof do you have any views?
2V3EvG4LMJFdRe
commented
2 years ago Hmmm I believe it's that second option you list that all the major apps use, including the ones bundled with the system. Some multi-platform apps have it at ~./config in the user's folder, it's all over the place, but the tendency and personally too I would prefer it in ~/Library/Application Support/RetroFE, most users don't know about right click > Show Package Contents.
Files that aren't personal configs (core, meta.db, retrofe, the .ico and .png) should probably go inside Contents/Resources.
2V3EvG4LMJFdRe
commented
2 years ago I've messed around further with the build and I'm happy to report again that it runs super smooth and much better than what I had on wine 👍 There are just a handful of missing links:
fullscreen = no uses the legacy fullscreen mode of macOS. This is a leftover fullscreen implementation that doesn't play nice with the OS: Command+Tab doesn't work or doesn't show the transition animation, PiP windows aren't layered on top, etc. I'm not sure how it is invoked, but I found a way to bypass it. A while ago, I asked phulshof if he could implement a windowed mode, which he added as: fullscreen = no
windowBorder = yes
windowResize = yesWith these, RetroFE launches as a window which you can maximize into the proper fullscreen mode with the green button.
That's mostly to lay the information out there. Now, if anyone finds a way to launch the app properly fullscrenned, that'd be even better.
By the way, have you had the chance to look at the files I sent you by mail? 👀
palmerj
commented
2 years ago Fullscreen
I don't think this is a legacy mode, but maybe @phulshof can comment. But the difference is fullscreen=yes asks OS to set an exclusive specified video mode. fullscreen=no is just an ordinary window, but window size is set to match the desktop resolution, and window decorations are disabled (well almost see below)
Note I've tested using fullscreen = yes (with defaults of windowBorder = no and windowResize = no) because I think it gives the best control for resolution and gives the application more exclusive control of keys, but it depends on what you are after. At the moment, the downside of using this method is some standard desktop shortcuts do not work, but it is possible to improve this. Currently, you can use CMD+H to minimise/hide the app when it's running, and it will return to the desktop. With fullscreen = no I can still see the menubar, which isn't nice. Did you manage to avoid this? What do you mean by missing transition animation? The intro video and transitions artwork into loading games works for me.
Keyboard - The keyboard arrows moves the entries by order of two 🤔 Controller works fine. Any idea?
Yeah sorry, I did notice that and haven't investigated. However, now you have seen the same I will take a closer look.
Exit - Right click > Quit doesn't work (from the dock) nor does the red button for the window.
Ok I can confirm this when in windowed mode. So my guess is some signal event is not being processed.
By the way, have you had the chance to look at the files I sent you by mail? 👀
I didn't see anything. Did you try the Gmail one ending in nz? I might have used the wrong email in the commit. I've updated PR to use my correct email. Have at look at the latest commit https://github.com/phulshof/RetroFE/commit/15ff2b68eb6eed1e8743280557fb52ac39fcbb20 (add .patch on the end of the URL to see the email)
palmerj
commented
2 years ago I've played around with this patch to implement quit event on the application, as well as use fullscreen desktop mode. I will try to debug the double move and then make a new release.
diff --git a/RetroFE/Source/RetroFE.cpp b/RetroFE/Source/RetroFE.cpp
index 3046890..064372b 100644
--- a/RetroFE/Source/RetroFE.cpp
+++ b/RetroFE/Source/RetroFE.cpp
@@ -1445,11 +1449,19 @@ RetroFE::RETROFE_STATE RetroFE::processUserInput( Page *page )
SDL_Event e;
while ( SDL_PollEvent( &e ) )
{
+ if ( e.type == SDL_QUIT )
+ {
+ Logger::write( Logger::ZONE_DEBUG, "RetroFE", "SDL_QUIT called" );
+ attract_.reset( );
+ return RETROFE_QUIT_REQUEST;
+
+ }
input_.update(e);
if ( e.type == SDL_KEYDOWN && !e.key.repeat )
{
break;
}
+
}
// Handle next/previous game inputs
diff --git a/RetroFE/Source/SDL.cpp b/RetroFE/Source/SDL.cpp
index cc2f8de..83e498e 100644
--- a/RetroFE/Source/SDL.cpp
+++ b/RetroFE/Source/SDL.cpp
@@ -166,11 +170,11 @@ bool SDL::initialize( Configuration &config )
if ( fullscreen_[i] )
{
-#ifdef WIN32
+// #ifdef WIN32
windowFlags |= SDL_WINDOW_FULLSCREEN_DESKTOP;
-#else
- windowFlags |= SDL_WINDOW_FULLSCREEN;
-#endif
+// #else
+// windowFlags |= SDL_WINDOW_FULLSCREEN;
+// #endif
}
int rotation= 0;
I don't think this is a legacy mode, but maybe @phulshof can comment. But the difference is fullscreen=yes asks OS to set an exclusive specified video mode. fullscreen=no is just an ordinary window, but window size is set to match the desktop resolution, and window decorations are disabled (well almost see below)
Legacy fullscreen is a term I borrowed from some posts online I've seen discussing the issue before. It might be an (obscure) official term, but don't quote me on it. The OpenGL build of RetroArch has the issue, but not the Metal one. The thing for me that really sours the experience is the lack of playing along with the desktop. Try fullscreening Finder and then cmd+tab to another window - you'll see a sliding animation there that is not present for RetroFE fullscreen = yes (in fact, you can't even cmd+tab out of it at all). If you start RetroFE with fullscreen = no and click on the green button of the menubar, you'll get the proper fullscreen mode with all the playing along nicely stuff - no menubar either. What would be ideal for everyone would be to start the app this way.
Yeah sorry, I did notice that and haven't investigated. However, now you have seen the same I will take a closer look.
I used to fix this type of stuff by modifying the deadzone setting under controls.conf, but it's not helping now. What's interesting is, if you use the keyboard while you have a controller plugged in, it's sorted out. It's hit or miss though, I have to reconnect the controller a couple of times before it fixes the keyboard behaviour. There's some acceleration thing going on there.
I didn't see anything. Did you try the Gmail one ending in nz? I might have used the wrong email in the commit. I've updated PR to use my correct email. Have at look at the latest commit.
I'll send it again, I had used the libretro address.
Sadly, I can't vouch for any of the code 😞 I'm just a professional layman.
Oh wow! Does this work still? Been running RetroFE on Wine for a while.
I'm stuck before compiling at:
It's because the modules installed by brew are not linked properly with export
LIBRARY_PATH=/usr/local/opt/gst-plugins-base/lib:/usr/local/opt/gstreamer/lib:/usr/local/lib:/usr/local/opt/glib/lib:/usr/local/opt/gettext/lib. I know I solved it once per a thread on the forum:http://retrofe.nl/SMF/index.php?topic=455.15 but the solution I linked to is a 404 now.