(N64 Emu) Mupen64plus 2.0


Rice's plugin is usable by project64, but not exclusively used by it. What this might bring to the table for our pandora, this would most likely bring better game compatibility. I am not going to promise speed at all, but I am optimistic. This most certain can enhance visuals to a potent level...


Here is the change log of the fork from paul's code



Code:
1.8

- Updated gles2rice to v0.1.0

	- Fixed graphics glitches in many games

	- Improved 2D elements

	- Improved speed on many devices

	- Implemented HiRes Texture functionality

v1.7

- Fast Texture CRC: disable to improve 2D elements

v1.5

- Skip Frame: speed improvement

- Fast Texture: circle transition fix (Conkers Bad Fur Day)

v1.4

- Updated gles2rice to v0.0.9 (improves 2D elements)
 
Last edited by a moderator:
Rice's plugin is usable by project64, but not exclusively used by it. What this might bring to the table for our pandora, this would most likely bring better game compatibility. I am not going to promise speed at all, but I am optimistic. This most certain can enhance visuals to a potent level...


Here is the change log of the fork from paul's code



Code:
1.8

- Updated gles2rice to v0.1.0

	- Fixed graphics glitches in many games

	- Improved 2D elements

	- Improved speed on many devices

	- Implemented HiRes Texture functionality

v1.7

- Fast Texture CRC: disable to improve 2D elements

v1.5

- Skip Frame: speed improvement

- Fast Texture: circle transition fix (Conkers Bad Fur Day)

v1.4

- Updated gles2rice to v0.0.9 (improves 2D elements)

Thanks for the answer & a huge thanks for undertaking this.. here's hoping we will see some improvements soon.. Paper Mario playable speed & glitch free..?? (and even sshhh Goldeneye) i live in hope.
 
Well it still doesn't show the new plugin but the old ones showed up this time.


Here's my out file now.


Version 1.5-development


Couldn't load plugin 'libvideorice_EXPERIMENTAL.so': /mnt/utmp/mupen64plus-r1/plugins/libvideorice_[audio] can't open config: No such file or directory


EXPERIMENTAL.so: undefined symbol: Android_JNI_SwapWindow


Config Dir: /mnt/utmp/mupen64plus-r1/config/


Install Dir: /mnt/utmp/mupen64plus-r1/


Plugin Dir: /mnt/utmp/mupen64plus-r1/plugins/


Rescanning rom cache.


Rom cache up to date. 0 ROMs.


Glad to be helping out.
 
Thank you, Game master. You are posting the information I need.


To everyone following, don't expect an update in the next 3 hours, I have something else I have to do. Cheers.
 
if youre looking for real-time support/testing, irc.freenode.net #openpandora is always open for business
 
I could probably utilise my experience from Daedalus if this Plugin works :)
 
Last edited by a moderator:
Ok it still doesn't show up in the menu and here's the data.


Version 1.5-development


/mnt/utmp/mupen64plus-r1/plugins/libvideorice.so: undefined symbol: GetDllInfo


Plugin 'libvideorice.so' is an invalid plugin


[audio] can't open config: No such file or directory


Config Dir: /mnt/utmp/mupen64plus-r1/config/


Install Dir: /mnt/utmp/mupen64plus-r1/


Plugin Dir: /mnt/utmp/mupen64plus-r1/plugins/
 
Did I get the right file because I have the same out data.


Version 1.5-development


/mnt/utmp/mupen64plus-r1/plugins/libvideorice.so: undefined symbol: GetDllInfo


Plugin 'libvideorice.so' is an invalid plugin


[audio] can't open config: No such file or directory


Config Dir: /mnt/utmp/mupen64plus-r1/config/


Install Dir: /mnt/utmp/mupen64plus-r1/


Plugin Dir: /mnt/utmp/mupen64plus-r1/plugins/
 
Last edited by a moderator:
Try it now, I have rename the pnd mupentest.pnd, I will start a naming scheme on it the next time.


EDIT: On examining the other programs, we might be very close. 'Grep'ing" the other plugins within the published pnd reveals that they have the "GetDllInfo" symbol, while ours does not. If you get the same error again, that might be okay news. This is a Job for tomorrow.
 
Last edited by a moderator:
After studying the source on sebt's website, paul's android source, and the current mainstream build of mupen64plus, I have concluded that the plugin I am porting is too new (1.9) to be compatible with the pandora's mupen build (1.5) . The 'GetDllInfo' missing symbol Gamemaster is reporting is part of a strict handshake sequence between the old plugins and the old mupen core. The more recent builds do have not this sequence. Since this plugin doesn't inherently have the call-back for the GetDllInfo sequence that the core expects, it fails, and does not get loaded.


I have a few options, one to go the extra mile and completely do the entire 1.9 build?

This would mean that:

  • There would be no GTK front-end, just picklelaucher + CLI. New versions of mupen step completely away from gui entanglements.

  • All the plugins would have to be rewritten and recompiled for the new branch, and I can't find the sources to notaz's sound plugin or the custom control plugin. I have tried slapping older plugins into 2.0 to see if it still had some kind of support, but new versions of mupen won't accept 1.5 plugins. They Need to be changed to this api.
  • All options will have to be handled by text editor.
  • GLES2N64 wouldn't be forgotten, it would have to be recompiled, and its api has already be corrected in the android and webos builds. It would, needless to say, gain or lose title support.

Somehow spoof the core.

This could mean more work then what really appears, mupen64plus has changed alot more then one area, and somehow getting an older core to accept a younger plugin may be difficult


Rewrite the current core.

Just the inverse of above, except that it could theoretically accept all plugins. I repeat, Theoretically. If I was going to this, I might as well do option one.


If I had to go with option one, when it came to the repo, I would recommending reclassifying the current mupen64plus as a legacy version 1.5 and leave it completely intact the way it is right now, The new version would have an opposite label 2.0, and both would coexist together on the repo. I want the community's opinion on this, especially devs. If I was going to tackle this, I would need the sources of the two plugins I have mentioned.
 
Last edited by a moderator:
I would have to say if you feel up to it go with option one. It sounds like it could increase the performance some. Plus I would like a new GUI something about like the one used in PCSX ReArmed. Allowing for save states and config saves for each game.


But like I said it is up to you since you would be doing the work. Which ever you decide good luck and I will be here for testing when time comes. :)
 
I would recommend the first option, too, as it will be a lot easier to maintain, when it can use stuff from upstream directly.


I think it should become a new version on repo then.
 
Back
Top