What is DMG ?

[spotanjo3]

And can it compile for macOS ?

[shonumi]

DMG = Dot Matrix Game. That's the 3-letter code Nintendo used for the original Game Boy (black and white one).

If you're wondering whether or not GBE+ will compile on MacOS, it should but no one has verified it.

[spotanjo3]

DMG = Dot Matrix Game. That's the 3-letter code Nintendo used for the original Game Boy (black and white one).

If you're wondering whether or not GBE+ will compile on MacOS, it should but no one has verified it.

Very good. Thanks.

I can compile it for you. I did with several emulators. Succeed. The problem is yours and maybe you can help me out ?

I did this:

git clone https://github.com/shonumi/gbe-plus.git

cd gbe-plus

export QT5_DIR=$(brew --prefix)/opt/qt5

mkdir build && cd build

cmake .. -DCMAKE_OSX_ARCHITECTURES="x86_64;x86_64h" -DCMAKE_BUILD_TYPE=Release

I got an error:

-- The C compiler identification is AppleClang 11.0.0.11000033 -- The CXX compiler identification is AppleClang 11.0.0.11000033 -- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc -- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ -- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ - works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found SDL2: /usr/local/lib/libSDL2main.a;/usr/local/lib/libSDL2.dylib;-framework Cocoa
-- Found SDL2NET: /usr/local/lib/libSDL2_net.dylib CMake Warning (dev) at /usr/local/Cellar/cmake/3.17.0_1/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:272 (message): The package name passed to find_package_handle_standard_args (SDL2) does not match the name of the calling package (SDL2NET). This can lead to problems in calling code that expects find_package result variables (e.g., _FOUND) to follow a certain pattern. Call Stack (most recent call first): CMakeTests/FindSDL2NET.cmake:83 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:32 (find_package) This warning is for project developers. Use -Wno-dev to suppress it.

-- Found OpenGL: /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/OpenGL.framework
CMake Error at /usr/local/Cellar/cmake/3.17.0_1/share/cmake/Modules/FindQt4.cmake:1314 (message): Found unsuitable Qt version "5.14.1" from /usr/local/bin/qmake, this code requires Qt 4.x Call Stack (most recent call first): CMakeLists.txt:91 (find_package)

-- Configuring incomplete, errors occurred! See also "/Users/username/gbe-plus/build/CMakeFiles/CMakeOutput.log".

Did you find what's the error ?

[spotanjo3]

To my understanding.. sdl2 does not match the name of the calling package SDL2net ?

And I am using Qt 5 and according to this error: Found unsuitable Qt version "5.14.1"... this code requires Qt 4.x. Obviously, your Qt is older version.

[shonumi]

Make sure you have SDL2net installed.

Alternatively, you can disable SDL2net. Change this line in CMakeLists.txt from this:

option(LINK_CABLE "Enable link cable emulation (requires SDL2_net)" ON)

To this:

option(LINK_CABLE "Enable link cable emulation (requires SDL2_net)" OFF)

[spotanjo3]

Make sure you have SDL2net installed.

Alternatively, you can disable SDL2net. Change this line in CMakeLists.txt from this:

option(LINK_CABLE "Enable link cable emulation (requires SDL2_net)" ON)

To this:

option(LINK_CABLE "Enable link cable emulation (requires SDL2_net)" OFF)

I understand.. I have it installed and it mentioned about QT4.. Read the error log please:

The package name passed to find_package_handle_standard_args (SDL2) does not match the name of the calling package (SDL2NET). This can lead to problems in calling code that expects find_package result variables (e.g., _FOUND) to follow a certain pattern. Call Stack (most recent call first): CMakeTests/FindSDL2NET.cmake:83 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:32 (find_package) This warning is for project developers. Use -Wno-dev to suppress it.

-- Found OpenGL: /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/OpenGL.framework CMake Error at /usr/local/Cellar/cmake/3.17.0_1/share/cmake/Modules/FindQt4.cmake:1314 (message): Found unsuitable Qt version "5.14.1" from /usr/local/bin/qmake, this code requires Qt 4.x Call Stack (most recent call first): CMakeLists.txt:91 (find_package)

-- Configuring incomplete, errors occurred! See also "/Users/username/gbe-plus/build/CMakeFiles/CMakeOutput.log".

[spotanjo3]

Can you help ?

[shonumi]

You can disable Qt altogether from CMakeLists.txt as well. It will build the Command-Line only version, but you should probably try building that before the Qt GUI version.

Also, my ability to help is quite limited as I don't have any access to macOS.

[spotanjo3]

You can disable Qt altogether from CMakeLists.txt as well. It will build the Command-Line only version, but you should probably try building that before the Qt GUI version.

Also, my ability to help is quite limited as I don't have any access to macOS.

I prefer GUI instead of Command-Line. I understand that you have limited. That's alright. I have Dell laptop as well. Just want to check it out for macOS, is all. Much obliged, thought. :) Keep up the good work for Windows version.

[alchzh]

Hey, I also don't have macOS but one of the links here might work: https://wiki.qt.io/Qt_4_versions

You will need to install the development tools for Qt4 (quite old software) rather than the Qt5 you already have, as Qt5 is incompatible with Qt4. Cmake might have some difficulty finding the Qt4 installation, if that happens comment again and I'll help you out with the flags

[spotanjo3]

Hey, I also don't have macOS but one of the links here might work: https://wiki.qt.io/Qt_4_versions

You will need to install the development tools for Qt4 (quite old software) rather than the Qt5 you already have, as Qt5 is incompatible with Qt4. Cmake might have some difficulty finding the Qt4 installation, if that happens comment again and I'll help you out with the flags

Hey and thanks. However, I am not sure I shall because I do not want Qt4 and Qt5 to be conflicts, do they?

[alchzh]

Qt4 shouldn't conflict with Qt5 -- it'll install to a different directory that cmake will then either find or you will need to point to manually

https://github.com/cartr/homebrew-qt4 might be useful as well if you use homebrew

[spotanjo3]

Thank you but according to this:

Please note: Qt4 is unsupported by its creators, so there are likely security/usability problems with it that will never be resolved. If you can, please consider migrating your projects to Qt5.

On Tue, Apr 14, 2020 at 2:51 PM Albert Zhang notifications@github.com wrote:

Qt4 shouldn't conflict with Qt5 -- it'll install to a different directory that cmake will then either find or you will need to point to manually

https://github.com/cartr/homebrew-qt4 might be useful as well if you use homebrew

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shonumi/gbe-plus/issues/111#issuecomment-613489312, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD5X34V6MA5TMIUS3AQBN3LRMR2A5ANCNFSM4L2WDUHA .

-- In Memory of Spot (FOREVER)

[alchzh]

Yes, Qt4 has been unsupported for a few years now with all development focused on Qt5. That being said, this project (GBE+) is quite old and it's not like network infrastructure software or anything -- the software was used for many years and is quite battle tested, at worst in a very specific scenario loading some kind of image can crash Qt4.

Migrating any project to Qt5 is not a large undertaking, but really unnecessary at the moment for an emulator focused on emulation accuracy, not having an extremely functional frontend. If you or anyone else is willing to migrate the old codebase to Qt5, you're welcome to try. Most of the work (usually) is in changing headers and config files, though I haven't looked at GBE+'s source.

For the time being, if you just want to run the emulator, install Qt4 on macOS and tell us how it goes.

[shonumi]

FWIW, GBE+ continues to support Qt4 because the OS I use (Slackware Current) is still on 4.8.7. Additionally, on the C++ side of things, when GBE+ moved to Qt5, it was literally as simple as changing just six lines of code across a handful of headers and files (about 10 or 11 iirc). I don't think anything else needed to change, except for CMake stuff. The basics of Qt (menus, text boxes, buttons, etc) didn't change drastically from 4.x to 5.x, so nothing needed to be reworked in GBE+.

At any rate, I should let everyone know that Qt4 and Qt5 are probably not going to be used for GBE+'s frontend when 1.5 comes out next year. Some brief reasons:

• I don't really like the direction Qt in general is moving towards. The current Qt code in GBE+ is quite bloated, especially in relation to CGFX.

• On Windows, it requires me to bundle a bunch of DLLs causing the entire 7z archive to be around 17MB (~70MB when uncompressed!). Seems excessive... Projects like Citra have the same issue.

• Some things I'd like to really do via a GUI (game lists for one thing) have been put on hold due to how onerous it is working any of them into the current Qt code.

• Apparently there's been a mysterious crash with Qt5 on Windows when trying to use the .ini file. It's been there for over a year now, and I can't pinpoint the source. Doesn't happen with the command-line version. Doesn't happen with the Qt4 version on Linux. This was actually the final straw because whatever Qt5 is doing wrong, it's not real obvious and it feels like something I don't really have any control over.

So, a new, simpler, more maintainable GUI solution is coming, hopefully one based entirely on SDL (meaning less external dependencies).

[shakeyourbunny]

Have you considered looking int WxWidgets ( https://www.wxwidgets.org/ ) or FLTK ( https://www.fltk.org/ )?

I don't advocate both, but these are also cross-platform C++ UI libraries not unlike QT and the added bonus is that they use the native widgets of the platform instead of having to draw these by yourself.

[shonumi]

WxWidgets is worse than Qt IMO in terms of bloat/cruft. I dealt with it for a while (back when Dolphin used to use it). I moved away from it for many of the same reasons Dolphin did.

I used to love FLTK and played around with it quite a bit before I dove into emudev. Unfortunately, it's not really much of a looker. I can deal with having a non-native looking GUI, but I wasn't satisfied with the appearance of its schemes (standard = 90s era Windows, plastic = 2000s era Mac). The gtk+ scheme was the only one that felt decent. But how the emulator looks at the end of the day is important to me, because I personally use GBE+ (and in many ways, I make it for myself).

Suffice to say, I've got something in the works. Yes, it's DIY (or NIH, take your pick), but its something extremely small, light, and targeted for internal use for GBE+. Not quite as barebones as Mednafen's built-in text menus, but something hopefully in the same vein as PPSSPP's SDL UI.

[shakeyourbunny]

I really don't mind the tech behind the user interface as long as it integrates visually natively into the current running user interface style of the operating system. As long the applicatoin does this, I don't care about the underlying UI library.

The reason for this insistence is WinAMP. I used to be a huge fan of NullSoft and this player, also played around much with its skins, but it has the habit to slowly eating up CPU and drawing resources until it hangs the PC. Mind you, at this time I had Windows 98 which then froze the whole computer and afterwards Windows 2000 which still clogged up my single CPU after letting it sit for an hour or so.

ZSNES was also a thing to avoid, the emulator by itself was better than SNES9x, but the UI of the former is really unusable.

The final nail in the coffin in this irrational behaviour was MS Office 2007 with its butt-ugly blueish self-drawn user interface paradigma and in the more recent times, all electron-based applications which eat up resources like candy, compared to their functionality and integration into the platform.

Since then I avoid applications which do they own thing UI wise like the plague :-)

Dunno if you hardcode your UI theme, but perhaps you'll read the UI / theming definitions from a theme file (hackable JSON, XML, INI or something), I'd submit some variations ;)

[spotanjo3]

Yes, Qt4 has been unsupported for a few years now with all development focused on Qt5. That being said, this project (GBE+) is quite old and it's not like network infrastructure software or anything -- the software was used for many years and is quite battle tested, at worst in a very specific scenario loading some kind of image can crash Qt4.

Migrating any project to Qt5 is not a large undertaking, but really unnecessary at the moment for an emulator focused on emulation accuracy, not having an extremely functional frontend. If you or anyone else is willing to migrate the old codebase to Qt5, you're welcome to try. Most of the work (usually) is in changing headers and config files, though I haven't looked at GBE+'s source.

For the time being, if you just want to run the emulator, install Qt4 on macOS and tell us how it goes.

Nope. It doesn't worked. Still complaint about: Found unsuitable Qt version "5.14.1" from /usr/local/bin/qmake, this code requires Qt 4.x

I can't used export Qt5_DIR=$(brew --prefix)/opt/qt5 because I dont know what export to type for Qt4

[alchzh]

Try passing -DQT_QMAKE_EXECUTABLE=/path/to/qmake to cmake

[ghost]

@shonumi close this issue