Updated for building on MacOS #5
Conversation
|
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 |
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.
Did you install the packages via brew I documented in the readme? |
|
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. |
Yup. It's weird, it seems they are on the path: Just don't seem to get picked up by cmake. Indeed, it compiles if I remove the |
|
What does |
|
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 |
@phulshof no worries at all. I have brought the PR up-to-date with master so this is good to merge now. |
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 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. |
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.
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. 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: As mentioned before, we should look to bundle the libraries or frameworks, but that's for another day.
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. |
Sorry I should have mentioned this before but do you have the following header installed (file and symlink)? |
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
Thank you kindly for keeping up with me. It's compatible with High Sierra now, although I still get a crash from incompatible libraries: Was that
I don't know how to check these, sorry. The first path exists, the second one doesn't. I have
Wow, that's great news! I'm thinking gstreamer was the culprit since the name appears time and time again on these issues. |
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.
Seems your compiler should find the header if you have /usr/local/include/gstreamer-1.0/gst/gst.h. I would run |
|
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: The frameworks are installed in the bundle, so you don't need to install any more dependencies now. Also, note that the
I would only use that option if you don't want to use the app bundle. |
|
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 😅 |
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.
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.
As you pointed out, I feel it is best to go with option one. @phulshof do you have any views? |
|
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 Files that aren't personal configs ( |
|
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:
With 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? 👀 |
…arameter to allow resizable windows with border
…jbFastRewind5p, jbPause, and jbRestart JukeBox key codes. Added duration and current as ReloadableText types.
…e and reloadableText.
…ackage directory.
…ssues with video walls.
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
Yeah sorry, I did notice that and haven't investigated. However, now you have seen the same I will take a closer look.
Ok I can confirm this when in windowed mode. So my guess is some signal event is not being processed.
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 15ff2b6 (add |
|
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;
|
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
I used to fix this type of stuff by modifying the
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. |
No description provided.