• Visual Boy Advance - M
  • Building
  • Cross compiling for 32 bit on a 64 bit host
  • Cross Compiling for Win32
  • CMake Options
  • MSys2 Notes
  • Debug Messages
  • Reporting Crash Bugs
  • Contributing

Visual Boy Advance - M

Game Boy Advance Emulator

Homepage and Forum: http://vba-m.com

Windows and Mac builds are in the releases tab.

Daily Ubuntu packages here: https://code.launchpad.net/~sergio-br2/+archive/ubuntu/vbam-trunk

Your distribution may have packages available as well, search for "vbam" or "visualboyadvance-m".

It is also generally very easy to build from source, see below.

If you are using the windows binary release and you need localization, unzip the translations.zip to the same directory as the executable.

Note for Windows Users

If you are having issues, try resetting your config file first.

• open file explorer
• in the location bar, type %USERPROFILE%\AppData\Local and press enter
• delete the directory called visualboyadvance-m

Building

The basic formula to build vba-m is:

cd ~ && mkdir src && cd src
git clone https://github.com/visualboyadvance-m/visualboyadvance-m.git
cd visualboyadvance-m
./installdeps

# ./installdeps will give you build instructions, which will be similar to:

mkdir build && cd build
cmake ..
make -j`nproc`

./installdeps is supported on MSys2, Linux (Debian/Ubuntu, Fedora, Arch, Solus and RHEL/CentOS) and Mac OS X (homebrew, macports or fink.)

The Ninja cmake generator is also now supported, including on msys2 and Visual Studio.

Building a Libretro core

Clone this repo and then,
$ cd src
$ cd libretro
$ make

Copy vbam_libretro.so to your RetroArch cores directory.

Visual Studio Support

For visual studio, dependency management is handled automatically with vcpkg, just clone the repository with git and build with cmake. You can do this from the developer command line as well. 2019 will not work yet for building dependencies, but you can build the dependencies in 2017 and then use the project from 2019.

Using your own user-wide installation of vcpkg is supported, just make sure the environment variable VCPKG_ROOT is set.

To build in the visual studio command prompt, use something like this:

mkdir vsbuild
cd vsbuild
cmake .. -DVCPKG_TARGET_TRIPLET=x64-windows
msbuild /m .\ALL_BUILD.vcxproj

Dependencies

If your OS is not supported, you will need the following:

• C++ compiler and binutils
• make
• CMake
• git
• nasm (optional, for 32 bit builds)

And the following development libraries:

• zlib (required)
• mesa (if using X11 or any OpenGL otherwise)
• ffmpeg (optional, for game recording)
• gettext and gettext tools (optional, with ENABLE_NLS)
• png (required)
• SDL2 (required)
• SFML (optional, for link)
• OpenAL (optional, a sound interface)
• wxWidgets (required, 2.8 is still supported, --enable-stl is supported)

On Linux and similar, you also need the version of GTK your wxWidgets is linked to (usually 2 or 3).

Support for more OSes/distributions for ./installdeps is planned.

Cross compiling for 32 bit on a 64 bit host

./installdeps m32 will set things up to build a 32 bit binary.

This is supported on Fedora, Arch, Solus and MSYS2.

Cross Compiling for Win32

./installdeps takes one optional parameter for cross-compiling target, which may be win32 which is an alias for mingw-w64-i686 to target 32 bit Windows, or mingw-gw64-x86_64 for 64 bit Windows targets.

The target is implicit on MSys2 depending on which MINGW shell you started (the value of $MSYSTEM.) It will not run in the MSys shell.

On Debian/Ubuntu this uses the MXE apt repository and works really well.

On Fedora it can build using the Fedora MinGW packages, albeit with wx 2.8, no OpenGL support, and no Link support for lack of SFML.

On Arch it currently doesn't work at all because the AUR stuff is completely broken, I will at some point redo the arch stuff to use MXE as well.

CMake Options

The CMake code tries to guess reasonable defaults for options, but you can override them on the cmake command with e.g.:

cmake .. -DENABLE_LINK=NO

Of particular interest is making RELEASE or DEBUG builds, the default mode is RELEASE, to make a DEBUG build use something like:

cmake .. -DCMAKE_BUILD_TYPE=Debug

Here is the complete list:

Note for distro packagers, we use the CMake module GNUInstallDirs to configure installation directories.

MSys2 Notes

To run the resulting binary, you can simply type:

./visualboyadvance-m

in the shell where you built it.

If you built with -DCMAKE_BUILD_TYPE=Debug, you will get a console app and will see debug messages, even in mintty.

If you want to start the binary from e.g. a shortcut or Explorer, you will need to put c:\msys64\mingw32\bin for 32 bit builds and c:\msys64\mingw64\bin for 64 bit builds in your PATH (to edit system PATH, go to Control Panel -> System -> Advanced system settings -> Environment Variables.)

If you want to package the binary, you will need to include the MinGW DLLs it depends on, they can install to the same directory as the binary.

For our own builds, we use MXE to make static builds.

Debug Messages

We have an override for wxLogDebug() to make it work even in non-debug builds of wx and on windows, even in mintty. Using this function for console debug messages is recommended.

It works like printf(), e.g.:

int foo = 42;
wxLogDebug(wxT("the value of foo = %d"), foo);

Reporting Crash Bugs

If the emulator crashes and you wish to report the bug, a backtrace made with debug symbols would be immensely helpful.

To generate one (on Linux and MSYS2) first build in debug mode by invoking cmake as:

cmake .. -DCMAKE_BUILD_TYPE=Debug

After you've reproduced the crash, you need the core dump file, you may need to do something such as:

ulimit -c unlimited

in your shell to enable coredump files.

This post explains how to retrieve core dump on Fedora Linux (and possibly other distributions.)

Once you have the core dump file, open it with gdb, for example:

gdb -c core ./visualboyadvance-m

In the gdb shell, to print the backtrace, type:

bt

This may be a bit of a hassle, but it helps us out immensely.

Contributing

Please keep in mind that this app needs to run on Windows, Linux and macOS at the very least, so code should be portable and/or use the appropriate #ifdefs and the like when needed.

Please try to craft a good commit message, this post by the great tpope explains how to do so: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

If you have multiple small commits for a change, please try to use git rebase -i (interactive rebase) to squash them into one or a few logical commits (with good commit messages!) See: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History if you are new to this.