Brainstorming Version 3.0

[littleguy]

@Mikhail - Cool find.  Are you suggesting we use this for smoothing in-game text, or for something in the front-end?

[Mikhail]

Actually scrap that notion i've ran some textures through ImageResizer
http://code.google.com/p/2dimagefilter/ and XBR 2x still looks the best to me.

Maybe Reverse AA was wrongly added to ImageRisizer because it looks the same as nearest neighbour 

PPSSPP currently uses XBRZ
http://www.vogons.org/viewtopic.php?p=287296
http://blog.metaclassofnil.com/?p=306

[littleguy]

Neat stuff.  So, how/where do you propose we use this?
 1. on the fly enhancement of stock textures
 2. offline enhancement of stock textures, loaded as custom textures at runtime
 3. on the fly enhancement of the final rendered image

I'm guessing you didn't mean option 2, since people already do that outside of mupen and hi-res texture packs already exist.  For options 1 and 3, sounds like this would require some shader programming inside the video plugin, which I'd consider an enhancement that could be done anytime (don't have to wait for version 3).  Not many devs here have the skillset for that however.

Might be worth starting a discussion with the upstream devs, since this would be useful across all platforms, not just android:
https://groups.google.com/forum/#!forum/mupen64plus

[RogerSmith]

Regarding eye candy, has anyone ever used the SuperGNES emulator? It has probably one of the best interfaces I've seen. I have some screenshots of mine. I really like how you can download covers of your games, and you can see screenshots of your save state. It all just looks really clean.

Spoiler: show

Spoiler: show

Spoiler: show

Spoiler: show

Spoiler: show

Spoiler: show

[littleguy]

Yep SuperGNES is a really good interface, and is partly what inspired this thread.  I was imagining something pretty much the same.  One thing I'm shooting for is a unified UI that works well with and without touchscreens.  I.e. the OUYA/GameStick/MOJO/etc. users can use their gamepads very easily.  I can't remember if superGNES on the OUYA is any different than on a phone/tablet.  Also there are little details like the rounded corners and background screen that seem a little amateurish to me... don't feel like they fit the Android theme very well.

Does SuperGNES remember per-ROM user settings?  Or are they global settings only?

[RogerSmith]

Does SuperGNES remember per-ROM user settings?  Or are they global settings only?

Global settings, though you can make multiple profiles with different settings.

[GenesisFlux]

One thing you might want to keep in mind is that some people really enjoy not having octagonal movement because it allows 360 sticks to move in smaller intervals of directions than just 8. While it might be more like the original, some would call it a limitation. Ocarina of Time allows for more directions of input than 8 and it allows movement in precise games like Super Mario 64 to be an easier task.

Also the bridge in Kokiri Forest doesn't need to be tip-toed on with octagonal movement turned off.

[Paul]

@GenesisFlux, have you actually compared with the setting enabled vs disabled?  In my experience the difference is subtle at best (certainly no limitation in vector direction, only in magnitude).  The only time a difference is really noticable to me is when over-saturation has a negative effect on games that were not designed to process it (such as being easier to spin out of control in Mario Kart).

WRT SuperGNES, I would prefer not to blatantly copy (take some good ideas, but design something original). The concept of settings being a child of the games should be the starting point, and make a UI that enforces the concept.  I'll try and put together a working branch this weekend, with some of the main components, like searching for ROMs and the game panel layout.

[littleguy]

@GenesisFlux - I think you may be misunderstanding what octagonal constraints does (all the more reason to exclude it as a setting).  You can still move the stick in any direction 0-360 degrees, not just 0,45,90,135,etc.  The octagon constraint simply limits the magnitude at the very extremes.  It's like putting an octagonal fence inside a circle with a radius of 100%. When you push the stick, say at 20 degrees from up, the magnitude is limited to something like 97%.  Like the original controller.  Like Paul said, some games are strangely sensitive to the strength at the limits, and this just fixes that.  There's really no reason it shouldn't always be enabled.

[littleguy]

I don't want to blatantly copy SuperGNES either, I just imagine version 3 will end up looking very similar in the end.  Games front and center, savestates easy to see/navigate, settings menu wider and shallower than it currently is.  I'm getting tired of typing out Settings->Input->Controller->(menu)->Controller diagnostics LOL   Plus the deep menus are clearly hiding a lot of important stuff from new users.

I haven't played with SuperGNES much but I'm thinking that a tabbed interface would kind of suck with a controller.  A lot of up/down presses on the d-pad.  Anyhow, I have some other ideas I was hoping to mock up in the next few days.  Look forward to seeing your ideas and comparing notes. 

[gazdaman]

Is it possible for you guys to release the $1 contribution builds in advance of the free builds on google Play? (Say a 3 month lead)
I think this would encourage more people to show their support.
It looks like around 1 in every 100 users supports the app which I think is ridiculous.
If people can afford a device to run this on they can afford $1 to support all the hard work that has / is being done on it.
Also, the more the development is supported, the better it will become.
Just a suggestion.
I have bought this about 3 times on google play and supported the Ouya build, and i would class my enjoyment to cost ratio for supporting the project as a major bargain.

[arrtoodeetoo]

Will you guys please keep tablet users in mind while reworking the UI? It helps a lot to have the paned menus to keep from having to switch screens so much when jacking around with the settings.

[littleguy]

I'm a tablet user myself, so if anything I have to constantly remind myself of phone and console user needs.

I think by "panes" you are referring to what are called "fragments" in Android developer lingo.  Fragments were introduced in Android 3.0.  Since MupenAE still supports Android 2.2 and up, we'd have to write two separate UIs depending on Android version.  Since this isn't a commercial app, and we don't do this for a living, and a fragment-based UI isn't essential, we decided long ago to keep it simple and only maintain one universal design.  In this vein, something I'd like to accomplish in version 3 is to actually unify the "big-screen" (controller input only) UI with the standard UI, to reduce maintenance.

Regarding the settings screens themselves, Version 3 aims to minimize the amount of "jacking around" necessary, another reason why we'll probably KISS.

[Paul]

In the design I'm working on, the "games gallery" is a list of carousels.  You can scroll left and right on each carousel, and scroll up and down to get to other carousels not visible on the screen.  The carousels themselves are sort of like play-lists, with some built-in lists ("Resume Playing", "All Games", and "Frequently Played" for example), and user-created lists.  The carousel strips design should maximize whatever screen space is available.  So a user plugged in to their wide-screen TV will see more games horizontally per carousel and more carousels vertically on the screen at once, while a user with a tiny screen may only see one game horizontally per carousel and two or three carousels vertically on the screen at once.  Additionally, the design lends itself to support navigation by touch input, arrow input, and mouse input all at the same time (for the latter, I plan to make right and left arrows appear on the sides of the carousel on mouse-over).

As for the settings preferences themselves, I haven't gotten that far into the design yet, but I would definitely like to come up with something that maximizes screen space for that part as well.  Any ideas are welcome.

[littleguy]

Awesome.  I tinkered a bit with a simple gridview, but the carousel idea sounds much cooler.

I wrapped the ROM header stuff into Java classes.  Makes the meta-info easy to work with, the ROM only needs to be read once, and the JNI dependency is eliminated since the file can just be read in Java.  Should make it easier to populate the views in the carousel.

I thought we could just have an OptionsMenu in the gallery activity to keep it tucked out of the way.  I've been tinkering with restructuring the settings menu.  My hope is to have a single preferences.xml defining the structure, then hiding various elements depending on whether we're in global vs. rom vs. in-game settings.  For example, hide the Graphics (video-plugin-related) stuff in the global settings.  Only allow those to be changed per game.

Still thinking about an elegant way to merge multiple preference files and still use the vanilla PreferenceActivity stuff.

Also have some thoughts on revamping the multi-player configuration so it's more intuitive and easy to use without a touchpad.  Probably implement that as a separate activity.

https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2013-07-29-11-01-13.png
https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2013-07-29-11-01-29.png
https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2013-07-29-11-01-38.png
https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2013-07-29-11-02-05.png
https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2013-07-29-11-02-16.png