melonDS 0.1: soon a thing!

melonDS 0.1: soon a thing!
Mar 18th 2017, by Arisotura

And yet, it may very well take a while.

As stated in the TODO list, the main remaining thing to do, besides fixes to timers, is building an actual UI for melonDS. The current one was something I had thrown together quickly early in development so I could see graphics. melonDS was barely beginning to run things, it supported VRAM display so it could run ARMWrestler, then got some extra graphics support, enough to render the DS firmware interface.

Things have changed a lot since then. melonDS now has an almost-complete 2D renderer with more accurate colors than the other emulators out there, and even a 3D renderer that is more than satisfying for a first release. It got support for a bunch of things that don't sound very exciting but are required to get games working. All in all, I believe we have a fairly solid emulator base.

But the interface is still lame. It still loads a ROM from a hardcoded filename. It's still a barebones video output and a console spewing nonsense as the game runs. It still has hardcoded (and retarded) key mappings.

The current interface is made of Windows-specific code, which is why I didn't build upon it; I want something cross-platform.

I'm still having trouble deciding what I will work with for this UI. I'm considering libui and SDL, if I can get them to cooperate. I want something lightweight, melonDS is going to stay pretty simple. As for SDL, I'm going to need it (or an equivalent library) for things like joystick input or audio output.

I initially hoped to be able to stay away from Visual Studio as far as Windows is concerned, but to my regret, alternate solutions are more or less of a headache to get working. So I'm likely going to ditch the CodeBlocks project and use CMake.

Which reminds me why I have been postponing the UI stuff: I would rather work on interesting emulation stuff than go through this trouble for a cross-platform UI. I recently discovered that there is an aging cart (Nintendo-internal test ROM) for the DS, and of course, I want to run it in melonDS to see how good it does. None of the emulators I know of pass the whole test, which means that either the test ROM is tricky or the emulators aren't as good as we think. Well, in its current state, melonDS wouldn't pass it either, but there's room for improvement.

No screenshots for this post, I'm keeping some surprise for the release ;)

21 comments have been posted.

< VRAM? Lots of fun!The aging cart >

Pages:12

Yuer says:
Mar 19th 2017

I hope it can run on computer which was manufactured in 1995.my computer is not very Good

Yuer says:
Mar 19th 2017

I hope it can run on computer which was manufactured in 2009.my computer is not very Good

RandomGuyFromReddit says:
Mar 19th 2017

Uh yeah no. I would guess the DS is as powerful as a desktop PC from the 90's.

Niklink says:
Mar 19th 2017

Great news! I just hope that whatever interface you decide on, it's something that can be hidden when not needed, or something similar. DS games need all the vertical resolution you can get, for obvious reasons.

Lurkon says:
Mar 19th 2017

Ahhh no screenshots, only joking. Great to have a progress update to let us know your still working on it, I'm looking forward to testing the initial release.

Lagseeing says:
Mar 19th 2017

Great! Can not wait

NPlumb says:
Mar 19th 2017

Great work! Hope we will be able to adjust position and scale of the screens, if possible some sort of app set up available too to display the bottom screen on a smartphone or tablet, heck even a homebrew for the vita!

anonymous says:
Mar 19th 2017

Some 2D looking games(that use polygons to display the characters) have some really bad texturing glitches. Load up Castlevania: Dawn of Sorrow and move Soma left and right really quickly and you'll see his texture spaz out. This happens in many other games, too.

Another Anonymous says:
Mar 19th 2017

You could always just port it to libretro and never make an interface.
Or you could do a goofy zsnes thing that people nostalgia over.

Or hopefully your current ideas work. Much luck to you!

RandomGuy says:
Mar 19th 2017

Hi, I reached your blog via the emulation subreddit and I fell in love with Kuriblog. I downloaded v1.1 on GitHub and I see that you're running v1.3 here, will you eventually update it?

Bighead says:
Mar 20th 2017

Since the UI has yet to be started, maybe design it in a way that screens can be separated from each other, or at least configured individually. Many of us today have 2x+ monitors, and it would be great to have an option to have each screen on a different monitor. This is one of the things I was hoping to see in DeSmuME for years but it just never happened (at least on Windows). This would be useful for games such as the Castlevania series where you're looking at game play on one screen, and only looking at a map on the other screen. One workaround is a program known as OnTopReplica, which is a pain to set up every play session.

Another option that would be nice is screens of different sizes docked in the same window such as in DraStic, because even though multiple screens is nice, sometimes you want it all on one monitor. This is useful for games like Chrono Trigger where you have the battle field on one screen and menu options on the other. Overall I feel that DS emu authors don't put enough attention into the UI when it comes to screen options (aside from DraStic, as there is only 1 screen to work with), which to me feels critical to the end user experience.

Obviously I have no idea how hard it is to implement these ideas, but I thought I would mention it so later on down the road the same argument can't be made that I heard quite often from DeSmuME team (more specifically zeromus): more screen options would require an entire rewrite to the UI, and nobody cares to do it. Since you're starting from scratch, that opportunity immediately presents itself.

coto says:
Mar 20th 2017

so i just noticed you are working on a ds emu. Yes, most stuff you have found out has been already met in the past across different emus (snemulds co processor support tests, gbaemu4ds (mode1 rotscale guessing), dma timers for different games that rely on IRQ interrupts to feed the sample + dma fifo), nifi for DS , and I could go on...

just keep learning and improve

randdd says:
Mar 20th 2017

Have you tried QtCreator? It's a decent IDE (much better than codeblocks imo) even if you don't use Qt. The debugger isn't as pleasant to use as VS Studio but it can get stuff done.

StarTrekVoyager says:
Mar 20th 2017

As long as your UI isn't as shitty as the DeSmuME one, I'm fine. You could inspire yourself from the Dolphin/Ishiiruka UI, which is pretty solid.

Dawn says:
Mar 20th 2017

I took a peek at the git repo, looks like you've chosen wxWidgets for getting the UI done.
In my experience from building various packages from source over the years, wxWidgets is by far the most flakey UI library out there.
Its obsession with having the library used when running the program and building the program be EXACTLY THE SAME is unhealthy.
When running any program that uses wxWidgets, it's not uncommon to run into this sort of error message:

Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1002,wx containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1008,wx containers,compatible with 2.8).
Aborted (core dumped)

As you can see, even though both the library used to build and run the program are wxWidgets 3.0, the ABI (Application-Binary Interface) version for the library and program is just slightly off, so the program just refuses to run at all!

These strict requirements are, in theory, for the sake of both backwards and forwards compatibility, so that one may simply have a single package of wxWidgets that will work with programs that targeted various versions of wxWidgets.
In practice, the restrict requirements have the exact opposite effect.
For example, sometime earlier this year I was building Audacity, and it wouldn't run properly if built and run against wxWidgets 2.8.x (legacy version) nor 3.1.x (the latest version), it would only work with 3.0.x.

If I could possibly make a recommendation, I'd recommend GTK or QT, anything but wxWidgets...But I may be too late.
Oh well. Just don't say no one warned you...

Pages:12