Alpha Testing Underway!

[Kris]

I've been using the core from n64oid, I haven't made any compatibility fixes to the core the only changes were to get it to running on webos, some sdl stuff and __clear_cache mainly. I don't know if things have changed since but here is a post indicating the same zelda problem occurs on the pandora. I haven't had a good look through the debugger yet but the emulator still responds to pause and resume, there is some mention about changing framebuffer settings aswell which I haven't tried nor have I looked at using a save further into the game.

I'm hoping to fix Yoshi's Story in rice, I've found the same problem happens with with original version if you compile without asm so that narrows things down a bit, I've sorted the missing menu backgrounds on Mario Kart but the drivers are still facing backwards :/

I think I previously mentioned it a while back the missing backgrounds in gles2n64 and Ocarina of Time is due to gSPBgRectCopy in gSP.cpp:1561 returning early. You can checkout earlier versions of gles2n64 from the google code page but I haven't looked closely.

When you mention the api changes Yongzh made what are you referring to? Other than ReadScreen/ReadScreen2 I can't think of much else.

[Paul]

I found the code I was talking about again (in the rsp plug-in, ucode1.cpp, ucode2.cpp, and ucode3.cpp)..  Definitely looks like logic error fix, but unrelated to the Majora's Mask crash.  There is also another logic error fix I found in the core, rom.c.  Line 100 should read localrom=localrom[i+3]; (not localrom=localrom[1+3];).  I don't see any visible differences with these fixes in place, though, so they must not be very important.  You already have these fixes anyway, since you are based on n64oid (they'll mainly benefit Richard42 if he hasn't found them already).

I think I previously mentioned it a while back the missing backgrounds in gles2n64 and Ocarina of Time is due to gSPBgRectCopy in gSP.cpp:1561 returning early. You can checkout earlier versions of gles2n64 from the google code page but I haven't looked closely.

Thanks, I'll definitely take a look into this and let you know what I find out.

When you mention the api changes Yongzh made what are you referring to? Other than ReadScreen/ReadScreen2 I can't think of much else.

Well, I don't mean documented API specifically, but to the assumptions made in the code for how things are linked, where functions are located, and what calls what from where (which are every bit as important).  I may be wrong to refer to this as the "Mupen64Plus API", but I don't have a better term.  Since you had to add the SDL linkage back into Yongzh's code, I'm sure you know what I'm talking about.  It's the little things that make his specific plug-ins only work with his emulator.  Part of the reason was the removal of SDL, and part was to control things from the central GUI, and part was to keep the closed-source components he wrote separate from the open-source code.  By comparison, plug-ins written for PC Mupen64Plus, if recompiled for the ARM architecture, should work "out-of-the-box" in Mupen64Plus AE (at least that is the goal.. to have a source code base from which patches could be easily applied back to the official Mupen64Plus project, and vice versa).  The exception, of course, is the video plug-ins, which require a JNI linkage to flip the EGL buffers -- but then they wouldn't work "out-of-the-box" anyway due to GLES, so I don't feel too badly about that!  The GUI interfaces with unique features of the plug-ins (such as "frame skip", "screen stretch", and so on) through their config files rather than linking with the plug-in directly through an altered API with linkage to JNI.  That allows me to leave the plug-in code virtually unaltered and still portable.

[Paul]

Ok, reading back on my last post, it seems like a bit of a rant.  Let me put it a simpler way.  Take a look at Ari64's project, and then look at Yongzh's.  Ari64's code is not just a Pandora port with an ARM dynarec - he has improved the x86 and x86_64 dynarecs as well, and set it up so it can be built cross-platform.  Which one adheres to the  philosophy of collaboration and open-source?  That's what my goal is with this project (obviously I'm not there yet, but I will eventually.)  Hell, Yongzh's code isn't even complete!

[ulquiorra]

Hello, This emulator work on samsung galaxy Ace?
I have not got this phone, but I buy
i use google translate for this XD

[Paul]

Yes, folks have reported it working on the Galaxy Ace.  It will run slowly though, because it has one of the ARM6 chip-sets.  Besides rooting and over-clocking if possible, optimizations you can use in the upcoming version to make games more playable are to disable the audio plug-in, use the rsp-hle-nosound RSP plug-in, disable the virtual game-pad (or at least use one of the "touch" layouts with FPS disabled), use the gles2n64 video plug-in, disable screen stretch, and use frameskip.

[ulquiorra]

ok, thank you very much for your great work friend.
FOR MORE UPDATES WILL BE PENDING!!! Thanks

[Paul]

(that's a poke at Google Translate, not your language skills)

[ulquiorra]

(that's a poke at Google Translate, not your language skills)

my english no is very good sorry XD
but excelent work whit this emulator. (this is my english jeje)

[Paul]

No problem, I was just laughing that the program chose "pending" rather than the more obvious word "waiting".  Sounds like something a computer would say (oh wait, it is a computer!) 

I figured out a couple more things you could have meant..

"More updates will be outstanding".  The word "outstanding" translates to "pendiente".  However, another translation for "pendiente" is "pending".  "Pending" means "espera de".  Thus the confusion.

"For more updates(, I) will be watching".  "Pendiete" can also translate to "watching".  If a word were missing, I could see this translation happening.  A better translation would be "I will be watching for more updates"

And the most likely meaning:

"I will be waiting for more updates" (Estar? esperando m?s actualizaciones).  This could happen if google got the grammar backwards.  I'm pretty sure this is what you meant to say.

Anyway, my Spanish skills are worse than your English, so don't worry. 

[scorpio16v]

The actual version of Pixel Dancing Studios " Sixaxis Controller " now supports mapping for touchinput. So you can map one hardware analog stick to the virtual stick to controll it.
So analog input for Sixaxis gamepads is possible on mupen64plus-ae, even if it's not implemented.

[tgwaste]

Galaxy Nexus will be here tomorrow.  Wonder if M64P will run...

[Paul]

I figured out the issue with the audio.  It seems that if Mupen64Plus fails to load the plug-in specified in the config file, it searches the plug-ins directory for an alternate audio plug-in to use (the name doesn't matter).  Frankly, I find this behavior extremely presumptive and even potentially dangerous..  This is the first real criticism I have with the emulator and something I will definitely discuss with Richard42 about changing.  In the mean time, I still want to remain true to the original project, so I'm not going to "fix" the code.  There are other ways to disable the audio besides through the config files (there is an interface in the API for example), so I'll just hook it up a different way.

[Mats]

I figured out the issue with the audio.  It seems that if Mupen64Plus fails to load the plug-in specified in the config file, it searches the plug-ins directory for an alternate audio plug-in to use (the name doesn't matter).  Frankly, I find this behavior extremely presumptive and even potentially dangerous..  This is the first real criticism I have with the emulator and something I will definitely discuss with Richard42 about changing.  In the mean time, I still want to remain true to the original project, so I'm not going to "fix" the code.  There are other ways to disable the audio besides through the config files (there is an interface in the API for example), so I'll just hook it up a different way.

nicce, but in the next test could you include frameskip, or takes it time to include in the gui ? 

[Paul]

nicce, but in the next test could you include frameskip, or takes it time to include in the gui ? 

Yes, I've added a quick hack into the code to give folks access to it.  Of course, it only works with the gles2n64 plug-in (so it won't help Conkers).  I honestly don't really like it myself.  I'd almost rather have the audio disabled and the emulation speed a tad slow than to have the emulation speed normal with a low frame-rate (but to each his own, I suppose).  This is definitely not the ideal solution for improving performance (needs more tangible optimizations, IMO).

Anyway, here's the latest build.  All the plug-in "disable" buttons still don't function (it isn't just audio that Mupen64Plus automatically loads - it's all of them).  I'm thinking the best solution will be to compile "dummy" dynamic libraries, so Mupen64Plus feels happy that it loaded a plug-in (and the plug-in will simply not do anything, essentially disabling it).

 Someone recently accused me of violating the GPL with the recent post-GUI updates, so just to make it clear: as I stated before, if anyone wants the source code before I finish updating, just PM me and I'll send it to you (I'm just trying to avoid folks starting branches of the project in its current incomplete state, but if you really want the code right now, its yours).

It's really almost complete, I just need to implement the plug-in disabling, fix a bug with gles2rice when choosing "Close" from the in-game menu, and implement screen-stretch in gles2rice (maybe one or two other small things, I'll have to play around with the menus to see if I missed anything)

Test APK

[tgwaste]

.zip files supported in this latest version?