VisualBoyAdvance-M

First off: No, I'm not looking for a Mac build. I am plenty capable of building it myself. However, the build is currently extremely buggy. It took a lot of tweaking just to get it to compile. I can provide some really hackish build fixes for you so that it will at least build on OS X, but after that it doesn't work very well (everything is yellow!), and some of the Mac-specific code just doesn't work on modern OS X.

 

Are there any Mac devs still on this?

I just built VBA-M for the first time today. The latest SVN builds quite nicely. The SDL version is much more yellow than it should be, but if you have X11 installed and use the GTK version, the colouring is normal. The only thing I needed to do to make it build (after installing all the dependencies, of course), was add

-L/opt/X11/lib/

to

vbam/trunk/CMakeFiles/gvbam.dir/link.txt

after running

cmake .

.

ah, great, im glad gvbam works for you [img]<fileStore.core_Emoticons>/emoticons/biggrin.png[/img]/emoticons/biggrin@2x.png 2x" width="20" height="20" />

Oh hey, I just spent my weekend trying to build this myself. It sounds like we had exactly the same experience!

 

I had to make -k it (pages and pages of linker errors) in the end, and most targets couldn't be built, just the core. Had to edit cheatlist.h and joypadconfig.h. And make some changes to gtkmm that I'm not particularly proud of.

 

Finding dependencies was a b*tch; had to use Homebrew, MacPorts and Fink combined to get the right versions of everything (and stuff like the gtkmm version wasn't available on any, so I had to build that myself). Then a hundred symlinks to get all of these dependencies to actually show up in my path (not happy that I had to do that manually on a file-by-file basis). Then, because I don't understand how cmake finds this shit automatically, I had to manually populate the CMAKE cache with copypasta'd paths from each dependency's /include/ .pc. Not my proudest moment!

 

Incidentally, I, too, get a yellow-tinted version:

 

With OpenGL (--opengl=1):

 

Without (--opengl=0):

 

But it seems to have a lot smoother video and way better sound than the old 2009 VBA binary that we have (admittedly the terminal options are extremely limited, so dunno about controller, etc... if only the other targets had compiled, we'd have a GUI).

 

Was your experience similar to mine?

 

As for the tinting, I assume this is an OpenGL issue on some level. I wonder if just being careful with the version we use might make some difference…

 

Incidentally, I noticed a choice between Apple's and someone else's OpenGL:

 

#ifdef APPLE

#include 


#include 

#else

#include 


#include 

#endif

 

Though, I have tried a clean make with both of those options, and they were both yellow. But maybe this exists in more places? I need to sleep though~

 

[EDIT]:

Supposedly there is a solution in this thread!

http://vba-m.com/forum/Thread-patch-included-opengl-missing-blue-channel-on-mac-os-x

Yes, that thread is relevant.

 

It will benefit you more to use GVBAM as well on OSX though, alot of changes have been made to bring it in line with the windows builds improving emulation and feature parity.

 

Try building with the latest svn, only sdl.cpp is updated.

I've been appreciating your work on VBA-M for quite a number of years. I wanted to build the latest SDL version for myself, but I found that I needed to make a few changes. I'm not sure if any of this is due to a bad system setup or my lack of expertise in this area, but I wanted to list the changes I needed to make to get r1147 to build on my machine. This was just the SDL port, with no GTK+, localization, linking, LIRC, graphic filter (whatever that is), or FFMPEG support. I used homebrew for all of my dependency needs.

 

1. I needed to alter src/gba/GBALink.cpp . Where it says #include , it needed to say #include

 

1. I needed to alter CMakeLists.txt . Around line 53 or so, where it says SET (SDLMAIN_LIBRARY "-lSDLMain.m"), it needs to say SET (SDLMAIN_LIBRARY "-lSDLMain")

 

1. I added 3 lines to CMakeLists.txt to help cmake find my SDL libraries:

SET(CMAKE_LIBRARY_PATH ${CMAKE_LIBRARY_PATH} /opt/brew/lib)

SET(CMAKE_INCLUDE_PATH ${CMAKE_INCLUDE_PATH} /opt/brew/include/SDL)

link_directories( /opt/brew/lib )

 

It's entirely possible that I could have accomplished the third item using environment variables, but I'm kinda new to this....

i won't alter the cmake file, i leave that to bgka

Aha! did a new build. Pleased to report that it worked without changing source, or CMake file.

 

This was extra-special for me, since last time I wrote the CMakeCache file myself manually (yes, it took fscking aeons). This time I just made sure that all my /lib/pkgconfig directories were on my path, so PKG_CHECK_MODULES() could find them. To find out which paths pkg-config looks for libraries, use:

 

pkg-config --variable pc_path pkg-config
#returns, for me:  /sw/lib/pkgconfig:/sw/share/pkgconfig:/usr/X11/lib/pkgconfig:/usr/X11/share/pkgconfig:/usr/X11R6/lib/pkgconfig:/usr/X11R6/share/pkgconfig:/usr/lib/pkgconfig

 

I noticed that it was missing the MacPorts libraries, and the lib inside ffmpeg itself. So I added them to my bash-profile:

 

# add libraries of MacPorts
export PKG_CONFIG_PATH=/opt/local/lib/pkgconfig
append_path PKG_CONFIG_PATH /sw/lib/ffmpeg-1.0/lib/pkgconfig

 

This even fixed the linking issues I was having when I'd made the CMakeCache by hand, and now I get an OS X package! (doesn't do anything, though; just crashes)

 

EDIT: If anybody's interested, the build I just did is completely vanilla; I did not disable SDL, OpenGL or GTK, so I will declare that it is possible to build that on a Mac with zero errors (though the fact that only the command-line target actually works is another issue [img]<fileStore.core_Emoticons>/emoticons/tongue.png[/img]/emoticons/tongue@2x.png 2x" width="20" height="20" />)

 

EDIT2: Update on Yellow problem. Symptoms have changed; I can turn on --opengl-nearest and it won't be yellow, but if I turn on --ifb-filter=1, (note: 0 and 2 are fine), it goes yellow. In addition, it goes a /tiny/ bit yellow if you turn on certain filters (for example, 2xSaI, Super Eagle, but NOT stretches)

The filters cause a similar problem under opengl on windows, so it needs to have its bit swapping checked as well.

Ah, got it. So, this is not a 'problem with the Mac build'. I suppose this is working as it's meant to.

 

So, are we gonna try and get a binary released out of this?

 

The .app target crashes upon launch (for me), even though it does at least build with no errors.

 

vbamcore works fine, though. But, I don't know what the value of releasing this is, as compared to the old 2009 binary that already exists, and has a GUI.

 

What's new since 2009, and what's different about VBA-M compared to VBA?

Do we have docs on how to save, and how to connect a gamepad, on the commandline version?