Alpha Testing Underway!

[Paul]

I think it would probably be a good idea to continue testing the current builds with an unzipped mario 64 rom. That way you can be sure the crashes are not being caused by the roms.

Yes, I forgot to mention, the .zip reading is still disabled.  I'll be sure to mention when I get it working properly.

the only problem is the key mapping, it doesnt recognize the keys in the input settings

The key listener is not hooked up yet (the listener is coded, but I haven't figured out how to receive key input from a custom dialog box yet -- the usual way doesn't work).  I'll post questions on various Android development sites tonight to see if someone knows.  I might end up having to get rid of my beautiful dialog box if I can't figure it out.. 

and the virtual pad is too big but im not sure about what app-data folder i have to replace by to fix that

This parts already coded into the GUI and working.  From the main menu, go to Skins->Virtual Gamepad->Change and select the layout you want to use from the list (probably one of the "Small" or "Tiny" layouts).

So if the users screen if larger or smaller then a certain size the first time mupen is launched it will set the appropriate control size for that user.

Only make it do this on the first launch after installing or else it will override the users current settings.

I'm way ahead of you -- I thought of this idea but haven't implemented it yet.. it will be in the next release (I'll post an update tonight whether or not I have time to finish the GUI).

[Paul]

Paul, it works ! but ven i disable the audio plugin it crash

This doesn't happen for me.  The "Enable" checkbox isn't working for me, but no crash.  I'll get it working and see if that fixes your problem as well.

Could you try librsp-hle-nosound.so see if it works for you (choose it in the the RSP plug-in section, not the audio plug-in section.. I might need to come up with something to make this more clear, haha).

and is it possible to add frameskips so it wont lag so much ?

From what I've gathered, this function was handled differently in different versions of gles2n64.  I haven't looked that closely at this part of the code for the version I'm using to know how to configure it (it would be done through the config file).  This is one of the areas I will focus on after finishing the GUI.  I need to get my hands on the source code for a couple builds of gles2n64 from the Pandora project for comparison, and figure out which version works best for most folks.

If anyone can help me locate the versions of gles2n64 from the Pandora project that seem to have been removed, I'll look into this sooner rather than later..

[xperia64]

found this on the maemo website: http://repository.maemo.org/extras-devel/pool/fremantle/free/source/m/mupen64plus-arm/mupen64plus-arm_20100627.orig.tar.gz
appears to be the same thing as the pandora source? idk
Edit: yeah appears to be glide64 and gl64 in there if those are what you want

[Paul]

Yes, I have that, it's just the emulator itself.  As I recall, the gles2n64 plug-in development was done separately, and there are at least 2 versions which had frameskip added (something like "r4b" and "r5", but I can't remember off the top of my head).  They both handled frameskip differently (as I recall one allowed like one or two frames to be skipped and the other allowed you to specify a number.. don't quote me on that).  The version I'm using is a hybrid of Yongzh's, Zodttd's, and Lachlan's code, so I have no idea what's in there and what needs to be added for frameskip to work (I'd be willing to bet it is broke at the moment).  That's why I need some different versions for comparison before I can get an idea of how it is supposed to be implemented.

--EDIT--
I did a little digging through the code, and it looks like the frame skipping stuff is there, but just not hooked up.  There is the following callback, which is not part of the official Mupen64Plus API, and is not being called from anywhere in the code:

Code: [Select]

EXPORT void CALL SetFrameSkipping(bool autoSkip, int maxSkips)
{
    frameSkipper.setSkips(
            autoSkip ? FrameSkipper::AUTO : FrameSkipper::MANUAL,
            maxSkips);
}Presumably, this is called from the front-end (I'm pretty sure the Pandora versions allowed you to configure this through the config files, not via a callback, so this is probably something Yongzh came up with).  Looking at the config file, it seems to be written for a different version of gles2n64 (several parameters are missing or simply ignored) - I'm assuming Yongzh pulled functionality out of the config files to move it to the GUI instead.  I'll play around with the code to see if frameskip actually works when I call the callback.  From the code, it looks like "autoSkip"" is supposed to cause frameskipping to change dynamically to try and achieve the target FPS, or if set to manual, you define the maximum skips yourself.

[Paul]

Yep, frameskip works.  I can get Zelda to emulate at full speed with no audio glitches using a frameskip of 4 (slows me down to 3 FPS though  )  I'll implement an interface for this after I finish the GUI (I'll need to move stuff back into the config file to work with the way I implemented the GUI, which reads/writes from the config files, rather than whatever method Yongzh's N64oid GUI uses)

[xperia64]

Sounds good. I wonder if Banjo Tooie might work better 
Btw, also tweeted to zodttd about this project in case he hasn't found it yet

[Epic_bubble]

Sounds good. I wonder if Banjo Tooie might work better 
Btw, also tweeted to zodttd about this project in case he hasn't found it yet

zodttd definitely knows about this project, I remember him posting here before and he asked if paul wanted his unfinished n64droid source.

[Paul]

Yes, Zodttd helped me solve the "black screen" bug that had the project at a standstill for almost six months.  He emailed me the source code for his unfinished Android port of gles2n64, and suggested where the problem might be located (which gave me some more code to compare and tinker with and eventually get a working plug-in).

[Paul]

I hooked up nearly all of the remaining functionality besides the key listener, which I'm waiting for a necessary piece of information before I can do that.  Unfortunately, I broke the golden rule of development, which is to never do too much at once between tests.  I seem to have introduced some instability, and I can't figure out what's causing it.  Basically, going back from the game to the menu, or from the game to the home screen then to the menu causes the app to crash.  Logcat is useless (stack trace full of libc calls).  My initial thought was that it was the save-state code that was causing it, but I commented that out and it still crashes, so it is definitely something else.  I'm going to have to back-track a bit and disconnect stuff once again until I figure out what's causing the crash.

Additionally, I haven't been able to figure out why disabling the audio plug-in doesn't work.  I can verify that the GUI removes the path from the config file (I've also manually removed it just to be doubly sure).  It is definitely still gone from the config file when Mupen64Plus starts up.  I've also removed the "default plug-ins" list that was hard-coded in, so it isn't getting loaded from there.  I even did a file-system search for the string "audio-sdl" and can not find where it is being loaded from in the code.  But every time (unless I enable the rsp-hle-nosound RSP plug-in), the sound always plays!     I pretty much spent all evening trying to figure out why..  I'm sure it is something obvious and I'm going to feel stupid when I figure it out.

Anyway, in case folks want to try it, here it is.  Once again, it is not stable, and will crash every time you go to the menu after running a game


Test APK

[Epic_bubble]

[Additionally, I haven't been able to figure out why disabling the audio plug-in doesn't work.  I can verify that the GUI removes the path from the config file (I've also manually removed it just to be doubly sure).  It is definitely still gone from the config file when Mupen64Plus starts up.

I know its not a good idea to use hacky work arounds but is it possible to move the audio plugin to a temporary folder when the user chooses to disable the audio plugin? That way the emulator couldn't use it at all.

If I remember correctly the plugin is stored somewhere which required root to access though. :/

EDIT: there definitely something wrong with the audio settings. Even when I change the plugin to something ridiculous like a video plugin it still plays audio.

[neo3]

[Additionally, I haven't been able to figure out why disabling the audio plug-in doesn't work.  I can verify that the GUI removes the path from the config file (I've also manually removed it just to be doubly sure).  It is definitely still gone from the config file when Mupen64Plus starts up.

I know its not a good idea to use hacky work arounds but is it possible to move the audio plugin to a temporary folder when the user chooses to disable the audio plugin? That way the emulator couldn't use it at all.

If I remember correctly the plugin is stored somewhere which required root to access though. :/

EDIT: there definitely something wrong with the audio settings. Even when I change the plugin to something ridiculous like a video plugin it still plays audio.

I also selected another plugin in audio, but seems to have no change. In the video, yes, I changed to another plugin and the emulation slowed.

[Mats]

if i have n64oid and take the audioplugin or videoplugin in use on mupen64plus would it work?

[Paul]

No.  Yongzh altered the official Mupen64Plus 2.0 API considerably.

[Paul]

I know its not a good idea to use hacky work arounds but is it possible to move the audio plugin to a temporary folder when the user chooses to disable the audio plugin? That way the emulator couldn't use it at all.

Actually, an even better solution might be to change the name of the plug-in library all together.  Since I'm planning on altering it anyway (to allow for dynamic framerates to eliminate skipping), I should rename it anyway so it isn't confused with the official audio plugin.  I'm also going to do some tests on the PC version to see if this bug exists in the official Mupen64Plus, and let Richard42 know if it does.

[Paul]

I'm still wondering if the early Majora's Mask hang is only on my port or if its a fix not in the current source release of n64oid.

Kris, did you base your core library off of the code for n64oid, or Mupen64Plus AE (or another project all together)?  I recall seeing various changes to the source code in Yongzh's project (either the core or the rsp plug-in, near some comments about Zelda) a few months ago when he released one of the versions on Source Forge (the second one I think).  I haven't gone back to see what this stuff is related to (I've been trying to get all the basics in place first).  The solution may be in there.  Also, it might be worthwhile to ask some of the Pandora folks if the problem exists in Ari64's project (if not, that could narrow down the search to the main sections of code that are different between versions 1.5 and 1.99.4 - better than starting from scratch anyway).  Let me know if you find a solution (and I'll do the same).