Brainstorming Version 3.0

[littleguy]

A lot of things (bug-fixes, new features, etc.) are easily accommodated in a minor version change.  But over the course of an app's evolution, you realize it would be best if you could restructure some of the UI, change some default values, etc.  It can be difficult to make these kinds of changes over a course of minor releases, since the user has to be aware of - and adapt to - a small set of important changes at each update.  Sometimes it's better to lump all these changes together, call it a major new release, and let users adapt to the new paradigm all at once.

What the heck am I talking about?  Well, here's a list of things I look back on and wish were different:
 - More Auto values for each preference (like the current Settings->Advanced->Accessibility)
     - Makes it easy to change default values between releases, and keep most users on the default
     - Makes it easy to implement game/device specific settings so things "just work" for most users
     - Candidates for Auto preference
         - Video plugin
         - Frameskip
         - Dynarec
         - Button layout
 - Restructuring the savefile folders to use the "good name" of the rom rather than filename
     - Works better if zip contains multiple rom files
     - Harder to misplace your savefiles
 - In the game selection dialog, navigate into zip files (rather than allowing them to be selected)
 - Re-balance the menus somehow
     - Audio menu is very light while Input and Video menus are very heavy
     - Plugins menu is often overlooked
 - Consider redesigning some menus/dialogs to avoid big-screen (no touchscreen) issues
     - Input and player mapping
     - Cheats
 - Consider tweaking some default input maps
     - I noticed that "Start" is often mapped to pressing the left or right stick in emulators on OUYA
 - Remove some preferences
     - Octagonal joystick limits (always enable?)
     - Share controller (enable/disable depending on connected devices)
     - RGBA_8888 mode (always enable?)
     - Audio resampling algorithm (always trivial?)
 - Tweaks to touchscreen skin stuff
     - Consider removing the buttonsNoScaleBeyondScreenWidthInches parameter
         (may cause more trouble than it's worth and users can fall back on the button sizing preference)
     - Perhaps add an example/template skin in the <sdcard>/mupen64plus to simplify customizations

The idea would be that when we make the major update, we wipe the slate clean so that we don't have to worry about leftover cruft:
 - Revert all settings to their default values
 - Migrate any files to the new file structure

As I said, it's best to do all this stuff in one fell swoop.  So, what major structural changes/features would like to see in a version 3?

 

[Paul]

- More Auto values for each preference (like the current Settings->Advanced->Accessibility)

This is a good idea, expecially for the folks who never want to touch the settings (which seems to be the majority of them, LOL).  I'm not sure if this could somehow tie into remembering game-specific settings, so that users can tweak "auto" values when necessary.  For example, some folks can not stand the sight of green rooms in Zelda OOT and would argue gles2glide64 should be the default "auto" value for this game.  Other folks realize the areas affected are few and far between, and would rather have the smoother video provided by gles2n64.  And there are the anomalous devices where, for example, gles2rice even without frameskip runs much better than gles2n64, or where one particular video plugin or frameskip setting will cause crashes.  And there is the non-Neon issue for gles2n64.

- Candidates for Auto preference
...
         - Button layout

YES 

- Restructuring the savefile folders to use the "good name" of the rom rather than filename

What would be the best way to make sure folks don't lose all their saves when they upgrade to 3.0?

- In the game selection dialog, navigate into zip files (rather than allowing them to be selected)

In addition to this, I'd like to see the core link to the ROM through a zip input stream, so that it wouldn't be necessary to ever extract the zip file (faster loading time for the games and cheats menu, while still using minimal storage space)

- Plugins menu is often overlooked

While this wouldn't help with the clutter, I'd like to see each plugin's settings built into their respective sections, rather than having separate menus for Plugins versus Settings.  I can't count how many times I've had to explain to users where to find the video plugin preference (they always assume it is in the video settings section -- often times reporting that they have "already tried all the video plugins" when in fact they only modified the settings for gles2n64).  So preferably you'd select the video plug-in from the "Video" section, and have the plugin-specific preference groups would show/ hide as necessary.  This would require writing a separate Activity for the video section to get around the current problem of having to reload the entire menu when the video plugin is changed.

     - Octagonal joystick limits (always enable?)

I think we can go for always enabled on this one.  As far as I know, speed differences are not noticeable on any device, I have not heard of any negative effect from having it enabled, and it improves the gameplay for many games (such as decreasing spin-outs out on Mario Kart, easier to do spin-attack in Zelda OOT, etc).

     - RGBA_8888 mode (always enable?)

I'm not sure on this one.  I'd have to look through the forum history for when we were testing this option to see if it had a negative effect for any devices.

     - Audio resampling algorithm (always trivial?)

We'd probably want to try and determine if anyone is using this feature.  I don't really hear any difference myself, but it could have an effect on higher-quality speaker systems.  Might also be worth seeing if it has any effect on the latency problem that has been reported (can't remember how this links up with SDL off hand).

     - Consider removing the buttonsNoScaleBeyondScreenWidthInches parameter

I suppose this could be hard-coded to some "average phone width".

So, what major structural changes/features would like to see in a version 3?

I'll think about this some more.  I've been toying with the idea of a more extreme change in the base menu sections to move away from the built-in Android preference-list look and utilize more graphics and custom UI features.  I am sometimes envious of devs who emulate simpler systems like the NES, and are able to spend much more development time on "eye candy".  I'll do some mock-ups (we'd want to get some of the artists in on the discussion as well).  Difficulty will be in testing on many different screen sizes and densities to make sure it is flexible.

[littleguy]

- More Auto values for each preference (like the current Settings->Advanced->Accessibility)

This is a good idea, expecially for the folks who never want to touch the settings (which seems to be the majority of them, LOL).  I'm not sure if this could somehow tie into remembering game-specific settings, so that users can tweak "auto" values when necessary.  For example, some folks can not stand the sight of green rooms in Zelda OOT and would argue gles2glide64 should be the default "auto" value for this game.  Other folks realize the areas affected are few and far between, and would rather have the smoother video provided by gles2n64.  And there are the anomalous devices where, for example, gles2rice even without frameskip runs much better than gles2n64, or where one particular video plugin or frameskip setting will cause crashes.  And there is the non-Neon issue for gles2n64.

Excellent points.  Perhaps the app searches three places for preferences.  First, the current location, then the <sdcard>/Android/data/... location, then finally say <sdcard>/mupen64plus/....   The second file would have game/device specific overrides which would only be used wherever "Auto" was selected.  The third file, if present, would contain user overrides for the second file.  We could probably hide the user override stuff behind behind a UI, I already have some ideas...

- Restructuring the savefile folders to use the "good name" of the rom rather than filename

What would be the best way to make sure folks don't lose all their saves when they upgrade to 3.0?

I was thinking a one-time migration of files from one location to another.  Trick would be making it 99.9999% failure-proof.  Lots of solid exception handling.

- Plugins menu is often overlooked

While this wouldn't help with the clutter, I'd like to see each plugin's settings built into their respective sections, rather than having separate menus for Plugins versus Settings.  I can't count how many times I've had to explain to users where to find the video plugin preference (they always assume it is in the video settings section -- often times reporting that they have "already tried all the video plugins" when in fact they only modified the settings for gles2n64).  So preferably you'd select the video plug-in from the "Video" section, and have the plugin-specific preference groups would show/ hide as necessary.  This would require writing a separate Activity for the video section to get around the current problem of having to reload the entire menu when the video plugin is changed.

I agree with all that.  A good example of a decision I regret.  The whole show/hide thing can be solved in numerous ways and shouldn't be driving the design of the UI.

     - Consider removing the buttonsNoScaleBeyondScreenWidthInches parameter

I suppose this could be hard-coded to some "average phone width".

This may be a matter of personal preference, and hearing all the complaints on Google Play, but I'm suggesting we remove this altogether.  Scaling proportional to screensize, regardless of screensize, seems to be the simplest mental model and I think what most users would expect.  A compromise would be to set the threshold above the 7" form factor but below 10".  First thing I do after reinstalling/resetting on my Nexus 7 is bump the scale up to 150% so that it's back to where it was.

I've been toying with the idea of a more extreme change in the base menu sections to move away from the built-in Android preference-list look and utilize more graphics and custom UI features.  I am sometimes envious of devs who emulate simpler systems like the NES, and are able to spend much more development time on "eye candy".  I'll do some mock-ups (we'd want to get some of the artists in on the discussion as well).  Difficulty will be in testing on many different screen sizes and densities to make sure it is flexible.

Would be cool, and would really reinforce the "3.0-ness" of the version.  Cover art would be nice, if there are no legalese issues.

[Paul]

     - Consider removing the buttonsNoScaleBeyondScreenWidthInches parameter

I suppose this could be hard-coded to some "average phone width".

This may be a matter of personal preference, and hearing all the complaints on Google Play, but I'm suggesting we remove this altogether.  Scaling proportional to screensize, regardless of screensize, seems to be the simplest mental model and I think what most users would expect.

I'm not sure I agree this is what most users would expect.  The reason for this value was for use in logic to prevent enormous virtual controls on tablets and microscopic controls on tiny screens.  Sure, folks could just scale them down, but from my experience, people tend not to even check if a resize option exists before they write a 1-star review which they never update.  That said, I think the math could improved from what it is now, to avoid more of the "too small" and "too large" complaints, and this particular value may not be needed to accomplish this anyway.  Another solution might be to make the scaling option more obvious somehow (using a word like "size" instead of "scale", adding an icon, etc)

[littleguy]

Fair enough.  My personal vote would be to set buttonsNoScaleBeyondScreenWidthInches to 5 or 6 for all the built-in skins, but that's just me.  Feels like a nice comfortable size on a Nexus 7, and probably the max size I would ever want.  But that's just me.

Wording suggestions are good if you think it's not obvious.

[Paul]

Ok, here is my first attempt at a UI mockup.  Keep in mind that I am no artist, and that this is a really rough representation just to get the conversation going (there are already some things I dislike about this after looking at it rather than just imagining it my head):



Basically the idea here is that in the current UI, the games are in effect a child of the settings.  Instead the focus should change to where the settings are a child of the games.  This would function basically like the gallery, where you start out at your list of games, with categories like "Resume Playing" shown here.  There would be an option to search your device for games (folder navigation would go away completely).  Bringing an item to focus would give you options to play/ resume or settings.  Settings would default to whatever is "auto" for that particular game, and would remember the user's preferences (and an option to return to defaults).  All settings would be dependent on the selected game.

Anyway, it is still a rough idea, but should give you the idea of where my imagination was going.

[littleguy]

Ooh, I like that child/parent analogy.  Makes me imagine the menu system that we have now simply as a viewer for Android-format preference files, of which we'd have many.  Global default, game overrides, and user overrides, in increasing order of precedence.  The user could potentially override anything, for a particular game (e.g. number of enabled players).

[littleguy]

Ok, now I'm itching to start implementing some concepts    Are there any loose ends in the current version that need tying up before we dive into this?  I imagine getting sucked into this, sounds fun...

[Paul]

I don't think there is anything glaring in the current version that needs to be addressed (most issues at this point are related to dynarec or video plugin problems).  There are a couple of small things I saw reported on the Play Store ratings after the update which I'm following up on (missing cheats and input delay).  I'll put these into issues on Github if they turn out to be regressions (too early to tell yet).

[littleguy]

So I was turning all this stuff over in my head last night, thought I'd post some initial thoughts on activity/menu hierarchy:

SplashActivity (rename MainActivity)
- Extracts assets and launches MainActivity

MainActivity
- Gallery panel (arrangement of blocks representing game roms, like Android's Gallery app)
    o Example game block (like your illustration)
        " Cover art
        " Game name (possibly with interpretation of tags like (U), (!), etc.)
        " Clicking/tapping pops up dialog:
            * Resume (launches GameActivity, pass resume flag to activity)
            * Restart (launches GameActivity)
            * Game-specific settings (launches SettingsActivity, passing <gameid> to activity)
- Action bar (or bottom menu in pre-Honeycomb), with most or all items in overflow
    o Multi-player setup (launches player mapping dialog)
    o Global settings (launches SettingsActivity without passing a game id)
    o Refresh games list (starts task to locate roms, pre-compute CRCs, download art)
    o Language
    o Help
    o About

SettingsActivity, when no game is passed (i.e. global settings) (evolution of current MenuActivity)
- Touchscreen (same as current, exceptions below)
    o Different UI for managing the layout (needs an Auto setting at very least)
- Touchpad (same as current)
- Controllers, keypads, and buttons
    o Mappable volume keys
    o Player 1 (dropdown with profiles, with a "disabled" option)
    o Player 2 (dropdown with profiles, with a "disabled" option)
    o Player 3 (dropdown with profiles, with a "disabled" option)
    o Player 4 (dropdown with profiles, with a "disabled" option)
    o Create custom profile (launches InputMapActivity)
- Video
    o Flicker reduction
    o Screen orientation
    o Vertical screen position (default: Top)
    o Rendered resolution (add Auto, make default)
    o Screen scaling (add Crop option)
    o Display framerate
- Advanced
    o Navigation mode
    o Swap audio channels
    o Use framelimiter
    o ROM directory
    o User data directory (slot saves, manual saves, input profiles, custom skins, per-game prefs)
    o Reload app resources
    o Device info
    o Crash reports category (same as current)
- Reset global preferences

SettingsActivity, when <gameid> is passed (hide some global settings, show some extra ones)
- Touchscreen (allow game-specific layout, skin, holdables)
- Touchpad (allow everything game-specific)
- Controllers, keypads, and buttons (allow game-specific profiles)
- Video
    o Flicker reduction
    o Screen orientation
    o Vertical screen position
    o Rendered resolution
    o Screen scaling
    o Display framerate
    o Video plugins
        " Plugin (Auto, glide, rice, n64) (default: Auto)
        " gles2n64 category
        " gles2rice category
        " gles2glide category
- Expert settings (don't change these unless you what you're doing!)
    o Use framelimiter
    o R4300 emulator (Auto, dynarec, cached interpreter, pure interpreter)
    o RSP plugin (Auto, rsp-hle, rsp-hle-nosound, none)
    o Audio plugin (Auto, mupen64plus-sdl-audio, none)
    o Input plugin (Auto, input-android, none)
- Reset <gamename>-specific preferences

[gdark100]

A very interesting feature to be implemented, but that would be really hard to make is the netplay. I've never seen any emulator with this feature in Android. The ppsspp will soon have this feature.

The ideas for the new UI is very cool. There goes a few suggestions:

- Ability to change settings with game running
- Screenshots in the savestate slots

Another thing, the plugin glide64 is great in terms of graphics quality, the only that can run conker's bad fur day without graphical errors. However, it is extremely slow and is unplayable. It would be nice if you can improve the speed of this plugin

[littleguy]

Great suggestions, I forgot about those two.  As long as we can get the screenshot itself, making a gui for it would be straightforward I think.  I know the core has the screenshot capabilities built-in but they might be stubbed out for the Android edition.  Will have to double check that.

Regarding in-game changing of settings, the one caveat is that most of the core settings are read just once at startup; the core API doesn't allow changing them on the fly AFAIK.  Certainly it would not be possible to change plugins on the fly, since that requires a full restart of the engine.  With a fair bit of work we could probably meddle with the settings through the JNI, but that would involve a fair bit of customization of the core source and could lead to instabilities if we don't know exactly what we're doing (I don't).  That said, nearly all the input configuration is done outside the core, so the following could be tuned on the fly
  - Touchscreen enable/disable, layout, button size, style, etc.
  - Xperia Play touchpad enable/disable, layout
  - Input (button) map
  - Multi-player map
  - Some video options:
     - Screen orientation, position, rendered resolution, scaling (need to use the new resize API in core v2.0)
     - Action bar opacity
     - Display framerate
     - Flicker reduction profile
     - Frameskip settings
  - Some options currently in the Advanced menu
     - Accessibility
     - Enable crash reporting (I think)

[gdark100]

I did a little demonstration of a menu style that I think would be cool. Is not very good, is just to give an idea.

The games with screenshots could continue playing when touched, and games without screenshots has not been opened yet. It would be interesting to put a button next to the name to start the game from the beginning, instead of continuing.

[karl_87]

Ok, here is my first attempt at a UI mockup.  Keep in mind that I am no artist, and that this is a really rough representation just to get the conversation going (there are already some things I dislike about this after looking at it rather than just imagining it my head):



Basically the idea here is that in the current UI, the games are in effect a child of the settings.  Instead the focus should change to where the settings are a child of the games.  This would function basically like the gallery, where you start out at your list of games, with categories like "Resume Playing" shown here.  There would be an option to search your device for games (folder navigation would go away completely).  Bringing an item to focus would give you options to play/ resume or settings.  Settings would default to whatever is "auto" for that particular game, and would remember the user's preferences (and an option to return to defaults).  All settings would be dependent on the selected game.

Anyway, it is still a rough idea, but should give you the idea of where my imagination was going.

THIS LOOKS AWESOME! Exactly what we ned for the ouya version! It's all about the games, and settings come after, this way settings per game would work fantastic.

[Mikhail]

Include Reverse AA filtering at 2x and 4x

http://kdepepo.wordpress.com/2012/08/15/reverse-antialiasing-for-image-scaling/
http://board.byuu.org/viewtopic.php?f=10&t=3211