Beta Mupen64Plus

[fusion_power]

I played Ultra HLE onto an 266MHz PC ages ago and it worked. All I had else was an VooDoo2 GFX Card with only 8MB VRAM.

UltraHLE was also a lot less compatible. But the real advantage it had (and the biggest impediment to performance on Pandora) is the very light-weight API Glide gave you, which I guess was a close enough match to the N64 feature set UltraHLE emulated.

Yes, good old Glide - games never looked better those days, even in 16Bit color depth.
I thought, the Open GL ES is some kind of light and optimized version of the "big" OpenGL, somehow like Glide, just focussed onto mobile devices. I don't know how powerful GLES can be but I hope it is an advantage and not an Bottle neck. ^^""

 

[Pickle]

I played Ultra HLE onto an 266MHz PC ages ago and it worked. All I had else was an VooDoo2 GFX Card with only 8MB VRAM.

UltraHLE was also a lot less compatible. But the real advantage it had (and the biggest impediment to performance on Pandora) is the very light-weight API Glide gave you, which I guess was a close enough match to the N64 feature set UltraHLE emulated.

Yes, good old Glide - games never looked better those days, even in 16Bit color depth.
I thought, the Open GL ES is some kind of light and optimized version of the "big" OpenGL, somehow like Glide, just focussed onto mobile devices. I don't know how powerful GLES can be but I hope it is an advantage and not an Bottle neck. ^^""

Nope ES is really only the core portions of desktop GL

 

[Exophase]

Yes, good old Glide - games never looked better those days, even in 16Bit color depth.
I thought, the Open GL ES is some kind of light and optimized version of the "big" OpenGL, somehow like Glide, just focussed onto mobile devices. I don't know how powerful GLES can be but I hope it is an advantage and not an Bottle neck. ^^""

Glide is light because it's designed to fit directly on top of one vendor's hardware, and because the hardware acceleration model for 3D was a little simpler in general back then. OpenGL ES 2 has to support a variety of hardware, and their implementation techniques vary probably more substantially than desktop GPUs (where immediate mode, non-deferred tilers, and TBDRs are all used)

 

[Esn]

How beneficial frameskip is depends on how much work is done per frame (preferably autonomously) entirely by the GPU hardware, ie hardware acceleration. Old 2D PCs games had very little in the way of hardware acceleration. You had a framebuffer which presented a single layer and the ability to change its offset per-pixel for fast scrolling without having to redraw the screen. But it was up to the CPU to fill in the new background graphics as they appeared, and draw in sprites by first drawing background over where the sprites were and then drawing the sprite manually at a new location.

So it's probably not that you can't do frameskip, but that you'd only be skipping the redrawing of a flat framebuffer, which probably isn't that expensive. You wouldn't be able to skip all of the stuff that the CPU is tightly integrated in performing.

No, you can do frameskip, but not automatic frameskip. I was wondering if there's a reason for that or it's just because nobody ever got around to it. I do know that running Netkeen at frameskip 4 in DOSBox leaves it fairly unlaggy, while at frameskip 0 it is unplayable. So frameskip itself seems to make a substantial difference.

 

[PokeParadox]

Hi guys, bzFrank contacted me and asked if I could reintegrate his latest version of Mupen64Plus with PickleLauncher, so here we are: http://projectinfinity.org.uk/lib/exe/fetch.php?media=pokeparadox:beta:mupen64.pnd

Here is what he has to say about the new features of the display plugin:

--readme---
This is description for the additional configuration (auto frameskip).

1. Auto frameskip can now vary frame rate between 1 and 3 (meaning every frame, every second, every third) by default. The integration time is 8 frames, meaning the feature checks the times of last 8 frames and decides if frame skip must be increased or lowered. The increase happens rather quickly (to increase response, that the upper trigger with value "1100" below), the lowering more slowly (thats the lower trigger with value "600" below). The rate can only change every 8 frames, this is the delay frames factor.

2. For gles2n64 0.0.5 you can now setup the auto frameskip feature in the config:

auto frameskip <0 or 1> turns on autoframeskip is set to 1
auto maxskip <NUM> the maximum skip rate (every 1, 2, 3, 4, ...), default 3
auto minskip <NUM> the minimum skip rate (I suggest to set to 1 or 2), default 1

If you want to tune the internals:

auto adjust fps <0 or 1> if the target FPS rate should be adjusted too if min/max skip is reached, default
is yes (1)
auto delay frames <NUM> the number of frames the skip feature waits before adjusting the rate again
auto upper trigger <NUM> the time factor when the frame rate is increased, default 1100 (meaning 10% above
the default frame time integrated over 8 frames), Should be higher than 1000!
auto lower trigger <NUM> the time factor when the frame rate is lowered again, default is 600.
Should be lower than 1000!

3. gles2n64 0.0.4 now also has the auto frameskip feature, however not configurable set fix to maxskip 3. I have kept 0.0.4 in because it still renders LOZ:OOT better than 0.0.5, in particular the static scenes (e.g. when entering Hyrule, on the drawbridge).

 

[fusion_power]

nice. ^^
I wondered for what I should use gles2n64 0.0.4 when 0.0.5 is already there, so I actualy only need the older one for Zelda?

 

[Exophase]

No, you can do frameskip, but not automatic frameskip. I was wondering if there's a reason for that or it's just because nobody ever got around to it. I do know that running Netkeen at frameskip 4 in DOSBox leaves it fairly unlaggy, while at frameskip 0 it is unplayable. So frameskip itself seems to make a substantial difference.

If frameskip is effective then auto frameskip will be more effective, but only if you can achieve real-time speed with it. If you can't then auto frameskip degenerates into a fixed frameskip since it hits some cap. Or skips every single frame, like the old SNES emulator NLKE would do. In this case it sounds like you'd fall under this situation still.

I'm surprised that skipping most of your frames on a DOS game makes that much of a difference. Maybe the screen blit code isn't that efficient? I know on some platforms SDL has really slow surface updates.. on my Atom netbook running Linux it can take over 9ms for a pretty tiny surface, which is deplorable. Doesn't have that kind of hit in Windows though. Might be GPU driver related.

There'll also be an additional speed hit per-frame that's possibly worth skipping if it's scaling in software (and if that isn't that optimized, especially if it has filtering)

 

[Blue Protoman]

OK, this is how the update works for several games;

Super Mario 64 is no longer plagued by unnecessary frameskip! Hooray!

GoldenEye 007 runs a bit better now!

Star Soldier: Vanishing Earth is hard to play! The menus are invisible now, and the background elements when in-game don't show up. Not good!

And F-Zero X is slower now. But not choppy; I think it's the new frameskip. Not good!

Wave Race 64 is now unplayable! A black box appears over everything, including gameplay!

Ridge Racer 64 now runs blissfully! (In-game at least; menus are a bit slow with choppy sound, but they're plenty usable.) Awesome!

And San Francisco Rush is still slow, as is Extreme-G.

 

[fusion_power]

OK, this is how the update works for several games;

Super Mario 64 is no longer plagued by unnecessary frameskip! Hooray!

GoldenEye 007 runs a bit better now!

Star Soldier: Vanishing Earth is hard to play! The menus are invisible now, and the background elements when in-game don't show up. Not good!

And F-Zero X is slower now. But not choppy; I think it's the new frameskip. Not good!

Wave Race 64 is now unplayable! A black box appears over everything, including gameplay!

Ridge Racer 64 now runs blissfully! (In-game at least; menus are a bit slow with choppy sound, but they're plenty usable.) Awesome!

And San Francisco Rush is still slow, as is Extreme-G.

All with standard Clock rate? I still use the old Mupen and played everything at 750 MHz but even Mario64 feelt very different than I remember it in case of "smoothness". Great if this is fixed, will try the new Version later. Are the sound issues fixed? In nearly all games the sound was lagging and stopping for some frames. Lylat Wars or Smash Bros have this for example. And no, I don't want to play without sound. ^^

 

[bzfrank]

Thanks for the tests fusion_power and of course PokeParadox for the Picklelauncher work. At the moment I am at the beach (vacation) so I can only check here infrequently. But the weather is good and the water nice!

Most of the issues are regressions caused by 0.0.5, just set the gfx driver to 0.0.4 and they should go away. Thats why I kept it in. 0.0.4 in the version has all the hacks now in 0.0.5 (patch for Zeldas sun, Pilotwing, etc.) and the new auto frameskip (min: 1 max: 3) is on by default but is not as configurable.

 

[Blue Protoman]

Sound I haven't checked. And good move in keeping the old plugin; problem is, I REALLY don't want to have to switch back and forth between plugins! Can you allow plugins to be selected on a per-game basis? Please?

 

[fusion_power]

Thanks for the tests fusion_power and of course PokeParadox for the Picklelauncher work. At the moment I am at the beach (vacation) so I can only check here infrequently. But the weather is good and the water nice!

Most of the issues are regressions caused by 0.0.5, just set the gfx driver to 0.0.4 and they should go away. Thats why I kept it in. 0.0.4 in the version has all the hacks now in 0.0.5 (patch for Zeldas sun, Pilotwing, etc.) and the new auto frameskip (min: 1 max: 3) is on by default but is not as configurable.

Hm, this could be a reason, I only had v.0.0.5 active, never testet the older one. ^^"" But I actualy haven't played much with Mupen at all, just testet how Mario runs (runs OK at 750 MHz and low res like 400x240) and Lylat Wars (not that great onto the older Mupen). I also have Goldeneye somewhere but I can imagine that it is not the fastest emulated Game onto Mupen64.
I set the Res in Mupen config to 400x240 in general, feels smoother but I have no real values how faster this is compared to full 800x480 res. I guess it is still not full speed, which I understand as 50-60 FPS all the time with sound and no Frameskip. ^^ But some Games you can already play, this is good.
I just wish I could set the Renderer to 4:3 without gfx artifacts around the screen area. Mupen 64 works with 640x480 res for example but the Image is not centered. I hope this can be fixed without much trouble.
Or a "true" widescreen mode would be also nice, so Mario is not that fat anymore in Fullscreen.

 

[Blue Protoman]

That would require some extreme hacking, to my knowledge. Possibly even patches for the games themselves.

 

[fusion_power]

OK, I tested the new Mupen64 and it runs good, now with the nice screen centering when using a 4:3 Resolution, works great. With the older graphics Plugin the imge has a small frame around, even in full screen 4:3 where some artifacts remain, at least with Starfox 64. But I was able to eliminate the artifacts by disabeling offscreen rendering. I don't know the settings for eliminating the small frame around the image to get the full 640x480 but I continue testing. ^^
The 0.0.5 GFX Plugin displays the image over the full size, but the 0.0.4 Plugin on the other hand is faster. The newer one however has this new Frameskip....hmmm decicions, decicions...

EDIT: the new Graphics Plugin ignores in Smash Bros the 4:3 setting in the config. I wanted to use the new one because there the game is faster than with the old plugin. However, Sound is horrible with both sound plugins, lags nonstop in smash bros. ROM is marked as possible Hack, shouldn't be actualy.

Possible Bug of the Emu: when returning to the desktop, right nub is not in Mousebutton mode, older Mupen Version returned this correct, at the Moment I have to set the nubmode per hand back to normal.

 

[Blue Protoman]

I'd REALLY like to be able to configure settings (including choices of plugins) on a per-game basis. Doing so would improve the emulator by leaps and bounds.

 

[bzfrank]

Game-specific config settings are already in gles2n64 0.0.5.

 

[Blue Protoman]

So how can I use them, then? And I wanna be able to pick plugins by game, too.

 

[Schnatterplatsch]

Hi guys, bzFrank contacted me and asked if I could reintegrate his latest version of Mupen64Plus with PickleLauncher, so here we are: http://projectinfinity.org.uk/lib/exe/fetch.php?media=pokeparadox:beta:mupen64.pnd

So there is a new version of Mupen? At the moment it seems I cannot connect to the repo, but would it be possible to upload it there(since precious version didn't seem to be)? Not everyone is (sadly) using gp32x.de anymore, or checking threads for updates.

 

[PokeParadox]

Hi guys, bzFrank contacted me and asked if I could reintegrate his latest version of Mupen64Plus with PickleLauncher, so here we are: http://projectinfinity.org.uk/lib/exe/fetch.php?media=pokeparadox:beta:mupen64.pnd

So there is a new version of Mupen? At the moment it seems I cannot connect to the repo, but would it be possible to upload it there(since precious version didn't seem to be)? Not everyone is (sadly) using gp32x.de anymore, or checking threads for updates.

I don't consider myself to be the maintainer of Mupen64Plus. I merely hacked the scripts and added PickleLauncher support. I do not want to personally upload this to the repo since no-one has previously done so. You are fortunate I have it easily available from my web space in the meantime.
The idea is that bzFrank or anyone else actively working on the project itself can put the "stamp of approval" on this and upload it to the repo.

 

[bzfrank]

For this version Mupen itself has not changed. Only gles2n64 has changed (to add the new frameskip) and Poke did add the Picklelaucher support.

Speaking of a release on the repository - I think the main issue is that there is currently no real maintainer of Mupen64. A lot people contributed large parts, Ari64, Adventus, ... but are currently busy with other stuff. I only worked on the gfx plugin a bit, so I don't feel qualified to assert maintainer status.