June 2015, “Community Choice” Project of the Month – VBA-M

By Community Team

For our June “Community Choice” Project of the Month, the community elected VBA-M, a merge of the original Visual Boy Advance forks. The VBA-M Team shared their thoughts about the project’s history, purpose, and direction.

SourceForge (SF): Tell me about the VBA-M project please.
VBA-M Team: VBA-M started out as a project to merge all known forks of the original Visual Boy Advance into one solid project. I guess you could say “the fork to end all forks” but not at the same time.

SF: What made you start this?
VBA-M Team: We were tired of all the other forks and wanted just a basic build that had the most useful features from various forks. So we merged features from various forks into one place and added a few of our own to make it our own.

SF: Has the original vision been achieved?
VBA-M Team: For the most part we like to think so but like any project, we want to continue improving VBA-M and make it even better. For example, e-reader support, core improvements, and useful features from other forks were added; however, there are still a few things to get working satisfactorily, such as game boy linking; although, recent contributions improved our game compatibility a great deal.

SF: Who can benefit the most from your project?
VBA-M Team: A lot of people benefit from VBA-M, from Game Boy Advance enthusiasts, hardware tinkerers, and folks who own games they no longer have an original system for. For example, a lot of folks played Pokemon on a Game Boy and wished for a bigger screen.

SF: What is the need for improvements upon Visual Boy Advance?
VBA-M Team: Well right now the biggest thing is stabling our new cross-platform interface, which uses the wxWidgets toolkit to make sure each feature works properly cross-platform (Windows, Linux, OSX) on a variety of compilers and libraries. Then we will add features requested by our users, like hardware-accelerated graphics filters and we may even re-implement the linking code, particularly the IPC (single computer) code.

SF: What’s the best way to get the most out of using VBA-M?
VBA-M Team: VBA-M is a merge of the many forks of VBA and the best way is to explore all of the merged features of VBA-M (from GBA to GBA Cable and RFU wireless link gaming, GameCube (Dolphin) link gaming, Game Boy link gaming (across operating systems), e-Reader scanner support, GDB debugging support, xBRZ 1.3 support, OAM viewers, tilt sensor support in WarioWare – Twisted, Solar Sensor support, automatic save type detection, ROM database support and flashcart CHT cheat support for the GBA cheats database). In short, take a look and tell us if we are missing something that you need.

SF: What has your project team done to help build and nurture your community?
VBA-M Team: We simply add features that the community has requested and encourage contributions such as translating the UI to a requested language, reporting bugs, getting VBA-M packaged by Arch Linux, Ubuntu, and Debian, and help with the VBA-M forum.

SF: Have you found that more frequent releases help build up your community of users?
VBA-M Team: Yes, a surge of activity and interest follows whenever a new release occurs. And some of the changes should help narrow down issues considerably.

SF: What was the first big thing that happened for your project?
VBA-M Team: Several things, for instance:

  • darktjm, the original author of the wxWidgets code, decided to contribute some code that paved the way for our new interface. For this we are forever grateful.
  • Replacing the old 1.8 GBA core with a new core, which had a 15% speed increase from the old core and was never officially implemented.
  • The current WIP WxWidgets GUI, and the mature libretro implementation, which both opened the doors for true extensive cross platform compatibility by RetroArch; a rather nice way of running emulator cores, games, graphics demos, and other things.
  • Replacing the APU with the one written by Blargg improved the audio of many games while reducing emulation complexity.

SF: What helped make that happen?
VBA-M Team: A couple of months ago, during a quiet period, we started to fix the linking and tried to improve the wxWidgets interface, including bringing in features that were initially in the MFC interface over to the new interface so that all wxWidgets platforms are represented.

SF: What was the net result for that event?
VBA-M Team: Overall, we have a unified interface for major operating systems and an improved user experience

SF: What is the next big thing for VBA-M?
VBA-M Team: Once we fix a small few issues, we are hoping to do a few beta builds and do a 2.0.0 release finally.

SF: How long do you think that will take?
VBA-M Team: We hope that when this interview is published we will have gotten through a few betas and, maybe, have a release candidate.

SF: Do you have the resources you need to make that happen?
VBA-M Team: Yes, for the most part but we could do with some other platform developers, such as an OSX developer, if possible. Actually, any help would be appreciated, such as help making bug fixes, creating new features, finding and reporting bugs, translations, and supporting new users in the forum.

SF: If you had it to do over again, what would you do differently for VBA-M?
VBA-M Team: Using a cross-platform UI system like wxWidgets instead of a single-platform framework like MFC would have made VBA-M usable by a wider user base and improve the underlying GB/GBC/GBA cores.

SF: Why?
VBA-M Team: To make it more accurate and improve speed.

SF: Any reason you can’t do that now?
VBA-M Team: Presently, the issue is the time to go back and do it over again.

SF: Is there anything else we should know?
VBA-M Team: We accept all feedback, both positive and negative at the VBA-M forum.

[ Download VBA-M ]

Comments are closed.