- Thread starter catlover007
- Start date
- Views 351,456
- Replies 884
- Likes 97
I just to say that this is a very very good emulator. Aside from the fact that I have to overclock this more than id like, I have no issues whats so ever playing.
I do have a couple questions regarding some very minor things with the emulator. Is there a way to set a screen swap like how you press R3 to adjust the size emphasize? I like playing with hybrid mode but sometimes I feel like I need to switch primary screens briefly without either squinting on the smaller screen or going to the display menu and switching it there.
Also is there a way to manually set this up as a core for retroarch to replace the outdated one?
I do have a couple questions regarding some very minor things with the emulator. Is there a way to set a screen swap like how you press R3 to adjust the size emphasize? I like playing with hybrid mode but sometimes I feel like I need to switch primary screens briefly without either squinting on the smaller screen or going to the display menu and switching it there.
Also is there a way to manually set this up as a core for retroarch to replace the outdated one?
This is a great emulator, amazing work catlover007!
Would you please clarify ? To me the response reads as if people demanded to distribute the forwarder itself - and then the response is of course not.
However, I think the question was more if melonDS could support a command line argument with the path to the game image. Just like any other core in retroarch for example ? This doesn't mean any distribution of forwarders (everybody has to create their own), just a small if argc == 2 -> use argc[1] as LoadROM(...) argument.
The emulator is great though, and I would be grateful for this command line argument support
Would you please clarify ? To me the response reads as if people demanded to distribute the forwarder itself - and then the response is of course not.
However, I think the question was more if melonDS could support a command line argument with the path to the game image. Just like any other core in retroarch for example ? This doesn't mean any distribution of forwarders (everybody has to create their own), just a small if argc == 2 -> use argc[1] as LoadROM(...) argument.
The emulator is great though, and I would be grateful for this command line argument support
that's not the point why I don't support them. I don't support homebrew nsps of any kind, no matter if you created them yourself or not.
It's because the requirement of sigpatches to run NSP's in that manner is frowned upon as everyone has this anti-piracy god complex in these communities anymore even though making any form of emulator is going to come along with piracy anyways since no one truly "owns" the games they are emulating as it is much easier to get them through other sources. This and the drama surrounding the topic is why you will see most creators say they only support, "title redirection" when NSP creation works fine and makes it much easier for the end consumer
Am I right in thinking that the parsing of command line arguments would also work for running a game by choosing the ROM file from the homebrew launcher, with the relevant file association configured, or does that use a different mechanism?
The reason why many developers don't support NSP forwarders of any kind is because of the uncertainty the NSP stuff introduces.
They have plenty of stuff to take care of with their Homebrew apps as NROs as it is, to also debug NSP forwarding and why they could possibly not work.
It's just too much of a hassle, and I can understand it from a developer's point of view, since focusing only on the NROs and being able to reproduce the issues is a primary thing when debugging something, and we all know NSP behaviour is shoddy at best.
That's the main reason, piracy is just a second thought and/or an excuse for some devs (not saying that's the reason in this case, but that it could for other homebrew apps/devs).
They have plenty of stuff to take care of with their Homebrew apps as NROs as it is, to also debug NSP forwarding and why they could possibly not work.
It's just too much of a hassle, and I can understand it from a developer's point of view, since focusing only on the NROs and being able to reproduce the issues is a primary thing when debugging something, and we all know NSP behaviour is shoddy at best.
That's the main reason, piracy is just a second thought and/or an excuse for some devs (not saying that's the reason in this case, but that it could for other homebrew apps/devs).
It's not much of a God complex if it's something you personally just feel weird about and don't want to partake in that aspect of it. Being anti-piracy in these circles is also really safe, especially considering what company's systems we're dealing with. Homebrew itself is always known as being open to piracy, but you don't make a big flashing sign about it. It's not the same as the actual act of piracy, y'know, getting the roms.
Last edited by Tsukiru,
I have read all the posts above and I have finally starting getting the picture - thank you everybody for taking the time to respond!
Initially, I was confused, the emulator already has the possibility to load an .nsp (Browse) so ... command line argument ?
On the other hand, the picture starts forming, if users start seeing pretty screens with independent launchers and nice hi-res icons for old games, it may tickle the dragon.
Smart choice for a very smart emulator - I love the speed and really hope the deko3d PR gets accepted. Amazing work!
Initially, I was confused, the emulator already has the possibility to load an .nsp (Browse) so ... command line argument ?
On the other hand, the picture starts forming, if users start seeing pretty screens with independent launchers and nice hi-res icons for old games, it may tickle the dragon.
Smart choice for a very smart emulator - I love the speed and really hope the deko3d PR gets accepted. Amazing work!
the deko3d renderer isn't planned to be merged into upstream, it will stay in this port because there's not really a point in having it anywhere else.
did it for you? Normal homebrew like melonDS shouldn't ever break with these things (except that one time Nintendo changed how input is passed to applications, but I can't recall any other instance of something like this).
To me and a friend I know... It was working just fine. I wonder if I did something wrong?
Have you thought about making an exclusive RA core for arm64 systems with deko3d?
One that's separate from the main melonDS. Perhaps that could be feasible so the updated melonDS with deko3d appears on the buildbots as well.
it works fine for me with firmware 13.1.0 and Atmosphere 1.2.4.
getting deko3d to work with Retroarch on Switch (which uses OpenGL) would be possible but a huge hack and I frankly care too little about the libretro version of melonDS to put any work into that.
I reinstalled it and it now works. I probably did something stupid.
By the way, is it possible to remove that semi transparent hand from the bottom screen?
it's the cursor for the touch screen input. In mouse mode move it to the edge of the screen with the right analog stick and it will disappear.
Hi, I'm trying to run Pokemon Renegade Platinum (with none of the optional speedhacks installed) on melonDS in my Switch. I'm getting a lot of lag when I try to save if I've caught a new 'mon ("saving a lot of data" vs "saving"), and in Jubilife City (which has 3D assets of tall buildings). This persists even when increasing overclock using the sys-clk overlay. Are there any other types of optimization I might be missing to make the process smoother?
The version I'm running would appear to be Release 6.
Edit: this will really teach me. I tried changing the melonDS CPU clock option to 1785mhz and enabling JIT recompiler and now it does not seem to be lagging at all. It still takes oddly long when "saving lots of data" but it isn't lagging the music or anything anymore. Thanks so much for all your hard work, friend.
The version I'm running would appear to be Release 6.
Edit: this will really teach me. I tried changing the melonDS CPU clock option to 1785mhz and enabling JIT recompiler and now it does not seem to be lagging at all. It still takes oddly long when "saving lots of data" but it isn't lagging the music or anything anymore. Thanks so much for all your hard work, friend.
Last edited by Eevenin,
Similar threads
-
- Article
