3.0 Alpha Testing

[scorpio16v]

Are there any plans to make the alpha 3.0 ui compatible to Nexus Player / ATV in the next time ?
Would be perfect to have all the new fixes and the gallery on TV.
A gamepad profile for the Asus Nexus Gamepad would be nice too. 

[littleguy]

I thought it was compatible with ATV?  We merged a pull request for this: https://github.com/mupen64plus-ae/mupen64plus-ae/commit/449a1781a677c4dce1289b8d1c9580bcddf40012

If you have the nexus gamepad, please create a custom profile for it, and then post the contents of mupen64plusae-v3-alpha/Profiles/controller.cfg back to this forum.  I'll include it in the next alpha.

I plan to post Alpha 20 once everything is converted to material design.  Seems like a good milestone.  Should happen this week.

Edit: Also, if you have a nexus player/ATV, please go to Help -> Hardware info in the main navigation drawer, and post the text to this forum.  That way we can put the UI in leanback mode by default for anyone with those devices.

[retroben]

Yeah,the latest master works perfectly fine on my ATV. (FireTV)
It doesn't even randomly crash after exiting a game anymore.

[scorpio16v]

just downloaded the latest master, retroben mentioned, on nexus player. This version didn't resume to home, like the version I testet before.
One big problem is, that I can only choose and start a game from the gallery, if I use a mouse. I can't access the games and the sidebar menu with the remote controller or gamepad.
In the game, it's impossible to go back to menu, because only the upper statusbar opened. No menu access. So I must kill the app and restart it.

Maybe I'm to stupid, but can't copy/share the hardware info on NP. I can't copy to clipboard or have another option. Only option is to ESfile-Explorer, but it isn't saved anything. Any ideas ?

A short video of the menu problem:
http://youtu.be/Ue5wrsq3Qz4

[littleguy]

Thanks scorpio.  I noticed that too that controllers don't work to select a game.  I'll put that high on the priority list to fix.  There are a lot of growing pains with such a big UI overhaul and it's easy to forget about some of the edge cases.  Thanks for the controller profile.

[Paul]

I'm taking a look at the cheats system.  Any other smallish things I should look at to start getting more familiar with all the changes?

[littleguy]

I'd say the biggest fundamental change since 2.x is the new profiles system.  Of course the gallery and nav drawer are all brand new as well.  I'll probably move a few things out of the GamePrefsActivity into the game-specific nav drawer, like the wiki link and the multi-player mapping.

Regarding material design, all activities use it now except for Game*Activity.  I have a branch in my personal fork that has some WIP for that.  When that's complete I'll switch all the alert dialogs to material design and we should be done with that.  The only thing holding me back from merging to master is a few corner cases with the action bar for Gingerbread devices and/or devices with menu hard key.

The number of java classes has ballooned for version 3, and I'm not terribly excited about that.  I've tried my best to define sensical subpackages to keep things a bit more organized.  I'm sure there are more places we can refactor to clean things up.

[retroben]

@Paul: A good example for how useful Dual Async could be is trying to play SM64 hacks like Shining Stars 2: Mirror Madness.
Course 6 alone is immensely slow while many other areas slow to a crawl with painful stuttering also on SLES and even make the emulator performance judder like crazy,especially with frameskip set to "no more than 5" mode.
Glide64 is not so bad,but just try playing it with glN64 and it might even bring you to tears.

The 1st "Bowser" stage (a monochromatic maze) is so bad it eventually can corrupt the audio and get insane judders.
That is probably because of the massive amount of objects and level size.
(This SM64 hack is also a fine example of why we need at least VI Refresh Rate added.)

Yeah,I know this is a romhack of SM64,but these are always really interesting and fun.

[Paul]

@Paul: A good example for how useful Dual Async could be is trying to play SM64 hacks like Shining Stars 2: Mirror Madness.

The benefits of adjusting audio to match the core speed are obvious -- I don't need convincing
I don't really recognize "Dual Async" as an audio algorithm or library, though -- guessing the term is specific to whatever emulator or app you saw that setting in?  Do you have any links related to this?

Anyway, I know of several libraries for changing the tempo of audio output without affecting the pitch.  I was thinking of using one called "Rubber Band" which is probably one of the best open-source libraries for adjusting audio tempo and pitch independently.  I would need to make sure it is light-weight enough for use in the app, of course.

From what I can tell (although I haven't looked at it too closely yet), the existing resampling component of the audio plugins only takes into account what the frequency is supposed to be for the game, and doesn't apply any adjustments for lag.  It also appears to only be designed to initially scale both tempo and pitch to the output format.  Something like Rubber Band would allow you to adjust the tempo and pitch independently, and could be used to scale both for an initial base-line and at the same time to dynamically adjust the just tempo based on the core speed to compensate for lag.

The main unknown I'd need to figure out is how to get a metric from the audio plugin code of the actual core speed compared to what it should be -- without having to add a hack to the core for counting cycles like I was doing for the net-play experiments.  There may be something I missed in the Mupen64Plus API related to this.  I'll ping the upstream devs before I tackle the problem.

[littleguy]

Awesome.  I know there was some recent upstream discussion about possibly consolidating some of the resampling functionality into a common location.  Perhaps some of these ideas could be inserted into that discussion.
https://github.com/mupen64plus/mupen64plus-core/pull/79
https://github.com/mupen64plus/mupen64plus-ui-console/pull/19

Also, there has been some upstream work on netplay in case you missed it:
https://github.com/mupen64plus/mupen64plus-core/issues/112

[Paul]

I hadn't seen the netplay discussion yet.  ymartel06's commit is a little hard to read as it included a lot of code reformatting (makes it difficult to pull out the important changes).  I'll have to look at it more closely when I have a chance.

[motawa]

can you please bring back the octagonal joystick limits optins and add rom shortcut option for homescreen?

[ofm05]

Might sound silly, but how do I start a game on alpha 19?

I load the rom and then what? Sorry I just cant figure it our

[mrbluru]

Since updating my n910f Note 4 to Lollipop 5.0.1, Glide 64 gives me weird missing/glitch textures on any of the Alpha builds
Here is an example from Banjo Tooie

[retroben]

So Lollipop has claimed another victim,but with this.
I get minor polygon issues with Glide64 on "custom" 4.2.2 JellyBean with FireTV,and an identical polygon issue on 4.4.4 Kitkat with my x86 Tablet.

Hopefully the Android distributors can update again to a bugfix update for your device.

Rice is a bit faster for Banjo-Tooie,but you got to make sure settings are right to prevent glitchy frame rendering.
Changing the type to "First CI Image" completely stops the glitch,but disables the dynamic shadow while "VI Refresh Change" or "VI Refresh Update" makes the dynamic shadow work with minor consequences of broken frame visuals while pausing emulation via mapped button/hotkey.

Do you know of my 60fps Banjo-Tooie code? "No Frameskip" 8007913F 0001
It doesn't always go full 60fps when CountPerOp is 0 or 2 but 1 can have a few cutscene softlock issues.
But it can still get really smooth on default and improve your experience.
Using 1 is best when the game is beaten and you just wanna mess around.
(and if your device is strong enough to maintain performance)

*epiphany* I just found a reason to add VI Refresh Rate overclocking support!

Because of the rendering glitch on Rice,I realized it is similar to the behaviour of choppy
framerates when VI Refresh Rate is the default of 1500.
On PJ64,I had to set it to 2200 in order to fix the choppy framerate when my code was enabled and CF=1 too.

So my reason why we need this option (exists in libretro's Mupen64Plus core on Android,so maybe source port capable) is because somes games may become extra-taxing on the emulator and it needs the extra 700 refresh rate to keep things smooth.