RetroPie Raspberry Pi N64 Emulator

[whywi...@gmail.com]

Hello, I recently purchased the new Raspberry Pi 2 and installed RetroPie. I've tried playing around with the mupen64 .cfg files, using Rice and so on, but for the most part games either crash at the start screen or run incredibly slow. I'm not sure if someone has found a solid way to emulate the N64 on the new Pi. Anyway I figure I might as well ask. Otherwise I'll just be patient and wait for the update to roll around as I know it will. Thanks for your hard work guys/ gals.

[Dorian FEVRIER]

The GPU is supposed to be the same than RPi 1 so I suppose it's not GPU related (but I may be wrong). Could you try to run a game without video and try to see if it's still slow.

Le Lundi 16 février 2015 9h20, "whywi...@gmail.com" <whywi...@gmail.com> a écrit :

Hello, I recently purchased the new Raspberry Pi 2 and installed RetroPie. I've tried playing around with the mupen64 .cfg files, using Rice and so on, but for the most part games either crash at the start screen or run incredibly slow. I'm not sure if someone has found a solid way to emulate the N64 on the new Pi. Anyway I figure I might as well ask. Otherwise I'll just be patient and wait for the update to roll around as I know it will. Thanks for your hard work guys/ gals.

--
You received this message because you are subscribed to the Google Groups "mupen64plus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mupen64plus...@googlegroups.com.
To post to this group, send email to mupen...@googlegroups.com.
Visit this group at http://groups.google.com/group/mupen64plus.
For more options, visit https://groups.google.com/d/optout.

[whywi...@gmail.com]

Well some games run okay such as Mario Kart while others display no video such as Vigilante 8. Jet Force Gemini and Goldeneye have trouble keeping up with the audio. overall most N64 games aren't very playable at this time on the Raspberry Pi.

[Dorian Fevrier]

From the description you provide they seems to almost have the same
issues than any arm device no?

On 02/16/2015 05:31 PM, whywi...@gmail.com wrote:
> Well some games run okay such as Mario Kart while others display no
> video such as Vigilante 8. Jet Force Gemini and Goldeneye have trouble
> keeping up with the audio. overall most N64 games aren't very playable
> at this time on the Raspberry Pi.
>
> On Monday, February 16, 2015 at 6:28:42 AM UTC-8, Narann wrote:
>
> The GPU is supposed to be the same than RPi 1 so I suppose it's not
> GPU related (but I may be wrong). Could you try to run a game
> without video and try to see if it's still slow.
>
>

> Le Lundi 16 février 2015 9h20, "whywi...@gmail.com <javascript:>"
> <whywi...@gmail.com <javascript:>> a écrit :

>
>
> Hello, I recently purchased the new Raspberry Pi 2 and installed
> RetroPie. I've tried playing around with the mupen64 .cfg files,
> using Rice and so on, but for the most part games either crash at
> the start screen or run incredibly slow. I'm not sure if someone has
> found a solid way to emulate the N64 on the new Pi. Anyway I figure
> I might as well ask. Otherwise I'll just be patient and wait for the
> update to roll around as I know it will. Thanks for your hard work
> guys/ gals.
> --
> You received this message because you are subscribed to the Google
> Groups "mupen64plus" group.
> To unsubscribe from this group and stop receiving emails from it,

> send an email to mupen64plus...@googlegroups.com <javascript:>.

> To post to this group, send email to mupen...@googlegroups.com

> <javascript:>.

> Visit this group at http://groups.google.com/group/mupen64plus

> <http://groups.google.com/group/mupen64plus>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "mupen64plus" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mupen64plus...@googlegroups.com

> <mailto:mupen64plus...@googlegroups.com>.

> To post to this group, send email to mupen...@googlegroups.com

> <mailto:mupen...@googlegroups.com>.

[whywi...@gmail.com]

Uh, sorry I didn't quite understand that.

> <mailto:mupen64plus+unsub...@googlegroups.com>.

[Dorian FEVRIER]

What I said is that issues you've reported doesn't seems to be specific to RPi 2 but also RPi 1 and ARM devices in general. But I may be wrong.

>     send an email to mupen64plus...@googlegroups. com <javascript:>.

>     To post to this group, send email to mupen...@googlegroups.com
>     <javascript:>.
>     Visit this group at http://groups.google.com/ group/mupen64plus

>     <http://groups.google.com/ group/mupen64plus>.

>     For more options, visit https://groups.google.com/d/ optout

>     <https://groups.google.com/d/ optout>.

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "mupen64plus" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mupen64plus...@ googlegroups.com

> <mailto:mupen64plus+ unsub...@googlegroups.com>.

> To post to this group, send email to mupen...@googlegroups.com

> <mailto:mupen...@ googlegroups.com>.
> Visit this group at http://groups.google.com/ group/mupen64plus.
> For more options, visit https://groups.google.com/d/ optout.

--

You received this message because you are subscribed to the Google Groups "mupen64plus" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mupen64plus...@googlegroups.com.
To post to this group, send email to mupen...@googlegroups.com.

[whywilson11 .]

Ah, well that's for the most part true. No one (that I know of) has really gotten the RPI to play N64 emulation well. In theory the RPI2 should do it flawlessly but it just came out and updates down the road are probably necessary. That's why I was curious if someone here may have, or if a new version of mupen64 may be released sooner rather than later.

--
You received this message because you are subscribed to a topic in the Google Groups "mupen64plus" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mupen64plus/6iz4onBpOEw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mupen64plus...@googlegroups.com.

[hir...@gmail.com]

From the best I can tell, the problem stems from mupen64plus not being optimized to take advantage of the Pi 2's multiple cores. When I tested it, I noticed on top that 1 CPU was completely pegged out. However, overall CPU usage was around 25%. Also, the CPU isn't the same as the pi 1. My understanding is the pi 1 was arm6, whereas the pi 2 is arm7. Even without utilizing multiple cores, it should still run better than a 1st gen pi. Still, if mupen64plus could be optimized to handle multithreading to the other 3 cores we'd see a world of difference. IMHO anyways.

[Dorian Fevrier]

Keep in mind multithread an emulator of a single threaded hardware is
not something easy and it complexify the code a lot without provide any
garantee to be more efficient.

cen64 tried to use multithreading once upon a time and finally put a
step back to single thread.

On 03/31/2015 12:13 PM, hir...@gmail.com wrote:
> From the best I can tell, the problem stems from mupen64plus not being
> optimized to take advantage of the Pi 2's multiple cores. When I tested
> it, I noticed on top that 1 CPU was completely pegged out. However,
> overall CPU usage was around 25%. Also, the CPU isn't the same as the pi
> 1. My understanding is the pi 1 was arm6, whereas the pi 2 is arm7. Even
> without utilizing multiple cores, it should still run better than a 1st
> gen pi. Still, if mupen64plus could be optimized to handle
> multithreading to the other 3 cores we'd see a world of difference. IMHO
> anyways.
>
> On Wednesday, February 18, 2015 at 9:54:45 PM UTC-5, whywilson11 . wrote:
>
> Ah, well that's for the most part true. No one (that I know of) has
> really gotten the RPI to play N64 emulation well. In theory the RPI2
> should do it flawlessly but it just came out and updates down the
> road are probably necessary. That's why I was curious if someone
> here may have, or if a new version of mupen64 may be released sooner
> rather than later.
>
> On Tue, Feb 17, 2015 at 10:33 AM, 'Dorian FEVRIER' via mupen64plus
> <mupen...@googlegroups.com <javascript:>> wrote:
>
> What I said is that issues you've reported doesn't seems to be
> specific to RPi 2 but also RPi 1 and ARM devices in general. But
> I may be wrong.
>
>
> Le Mardi 17 février 2015 2h53, "whywi...@gmail.com

> > Visit this group athttp://groups.google.com/ group/mupen64plus
> <http://groups.google.com/group/mupen64plus>

> > <http://groups.google.com/ group/mupen64plus
> <http://groups.google.com/group/mupen64plus>>.

> > For more options, visithttps://groups.google.com/d/ optout
> <https://groups.google.com/d/optout>

> > <https://groups.google.com/d/ optout
> <https://groups.google.com/d/optout>>.
> >
> >
> > --

> > You received this message because you are subscribed to the Google
> > Groups "mupen64plus" group.
> > To unsubscribe from this group and stop receiving emails from it, send

> > an email tomupen64plus...@ googlegroups.com

> > <mailto:mupen64plus+ unsub...@googlegroups.com>.
> > To post to this group, send email tomupen...@googlegroups.com
>
> > <mailto:mupen...@ googlegroups.com>.
> > Visit this group at http://groups.google.com/

> group/mupen64plus <http://groups.google.com/group/mupen64plus>.

> > For more options, visit https://groups.google.com/d/

> optout <https://groups.google.com/d/optout>.
>
> --

> You received this message because you are subscribed to the
> Google Groups "mupen64plus" group.
> To unsubscribe from this group and stop receiving emails from

> it, send an email to mupen64plus...@googlegroups.com <javascript:>.

> To post to this group, send email to mupen...@googlegroups.com
> <javascript:>.
> Visit this group at http://groups.google.com/group/mupen64plus

> <http://groups.google.com/group/mupen64plus>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
> --

> You received this message because you are subscribed to a topic
> in the Google Groups "mupen64plus" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/mupen64plus/6iz4onBpOEw/unsubscribe

> <https://groups.google.com/d/topic/mupen64plus/6iz4onBpOEw/unsubscribe>.

> To unsubscribe from this group and all its topics, send an email

> to mupen64plus...@googlegroups.com <javascript:>.

> To post to this group, send email to mupen...@googlegroups.com
> <javascript:>.
> Visit this group at http://groups.google.com/group/mupen64plus

> <http://groups.google.com/group/mupen64plus>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
> --

> You received this message because you are subscribed to the Google
> Groups "mupen64plus" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mupen64plus...@googlegroups.com

> <mailto:mupen64plus...@googlegroups.com>.

> To post to this group, send email to mupen...@googlegroups.com

> <mailto:mupen...@googlegroups.com>.

[William Shipley]

> In theory emulation should be flawless

Here are some of the restrictions on emulation in theory vs practice:

Different systems have specialized hardware, in which instructions don't translate perfectly. This leads to emulation being *much* slower than equivalent clock cycles. Depending on how similar architectures are, basic functionality can take more than 20x as long, instruction for instruction.

The easiest way to write an emulator is with a simple interpreter. It essentially runs like a person reading out of a cookbook. "Load this location" "Add these two things together". A table of what each instruction means tells the interpreter what to do in every case. However, this is extremely slow, since every instruction is both read AND executed every time it's interpreted.

The ideal emulator would translate an entire program into code that can be run on the new host. This is referred to as static recompilation. A program is taken and converted before execution to run on a new system. In practice, this type of emulation is near-impossible, and most programs would need to be compiled by hand. However, the concept led to a close approximation: Dynamic Recompilation.

A Dynamic Recompiler, or dynarec, takes segments of the code as they're executed, and compiles entire branches into machine code. It then caches these for later use. However, if something occurs to invalidate that code, it's purged and recompiled. This allows for code that is heavily reused to perform extremely well, but can cause code that frequently modifies itself to become even slower than a simple interpreter. It's a tradeoff that drastically improves performance for predictable programs, while still allowing small amounts of unpredictable behavior.

Mupen64plus is not written to be a "fast" emulator, per-se. It uses a dynarec, and HLE graphics, but a great deal of the architecture focuses on accuracy* rather than performance, given the choice. The consequences of this are an emulator with far fewer glitches, but which can be quite a bit slower. Compared to some of the much older N64 emulators, like 1964 or Corn, Mupen64plus is much slower. However, due to severe glitches, those emulators make many N64 games completely unplayable. They're essentially made from hacks stacked on hacks until a target game works.

Multithreading is basically impossible, as Dorian said, for several reasons: 

* The N64 was a single-threaded platform. 

* The GPU is already hardware-accelerated, so it doesn't have much independent work to share between threads as far as rendering. The heavy lifting is extremely intertwined with the dynarec, making it very difficult to separate the two.

* Making a single-threaded application multi-threaded is very complex, and often won't bring significant improvement in relatively linear applications. Emulation doesn't have a chance to build up a large buffer of events, since large parts of execution are reevaluated constantly. Even if such optimizations were put in, they would struggle to save more than the overhead they would produce.

Here's an analogy for the problem. A group of four people is reading a book. In order to reach the end fastest, they decide to split it into four sections. Four people means you'll get it done 4x as fast, in theory. However, in order for the second, third, and fourth person to understand what's happening, they have to go back and look, or wait for the first to explain to them. Unless the story has lots of independent splits, they spend most of their time looking back. In the end, they only read the book 1.1x faster, because so much waiting was involved. Plus, it took them a fair amount of time to get organized in the first place. 

Here are some potential optimizations that could *potentially* work, to a noticeable degree.

* RPi-optimized Graphics Plugin

* ARM7 specific dynarec optimizations. (That is, assuming they're not already there. The core has some, but the RPi package people are using might be outdated. I don't keep up on such things)

Practically speaking, though, you shouldn't expect particularly good performance on the RPi, especially at higher resolutions.

*Note: I am not trying to claim that Mupen64plus is a cycle-accurate emulator like BSNES or Cen64. I'm only asserting that it's a more accurate emulator than the others listed, and lower performance as a result.

I hope this helps clear some things up.

William Shipley

an email to mupen64plus+unsubscribe@googlegroups.com
<mailto:mupen64plus+unsub...@googlegroups.com>.

To post to this group, send email to mupen...@googlegroups.com

<mailto:mupen64plus@googlegroups.com>.

Visit this group at http://groups.google.com/group/mupen64plus.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "mupen64plus" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mupen64plus+unsubscribe@googlegroups.com.
To post to this group, send email to mupen...@googlegroups.com.

[Dorian FEVRIER]

Thanks a lot William!

If I can add: mupen64plus (as many emulators) is highly CPU based. Even GPU tasks need a lot of CPU activity (texture decoding, vertex processing...) while RDP (N64 GPU) was doing this in hardware. There is a lot of things RDP was doing you can't do today in a portable way and which require _massive_ (using this word I mean: "Impacting the whole emulator graphic plugin code design") _hacks_ (aka: "far more than 1") to be properly emulated.

I've dig into the RPi GPU code (thanks to Eric Anholt presentation and code) and what I can say is: If you want good performance to emulate N64 RDP on RPi, you would have to write a whole driver with it's own API... This is not something doable hobbying project per se.

The more I see Vulkan the more I think some RDP tasks would require quite less hacks if someone would start a graphic plugin based on this but:

* there is no Vulkan graphic plugin yet
* its very unlikely RPi would ever had a Vulkan driver


So the most prolific improvement would be ARM7 specific optimization but those are complex code:

* It require a lot of time to write
* It complexify the code (because mupen64plus does support many platform).
* And, from my perspective the worse: Anytime you have a problem with there is few hope it would be fixed if the orginal maintainer is not there anymore, letting code that would possibly became dirty with years making any tiny code refactor very hard.

To unsubscribe from this group and stop receiving emails from it, send an email to mupen64plus...@googlegroups.com.

[pacemc...@gmail.com]

I'm enjoying most N64 games, although there are still lots of bugs that I'm hoping will be fixed with a Mupen update. If you install the RetroPie 3.0 Beta, things are setup better to allow for faster testing. Installing the experimental mupen also give more video options. Pressing X when a ROM loads allows you to change the emulator, video plugin or resolution; all of which impact the roms performance. Also make sure you expanded your filesystem and your memory split settings will help a game. I'm currently using a memory split of 320. If it's too low GoldenEye won't load, if it's too high it lags.

Hope that helps.

[candadi...@gmail.com]

get pi 3 and update retropie

On Monday, February 16, 2015 at 3:10:26 AM UTC-7, whywi...@gmail.com wrote: