melonDS

DS emulator, sorta

Go to file

Valtýr Kári Daníelsson 22f4a16998 rewrites UpdateClipMatrix to avoid 2 memcpies Small optimization of UpdateClipMatrix. There is of course the possibility that at O3 the compiler can tell those copies are superfluous and optimize them away anyway. Although I haven't done super rigorous tests, comparing the uncapped framerates of versions compiled with and without the change the new version does seem to be generally a bit faster depending on the scene. On the startup screen of Pokemon Black the new version seemed to be about a couple to a few% faster than the old one, but about the same on starter selection. MatrixMult4x4 was also rewritten for better reuse, but unfortunately it's no longer in style with the other matrix multiplication functions. Fun observation, because there are 53 bits of mantissa in a double and 64-12=52<53, it's possible to convert these integers to doubles, perform the calculation on them and then convert back again without losing any precision. This may sound completely goofy, but compilers are better at vectorizing floating point arithmetic as you can see on e.g. compiler explorer, so such a thing could possibly improve performance in some scenarios. I tried it, and alas, even though the improved vectorization from using floating points made a good effort, it just wasn't enough to make up for the extra copies and conversions. I even tried using BLAS, but that didn't do any better. But that does raise an interesting thought, if the compilers don't vectorize the integer instructions that much, could the matrix multiplications be sped up with explicit use of SIMD intrinsics? Possibly with the vectorclass library? Another thing I haven't tried is getting rid of the memcpy in the multiplications. This would probably require heap allocating the arrays so that pointers could be reassigned, and that extra heap faffery would probably more than negate the improvement from getting rid of the memcpy. If you add some intermediate arrays maybe there's some way to shuffle stack allocated arrays around to get around heap allocating. Another thing I tried was multithreading, although I only tried the standard threading library. To begin with, since these matrices aren't that big I suspected the overhead from threading would negate or overwhelm any possible speedup. And indeed, using that approach ground the emulator to a near halt, even on a computer that should be fairly overspecced. But bear in mind that I'm a total multithreading n00b and was only using std::thread, so maybe a multithreading whiz could come up with an approach that's at least on par with the single threaded version.		2022-08-30 04:38:53 +02:00
.github	Modernize CMake build system (#1434 )	2022-05-21 19:54:55 +02:00
cmake	Modernize CMake build system (#1434 )	2022-05-21 19:54:55 +02:00
freebios	FreeBIOS: add VRAM-compliant LZ77 decompressor. fixes #1353	2022-03-14 19:42:30 +01:00
res	Modernize CMake build system (#1434 )	2022-05-21 19:54:55 +02:00
src	rewrites UpdateClipMatrix to avoid 2 memcpies	2022-08-30 04:38:53 +02:00
tools	macOS: fix bundling on Monterey	2022-05-16 18:09:39 +02:00
.gitignore	Redesign the Input dialog (#1226 )	2021-09-30 17:23:25 +00:00
CMakeLists.txt	oh fuck you macos	2022-05-23 15:35:34 +02:00
CONTRIBUTING.md	Rename contributing.md to CONTRIBUTING.md	2021-09-03 15:16:09 +00:00
LICENSE	reorganize repo, move shit around	2017-03-16 23:01:22 +01:00
README.md	Modernize CMake build system (#1434 )	2022-05-21 19:54:55 +02:00

README.md

melonDS

DS emulator, sorta

The goal is to do things right and fast, akin to blargSNES (but hopefully better). But also to, you know, have a fun challenge :)

How to use

Firmware boot (not direct boot) requires a BIOS/firmware dump from an original DS or DS Lite. DS firmwares dumped from a DSi or 3DS aren't bootable and only contain configuration data, thus they are only suitable when booting games directly.

Possible firmware sizes

128KB: DSi/3DS DS-mode firmware (reduced size due to lacking bootcode)
256KB: regular DS firmware
512KB: iQue DS firmware

DS BIOS dumps from a DSi or 3DS can be used with no compatibility issues. DSi BIOS dumps (in DSi mode) are not compatible. Or maybe they are. I don't know.

As for the rest, the interface should be pretty straightforward. If you have a question, don't hesitate to ask, though!

How to build

Linux

Install dependencies:
- Ubuntu 22.04: sudo apt install cmake libcurl4-gnutls-dev libpcap0.8-dev libsdl2-dev qtbase5-dev libslirp-dev libarchive-dev libepoxy-dev
- Older Ubuntu: sudo apt install cmake libcurl4-gnutls-dev libpcap0.8-dev libsdl2-dev qt5-default libslirp-dev libarchive-dev libepoxy-dev
- Arch Linux: sudo pacman -S base-devel cmake git libpcap sdl2 qt5-base libslirp libarchive libepoxy

Download the melonDS repository and prepare:

git clone https://github.com/Arisotura/melonDS
cd melonDS

Compile:

cmake -B build
cmake --build build -j$(nproc --all)

Windows

Install MSYS2
Open the MSYS2 MinGW 64-bit terminal
Update the packages using pacman -Syu and reopen the terminal if it asks you to
Install git to clone the repository
```
pacman -S git
```

Download the melonDS repository and prepare:

git clone https://github.com/Arisotura/melonDS
cd melonDS

Dynamic builds (with DLLs)

Install dependencies: pacman -S make mingw-w64-x86_64-{cmake,mesa,SDL2,toolchain,qt5,libslirp,libarchive,libepoxy}

Compile:

cmake -B build -G "MSYS Makefiles"
cmake --build build -j$(nproc --all)
cd build
../tools/msys-dist.sh

If everything went well, melonDS and the libraries it needs should now be in the dist folder.

Static builds (without DLLs, standalone executable)

Install dependencies: pacman -S make mingw-w64-x86_64-{cmake,mesa,SDL2,toolchain,qt5-static,libslirp,libarchive,libepoxy}

Compile:

cmake -B build -G 'MSYS Makefiles' -DBUILD_STATIC=ON -DCMAKE_PREFIX_PATH=/mingw64/qt5-static
cmake --build build -j$(nproc --all)

If everything went well, melonDS should now be in the build folder.

macOS

Install the Homebrew Package Manager
Install dependencies: brew install git pkg-config cmake sdl2 qt@6 libslirp libarchive libepoxy

Download the melonDS repository and prepare:

git clone https://github.com/Arisotura/melonDS
cd melonDS

Compile:

cmake -B build -DCMAKE_PREFIX_PATH="$(brew --prefix qt@6);$(brew --prefix libarchive)" -DUSE_QT6=ON
cmake --build build -j$(sysctl -n hw.logicalcpu)

If everything went well, melonDS.app should now be in the build directory.

Self-contained app bundle

If you want an app bundle that can be distributed to other computers without needing to install dependencies through Homebrew, you can additionally run ../tools/mac-bundle.rb melonDS.app after the build is completed, or add -DMACOS_BUNDLE_LIBS=ON to the first CMake command.

TODO LIST

better DSi emulation
better OpenGL rendering
better wifi
the impossible quest of pixel-perfect 3D graphics
support for rendering screens to separate windows
emulating some fancy addons
other non-core shit (debugger, graphics viewers, etc)

TODO LIST FOR LATER (low priority)

big-endian compatibility (Wii, etc)
LCD refresh time (used by some games for blending effects)
any feature you can eventually ask for that isn't outright stupid

Credits

Martin for GBAtek, a good piece of documentation
Cydrak for the extra 3D GPU research
limittox for the icon
All of you comrades who have been testing melonDS, reporting issues, suggesting shit, etc

Licenses

melonDS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

External

Images used in the Input Config Dialog - see src/frontend/qt_sdl/InputConfig/resources/LICENSE.md