Release Preview: Mupen64Plus 2.0 Video


Does the emulator run much faster than before or is it simply that the compatability is much improved?
 
I just hope it doesn't end up with what we had with 1.x, with lots of tarbals all over the net, and where the source more or less got lost over time..
I checked mupen64plus-ae core, but I found nothing new.I have all the sources in the same structure as the original mupen64plus source. I just have a few #ifdef here and there.

I think I will create a new git for them (all of the sources). The android version as everything "usefull" in the jni subfolder, that's not very conveniant.
I'm one of the devs for Mupen64Plus-AE and I can tell you I've spent a lot of time getting AE "back upstream" as much as possible. Right now I'm overhauling some Android-specific stuff on this branch: https://github.com/paulscode/mupen64plus-ae/commits/lifecycle-fixes

But the bottom line is that Mupen64Plus-AE now uses the vanilla source for the mupen64plus-core library, and darn-close to vanilla source for mupen64plus-ui-console, mupen64plus-ui-audio, mupen64plus-rsp-hle, and mupen64plus-video-rice. All non-vanilla customizations for AE are clearly set off by #ifdef PAULSCODE, and there are only a handful of them. The main difference between AE and the upstream version is that AE uses Ari64's "new dynarec" which has many known bugs compared to the standard x86 dynarec which the PC versions tend to use.

Just to clarify....
 
Last edited by a moderator:
The beta is fast moving. They're releasing updates twice a day to the testers with new menus, new plugins and more config options..... Once everything starts to stablize, you'll start to see more information released :)

You'll be happy once it's released by the amount of effort being placed into the port :)
 
Last edited by a moderator:
I just hope it doesn't end up with what we had with 1.x, with lots of tarbals all over the net, and where the source more or less got lost over time..
I checked mupen64plus-ae core, but I found nothing new.
I have all the sources in the same structure as the original mupen64plus source. I just have a few #ifdef here and there.


I think I will create a new git for them (all of the sources). The android version as everything "usefull" in the jni subfolder, that's not very conveniant.
I'm one of the devs for Mupen64Plus-AE and I can tell you I've spent a lot of time getting AE "back upstream" as much as possible. Right now I'm overhauling some Android-specific stuff on this branch: https://github.com/paulscode/mupen64plus-ae/commits/lifecycle-fixes


But the bottom line is that Mupen64Plus-AE now uses the vanilla source for the mupen64plus-core library, and darn-close to vanilla source for mupen64plus-ui-console, mupen64plus-ui-audio, mupen64plus-rsp-hle, and mupen64plus-video-rice. All non-vanilla customizations for AE are clearly set off by #ifdef PAULSCODE, and there are only a handful of them. The main difference between AE and the upstream version is that AE uses Ari64's "new dynarec" which has many known bugs compared to the standard x86 dynarec which the PC versions tend to use.


Just to clarify....
Thanks for the information.

To build I used vanilla mupen for core, rse and sound. I tried at first vanilla Rice with GLESv2 but had crash before entering ingame with game (does Rice GLES v2 stable on Android?). Than I copied your version of Glide64mk2 (which is very good, congrats!) wich I had running with a few customization.

I also grabbed your gles2n64.

Than I converted vanilla Rice plugin to GLS v1, to check it's stability (it is stable) and Arachnoid too.

One thing missing in the Glide plugin is FrameSkip. I know there is some code between #ifdef PAULSCODE, but I didn't found this code working well. Do you have effective frameskip on the Android version using Glide? I have frameskip using Rice, but Glide don't react well when just dropping a DisplayList.
 
Last edited by a moderator:
^Well I'm not a part of the reindeer games either..
 
Well how come I don't get to try this?

Seriously, when does it seem likely there will be a public release?
Everyone will be able to try it when ptitseb is convinced its all working well. Right now there's a lot of things that need fixing: Including the menu :p
 
Well how come I don't get to try this?

Seriously, when does it seem likely there will be a public release?
You could request the sourcecode and compile it yourself for testing ;)

I thought you were a fan of people only releasing stuff when It's ready. You complained so much about stuff you cannot figure the menu out or that has low compatibility.
 
Back
Top