N64 Emulation


Kippykip

BFG 9000
Joined
Sep 6, 2016
Messages
520
Age
26
Location
'STRAYA
Website
kippykip.com
I don't play N64 so this wouldn't worry me too much, but I'd be interested to know if the dual 1.5ghz ARM CPU would be enough power to handle N64 emulation.
 
A lot of people said N64 was slow on the Pandora, but those comments were made before the 1ghz model existed.
Yeah I was mostly considering the 1Ghz in my comment. But the CC and Rebirth models overclocked could handle quite a bit of the games.
 
I read a bit about Mupen64 on the Pandora Wiki. Is it out of date ?
How's accuracy now ? Will games like Mario Tennis run well ? Is it HLE or LLE ?

Is GLideN64 supported ? If yes, how does it run ? If not, are there any plans to port it ?
 
Pandora Wiki is full of outdated information... I believe Ptitseb put out a new version sometime this year, it does have a glideN64 plugin, which performance of that plugin is a bit sluggish on the Pandora, the Pyra may handle it a bit better.
 
Mario Tennis is still a bit spotty iirc. It's one of the later games from Camelot - I suspect it actually has some code to determine whether it's being emulated or not. Generally these days it runs at close to real speed on my Pandora, but the shadows are misplaced making tracking the ball in three dimensions difficult. But ExciteBike runs very well, even better than on the real hardware, and that I think was released even later.
 
Wouldn't it be compatible to just compile Project64 and use that instead? Or would that be so slow on ARM? (Or just not compile at all?)
 
Wouldn't it be compatible to just compile Project64 and use that instead?
You do realize that it doesn't even support Linux at all?

To be able to "just compile" would mean that it 1. supports the same OS - i.e. Linux (or at least Unix), 2. uses APIs that are already available (OpenGL ES, SDL etc) and 3. either already contains handcrafted optimizations for your target architecture or doesn't use *any* architecture-specific/hand-crafted optimizations. This one probably fails in all 3 aspects.
 
You do realize that it doesn't even support Linux at all?

To be able to "just compile" would mean that it 1. supports the same OS - i.e. Linux (or at least Unix), 2. uses APIs that are already available (OpenGL ES, SDL etc) and 3. either already contains handcrafted optimizations for your target architecture or doesn't use *any* architecture-specific/hand-crafted optimizations. This one probably fails in all 3 aspects.
No I didn't realise it doesn't run on linux, I wouldn't know as I barely use that emulator.
Lemme rephrase: Wouldn't it just be easier to straight up compile Mupen64 from the source?
 
That's what we have already on Pandora, isn't it? Albeit with a few optimisations on top of the original source base, when run on the target hardware, and those optimisations will mostly apply also to the OMAP5 processor the Pyra has, so it should be a good starting point.

I'm hoping that on the Pyra we'll be able to have a build where it'll just take a game image and run - on Pandora there are various options, and I do have to try out two maybe three of the configurations to find the best one for me for each game.
 
You do realize that it doesn't even support Linux at all?

To be able to "just compile" would mean that it 1. supports the same OS - i.e. Linux (or at least Unix), 2. uses APIs that are already available (OpenGL ES, SDL etc) and 3. either already contains handcrafted optimizations for your target architecture or doesn't use *any* architecture-specific/hand-crafted optimizations. This one probably fails in all 3 aspects.

The first two could in theory be provided by winelib.
 
Back
Top