Beta Mupen64Plus


HackModford said:
This is great.
This is all software rendered right?
What is left to be optimized?
I'm asking because I'm hoping it'll be faster someday.

graphics uses a nanogl plugin
 
Last edited by a moderator:
I'm a little dense when it comes to this stuff. Does that mean we're using the 3d hardware of the pandora or is nanogl just an optimized software renderer? Will we see speed improvements?
 
HackModford said:
I'm a little dense when it comes to this stuff. Does that mean we're using the 3d hardware of the pandora or is nanogl just an optimized software renderer? Will we see speed improvements?

the rendering (what you see onscreen) is using hardware already.
but there might still be room for optimization
 
Last edited by a moderator:
HackModford said:
I'm a little dense when it comes to this stuff. Does that mean we're using the 3d hardware of the pandora or is nanogl just an optimized software renderer? Will we see speed improvements?

that was wrong its not using nanogl (which a limited wrapper for gles 1.X to opengl 1.X).
it was using wesgl a ogles 2.0 wrapper written by adventus. which means its using the 3d hardware on the pandora.
(Note: I say was cause i thought that i saw recently Adventus commented to the fact he wasnt using it anymore, but either case mupen is using 3d hw)
 
Last edited by a moderator:
So what about speed improvements? Or is this as good as it's gonna get? I realise it's beta and all... I just don't want to have dashed hopes and dreams :D
 
HackModford said:
So what about speed improvements? Or is this as good as it's gonna get? I realise it's beta and all... I just don't want to have dashed hopes and dreams :D

There will be speed improvements, but only the devs can give you an estimate of how much improvement might be able to be made.

-God Ginrai
 
Last edited by a moderator:
(Apologies for cross post, advised other thread was best left to die....)

Video of Pandora playing Starfox here: http://www.youtube.c...h?v=wUDdq83iz8E (posted by Trevsweb)

Comparing that to a N64 video, it looks like the draw distance in mupen64plus is greater than on N64 hardware. Or perhaps more accurately, fogging is not quite correct at distance. Most obvious a short way into first level when the mountains appear out the sea - they fade in on a N64 and suddenly pop into life on the pandora video.

Doubt this has any impact on the emu at all in terms of speed, and is a very minor bug report as such, but just wanted to mention in case it increased the amount of calculations that could be ditched in the gfx plugin as something not yet required on screen....
 
I went to minimenu
Set CPU to 750
Used Background Killer
And set the frameskip to 2

Suddenly Mario64 became playable :D
 
Tested 1080 again. This time at 700 MHz. The menu itself did not show up, but the background did this time. It seems that this is the same for the whole game. All of the menu overlays are not showing up. Seems to run well with frameskip 2 with sound. It's just that the sound is jumpy, like in most games.

EDIT:
HackModford said:
I went to minimenu
Set CPU to 750
Used Background Killer
And set the frameskip to 2

Suddenly Mario64 became playable :D

Strange... It works fine in Xfce for me at 700MHz with sound with fs 2. No need to use the Background killer. I get the occasional sound skip, which I'm sure can be dealt with by setting the clock up higher.

EDIT 2: Talking about Mario 64 made me want to play it. I just noticed one graphical glitch for the game. In the castle, it does not display the stars on the doors. (The Number of stars needed to enter a door)

EDIT 3: Is it me, or does it seem really hard to use the Analog nub in SM64? I think it's too sensitive. It's really hard to walk as Mario or to turn the right direction.

-God Ginrai
 
Last edited by a moderator:
I never tried without background killer...
Also I can change direction perfectly... I can make mario tiptoe but it is a little hard. Just a tad bit too sensitive for me.
Oh yeah... I have sound enabled also.
 
Try it with frameskip=2 and you can get similar speed with sound enabled too.
Just to be clear, if "frame skip=1" that means that NO frames are skipped. If it equals 2 then its half framerate, 3 = 1/3 framerate, etc.

Is there a way to see a fps? Emu works fine in minimenu.
It outputs the fps to stdout, so run it from the terminal. Its probably best to use something like: "/usr/pandora/scripts/pnd_run.sh -p mupen64plus-r1.pnd -e ./run.sh". This way the environment variables will be set correctly and it will find the config files.

But Yoshi's Story for example is still buggy as hell. That isn't really important. But if you want to see a game with huge graphical glitches, try it.
I don't think Yoshi Story works in gln64 either, it uses some strange rendering approach that requires game specific hacks.

(Note: I say was cause i thought that i saw recently Adventus commented to the fact he wasnt using it anymore, but either case mupen is using 3d hw)
Correct. I've ported it all to OGLES2 now, there is no wrapper involved.

Comparing that to a N64 video, it looks like the draw distance in mupen64plus is greater than on N64 hardware. Or perhaps more accurately, fogging is not quite correct at distance. Most obvious a short way into first level when the mountains appear out the sea - they fade in on a N64 and suddenly pop into life on the pandora video.
This is because Fog is disabled in the config file. I haven't tested it in a long time but setting it to 1 should turn it on. It comes with a noticeable performance drop.

EDIT 3: Is it me, or does it seem really hard to use the Analog nub in SM64? I think it's too sensitive. It's really hard to walk as Mario or to turn the right direction.
I broke my left analog nub, so those settings are bound to be wrong. Try the DPAD version if its unbearable.

Tested 1080 again. This time at 700 MHz. The menu itself did not show up, but the background did this time. It seems that this is the same for the whole game. All of the menu overlays are not showing up. Seems to run well with frameskip 2 with sound. It's just that the sound is jumpy, like in most games.
I have tested 1080 before, it has trouble with my frame skip implementation (I'm pretty sure it used to work though). It should look fine with frame skip=1, but it might be a bit slow.

BTW: I also suggest trying framebuffer enable=1 and half resolution settings (ie framebuffer width=400, framebuffer height=240), some games work a bit faster.
 
Adventus said:
EDIT 3: Is it me, or does it seem really hard to use the Analog nub in SM64? I think it's too sensitive. It's really hard to walk as Mario or to turn the right direction.
I broke my left analog nub, so those settings are bound to be wrong. Try the DPAD version if its unbearable.

Tested 1080 again. This time at 700 MHz. The menu itself did not show up, but the background did this time. It seems that this is the same for the whole game. All of the menu overlays are not showing up. Seems to run well with frameskip 2 with sound. It's just that the sound is jumpy, like in most games.
I have tested 1080 before, it has trouble with my frame skip implementation (I'm pretty sure it used to work though). It should look fine with frame skip=1, but it might be a bit slow.

BTW: I also suggest trying framebuffer enable=1 and half resolution settings (ie framebuffer width=400, framebuffer height=240), some games work a bit faster.

It's not that the analog is unbearable, it's just that it seems too sensitive. :\ It becomes "run" too easily in Mario, for example.

As for 1080, I'll try your suggestion later and see what comes of it. ^_^

Btw, half framerate means that every 2nd frame is rendered, and 1/3 framerate means every third is rendered, right?

-God Ginrai
 
Last edited by a moderator:
Thanks for the responses, very useful.

BTW: I also suggest trying framebuffer enable=1 and half resolution settings (ie framebuffer width=400, framebuffer height=240), some games work a bit faster

interesting. Can we not get essentially free scaling out of the sgx hardware? Or is it again due to sgx driver? How much gain - is it worth rendering to 400x240 and scaling?
 
Adventus said:
Comparing that to a N64 video, it looks like the draw distance in mupen64plus is greater than on N64 hardware. Or perhaps more accurately, fogging is not quite correct at distance. Most obvious a short way into first level when the mountains appear out the sea - they fade in on a N64 and suddenly pop into life on the pandora video.
This is because Fog is disabled in the config file. I haven't tested it in a long time but setting it to 1 should turn it on. It comes with a noticeable performance drop.
I'm not a N64 expert but I always thought the fog was to gain more performance because this way the drawing could be start later. I remember the N64 as a very foggy and blurry Console (PAL). So at the N64 the fog gave more performance (becuae it was less stuff rendered in the distance) but in emulation, it does quite the opposite thing?
The world of emulation really is a strange thing :lol:

Oh, because of the nubs: will there be an Emulator Menu-Setting for Nub-sensitivity/ general Button mapping?
 
Last edited by a moderator:
fusion_power said:
Adventus said:
Comparing that to a N64 video, it looks like the draw distance in mupen64plus is greater than on N64 hardware. Or perhaps more accurately, fogging is not quite correct at distance. Most obvious a short way into first level when the mountains appear out the sea - they fade in on a N64 and suddenly pop into life on the pandora video.
This is because Fog is disabled in the config file. I haven't tested it in a long time but setting it to 1 should turn it on. It comes with a noticeable performance drop.
I'm not a N64 expert but I always thought the fog was to gain more performance because this way the drawing could be start later. I remember the N64 as a very foggy and blurry Console (PAL). So at the N64 the fog gave more performance (becuae it was less stuff rendered in the distance) but in emulation, it does quite the opposite thing?
The world of emulation really is a strange thing :lol:

Oh, because of the nubs: will there be an Emulator Menu-Setting for Nub-sensitivity/ general Button mapping?

Sometimes you need to fog though - like in Mario 64, when you swim down to the pirate ship it doesn't appear straight away (it's normally covered by fog).
 
Last edited by a moderator:
Btw, half framerate means that every 2nd frame is rendered, and 1/3 framerate means every third is rendered, right?
Correct.

I'm not a N64 expert but I always thought the fog was to gain more performance because this way the drawing could be start later. I remember the N64 as a very foggy and blurry Console (PAL). So at the N64 the fog gave more performance (becuae it was less stuff rendered in the distance) but in emulation, it does quite the opposite thing?
The world of emulation really is a strange thing
The Fog is used to hide the fact that stuff is popping up in the distance. Its always faster without fog, its just uglier.

interesting. Can we not get essentially free scaling out of the sgx hardware? Or is it again due to sgx driver? How much gain - is it worth rendering to 400x240 and scaling?
It depends on how hard the SGX is being pushed. If its being pushed hard, like in Banjo Kazooie, then it makes a significant gain. Sometime i'll test out the scaling hardware which Notaz exposed.... but it will require dropping X11.

Oh, because of the nubs: will there be an Emulator Menu-Setting for Nub-sensitivity/ general Button mapping?
Probably, At the moment I'm tossing up whether we port blight input or improve ppsp_input. I'm leaning towards ppsp_input.... just so i can make modifications easily.
 
Any chance of an option to increase the graphics brightness? It doesn't look quite right, even with Ed's TV gamma setting.
 
Back
Top