Skip to content
Libretro VBA-Next port for Switch. **Don't use this, see readme!**
Branch: master
Clone or download
Latest commit c50aebf Mar 31, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.vscode
romfs
source
.clang-format
.gitignore Updated to 0.4. Added auto save on pause. Reverted default starting f… May 27, 2018
LICENSE Add GPLv2 License to VBA Next Feb 1, 2018
LICENSE.thirdparty
Makefile
icon.jpg
readme.md

readme.md

VBA Next/VBA-M for Switch

Please stop using this, you have now far better options available. I recommend switching to the execellent and more accurate mGBA which is available both in standalone form, as well as via Retroarch. But if you want to continue using vba-next, consider using the offical Retroarch core, which is reguarly updated and features more options than this frontend.

A VBA-M port for Nintendo Switch. It's based of the libretro port(the actual emulator) and 3DSGBA(the GUI, although heavily refactored).

After porting 3DSGBA(which often crashed probably because of a huge amount of memory leaks), I tried porting mGBA which ran not so well. That's why I decided to experiment with a lighter less accurate emulator, which lead to this port.

Needs libnx and devkitPro to build. Just run make.

Features

  • Quite high compability(haven't tried many games)
  • Save games and save states
  • Frameskip

Problems

  • In rare occasions the audio has problems
  • Video and Input not frame accurate(see Speed hack)

Speed hack

NOTE: some things don't apply anymore or were inaccurate observations

Before implementing this "speed hack" the emulator had regular slowdowns. Although I found out about these things by myself, these things might be common knowledge to emulator devs. These were the things which apparently slowed the emulator down:

  • The thread/core it's running on
  • The VSync

The first problem was solved by running the whole emulator in a second thread with a very high priority pinned to a core not used by the system.

Omitting the wait for vertical synchronisation lead naturally to artefacts. So I decided on only running the emulator inside the second thread, locked using sleep thread to 60 Hz. At the same time the main thread is locked by the vsync and only receives the framebuffer while sending the input. I left the audio in the emulator thread.

This leads of course to the problem that both threads, although locked to 60 Hz, may not run in sync, so the input or the graphics of a frame may be skipped or out of sync sometimes.

Credits

You can’t perform that action at this time.