Views: 6,695,994 Homepage | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 03-28-24 11:36 AM
Guest:

0 users reading Android port | 1 bot

Main - Development - Android port Hide post layouts | New reply

Pages: 1 2
MAGNUM_PT
Posted on 11-19-18 09:59 AM Link | #754
So, for the past couple of days I've been trying to port melonDS to Android and I managed to get it to run. Here's a small video of it (kinda) working on a OnePlus X (Snapdragon 801):



As you can see, performance is terrible, making it completely unplayable. Sound does not work properly and only touch input is implemented (as a proof of concept). Some changes were made to melonDS's source code (to make some aspects more abstract) and can be found here: https://github.com/rafaelvcaetano/melonDS-android-lib

The frontend source code will be released soon once I have it in a more user-friendly state (scale screens properly, proper input, BIOS location selection, and sound maybe?).

Regarding the culprits of bad performance, I don't have a clear idea of what is the main bottleneck. Currently, I have the emulation running on a separate thread and rendering is done on a separate thread using OpenGL, where I simply fetch the framebuffer and draw it. I didn't even bother implementing synchronization between those threads since the performance was so bad that the chances of having tearing were so low.

Hydr8gon
Posted on 11-19-18 08:35 PM Link | #755
Nice work on this. It's really weird that the performance is so bad... I skimmed over your code and nothing jumps out to me as something that would cause slowdown. I wouldn't expect it to reach full speed, but I would expect it to be much faster than this. I have a Switch port of melonDS (check it out here) and it doesn't run full speed, but it runs pretty good considering the Switch hardware and desktop melonDS performance. I have a similar setup too; drawing the framebuffer with OpenGL, and emulation and audio on a separate thread. So I can only imagine it would be a problem with the Java code. Wonky Android stuff, or some weird thread priority issue maybe? I have some Android experience, I'd be interested in taking a look at your code if you upload it all and maybe help find the problem.

Arisotura
Posted on 11-19-18 08:43 PM Link | #756
might just be that some OpenGL drivers for Android are total shit. dunno tho.

Android is crap too tbh.

but, like...

dunno

maybe this is not running in performance mode or whatever.

I don't know shit about Android.

____________________
Kuribo64

Hydr8gon
Posted on 11-19-18 10:10 PM Link | #757
Posted by StapleButter
might just be that some OpenGL drivers for Android are total shit. dunno tho.

Android is crap too tbh.

but, like...

dunno

maybe this is not running in performance mode or whatever.

I don't know shit about Android.

True, OpenGL drivers on Android are usually pretty bad. But for just drawing the framebuffer (and on a separate thread no less) it really shouldn't affect performance too much. Some sort of performance throttling could be happening, but that usually doesn't kick in until something's been running for a little while and the CPU starts to heat up. But yeah, there are so many Android devices out there and some do stupid shit with performance so it very well could be that.

MAGNUM_PT
Posted on 11-21-18 12:51 PM Link | #758
After remembering that doing a release build could a good idea, I managed to get between 20 to 30 FPS when starting the game. However, it quickly goes down back to 10 FPS. I will try to upload the frontend code today.

Hydr8gon
Posted on 11-22-18 04:55 AM Link | #759
Posted by MAGNUM_PT
After remembering that doing a release build could a good idea, I managed to get between 20 to 30 FPS when starting the game. However, it quickly goes down back to 10 FPS. I will try to upload the frontend code today.

Lol, debug build will do that to you. The release build FPS drop sounds like aggressive performance throttling. How long does it take before the FPS drops? When you upload the frontend code I'll give it a compile and test performance on my OnePlus 5T.

Arisotura
Posted on 11-22-18 12:55 PM Link | #760
well yeah debug builds are slow as shit

that's why the CodeBlocks project has that DebugFast config btw

it gets all the optimizations so it's fast, but it gets shit like the debug console

though it's not well suited to actual debugging or profiling

____________________
Kuribo64

MAGNUM_PT
Posted on 11-25-18 06:45 PM Link | #764
The frontend source code has been (finally) published. You can find it here: https://github.com/rafaelvcaetano/melonDS-android

A testing build can be found here: https://github.com/rafaelvcaetano/melonDS-android/releases

You will need to have the BIOS files (arm7, arm9 and firmware) in a directory to be able to use the emulator.

Hydr8gon
Posted on 11-25-18 10:57 PM Link | #765
Posted by MAGNUM_PT
The frontend source code has been (finally) published. You can find it here: https://github.com/rafaelvcaetano/melonDS-android

A testing build can be found here: https://github.com/rafaelvcaetano/melonDS-android/releases

You will need to have the BIOS files (arm7, arm9 and firmware) in a directory to be able to use the emulator.

Thanks. I ran the test build and noticed a few things:
-Sound works, even though your readme says it doesn't?
-On my phone, 2D performance is at least double my Switch build but 3D performance is only slightly better. Threaded rendering should be enabled by default, so there's probably something in your thread implementation that could be optimized.
-I had a save file already that I tried to use, but it wasn't loaded. My guess is that you didn't pass the right SRAM path to the LoadROM function?

I haven't looked at the code yet, but I'll try to look into these things after I finish some of my pesky assignments.

Arisotura
Posted on 11-25-18 11:01 PM Link | #766
hey hey hey comrades


how 'bout joining the melonDS IRC so we could exchange about all that


irc.badnik.net #melonds

____________________
Kuribo64

MAGNUM_PT
Posted on 11-26-18 03:12 PM Link | #767
Just to finish the conversation:
- Regarding sound, on my device it sound more like ear rape that anything else. Due to the low framerate that was expected, but it didn't seem right. I'll try to check on a better device
- Regardint 3D performance, it's quite possible that performance may be lacking. Android does not natively support semaphores, so I had to implement them using mutexes. However, I was not sure how SemTryWait() was supposed to be implemented and that might be causing problems. The other related methods could also use another revision
- Currently, the path to the SRAM is hardcoded to be inside the app's data directory. I'll add an option to specify a directory or use the same directory as the ROM

From now on, I'll try to be around IRC, as StapleButter suggested, so that we can start discussing some things there.

Arisotura
Posted on 11-26-18 04:22 PM Link | #768
re: semaphores

in the case of the 3D thread, there is a semaphore that is incremented each time the renderer finishes a scanline, and decremented each time a scanline is read to be composited in the final video output.

there's another semaphore that tells the renderer when it can start, and one that the renderer uses to signal when it has completed a frame.

____________________
Kuribo64

CrashGamer
Posted on 07-02-19 11:26 PM Link | #1148
How an nds emulator is created on android

kevincrans
Posted on 11-02-19 03:04 PM Link | #1344
Why OpenGL ES and not Vulkan?
I don't know shit about Android either.

Diego29
(post deleted) #1625

Diego29
Posted on 04-11-20 03:16 PM Link | #1630
Hello a question they are still with the melonds port I want to know why I want to use it but it will also have a local or online multiplayer

Hyla
Posted on 04-14-20 02:47 PM Link | #1637
Please keep trying to port MelonDs to android, possibly this will be the only emulator with multiplayer for nds games running on Android, and that would be really amazing. ❤️

MAGNUM_PT
Posted on 05-25-20 04:57 PM Link | #1780
Hey! Sorry for the late replies. Yeah. I've been keeping a close eye on developments and this week I ended up addnig support for GBA ROMs. I also took a look at the OpenGL renderer but unfortunately my knowledge in this area is limited.

I've also been looking at Wi-Fi support but I'm still not sure how viable it will be. To support direct mode, root is required, which is far from ideal. I'll keep making some tests but there is absolutely nothing I can promise.

Generic aka RSDuck
Posted on 05-25-20 05:03 PM (rev. 2 of 05-25-20 05:04 PM) Link | #1781
Hey! Sorry for the late replies. Yeah. I've been keeping a close eye on developments and this week I ended up addnig support for GBA ROMs. I also took a look at the OpenGL renderer but unfortunately my knowledge in this area is limited.


The OpenGL is probably to slow for a lot of devices anyway (especially with those allegedly terrible mobile GL ES driver). When I'm finished with the JIT I want to write a faster neon software renderer.

I've also been looking at Wi-Fi support but I'm still not sure how viable it will be. To support direct mode, root is required, which is far from ideal. I'll keep making some tests but there is absolutely nothing I can promise.


when the indirect mode gets improved wi-fi, we only need normal sockets.

For your port the aarch64 JIT and the neon renderer 2d developed with my switch port might be interesting for you :)
https://github.com/RSDuck/melonDS

____________________
Take me to your heart / never let me go!

"clearly you need to mow more lawns and buy a better pc" - Hydr8gon

Arisotura
Posted on 05-25-20 05:13 PM Link | #1782
alternately we could make a 'consumer-toy' GL renderer that sacrifices accuracy in the name of betterer speeds (doing more aggressive polygon batching, etc)

____________________
Kuribo64
Pages: 1 2

Main - Development - Android port Hide post layouts | New reply

Page rendered in 0.069 seconds. (2048KB of memory used)
MySQL - queries: 29, rows: 116/116, time: 0.023 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.