Homebrew [Release] FCEUMM3DS

  • Thread starter Thread starter Deleted User
  • Start date Start date
  • Views Views 110,863
  • Replies Replies 310
  • Likes Likes 29
I'd really like to use this rather than VC injection. But everytime I select a rom it return back to the main menu when I click A. Is there any fix for this? Or am I doing something wrong?
 
Can you make it so that L is rewind and R is fast forward? Thanks!
Rewind would be very CPU intensive for a 3DS, and if it can't run at full speed yet, it certainly can't do fast forwarding.
I think this emulator has potential to be better than nes vc. Sound fix and speed up. Then this will be the best!
Sound would likely be improved if it were running at full speed. I just haven't been working on it recently.
 
Rewind would be very CPU intensive for a 3DS, and if it can't run at full speed yet, it certainly can't do fast forwarding.

Sound would likely be improved if it were running at full speed. I just haven't been working on it recently.
nesDS had a rewind and fast forward button, and the 3DS is obviously powerful than the DS, fast forward isn't really a priority, though. I just like rewind, for Super Mario Bros:P
 
nesDS had a rewind and fast forward button, and the 3DS is obviously powerful than the DS, fast forward isn't really a priority, though. I just like rewind, for Super Mario Bros:P
nesDS was written in assembly. Highly difficult to port, hardware specific code written by some of the best GBA and DS coders. On top of that, the NES is annoying to implement correctly. The rendering hardware is incredibly dependent on the CPU state and timings. Worse yet, the rendering hardware on the 3DS isn't suitable for old games that use color palettes, so the CPU has to do a lot more work.

So bare that in mind when comparing to nesDS, it's not a simply matter of optimizing C++. nesDS was some serious old school coding on more suitable hardware.
 
  • Like
Reactions: SLiV3R
nesDS was written in assembly. Highly difficult to port, hardware specific code written by some of the best GBA and DS coders. On top of that, the NES is annoying to implement correctly. The rendering hardware is incredibly dependent on the CPU state and timings. Worse yet, the rendering hardware on the 3DS isn't suitable for old games that use color palettes, so the CPU has to do a lot more work.

So bare that in mind when comparing to nesDS, it's not a simply matter of optimizing C++. nesDS was some serious old school coding on more suitable hardware.
Ah, okay.
 
I hope this emu will fix its speed issues at some point, it could be the next big emu on the 3DS, also we don't want the vita to get more emus than the 3DS whereas its hack is very recent compared to the 3DS, I hope there will be competition between the two consoles and that it'll help us bring emus to both of them :)
 
  • Like
Reactions: SLiV3R
I'd really like to use this rather than VC injection. But everytime I select a rom it return back to the main menu when I click A. Is there any fix for this? Or am I doing something wrong?
For anyone else having this issue Steveice helped me solve it. The issue was that i'm using the No-Intro roms exclusively, which has the headers removed as that isn't a part of the actual dump. You simply need to either download a dump with the iNes headers attached, or run this Python script to fix the header.
http://greg-kennedy.com/wordpress/2012/05/30/ines-header-fixer/
You can also use NesToy or cajones to autofix the headers. They seemed to work perfectly fine. Make sure to delete any existing header before running the utilities, otherwise it could write garbage data to the file.
 
nesDS was written in assembly. Highly difficult to port, hardware specific code written by some of the best GBA and DS coders. On top of that, the NES is annoying to implement correctly. The rendering hardware is incredibly dependent on the CPU state and timings. Worse yet, the rendering hardware on the 3DS isn't suitable for old games that use color palettes, so the CPU has to do a lot more work.

So bare that in mind when comparing to nesDS, it's not a simply matter of optimizing C++. nesDS was some serious old school coding on more suitable hardware.

The GBA and DS had the benefit of 2D hardware that literally did most of the rendering for them, whereas the 3DS does not have such hardware accessible to it. If it had paletted textures at the very least (which it doesn't afaik), that would have greatly benefited the emulator scene, imo.
 
that would have greatly benefited the emulator scene, imo
Interesting that you say that, i gave ninjhax 2.0 a run with fceumm3ds and it's running at full speed now. Gameyob is able to run the 2.5x faster as well. So while paletted textures may not be availible, at least the new speed is giving a little more overhead.
 
Interesting that you say that, i gave ninjhax 2.0 a run with fceumm3ds and it's running at full speed now. Gameyob is able to run the 2.5x faster as well. So while paletted textures may not be availible, at least the new speed is giving a little more overhead.

Yeah, but you're probably running it on an n3DS, right?
 
Yeah, but you're probably running it on an n3DS, right?
Yes, I do also have a original ambassador 3ds, but n3ds is what I wish the 3ds was. I guess I shouldn't act so satisfied since buying new hardware isn't always an acceptable solution but at least the speed offers some more options to those who have n3ds.
 
Interesting that you say that, i gave ninjhax 2.0 a run with fceumm3ds and it's running at full speed now. Gameyob is able to run the 2.5x faster as well. So while paletted textures may not be availible, at least the new speed is giving a little more overhead.

Nice! Is the audio ok now? Could you tell some more about the performance on 2.0?
 
  • Like
Reactions: Idaho

Site & Scene News

Popular threads in this forum