PaulsCode Forum

Mupen64Plus AE => General Discussion => Topic started by: littleguy on July 15, 2013, 09:38:42 AM

Title: Brainstorming Version 3.0
Post by: littleguy on July 15, 2013, 09:38:42 AM
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?

 
Title: Re: Brainstorming Version 3.0
Post by: Paul on July 15, 2013, 03:49:23 PM
- 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  ;D

- 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.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 15, 2013, 04:29:04 PM
- 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.
Title: Re: Brainstorming Version 3.0
Post by: Paul on July 15, 2013, 05:06:27 PM
     - 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)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 15, 2013, 06:16:58 PM
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.
Title: Re: Brainstorming Version 3.0
Post by: Paul on July 16, 2013, 02:41:05 PM
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):

(http://www.paulscode.com/source/Mupen64Plus-AE/misc/mockup_ui.png)

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.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 16, 2013, 03:20:54 PM
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).
Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 16, 2013, 03:25:58 PM
Ok, now I'm itching to start implementing some concepts  ;D  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...
Title: Re: Brainstorming Version 3.0
Post by: Paul on July 16, 2013, 04:15:16 PM
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).
Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 17, 2013, 03:06:00 PM
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
Title: Re: Brainstorming Version 3.0
Post by: gdark100 on July 20, 2013, 07:29:17 PM
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 ;)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 20, 2013, 07:47:30 PM
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)
Title: Re: Brainstorming Version 3.0
Post by: gdark100 on July 21, 2013, 11:25:40 AM
(http://img163.imageshack.us/img163/1082/dh5f.png)
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.
Title: Re: Brainstorming Version 3.0
Post by: karl_87 on July 22, 2013, 05:46:45 AM
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):

(http://www.paulscode.com/source/Mupen64Plus-AE/misc/mockup_ui.png)

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.
Title: Re: Brainstorming Version 3.0
Post by: Mikhail on July 25, 2013, 03:54:09 AM
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

Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 25, 2013, 06:39:24 AM
@Mikhail - Cool find.  Are you suggesting we use this for smoothing in-game text, or for something in the front-end?
Title: Re: Brainstorming Version 3.0
Post by: Mikhail on July 25, 2013, 11:02:51 AM
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
Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 25, 2013, 11:23:05 AM
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

Title: Re: Brainstorming Version 3.0
Post by: RogerSmith on July 25, 2013, 01:56:33 PM
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
(http://img.photobucket.com/albums/v421/Roger_Smith0/Screenshot_2013-07-25-13-46-01_zps378eabe6.png)


Spoiler: show
(http://img.photobucket.com/albums/v421/Roger_Smith0/Screenshot_2013-07-25-13-45-42_zps3e3ec401.png)


Spoiler: show
(http://img.photobucket.com/albums/v421/Roger_Smith0/Screenshot_2013-07-25-13-45-34_zpsc5a70de0.png)


Spoiler: show
(http://img.photobucket.com/albums/v421/Roger_Smith0/Screenshot_2013-07-25-13-45-24_zps8f881e95.png)


Spoiler: show
(http://img.photobucket.com/albums/v421/Roger_Smith0/Screenshot_2013-07-25-13-45-16_zps298df339.png)


Spoiler: show
(http://img.photobucket.com/albums/v421/Roger_Smith0/Screenshot_2013-07-25-13-45-10_zps38bf3179.png)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 25, 2013, 02:23:02 PM
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?
Title: Re: Brainstorming Version 3.0
Post by: RogerSmith on July 25, 2013, 02:29:40 PM
Does SuperGNES remember per-ROM user settings?  Or are they global settings only?

Global settings, though you can make multiple profiles with different settings.
Title: Re: Brainstorming Version 3.0
Post by: GenesisFlux on July 25, 2013, 07:12:51 PM
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.
Title: Re: Brainstorming Version 3.0
Post by: Paul on July 25, 2013, 07:38:26 PM
@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.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 25, 2013, 08:07:37 PM
@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.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 25, 2013, 08:29:44 PM
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 :P  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.  :)
Title: Re: Brainstorming Version 3.0
Post by: gazdaman on July 27, 2013, 07:43:13 PM
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.
Title: Re: Brainstorming Version 3.0
Post by: arrtoodeetoo on July 29, 2013, 08:19:34 AM
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.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 29, 2013, 08:34:07 AM
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.
Title: Re: Brainstorming Version 3.0
Post by: Paul on July 29, 2013, 09:54:10 AM
(http://www.paulscode.com/source/Mupen64Plus-AE/misc/mockup_ui.png)

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.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 29, 2013, 10:18:29 AM
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

Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 29, 2013, 09:24:33 PM
@Paul - To download cover art, we'll need the ROM's "good name" in the Java code.  Which requires computing the MD5 checksum and looking it up in mupen64plus.ini.  We could write another JNI function that calls some functions in the core...

...but out of curiosity I tried doing it entirely on the Java side.  Turned out to be really easy with the ConfigFile class and the Apache commons-codec library.  The catch is that it adds a 258KB jar file to the APK.  Still, the ease of maintenance and the decoupling from the core might be worth it.  Thoughts?

Either way, it works well at least in the short term for prototyping.  I'm attaching the source in case you want to use it.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 29, 2013, 11:46:29 PM
Been working on the auto-cover-download machinery.  Having the "goodname" of the rom helps, but isn't a surefire way to construct the correct weblink.  So far I've only tried downloading the cover art from here (http://daedalusx64.svn.sourceforge.net/viewvc/daedalusx64/data/Resources/Preview/), and the filenames don't always match up easily to the goodnames.

This is just a debugging screen, but you can see right now I'm missing most of the cover art.  The text below each cover is [goodname][crc][md5] in case you're wondering.
(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2013-07-30-00-38-24.png)
Title: Re: Brainstorming Version 3.0
Post by: gdark100 on July 30, 2013, 04:02:34 PM
littleguy - this site has a LOT of hires box images, for most n64 titles. Unfortunately, the names are abbreviated.  :-\
http://64dd.net/modules/games/index.php?system=n64&type=released&show=alphabet&value=0-9&sort=title&order=asc
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on July 30, 2013, 07:39:11 PM
the problem is, it appears most of these sites have the images and such, but no publicly accessible database like there is for wii and gamecube games.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 30, 2013, 07:52:03 PM
@Paul - What do you think about just copying the cover files off the Daedalus repo (http://daedalusx64.svn.sourceforge.net/viewvc/daedalusx64/data/Resources/Preview/) and putting them somewhere we control.  Easiest might be just a folder in the git repo, files could then be downloaded via github http website.  Or put them on paulscode.com.  One benefit, besides being in control of the files, is that we could rename some of them so that they match the goodname.  One less hassle to deal with.
Title: Re: Brainstorming Version 3.0
Post by: Paul on July 31, 2013, 08:07:00 AM
Good idea.  I'll set up a repo for the images under paulscode.com.  Of course if Nintendo or other company takes issue, they may need to be taken down (storage of cover art is definitely a legal grey area)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on July 31, 2013, 08:37:12 AM
Alright then.  I'll probably rename a bunch of them so that it's easy to convert from the GoodName in mupen64plus.ini to the weblink.  Maybe I should do that first, then post them somewhere for you to grab.

I noticed wikipedia has cover art and it says it abides by "fair use".  Not sure that applies in our case but FWIW...
http://en.wikipedia.org/wiki/File:Super_Mario_64_box_cover.jpg
Title: Re: Brainstorming Version 3.0
Post by: littleguy on August 02, 2013, 09:53:44 AM
Paul - I may be able to sink some more time into this over the weekend.  But if you want me to slow down or focus on something in particular, let me know.  I don't want to dictate the design just because I happen to be the one with some time right now.  (I'm guessing you're on vacation or really busy this past week.)
Title: Re: Brainstorming Version 3.0
Post by: Paul on August 02, 2013, 10:05:27 AM
No worries, you can work on whatever you like.  We are back from vacation, but trying to meet an impossible deadline for work, so spending pretty much every waking hour on that.  On the flip side I'm learning some very useful new skills (I'm not sure if you are familiar with Symfony2, but it is a pretty awesome architecture - I highly recommend taking a look at it if you are into web development).  The tools suite I am developing has integrated components for web, Android, and iOS.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on August 02, 2013, 02:49:09 PM
Interesting.  Coincidentally I just got assigned a web-development project at work, not something I or my company does much of.  Will have to take a look at that in detail.  Thanks for the pointer.
Title: Re: Brainstorming Version 3.0
Post by: RogerSmith on August 05, 2013, 03:44:40 PM
Been working on the auto-cover-download machinery.  Having the "goodname" of the rom helps, but isn't a surefire way to construct the correct weblink.  So far I've only tried downloading the cover art from here (http://daedalusx64.svn.sourceforge.net/viewvc/daedalusx64/data/Resources/Preview/), and the filenames don't always match up easily to the goodnames.

This is just a debugging screen, but you can see right now I'm missing most of the cover art.  The text below each cover is [goodname][crc][md5] in case you're wondering.
(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2013-07-30-00-38-24.png)

Looks good littleguy.
Title: Re: Brainstorming Version 3.0
Post by: karl_87 on August 08, 2013, 05:48:02 AM
I've just had a great idea, once version 3 is futher in development, would it be possible to have all the settings per game stored in a text file. This way we can work out the settings for all the games on an ouya for example, and then share the text file with others to create a full master file! Once this has happened, the next step would be to load the master file by default (or even ask the user) if an ouya is detected on first run for example. This would obviously work for other devices but think ouya is a great starting point.

Hope I made sense, what do you guys think?
Title: Re: Brainstorming Version 3.0
Post by: Mikhail on August 09, 2013, 10:33:38 AM
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

I'd go for option 3. using XBR2 noblend.

As for options 1 & 2 not too sure about a texture filter as everything seems to blur pixels so 3d models always look muddy, NearestNeighbour and ReverseAA work best at retaining the likeness as if it was drawn at a higher resolution, tbh i'd rather just use hi-textures instead you can't add detail that was never their in the first place by upscaling so there's no overall benefit .


Also how about about a

option 4: Increasing the internal resolution to it's max then downscaling the final rendered image to your desired resolution, it should theoretically retain the most detail.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on August 09, 2013, 11:29:18 AM
Thanks for all the feedback, guys.

Just an update - I had planned to work on the user interface over the past weekend, but soon realized that the current activity mechanics/lifecycle should probably be cleaned up a bit first.  Gilles noticed some more GL context creation issues, and an increasing number of users are experiencing strange audio latency.  The hard-exit hack (ASDP bugfix) is also long overdue for removal.  These issues might be resolved by updating to the latest revision of SDL2, so I'm tackling that first.  Once the lifecycle/launch mechanics are resolidified, I'll then get back to wiring up the new front-end and updating the user preferences structures.  Don't want the tail (UI) to wag the dog (activity launch mechanics).

I agree, having the game-specific overrides in text files on the sdcard would permit a lot of flexibility.  Besides allowing experts to revise and share configs for games, it would also allow basic users to update the recommended settings between published releases.  For example, we could add these config files to the github repository, and users could have a button to refresh the config recommendations whenever they like.  Clicking the button would just download the text files to a location on their sdcard.  So, at the end of the day, there may be a "refresh" menu in the main gallery screen, with three items underneath it:
 - Refresh game list (searches sdcard for rom files)
 - Refresh recommended config settings (downloads config files from github http server)
 - Refresh cover art (downloads images from some http server)

I can just imagine the average user who opens a github issue to say <obscure game xxx> is buggy; we update the config file on github and tell them to refresh their recommended settings.  Case closed ;)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on August 09, 2013, 11:35:39 AM
3. on the fly enhancement of the final rendered image

I'd go for option 3. using XBR2 noblend.
...
Also how about about
option 4: Increasing the internal resolution to it's max then downscaling the final rendered image to your desired resolution, it should theoretically retain the most detail.

All interesting discussion, though I'm not the person with the skills to implement it.  As for option 4, if I understand you correctly, this is already implemented for the most part.  The current video settings allow you to specify the "rendered resolution" (internal resolution?) independent of the device's actual hardware resolution.  It would be trivial to add higher resolutions to the current list.  However, I don't think that this would make much difference regarding low-res textures; they'd still be muddy.  Maybe a little less pixellated, but still muddy.
Title: Re: Brainstorming Version 3.0
Post by: Paul on September 24, 2013, 09:20:01 PM
I mentioned this briefly in chat, and on the OpenPandora boards.  For some time, I've been wanting to restructure the folders to better match Richard's project.  The 3.0 update might be a good time to take a serious look at this.

I did a little thinking, and I believe the basic structure would look like this:

The root folder will contain folders for all the core modules, using the same names as upstream.  (Recommend removing rsp-hle-nosound.. Does this opimization really have a noticeable speed difference?)
mupen64plus-audio-sdl/
mupen64plus-core/
mupen64plus-input-sdl/
mupen64plus-rsp-hle/
mupen64plus-ui-console/

-- EDIT -- (and of course the video plugins)

Each of those will have in them:
projects/android/
This folder will contain an Android project to allow building the native .so plug-in stand-alone if desired

In addition to the core folders, the root folder will contain:
mupen64plus-ae/
This folder will contain the "master" android project.  Jni folder will have sub-folders for Xperia Play and ae-bridge, as well as a single Android.mk file that builds all the core modules (will use relative paths when referencing the source files: ../mupen64plus-core/core/src, etc).  Anyone who wanted to build a smaller APK without a particular plugin (or to add their own custom plugin) could just edit the relevant block in this Android.mk file.  This folder will also contain all the java, resources, etc for building the app.

This structure would work well for command-line compiling via ndk-build followed by ant.  However, I will need to play around with Eclipse to figure out how to set up an Eclipse project for this.  Obviously having the Eclipse project reside in the "master" android project folder would mean the native C/C++ files would be outside of the project, which would not be ideal.  Would be better if the Eclipse project could be set up from the root folder.  Alternately, could use separate individual Eclipse projects for the "master" android project and each plug-in ("master" project would build everything, and other projects would build the plug-ins individually).
Title: Re: Brainstorming Version 3.0
Post by: littleguy on September 24, 2013, 09:41:47 PM
(Recommend removing rsp-hle-nosound.. Does this opimization really have a noticeable speed difference?)

I agree, let's remove it.

This folder will contain the "master" android project.  Jni folder will have sub-folders for Xperia Play and ae-bridge, as well as a single Android.mk file that builds all the core modules (will use relative paths when referencing the source files: ../mupen64plus-core/core/src, etc).  Anyone who wanted to build a smaller APK without a particular plugin (or to add their own custom plugin) could just edit the relevant block in this Android.mk file.  This folder will also contain all the java, resources, etc for building the app.

Sounds good to me.  One thing though, we don't need mupen64plus-input-sdl.   I'm guessing we put SDL2, gles2glide64, gles2n64, png, and libsamplerate outside of mupen64plus-ae as well?  I'd say keep input-android in mupen64plus-ae for the time being since it's not upstream and is still very specific to android.

Obviously having the Eclipse project reside in the "master" android project folder would mean the native C/C++ files would be outside of the project, which would not be ideal.

I like the folder organization you laid out, and agree that it would be much tidier to keep android stuff isolated in mupen64plus-ae.  My guess is that the project would build just fine from eclipse, but you wouldn't be able to browse into the native stuff easily in the IDE.  Will have to think about that one a bit...
Title: Re: Brainstorming Version 3.0
Post by: Paul on September 24, 2013, 09:58:14 PM
Sounds good to me.  One thing though, we don't need mupen64plus-input-sdl.
It will be used by the Open Pandora port, so will need to keep it for that (no Android project for this one).  input-android would make sense to keep under the mupen64plus-ae/jni folder, since it is Android-specific.

I'm guessing we put SDL2, gles2glide64, gles2n64, png, and libsamplerate outside of mupen64plus-ae as well?
Yes, forgot to bring up the other libraries besides the core ones, but yes they would also go into the root folder.  Should be named to match the corresponding upstream project (glide64mk2, for example), to promote synchronization.

My guess is that the project would build just fine from eclipse, but you wouldn't be able to browse into the native stuff easily in the IDE.  Will have to think about that one a bit...
If all else fails, it might not be too big of a deal to just allow creating separate Eclipse projects for each module that is outside of the main Android project.  Wouldn't need to create an Eclipse project for every module, just the ones being edited.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on September 24, 2013, 10:11:01 PM
Oh right, openpandora.

Yes, if the goal is upstream sync, then it may be just as well if the external libs aren't visible in the eclipse project.  We should be treating them as black boxes ideally.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on September 25, 2013, 08:14:20 AM
One other thing, before we move/rename the libraries, we should let Sven know.  I'm not entirely sure the process he goes through to merge the upstream back into master.

Just did a quick test, moved the upstream libs outside the ae project.  From eclipse it compiles from just fine but I can't link yet.  Probably not too hard to track down.  Here's the makefile I used:

Code: [Select]
JNI_LOCAL_PATH := $(call my-dir)
NATIVE_ROOT_PATH := $(JNI_LOCAL_PATH)/../..

AE_BRIDGE_INCLUDES := $(JNI_LOCAL_PATH)/ae-bridge/
M64P_API_INCLUDES := $(NATIVE_ROOT_PATH)/mupen64plus-core/src/api/
SDL_INCLUDES := $(NATIVE_ROOT_PATH)/SDL2/include/
PNG_INCLUDES := $(NATIVE_ROOT_PATH)/png/include/
SAMPLERATE_INCLUDES := $(NATIVE_ROOT_PATH)/libsamplerate/

COMMON_CFLAGS :=                    \
    -O3                             \
    -ffast-math                     \
    -fno-strict-aliasing            \
    -fomit-frame-pointer            \
    -frename-registers              \
    -fsingle-precision-constant     \
    -fvisibility=hidden             \

COMMON_CPPFLAGS :=                  \
    -fvisibility-inlines-hidden     \

include $(call all-subdir-makefiles)
include $(wildcard $(NATIVE_ROOT_PATH)/*/projects/android/Android.mk)

Title: Re: Brainstorming Version 3.0
Post by: littleguy on September 25, 2013, 09:05:56 AM
On a different note, it might be a good idea to consider using a new package name for version 3.  There are some obvious drawbacks, but the most important benefit would be the use of the sharedUserId attribute in the manifest:
http://developer.android.com/guide/topics/manifest/manifest-element.html#uid

The sharedUserId would make it much easier to create multiple apps on the store that interact with each other.  I.e. we could more easily produce add-on apps for debugging/expert settings/data migration, etc.  I think it would also allow us to package native libs as separate "apps", e.g. if we wanted to distribute experimental video plugins but not have them installed by default.  We wouldn't have to publish every add-on on the google play either, so if it were a really niche add-on (e.g. very specific debugging tools) we could just make them available on the forum only and point specific users to them.

The thing about using sharedUserId is that you can't suddenly apply it to a package that's already been published (users will get upgrade errors).  So you have to make the decision up front.  See here for more: http://java-hamster.blogspot.com/2010/05/androids-shareduserid.html

Some other benefits of a new package name is that it would allow users to keep v2 and v3 installed on the same device.  We could make a third app that safely migrates the datafiles from v2 to v3.  So upgrade wouldn't be an all-or-nothing event.  I was thinking we could borrow FilePwn's implementation for a near bullet-proof file migration app.  (OUYA developer logs show zero crashes after the fourth release (Aug 20), with an install base of 20k users.)  For now, I'd prefer that source to be closed (I might put it up on google play someday), which would be a good reason to make the migration a separate app.

Of course the problems with changing the package name are:
 - Users need to be aware of the new package.  This could probably be addressed by adding a check in v2 to see if v3 is installed, and if not pop up a message.
 - We start over with google play statistics.  This might not be entirely bad.  If we have good conversion from v2 to v3, we'll hopefully have our high install count back soon.  And if we do a good job with version 3, it may be a good thing to shed all the old obsolete 1-star ratings from v2.

Finally, if we change the package name, I'd suggest com.paulscode.mupen64plus (or org or net or whatever) just to keep with the recommended naming conventions.  We could even consider just calling the app Mupen64Plus-Android.

Anyhow, just wanted to throw those out there.  I'm sure there some other drawbacks I hadn't thought of, so all discussion welcome.

Title: Re: Brainstorming Version 3.0
Post by: Paul on September 25, 2013, 10:05:09 AM
A couple other big drawbacks that I can think of are:

1) Folks who donated would have to donate again, or be stuck with the free version for 3.0 (not that they are any different).  This could be misconstrued as a money-grab by some users who have already donated.

2) A new user who is looking for a N64 emulator would suddenly be met with 3 or 4 instances of Mupen64Plus AE published on Google Play, which could be confusing.  A lot of folks already have trouble wrapping their head around the paid version being no different than the free version.

3) In the case of another bogus DMCA take-down, the number of flagged apps would be greater, which would increase the likelyhood of a subsequent ban of my developer account.


Perhaps a better solution would be to keep the same package name, and just warn people in the previous version before the change that they are going to experience an upgrade error and will need to uninstall the app and reinstall it.  We can even make it nag them every time they launch the app, rather than just once (so there is no chance of them missing it).  Release it a couple weeks at least before the change, so that majority of users have updated and received the nag dialog.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on September 25, 2013, 10:06:28 AM
Good points...
Title: Re: Brainstorming Version 3.0
Post by: littleguy on September 25, 2013, 10:13:20 AM
I am still concerned about the data upgrade and all-or-nothing-ness of an in-place upgrade.  Keeping two separate apps would vastly simplify the transition.

For 2) maybe you just rename the v2's "Mupen64Plus AE (obsolete)" and change the icon?

But 1) and 3) are definitely serious...
Title: Re: Brainstorming Version 3.0
Post by: littleguy on September 25, 2013, 10:21:30 AM
For 1) here's an alternative, but it requires a fair bit of work.  Move donations for v3 to an in-app payment, rather than a separate app.  Also helps with 2).  Then when v2-donate users install v3, we do some sort of account check and apply the donation entitlement to their v3 app.  As if they already donated in-app.

For 3).... don't know.  I wish google was more opaque on this stuff.  I wonder if you can give any sort of warning notice to google to pre-empt false dmca takedowns?  Has the previous dmca takedown been wiped off your "permanent record"?  I.e. it sounds like you are concerned with an accumulation of bad marks against your account.
Title: Re: Brainstorming Version 3.0
Post by: Paul on September 25, 2013, 10:33:58 AM
Going back to the folder restructure topic for a second, one drawback I thought of is that moving files around will cause them to lose history.  Might talk with Sven to see how he was able to bring in the upstream history into our repository (like some way of merging the file from the old location into the new location)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on September 25, 2013, 10:36:08 AM
Agreed, that's what I was attempting to say a few posts back.  Need to get in touch with Sven...
Title: Re: Brainstorming Version 3.0
Post by: littleguy on November 20, 2013, 03:51:04 PM
Ok, the rails are finally greased for me to start working on this.  Whew.  I'll start laying stuff out on some concept branches over the next few weeks.

Regarding restructuring the folders, I'll do a proof-of-concept to make sure all the build stuff works correctly and put that on a little branch of its own.  I recommend we continue to keep a copy of each plugin/library in our own single github repo.  Makes it much easier to go back in time to fix regressions.  If I get it working properly, I'll put it on ice and we can do the restructuring at the very end just before we release 3.0.
Title: Re: Brainstorming Version 3.0
Post by: Paul on November 20, 2013, 05:54:19 PM
Excellent.  That sounds like a good plan.  I may be switching gears for the next couple weeks to work on the SoundSystem library.  There are a few long-standing bugs I need to address, and I want to add a software mixer to LibraryJavaSound plugin.  I'm also going to finish the Android port with an SLES plugin, which will hopefully get me more comfortable with SLES and apply the lessons learned to the new audio plugin for Mupen64Plus AE.  I definitely want that to make it into 3.0.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on November 20, 2013, 06:50:39 PM
SLES probably holds the key to removing latency.  RetroArch has no noticeable latency in their mupen branch, and it looks like they're using a SLES plugin on Android.  So there's an existence proof.  I'm still not entirely confident that the Android portion of SDL2 is up to snuff.  Entirely possible it's just a bug in their glue code.  Might be possible to temporarily swap out the Android for the Linux audio driver in SDL...  I may try that tonight, see if there's a quick fix.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on November 21, 2013, 02:42:31 PM
I tested alternative audio drivers in SDL2.  Other than the 'disk' driver (which just dumps sound to disk), none of the others were buildable out of the box.  Missing headers in every case.  For future reference, the way to swap out drivers is to make the following substitutions

SDL2/include/SDL_config_android.h:
Code: [Select]
// #define SDL_AUDIO_DRIVER_ANDROID    1
#define SDL_AUDIO_DRIVER_FOO    1
where the list of drivers can be found in SDL2/include/SDL_config.h.in

SDL2/Android.mk
Code: [Select]
// $(wildcard $(LOCAL_PATH)/src/audio/android/*.c) \
$(wildcard $(LOCAL_PATH)/src/audio/foo/*.c) \

What it made me realize however is that there are two paths to implementing SLES.
 - Implement an alternative Mupen plugin, as you've described
 - Implement an alternative SDL2 audio driver, and continue using mupen64plus-audio-sdl
In case you hadn't already thought of this...
Title: Re: Brainstorming Version 3.0
Post by: littleguy on November 21, 2013, 07:41:50 PM
There are some things that don't necessarily need to wait for Version 3 and would be easy enough to implement in the next week for the 2.5 release.  Just wanted to get a yay or nay before I go ahead with the following:


I understand that audio and perhaps input might be useful to disable, but it seems more intuitive just to ise a checkbox to disable those.

If you're ok with that, I would probably then restructure the main settings menu a bit for version 2.5.  Remove the Audio and Plugins settings.  Move video plugins to the Video section, move R4300 to the Advanced menu, move Audio checkbox to advanced menu.  With the extra real estate it might even be nice to split the display stuff (e.g. resolution, orientation, etc. into a separate menu, sibling with video and input.  Maybe call it Display.

What do you think?
Title: Re: Brainstorming Version 3.0
Post by: Paul on November 22, 2013, 06:01:22 AM
Sound like good ideas to me :)
Title: Re: Brainstorming Version 3.0
Post by: Paul on November 30, 2013, 08:55:57 AM
With 2.5.0 almost ready, I thought it would be a good time to start talking about what direction we want to be heading for version 3, and break down some of the important components that need to be written and can be tackled separately.  Here is a rough outline to get the conversation started:

1) Boxart loading system (Littleguy started this one)
 - I want to host the image files myself, so we have control over their naming convention.
 - We should also lock down what the naming convention should be.  Easiest might be by CRC, but we might want to look at using the header name or good name to make it easier for users to compile their own boxart themes or fill in missing games.
 - An option to enter a custom URL to boxart should be part of this feature.

2) Carousel UI (I'm starting this)
- Panel size and carousel count needs to adapt to the screen dimensions.  Must handle from tiny screens all the way up to big-screen TVs, and in any orientation.
- Need to support touchless navigation.
- OUYA-specific touchless navigation button mapping when running on OUYA.
- Intuitive way to bring up the per-game settings menu in the UI.  Was thinking of using a two-step system, where choosing a game goes into a second menu with options to play, change settings, show recommended settings, enable cheats, etc.  Will need to experiment (may require separate solutions for touchscreen and touchless environments).  I'm happy to take suggestions.
- Intuitive way to bring up global app settings (such as crash reporting, change boxart URL, etc) from the main menu/ UI.

3) Per-game preferences
- Maybe use the CRCs in the preference IDs.

4) Screenshots on auto-save
- Determine lowest supported Android version.
- Research support for rooted earlier Android versions.
- Placeholder image to use when screenshots not possible.
- Handle black/ dark screenshots, so they are still visible in the UI (easiest would be to add a frame.. might also research way of programmatically detecting black/ dark screenshots).

5) Touchscreen virtual gamepad editor
- Look at other emulators that have this ability (mimic the best features, improve on any negative aspects).
- Ability to import custom button images.
- System for sharing layouts.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on November 30, 2013, 09:49:10 AM
1) Boxart loading system (Littleguy started this one)
 - I want to host the image files myself, so we have control over their naming convention.
 - We should also lock down what the naming convention should be.  Easiest might be by CRC, but we might want to look at using the header name or good name to make it easier for users to compile their own boxart themes or fill in missing games.
 - An option to enter a custom URL to boxart should be part of this feature.

That's great if you're comfortable hosting the images.  A while back I grabbed the cover art from daedalus and spent some time thinking about the filenames.  I believe I used the "good name" embedded in the rom as the basis, and daedalus generally stuck with that IIRC, but there were some exceptions that I manually tweaked.  I'll have to go back and look at what I did.

One of the first things I should do is push some of my Java-side crc/header utilities up to master so that it's easy to do various manipulations.  Useful for lots of stuff besides cover art.

2) Carousel UI (I'm starting this)
- Panel size and carousel count needs to adapt to the screen dimensions.  Must handle from tiny screens all the way up to big-screen TVs, and in any orientation.
- Need to support touchless navigation.
- OUYA-specific touchless navigation button mapping when running on OUYA.
- Intuitive way to bring up the per-game settings menu in the UI.  Was thinking of using a two-step system, where choosing a game goes into a second menu with options to play, change settings, show recommended settings, enable cheats, etc.  Will need to experiment (may require separate solutions for touchscreen and touchless environments).  I'm happy to take suggestions.
- Intuitive way to bring up global app settings (such as crash reporting, change boxart URL, etc) from the main menu/ UI.

3) Per-game preferences
- Maybe use the CRCs in the preference IDs.

Yes, will require some experimentation.  May be useful to break up the settings according to where/how they are set.  E.g. video settings are only shown per game, where the defaults are different for each game (which we define somehow), and the user overrides video per game.  Hopefully few users actually ever need to override anything.  Video settings saved by appending CRC to the names of Android's built-in persistence files sounds good to me, was thinking the same.

Controller mappings - I mentioned this before, but I think it would best to restructure this a bit.  From a global menu, user defines various profiles.  Then the per-game setting is which profile to use.  But don't show the mapping screen itself from the per-game settings.

Display settings - Probably global settings only for now to keep it simple.  I suppose someone might want to change resolution for particularly heavy games, but I'm concerned that showing the same settings in both places could create confusion about what overrides what.

Crash logging, data paths, diagnostics, navigation mode (if we still need it) make global.  Audio I could go either way (global or game-specific or even both).

Dynarec definitely game-specific, again we always provide sane defaults.

Touchscreen - will need to think more on this.  Was thinking maybe have skins (profiles) that can be defined globally, like the mappings.  Then maybe have three global list preferences.  Select profile for d-pad games; select profile for analog games; select profile for d-pad+analog games.  Then the right "class" of skin can be selected automatically per-game (no more Pokemon d-pad complaints).  Allowing per-game overrides would still be nice though.

4) Screenshots on auto-save
- Determine lowest supported Android version.
- Research support for rooted earlier Android versions.
- Placeholder image to use when screenshots not possible.
- Handle black/ dark screenshots, so they are still visible in the UI (easiest would be to add a frame.. might also research way of programmatically detecting black/ dark screenshots).

Upstream screenshot function is hooked up now (see NativeExports.java) but doesn't seem to work at the moment (just produces black images).  Might not be too hard to get working, and may be easier than dealing with Android APIs.

5) Touchscreen virtual gamepad editor
- Look at other emulators that have this ability (mimic the best features, improve on any negative aspects).
- Ability to import custom button images.
- System for sharing layouts.

Yes.  Lots of ways to go here.  Not sure if we can just adapt the existing stuff or start fresh.  If we start fresh I suppose we could just use Android's built-in button widgets.  If we go that route, for early prototypes we could just recycle the drawable resources used by the input mapping activity.


For now I suppose the first thing I can do is get the coverart stuff back on track.  Pretty low hanging fruit I think since it's mostly done.  Then maybe I'll make a branch to test some of the per-game settings stuff, both the menus and the backing code.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on November 30, 2013, 10:44:45 AM
5) Touchscreen virtual gamepad editor
- Look at other emulators that have this ability (mimic the best features, improve on any negative aspects).
- Ability to import custom button images.
- System for sharing layouts.
I like the ones in MyBoy and DraStic. Maybe look at those as examples.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on November 30, 2013, 10:15:36 PM
Just committed some initial demo stuff for cover art.  Basically the stuff I was working on several months ago, many posts back.  I'll copy the comment I made on github (https://github.com/paulscode/mupen64plus-ae/commit/7695d5eb9299d90152bafd845498ba9d16b31121):

Quote
Here's a crude initial demo of automatic cover art loading. There's a new item in the main menu for v3 concepts. Go to the gallery activity, tap (click) the menu, and tap refresh. It will appear to hang for a very long time (a few seconds per rom), but there's actually a background thread that's scanning for roms and then downloading coverart. Just let it go for a while and when it's done you'll see a gallery with all the detected roms and some cover art. It doesn't cache the files right now, so every time you re-enter this screen you'll have to refresh. It's just a proof of concept for now.

Title: Re: Brainstorming Version 3.0
Post by: xperia64 on November 30, 2013, 11:31:41 PM
I believe this was mentioned before but a cheat code editor is still needed. Maybe I'll look into that eventually.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 01, 2013, 09:10:31 AM
That would be great.  :)
Title: Re: Brainstorming Version 3.0
Post by: Mikhail on December 01, 2013, 11:58:57 AM
DraStic is pretty but there's too much on screen for my liking, it's cluttered and requires scrolling to view other options, I'd prefer a button to jump to the next set of options on a new page.
For the drop down selectable radio options, how about changing them for switchable boxes like this, I forget their name
(http://www.katsbits.com/images/news/wolfenstein/wolfenstein-game-menu-options.jpg)
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on December 01, 2013, 12:12:31 PM
(http://i.imgur.com/LamVH49.png) (http://i.imgur.com/LamVH49.png) (http://i.imgur.com/zv3GWMe.png) (http://i.imgur.com/zv3GWMe.png)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 01, 2013, 12:26:54 PM
For the drop down selectable radio options, how about changing them for switchable boxes like this, I forget their name

Those are nice looking.  Though that would require a lot of extra code since those aren't a native type of widget.  The reason we've been using list preferences is that they are easy to use and just work on all android versions without any effort.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 01, 2013, 12:30:01 PM
I'm doing some major restructuring of the preference menus, separating the global and game-specific settings into separate PreferenceActivities.  Will make it much easier to tie the settings screens into the front-screen carousel or wherever we deem appropriate.  I should have something to show soon, depending on how much Christmas decorating I get dragged into  :P
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on December 01, 2013, 06:38:24 PM
(http://i.imgur.com/ztNGTVO.png) (http://i.imgur.com/ztNGTVO.png) (http://i.imgur.com/hVDOgZh.png) (http://i.imgur.com/hVDOgZh.png) (http://i.imgur.com/J1ILS0g.png) (http://i.imgur.com/J1ILS0g.png)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 01, 2013, 08:52:35 PM
Cool!  I know nothing about cheats but the interface looks nice :)

Not sure where you're saving the user's custom stuff, but be careful not to save it to <sdcard>/Android/data/paulscode..../ because that stuff gets overwritten sometimes after an update.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on December 01, 2013, 09:25:31 PM
Currently it doesn't write anything yet. Have to deal with the headache of parsing both mupen64plus.cut and mupencheat.txt first. I'll probably copy both those files to the same folder as the saves and write to the copies.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 01, 2013, 10:19:51 PM
Just implemented per-rom preferences and pushed to a new branch 'rom-specific-prefs'.  R4300 and video settings are specified per rom, not globally.  We can make other settings game-specific without much effort, just following the framework that's there now.  Should also be very easy to migrate to a different front screen (e.g. carousel) since the preference activities are separated and you just launch them using intents.

https://github.com/paulscode/mupen64plus-ae/commit/82c49fa1d5dd91faefced1043d0f290b10b13c33

Check it out, it's pretty cool.

Still to do, define rom-specific defaults.  I have some ideas for this as well....
Title: Re: Brainstorming Version 3.0
Post by: Paul on December 02, 2013, 07:35:37 AM
Have to deal with the headache of parsing both mupen64plus.cut and mupencheat.txt first.

We need a new support class for reading/ writing specifically the mupencheat.txt syntax (I only used mupoen64plus.cht because it used the standard INI config format).  I'll write this support class today, so you don't have to deal with the headache of handling both files.

Carousel idea is coming along.  I have vertically stacked, horizontal scrolling panels working.  I still need to get the vertical scrolling to work though (not sure if Android widgets are suitable for the task -- might take some lower-level work.. I'll be tinkering some more this week)
Title: Re: Brainstorming Version 3.0
Post by: Mikhail on December 02, 2013, 10:51:28 AM
genplus-gx has the best emulator ui I've come across.
Title: Re: Brainstorming Version 3.0
Post by: beansta on December 03, 2013, 09:06:20 AM
A lot of great ideas in here. One of the things i was hoping for was 'per rom' settings is being worked on.

Might i suggest something that would benefit pokemon fans more than anything...Transfer Pak emulation?
Title: Re: Brainstorming Version 3.0
Post by: marshall110 on December 03, 2013, 03:01:13 PM
Feature Request, Automatic Saves every x amount of minutes

Hello, Majora's Mask runs great but it does have the occasional freeze and lockup and I am now in the habit of doing a save state every few minutes and if I forget and it crashes, I've forgotten what I did where not to mention it pulls me out of the game mentally to have to manually save.  Anyway to have an auto save state feature for every x amount of minutes?  Dedicate a separate "emergency" save slot just in case you don't want your current slot to be overwritten.  Thank you.
Title: Re: Brainstorming Version 3.0
Post by: baizen on December 04, 2013, 11:54:34 PM
One suggestion which would make testing less tedious would be to somehow change the video plugin while in game. My suggestion would be to have the option in the in-game menu which would allow you to choose the video plugin, and when you choose another one have the emulation automatically restart itself (saving the current game-state and then resuming from it). Not sure about how difficult would it be to implement it, but would make it much easier and faster to compare game performances with different video plugins. I do not feel like it would be a priority, but as stated before, just makes testing a little bit less tedious
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 05, 2013, 07:14:32 AM
Thanks for the ideas everyone.  Except for transfer pak emulation (which has been discussed before) I think those are all pretty doable and it will just come down to how quickly we can get the high-priority stuff done.  The settings system is getting a major overhaul behind the scenes, so it should be much easier to make them accessible in-game.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 06, 2013, 09:56:48 PM
A few screenshots on the separation of global and per-rom settings.  Wherever you see '%1$s', the selected value will be substituted.  Notice the use of the "goodname" in the per-rom menu.  The first screen would eventually be replaced by the carousel screen.  Open to suggestions...

(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2013-12-06-22-47-51.png)  (https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2013-12-06-22-47-31.png)  (https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2013-12-06-22-48-04.png)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 06, 2013, 10:17:18 PM
I might collapse the input stuff into a subscreen on the per-game settings screen.

The idea for the Configuration profile is that the user taps it, a list pops up with one or more possible profiles.  One of the profiles would always be "Custom".  Any other profile would disable or hide the video/r4300 menus to avoid clutter.  The last item in that menu (Reset) actually might not make sense in the per-rom screen.  Have to think about it some more.

For the profiles, I was thinking we'd have one file (e.g. configprofiles.ini) containing a master list of profiles, each profile with video/r4300 settings, a unique key, a brief name, and optionally a description like
 - "Very slow but allows you to get past the XXXX scene in YYYY"
 - "Best for higher-end devices"
 - "Decent compromise if you're getting audio stutter or low frame rates"
 - etc.

Then we have a second file that provides a cross reference between the entries in mupen64plus.ini and configprofiles.ini.  If you're familiar with relational databases, this would be a link table that defines many-to-many mappings.  Each line of the file would just contain a (MD5, ProfileKey) pair.  So, e.g. LoZ OoT and MM could share multiple profiles between them.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on December 06, 2013, 10:22:48 PM
Looks good, only issue I have is using the header name on the main menu. Most of the time it works but sometimes the header names are just weird. Also its not CamelCase :P.  Should the cheat editor be on the play menu still or with this new per game config menu?
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 06, 2013, 10:34:25 PM
Yeah, I'd rather put the "goodname" in the main menu, but as I said, it's a throwaway stand-in at this point.  Also it actually takes a second or three to calculate the md5 to get the goodname, so it slows the menus down a bit.

Maybe the cheats themselves go in a subscreen of the per-game menu to keep things tidy?  Just a thought.

Regarding the cheat editor, that's sort of a muddy area that would be good to discuss.  Currently I can imagine a few "editor" type activities:
 - cheats editor
 - touchscreen (touchpad?) skin/layout editor
 - input profile editor (mostly a tweak of the current InputMapActivity)
 - possibly a config profile editor down the road, to make it easy to import/export new profiles.
These aren't really settings per se, but activities.  Not sure where to fit them.  Probably easier to think about once the carousel screen starts to take shape.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 06, 2013, 10:41:13 PM
Yeah, the header names aren't great.  "CONKER BFD" comes to mind.  The great thing about header names is that they're guaranteed to never change (unlike mupen64plus.ini which is in principle mutable).  I can see that being useful if we define a new naming convention for savegame directory structures.  e.g. all saves for a particular CBFD (U) go into
    <sdcard>/mupen64plus/Saves/CONKER BFD 30C7AC50 7704072D/
where the header name makes it human readable and the header crc differentiates different versions/countries.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 07, 2013, 10:27:00 PM
Activities might make the most sense in the action bar.

(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2013-12-07-23-22-47.png)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 08, 2013, 04:21:27 PM
Just pushed a bunch of stuff.  I didn't push the rom-specific stuff yet, but I did some reorganization of the front screen.  Basically I moved almost all the front menu things up to the action bar.  Should give Paul room to implement the carousel and provides a hook for xperia64 to launch the cheats editor.

(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2013-12-08-17-16-59.png)

(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2013-12-08-17-17-05.png)

(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2013-12-08-17-17-12.png)

Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 10, 2013, 07:34:08 PM
Ok, the front screen is pretty much a blank canvas now.  Go wild with the version 3 front screen.  I recommend starting your own branch from this commit (https://github.com/paulscode/mupen64plus-ae/commit/520e36ba2918d8745e261056f42372baad477552).  I squished all the functionality up into the action bar for now (app is still completely functional).  Probably not the final resting spot for a lot of that... but it gets it out of the way so we can try out the carousel ideas and other stuff.  I added hooks for the cheats editor too.

To see how to add cover art to your widgets, just look at the little example branch I made on github.

(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2013-12-10-20-17-30.png)

I've made more progress on the rom-specific preferences, but haven't pushed it yet.  It will be easier to push if I lay down some more groundwork first.  My next near-term priorities are:

 - Change the way user specifies input map.  User will edit profiles with a separate InputMapActivity, and select a profile in the preference screen.

 - Similarly, bundling of touchscreen configurations into "profiles" that the user will later select in the preference screen.  A profile would consist basically of everything that's on the Touchscreen preference screen now.

 - Hide the digital/analog/both skin selection from the user and make it automatic.
Title: Re: Brainstorming Version 3.0
Post by: Paul on December 11, 2013, 12:28:40 PM
Thanks, littleguy.  You've got a lot done in such a short amount of time!  I'm hoping to have more time this weekend, since I met the most recent big deadline at work.  As that project gets into a more regular maintenance cycle it should be a lot less hectic (assuming I don't get put right onto another big one, HAHA)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 11, 2013, 12:31:01 PM
Yeah, I got a fire lit under me at thanksgiving when I had a lot of free time :)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 14, 2013, 10:40:52 AM
Just another status update.  I've been working on the controller profile stuff and have a basic framework in place that's mostly finished.  The framework is modular, so most of the code can be reused for touchscreen profiles and per-rom profiles.  There is the notion of "built-in" profiles (located in sdcard/Android/data/...) and "custom" profiles (located in sdcard/mupen64plus/Profiles/).  We define the built-in profiles, which are included in the assets.  The built-in profiles are read-only from the app but can be copied and hidden.  Both types of profiles are shown in a single list. User can create, copy, rename, and delete their own custom profiles.  Each profile has a unique name and a comment for display in lists.  Profiles are stored in two ConfigFiles - one for built-ins and one for custom.  Makes it easy to share profiles with users by sending a file or text snippet.  If we want we can always add an import/export facility later to make the process even easier.

(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2013-12-14-11-35-47.png)

Once I get it all ironed out with controller profiles, I'll only need to implement a few subclasses to make it work the same way for touchscreen profiles and rom-specific settings profiles.  Speaking of touchscreen profiles, I also have some more concepts in my head for a touchscreen layout customizer.  Too many ideas... too little time...

Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 15, 2013, 11:02:51 PM
New controller profile system is all implemented.  I'll wait till tomorrow to push it, after I do some more thorough bug testing on all my devices and controllers.

(https://dl.dropboxusercontent.com/u/3899306/Screenshots/IMG_1838.JPG)

Next two items I plan to tackle
 - Touchscreen customization activity and associated profiles
 - Per-rom config profiles
Title: Re: Brainstorming Version 3.0
Post by: Mikhail on December 16, 2013, 01:44:00 AM
Offtopic: What are those onlive controllers like? i've been thinking about getting one they look sleak.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 16, 2013, 06:26:38 AM
The black and orange controllers are actually the Moga Power-series controllers, not onlive.  I haven't had the chance to use them much yet, but my initial impressions are consistent with most of the online reviews I've seen of them.  Well made and the Hero is a big improvement over the original Moga Pocket controller.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 29, 2013, 07:24:54 PM
@Paul - As part of your front-screen implementation, have you yet implemented any searching/caching of rompaths/md5s/coverart?  If not, I may pick that off while I do a few other things.

Also, what were your thoughts about menus and user workflow?  I've had roughly this in my head, but wondered if you had other ideas:
 - Install mupen
 - Launch, assets are extracted at splash
 - User lands in gallery with no games shown
 - User presses button/action menu item to search/refresh rom list
 - Dialog pops up, perhaps prompts for root directory (to reduce search time)
    - Also has two checkboxes: Download cover art, Search zip files
 - User presses ok, app launches async task
    - Recursively searches folders for n64/v64/z64/zip files
    - Unzips zip files to some subdirectory in sdcard/mupen64plus
    - Computes rom's md5 hash to get detailed rom info
    - Downloads cover art to some subdirectory in sdcard/mupen64plus
    - Stores the paths of all found/uncompressed roms, coverart, and md5 in persistent area (e.g. SharedPreferences or ConfigFile)
 - When async task completes, gallery is populated

Then, normal usage
 - User taps a gallery item representing a ROM
 - PlayMenuActivity is launched for the given game

Alternatively, the user taps an item and it just highlights it, then they press other buttons to launch, etc.

The v3 PlayMenuActivity would have a few additional entries, for game-specific config stuff and directly loading savestates.
   
Title: Re: Brainstorming Version 3.0
Post by: Paul on December 29, 2013, 09:01:58 PM
@Paul - As part of your front-screen implementation, have you yet implemented any searching/caching of rompaths/md5s/coverart?  If not, I may pick that off while I do a few other things.

What I am working on now is an LRU cache system that holds on to as many of the most recently used images as it can, and then releases the oldest ones when it loads new ones as the allotted memory runs out.  This is necessary for scenarios where someone has a large game library.  After that, my plan was to hook into a system that auto-downloads missing coverart files.  A placeholder image would be used as the needed files are downloaded on a separate thread.  As each needed file becomes available, the placeholder images are replaced.  This will tie into the system controlling the LRU cache, since both will be dependant on which tiles are visible at a given time (no need to replace an image that isn't visible anymore by the time it finishes downloading, for example).  I'm not sure how this will tie into what you had in mind for caching the images, but if you want to work on that, I'll take a look and adapt it to my code.


- Install mupen
 - Launch, assets are extracted at splash
 - User lands in gallery with no games shown
 - User presses button/action menu item to search/refresh rom list
 - Dialog pops up, perhaps prompts for root directory (to reduce search time)
    - Also has two checkboxes: Download cover art, Search zip files
 - User presses ok, app launches async task
    - Recursively searches folders for n64/v64/z64/zip files
    - Unzips zip files to some subdirectory in sdcard/mupen64plus
    - Computes rom's md5 hash to get detailed rom info
Same thought I had up to this point

    - Downloads cover art to some subdirectory in sdcard/mupen64plus
This step could be skipped to speed up the search/ refresh process.  My thought was that coverart would not be downloaded until it was needed (i.e. when a tile for a particular game came into view for the first time)

    - Stores the paths of all found/uncompressed roms, coverart, and md5 in persistent area (e.g. SharedPreferences or ConfigFile)
I'm not sure about how to handle uncompressing ROMs.  This could take an enormous amount of time if the user has a large library of ZIPs (which anyone who uses an app like GameHunter likely would have).  Maybe we could, during the search, identify the zip files that had ROMs, and then pop up a second dialog upon completion stating something like "X number of zipped ROMs were found.. unzip them now (this will take a long time!)"  Really, though, the user is just going to have to wait for them to unzip-- no way around it.  What do you think?


- When async task completes, gallery is populated
If we did the unzipping after identifying all the zipped ROMs, we could display a progress bar (might help with the impatient users).  Could actually do the same with cover art downloading if we move it until after the initial search.  Or the other way would be to only unzip a ROM when it is actually played for the first time (once unzipped the first time, it would remain unzipped for future plays).

Then, normal usage
 - User taps a gallery item representing a ROM
 - PlayMenuActivity is launched for the given game
If we do this, I think we will want to revisit the Play Menu functionality.  User will first start in the "All Games" section.  Next section over will be the "Recently Played".  Reason I bring this up, is I have had numerous emails from users asking why "Resume" is visible when they haven't ever played a game before, or why they get a warning about loosing progress if they press "Restart" on a game they haven't ever played before.  Maybe an adaptive play menu, that shows "Play" if a game has never been played on the device, and "Restart" "Resume" if it has.

Alternatively, the user taps an item and it just highlights it, then they press other buttons to launch, etc.
This might be worth looking at (especially for touchless navigation).  Would need to work with touchscreen-only too, though.

The v3 PlayMenuActivity would have a few additional entries, for game-specific config stuff and directly loading savestates.
Sounds good.

EDIT: Another thing I thought of is that we will need to handle cases where a user has multiple copies of the same game (for example a zipped file, an .n64, and a .v64, all of the same game/ CRC).  Also, we'd want to exclude the files that the app uncompressed when a search/ refresh cycle is run.  This should also work across multiple instances of the app (user may have more than one build, or a couple clones of Mupen64Plus-ae installed along side it).  Just a couple thoughts I had.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 29, 2013, 09:47:35 PM
Awesome.  It's clear you've thought farther into the nitty-gritty than I have.  I suggest you take the lead with any caching/searching since you've already delved into that.  I had only been thinking about caching in terms of minimizing the need to refresh, but you've already been thinking beyond that, in terms of run-time memory usage and UI responsiveness.  Way ahead of me :)

We can definitely revamp PlayMenuActivity to address the issues you mention (very good points).  But basically sounds like clicking on a grid item will launch another screen with menu items for resuming/restarting/reloading and all the game-specific stuff (config/inputs/cheats).  We're on the same page.

Regarding the concept of tapping a grid item to highlight it.  I prefer the approach in the previous paragraph but thought I'd mention the highlighting approach just to play devil's advocate, in case there were benefits that you could see.

Regarding multiple copies of the same game.  That's a good point, we should probably omit duplicates (roms with identical md5's).
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 29, 2013, 09:54:54 PM
We will probably still want to download coverart to disk, even if not all coverart is resident in RAM at a given time.  In my experience it takes a few seconds to download each image over wi-fi and longer over 3g.
Title: Re: Brainstorming Version 3.0
Post by: gdark100 on December 30, 2013, 06:25:42 AM
Regarding multiple copies of the same game.  That's a good point, we should probably omit duplicates (roms with identical md5's).
It is quite common for a user to download a game, extract the ZIP file and forget to delete it. The best thing to do is to give preference to the extracted files, since they take less time to load.

I think it would be better to extract the game only when the users play it, and delete the extracted file after closing the game. Most users use compressed files to save space.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 30, 2013, 06:37:08 AM
Thanks for the input.  I wonder, do users ever put more than one game into a single zip file?  Also, how common are other compression formats (rar, 7z, tar.gz, etc.)?
Title: Re: Brainstorming Version 3.0
Post by: Paul on December 30, 2013, 06:44:03 AM
I think it would be better to extract the game only when the users play it, and delete the extracted file after closing the game. Most users use compressed files to save space.

I kind of doubt that most users have zipped ROMs for that reason, since the typical size of ROM files for the N64 is insignificant by modern standards (tens of MB).  I think most users only have zipped ROMs because that's how the ROMs were distrubuted (via Game Hunter and the like).  I suppose it we made unzipping happen only at the time of first play, then it wouldn't be too difficult from there to make an optional setting to have the uncompressed file removed after running.  Assuming we decide to go that route.  Another option might be to make the core able to support reading from zip files directly (avoiding the extra initial unzip step -- would still be slower than loading an unzipped ROM though)
Title: Re: Brainstorming Version 3.0
Post by: Paul on December 30, 2013, 06:46:17 AM
Thanks for the input.  I wonder, do users ever put more than one game into a single zip file?  Also, how common are other compression formats (rar, 7z, tar.gz, etc.)?

The 7z format is quite common (also because of ROM download sites).  These archives typically have all versions and regions of a game inside (and are larger than one uncompressed ROM)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 30, 2013, 06:53:44 AM
I suppose it we made unzipping happen only at the time of first play, then it wouldn't be too difficult from there to make an optional setting to have the uncompressed file removed after running.

Good point.  I guess we can just wait and see how the implementation unfolds.  If lazy extraction is used, we can always tack on the option at any time.  If we do eager extraction (e.g. during search phase) then it would be easy to tack on the inverse option later (delete zipfile after extraction).
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 30, 2013, 07:22:30 AM
Back to the PlayMenuActivity, how about this for organization:

 - Play (hidden if autosave exists)
 - Resume (hidden if no autosave)
 - Restart (hidden if no autosave)
 - Load state/slot (hidden if no savestates/slots)
     - (clicking takes you to a subscreen with screenshots for each savestate/slot)
 - Config profile (video/r4300 options)
 - Touchscreen profile (hidden if device has no touchscreen, e.g. ouya)
 - Touchpad profile (hidden if not xperia play)
 - Controller profile (hidden if game is multiplayer)
 - Controller profiles (hidden if game is singleplayer)
       - Multiplayer controller mapping
       - Controller 1 profile
       - Controller 2 profile
       - etc. depending on player count in RomDetail
 - Cheats (hidden if game has no cheats)
       - cheats shown on their own subscreen
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on December 30, 2013, 09:52:06 AM
Instead of hiding cheats if the game has no cheats, maybe make a popup or something that says cheats can be added in the main menu. I could see people running modded games or something and complaining that there are no cheats for the game, better to tell them how to fix that rather than hiding it completely.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 30, 2013, 09:53:03 AM
Good idea.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on December 30, 2013, 10:27:40 AM
Also, I'd recommend not having ultra-low for the audio buffer as default. On my N7, I can't fast forward that quickly plus all audio is slightly too high pitch. Regular-low works fine though.
Title: Re: Brainstorming Version 3.0
Post by: Paul on December 30, 2013, 02:01:28 PM
Not sure where cheats editing will fit in.  Those are going to be per-game, so might want to work cheat editing into the play menu ("main menu" is becoming more of a gallery).

-- I mean a subscreen of the play menu.  Such as press "Cheats", and it has interface or subscreen for adding/ editing/ removing them.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 30, 2013, 02:10:50 PM
Was thinking cheats could have their own subscreen off of PlayMenuActivity, and the editor could be launched from there.

 - Play (hidden if autosave exists)
 - Resume (hidden if no autosave)
 - Restart (hidden if no autosave)
 - Load state/slot (hidden if no savestates/slots)
     - (clicking takes you to a subscreen with screenshots for each savestate/slot)
 - Config profile (video/r4300 options)
 - Touchscreen profile (hidden if device has no touchscreen, e.g. ouya)
 - Touchpad profile (hidden if not xperia play)
 - Controller profile (hidden if game is multiplayer)
 - Controller profiles (hidden if game is singleplayer)
       - Multiplayer controller mapping
       - Controller 1 profile
       - Controller 2 profile
       - etc. depending on player count in RomDetail
 - Cheats
       - Enable cheats (checkbox)
       - Manage cheats (launches cheats editor when clicked)
       - Cheat A
       - Cheat B
       - Cheat C
       - ...
Title: Re: Brainstorming Version 3.0
Post by: Paul on December 30, 2013, 02:14:45 PM
That looks good to me :)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 01, 2014, 01:28:36 AM
Alright, pushed a boatload of updates tonight.  All the menus have been overhauled.  Play menu contains all game-specific settings (including cheats).  I flattened the global settings menu for now so that things are easier to work with as stuff evolves.  Actually once the video/touchscreen stuff goes into profiles, a flat menu for globals may be better anyhow.

I am very close to finishing the emulation profiles stuff.  Probably another day or two.  An "emulation profile" contains dynarec and video plugin settings.  There will be many built-in emulation profiles, and users will be able to add their own (just like the controller profiles system).

Right now the "game-specific" settings are still being stored globally, just to reduce debugging complexity.  It will only take a few lines of code to make the settings persist to a game-specific location once the UI is debugged.

Paul - In terms of interface with GalleryActivity, I will be changing how the selected game is passed to PlayMenuActivity.  Right now the selected ROM is passed via the UserPrefs class, which is now quite awkward.  I'll be changing it soon so that you just pass the path via the intent "extras" bundle, the same way the MD5 is passed.  i.e. the standard Android way of passing data between activities.
Title: Re: Brainstorming Version 3.0
Post by: Paul on January 01, 2014, 08:21:49 AM
Rgr sounds good.  I should have the gallery UI finished either today or over the weekend (just tracking down some crashes and general cleanup after that.. Need to put in better commenting, getter/ setter methods, etc)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 01, 2014, 05:45:53 PM
Here are the current defaults for the "emulation profiles" - taken straight from the current published version.  Are there any defaults we should change (e.g. Rice fog, Rice frameskip).  Are there any settings we should remove (e.g. some of the rice/n64 settings)?  Any we should add (e.g. Rice framebuffer).  Any core options we should add (e.g. CountPerOp (probably!), DisableExtraMem, NoCompiledJump).  Remember, super users can still set most options that aren't exposed in the UI, by modifying the config file.  So no need to hang on to obscure settings just for experts.  But if an obscure setting is needed for a game or two, then it's worth keeping in the UI IMO).

r4300Emulator = Dynarec
videoPlugin = gles2n64

gles2N64Frameskip = No more than 2 frames
gles2N64Fog = false
gles2N64Sai = false
gles2N64ScreenClear = true
gles2N64AlphaTest = true
gles2N64DepthTest = true (i.e. hack-z = false; we can rename this in v3 e.g. "Hack depth axis")

gles2RiceAutoFrameskip = false
gles2RiceFastTexture = false
gles2RiceForceTextureFilter = false
gles2RiceScreenUpdate = First CI change
gles2RiceTextureEnhancement = None
gles2RiceHiResTextures = true (I think this should be false)
gles2RiceFog = false

gles2Glide64Frameskip = No more than 5 frames

Also note that the upstream defaults are glide64 plugin,
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 01, 2014, 05:52:53 PM
Also, I'd like to generate some basic out-of-box profiles for initial use.  I was thinking giving the profiles simple names (easy to explain in help replies).  My thoughts were

N (gles2n64, frameskip <=2, dynarec)
Nn (gles2n64, no frameskip, dynarec)
Nni (gles2n64, no frameskip, cached interpreter)

R (gles2rice, ....)
Rn
Rni

G (gles2glide64, ...)
Gn
Gni
Title: Re: Brainstorming Version 3.0
Post by: Paul on January 02, 2014, 08:48:58 AM
gles2N64Frameskip = No more than 2 frames
gles2RiceFog = false
These are the only two I would change.  I'd set frameskip to "No more than 4".  I'd prefer to say 5, but in the past I have seen 5 cause unstable framerate in DK64 in interpreter mode on the OUYA (i.e. any case where there is a lot of lag-- which is currently quite common).  I haven't tested this recently though (in particular since the frame limiter option changed), so I think it should be tested before a final decision is made.  Either way, going higher than 2 will make the plugin run more games without audio skipping (and since folks tend not to immediately associate audio skipping with emulation speed, better to default to a higher number)

gles2RiceHiResTextures = true (I think this should be false)
I'm not sure about having this one default to false.  It would just means more clicks when folks want to add a hires texture pack.  I can see where having the option checked could be confusing, though.  Maybe the option should only be visible after a texture pack has been imported for a game?

I like the idea of the profiles.  Those are certainly the main combinations anyone should use when checking the compatibility of a new game, so would make it easy to switch between them quickly.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 02, 2014, 09:01:39 AM
gles2RiceHiResTextures = true (I think this should be false)
I'm not sure about having this one default to false.  It would just means more clicks when folks want to add a hires texture pack.  I can see where having the option checked could be confusing, though.  Maybe the option should only be visible after a texture pack has been imported for a game?

I see your point.  Actually I think the current nuts and bolts behind the texture pack is a little wonky anyhow.  The button just lets you import texture packs.  The effect is cumulative, you can keep importing them for many games.  i.e. it's not a preference at all but an action.  Might be better to make a menu item "Import texture packs" in the options menu of the gallery
Title: Re: Brainstorming Version 3.0
Post by: beansta on January 02, 2014, 10:04:33 AM
The hires texture should be enabled by default (since having it enabled but no available pack for the game doesnt affect the compatability of any game ive tried), importing texture packs also sometimes doesnt work because of the way the files are structured within the archive (bad naming of folders basically). Ive had more sucess adding the folders manually than using the import function. But then again not everyone likes to tinker like i do :p so to each their own.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 02, 2014, 10:16:17 AM
Might make the most sense to enable hi-res textures by default, but disable the menu item if no hi-res textures are available for the game (or were imported incorrectly).  In such a case, the menu comment could say something like "No valid textures found".
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 03, 2014, 09:38:57 AM
Sorry it's taking so long to get the emulation profiles pushed.  I'm getting new ideas faster than I can implement them, and I see all sorts of low-hanging fruit that gets me sidetracked.  And when I do that I see cleaner ways to do the emulation profiles.  But in the end I think it will work nicely.  This morning it occurred to me we could have device profiles, e.g. for OUYA or particular chipsets, where the user sets the flicker reduction profile, the rendered resolution, and the default controller/touchscreen maps.  With some forethought it also wouldn't be hard to eventually implement an online database (e.g. google docs) where users could upload/download device/emulation/controller/touchscreen profiles.  So the community could be more self-supporting.

@Paul  In any event, the GalleryActivity should be well clear for you to push the carousel UI, whenever you feel it's ready.  I'm all cleared out of that area with the exception of maybe adding a line of code once I have the touchscreen profiles implemented.  I think our work is pretty decoupled at this point.
Title: Re: Brainstorming Version 3.0
Post by: Paul on January 03, 2014, 09:49:33 AM
Thanks, you are definitely moving a lot faster than me, sorry about that.  The wife and son are out of town this weekend, and no rumors about having to work over the weekend, so I'll have the gallery ready soon.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 03, 2014, 10:30:33 AM
BTW I'll be traveling monday morning through wednesday evening so it's pretty much guaranteed you'll have the repository to yourself if you're concerned about conflicts.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 04, 2014, 12:20:55 AM
Just realized that the gles2n64 "2xSAI" option has never been wired up to the core since the project's been on github.  I went ahead and wired it up.  Here's the impact:

without 2xSAI
(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2014-01-04-01-15-52.png)

with 2xSAI
(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2014-01-04-01-15-15.png)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 04, 2014, 08:50:50 AM
I'd set frameskip to "No more than 4".  I'd prefer to say 5, but in the past I have seen 5 cause unstable framerate in DK64 in interpreter mode on the OUYA (i.e. any case where there is a lot of lag-- which is currently quite common).  I haven't tested this recently though (in particular since the frame limiter option changed), so I think it should be tested before a final decision is made.

I'll go with "no more than 5" for alpha testing, and if we see any issues, we can drop back.  The thing about profiles is that we can tweak them in later updates, and anyone using a built-in profile will get the update automatically.
Title: Re: Brainstorming Version 3.0
Post by: Mikhail on January 04, 2014, 12:29:29 PM
Just realized that the gles2n64 "2xSAI" option has never been wired up to the core since the project's been on github.  I went ahead and wired it up.  Here's the impact:

Linear filtering seems to work best for 2x resolution, less pixelation on text etc other filters at 2x seem to disort the image or cause bluring arround text edges. Might be worth asking exophase for that filter source code from Drastic.

None
http://imgur.com/G7rsFZI

Linear
http://imgur.com/BJvevKE
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 04, 2014, 04:04:55 PM
@Mikhail Feel free to contribute to the code if you can.  We're swamped just getting the basic new features together for version 3.  Something like texture filtering falls pretty low on my priority list personally.  My highest priority is reducing the number of repetitive questions we (Paul) are bombarded with daily.  i.e. making it much easier for noobs to get the settings right.
Title: Re: Brainstorming Version 3.0
Post by: Mikhail on January 04, 2014, 07:13:12 PM
I'm no coder unfortunately, I had dig through ppsspp's source code though and it mentions
that OpenGL can set Linear filtering by setting the following two flags
GL_TEXTURE_MIN_FILTER and GL_TEXTURE_MAG_FILTER to GL_LINEAR.

Realtime demo of it action here under lesson 6, working on the grass texture
https://play.google.com/store/apps/details?id=com.learnopengles.android
Title: Re: Brainstorming Version 3.0
Post by: gdark100 on January 05, 2014, 11:20:33 AM
Linear filtering is already implemented in all plugins. To enable it on gles2n64, go to "android\data\paulscode.android.mupen64plusae", open the file "gles2n64.conf" and change "force bilinear texture = 0" to "force bilinear texture = 1"  :D

littleguy - It would be interesting to expose this option on the menu too, maybe put a selection between 2xSaI and Linear filtering...
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 05, 2014, 05:16:14 PM
Thanks for the pointer gdark :)

Lumping it into a combo-box option with 2xSAI is a good idea to keep it simple (will need to test to see if they're mutually exclusive).  I'm actually already working in that area anyhow right now.  Might be a good time to see if there are any other advanced options to add.
Title: Re: Brainstorming Version 3.0
Post by: Paul on January 05, 2014, 08:11:23 PM
Thanks, you are definitely moving a lot faster than me, sorry about that.  The wife and son are out of town this weekend, and no rumors about having to work over the weekend, so I'll have the gallery ready soon.

My main PC went out last night, so I spent most of today getting back up and running (still have another hard drive on order, but at least I can program on it again).  Anyway, didn't get the gallery ready to commit this weekend like I hoped, but close to finishing up the initial implementation.  I'll try and get it ready this week, if things aren't too busy at work (no major projects finishing up in the near term, so that's helpful)  I hate looking like I'm standing still with all the great progress being made by everyone else :(
Title: Re: Brainstorming Version 3.0
Post by: Mikhail on January 06, 2014, 01:18:50 PM
Thanks for the pointer gdark :)

Lumping it into a combo-box option with 2xSAI is a good idea to keep it simple (will need to test to see if they're mutually exclusive).  I'm actually already working in that area anyhow right now.  Might be a good time to see if there are any other advanced options to add.

Co-sign thanks for the tip.

Could a confirmation prompt be added for autosaves? so you don't overwrite a previous autosave when exiting the emulator by accident or when it crashes but still saves. I know you can still use save slots but it involes two extra steps of menu navigation for us lazy users, autosaves also make it quicker to switch plugins too for bypassing certain areas of a game.
Title: Re: Brainstorming Version 3.0
Post by: Paul on January 06, 2014, 01:36:16 PM
Could a confirmation prompt be added for autosaves? so you don't overwrite a previous autosave when exiting the emulator by accident or when it crashes but still saves.

I don't think so, since you can't block the process for long when user presses Home button (causes ANR).
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 06, 2014, 05:06:54 PM
You shouldn't be using autosave for anything important.  That's what slot saves, in-game saves and state save are for.
http://www.paulscode.com/forum/index.php?topic=964

I'm getting pretty tired of this question.  I wonder if there's something else we might do.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on January 06, 2014, 05:20:58 PM
Maybe try to do the exit/auto save more async (depending on if its exiting to the menu or a lock/phone call/other interruption)? The save lag is more noticeable on older devices. Also, possible, check if the emulator is jammed and have it not save if it is.
Title: Re: Brainstorming Version 3.0
Post by: Paul on January 06, 2014, 05:31:44 PM
My sense is that the main source of this complaint comes from users who are used to seeing most other emulators pause on exit rather than auto saving (despite the obvious power-saving and more reliable progress protection benefits of the latter approach).  Maybe the only way to stop the complaints is to conform to what is considered "standard", even if our way is arguably better.  But then again, there would likely be folks who LIKE the way we do it now who would then complain if we remove it.  So from that perspective, maybe we should just do it however we want to  :P
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 06, 2014, 05:40:08 PM
If we removed it we'd get 10x as many complaints from people who lost all their progress on game X after receiving a phone call.  Like I said, I don't even want to make it an option because it's like giving someone a loaded gun without telling them it's loaded.

I've actually been thinking for awhile about a FIFO queue of several autosaves so that a person could manually revert to an older autosave if necessary.  The size of the queue could be a setting, default at 5 or something.  Have the autosaves show up along with slots and savestates maybe.

Edit: as for async shutdown, I'd have to look at the code some more.  There's a lot of careful synchronization going on in the finish sequence.  Maybe could do it as an async task that calls emulator stop, then a core statechanged callback that calls finish() after the save is made.  What you wouldn't want is the gl context being lost (onSurfaceDestroyed) before the core cleaned up (from emuStop).  I can't remember if that causes a hard crash or not...  In any event I'll put it on my suggestion list but probably won't take a look until version 3 is nearly done.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on January 06, 2014, 11:08:26 PM
Messing around with other emulators. Nds4droid uses auto save states with user selectable intervals. And I thought of a compromise, maybe let it run in the background as well as creating a save state (pause the emulation but keep all of the surfaces and such alive).
Title: Re: Brainstorming Version 3.0
Post by: Paul on January 07, 2014, 08:16:18 AM
Could a confirmation prompt be added for autosaves? so you don't overwrite a previous autosave when exiting the emulator by accident or when it crashes but still saves.

BTW, @Mikhail, these rants are not directed toward you. Your suggestion is not a bad idea.  It just isn't technically possible on Android to wait for user input on exit.  I think Google realized such a capability would be abused by spammers - you have only a very short amount of time that you can block the process, before the user will receive an ANR error dialog and force-close the app (basically enough time to get in a save-state and shut down the core, and that's about it).

My sense is that the main source of this complaint comes from users who are used to seeing most other emulators pause on exit rather than auto saving

For a little more context on what I mean by this, I have many great examples of completely unrelated users repeating the same complaints over and over again, all stemming from an apparent believe that all emulators (and all programmers) are exactly the same, and that any deviation from the 'standard' behavior or falling short of 100% compatibility is clear evidence of bad programming.  I'm guessing that all the clones of the popular emulators fuel these misconceptions (when shopping for a new emulator, you get used to seeing the same thing over and over again).

Besides the "How can I turn off auto-save" we are discussing, there are "[Button X] is missing", "Emulator sucks, and I know the problem isn't my phone since it is way faster than the N64", "[Game X] doesn't work, and it's the only reason I got this", "I'm a programmer, and I know amateur work when I see it", "How come [emulator for system X] works and this thing sucks", "I reported [problem with game X] months ago and it still isn't fixed" (just a few that come to mind). 

End of the day, I think we have to accept the fact that many people can't appreciate that programmers are people, not robots with exactly the same experiences and skills.  We can't expect them to realize it is silly to assume emulators which were developed by completely unrelated groups of people and of completely unrelated systems should all have the same levels of compatibility, to progress at the same rate, or to exhibit all the same behaviors and features.  By accepting this, we can then move forward with designing the app however we want to, because it is impossible to please everyone when their expectations are not realistic in the first place.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 07, 2014, 08:47:20 AM
Agreed, not a rant against @mikhail, and well explained Paul.

I'll probably implement the LRU/circular-buffer autosave thing before v3 ships, since it would be very easy to do.  We can alpha test to see what people think.
Title: Re: Brainstorming Version 3.0
Post by: Mikhail on January 07, 2014, 10:34:26 AM
Hmm how about adding a timestamp as part of the autosave filename so each autosave gets a brand new name, then give the user an extra option to import / load autosaves over a slot save if they so wish.
Is there any difference between the .sav and .st? format?
Title: Re: Brainstorming Version 3.0
Post by: Paul on January 07, 2014, 10:39:43 AM
Hmm how about adding a timestamp as part of the autosave filename so each autosave gets a brand new name, then give the user an extra option to import / load autosaves over a slot save if they so wish.
That's an interesting idea.  Maybe the load dialog could have something like "last auto-save", "older auto-saves" (brings up sub-list ordered by time), and "browse.."


Is there any difference between the .sav and .st? format?
The .st# extensions are the slot saves (just a way for the code to easily distinguish between the ten slots)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 07, 2014, 04:57:31 PM
Yes I was leaning towards timestamps, and only the most recent x would be saved, where x is a user setting.  I was thinking there would be a single load interface, where autosaves, manual saves, and slot saves would be grouped and shown together.  If we get screenshots working it could be a type of gallery/carouel interface.

There would still bw a resume button to make the 90 percent use case easy.
Title: Re: Brainstorming Version 3.0
Post by: gdark100 on January 07, 2014, 05:50:49 PM
A good idea to make the settings menu is to use tabs to organize categories, like the new version of retroarch for android. Something like this:

- Video TAB
<Plugin>
Video plugin / gles2glide64
<Video settings>
General video settings here....
<Glide64 settings>
Per-plugin settings here...

- Audio TAB
Enable audio (if disabled, choose no audio plugin)
Audio settings here...

- Input TAB
<USB/Bluetooth Controller>
External controller settings here
<Touchscreen gamepad>
Touch screen overlay settings here

- Advanced TAB
Advanced settings here...
Restart config here too... (only if is general settings, not per-game)

(and, if is per-game settings)
- Show Manage profile (or something like this) TAB, with options to:
Delete per-game config and use general config (go back to main menu)
Restart per-game config to defaults
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 07, 2014, 06:55:13 PM
Lioncash did a lot of the new stuff for the retroarch android menus, and I agree it is really nice.  Some of my main priorities are that the menu is easy to navigate with controller and is compatible with eclair.  I would need to do a little digging to be sure that's possible with that design.

The version 3 menus of mupen ae are structured a bit different than version 2 and your suggestion.  E.g. the video and input stuff would not be seen in the same activity as audio/advanced since they are now game and profile based.  But I'll definitely open the door to ideas once I get all the profiles stuff pushed.  I think it will be clearer to critique once everyone sees the new structure.

I'm on travel right now but the emulation profiles are finished and I'm literally just adding documentation and cleaning up the commit sequence.  I expect to push it over the weekend when I get back.   At that point it should be easier to imagine where improvements could be made.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 12, 2014, 11:39:17 PM
Ok, the profiles stuff is pushed to a separate branch, to avoid stepping on anyone's toes.  All the UI and persistence mechanics are there.  You can add, edit, copy, rename, and delete emulation/controller/touchscreen profiles.  The emulation and touchscreen profile editing screens should look very familiar - they are just sections of the version 2 settings menus.

Note that this doesn't include the touchscreen layout editor.  That will be coming later but I didn't want to delay this stuff anymore.

Also, note that I still have to do the final re-wiring from the emulation/touchscreen profiles into the UserPrefs.java class.  Right now the app is still using whatever has been set in the global settings screen.  I'm holding off on this last step because it will require some refactoring of the UserPrefs.java file, which would probably end up touching half the java files.  Which would probably best be done after the gallery activity is updated to minimize conflicts.
Title: Re: Brainstorming Version 3.0
Post by: Paul on January 13, 2014, 07:50:04 AM
Thanks, sorry again for the delay getting the gallery activity up and running.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 14, 2014, 09:14:41 AM
I have the profiles stuff finished and will be rebasing it all onto master in the near future.  I'll then be doing a fair bit of cleanup to the java package organization and class names.

@Paul - is your gallery implementation in a shareable state?  Even if it's buggy, it would be helpful to see it on a branch so I know where not to step during cleanup.
Title: Re: Brainstorming Version 3.0
Post by: Paul on January 14, 2014, 09:38:07 AM
I want to push the commits in a specific order, so I'll create a branch and start doing that tonight.  Unfortunately, it requires some hacking to make it function in the current state, due to needing to finish incorporating the ROM search piece (kind of in a chicken or the egg state at the moment).
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 14, 2014, 10:07:22 AM
Ok, I wasn't planning to modify or merge your stuff.  I appreciate clean commit sequences :)  Mostly just want to see what your dependencies are so I know what of my own stuff is safe to cleanup and what can be pushed to master without causing headaches for you.  Maybe commit to a branch like 'do-not-merge/...' so it's obvious to the other devs.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 14, 2014, 10:16:39 PM
Game-specific preferences are all pushed to master now.  There still remains some polishing and minor feature additions, but this is the lion's share of it.  (Minor things like allowing the user to pick a global default profile and jumping straight to the profile editor from the profiles popup in the play menu.)

This does not yet include a system for narrowing the list of emulation profiles per-game.  Currently, all emulation profiles are visible to all games.  The per-game filtering will require a new data file and some additional classes.  There are many ways to do it and I'm mulling it over in my head.

Touchscreen profiles are kind of a half-way implementation for now.  Basically it's all the old touchscreen functionality and menus, now just lumped into profiles and settable on a per-game basis.  Once I really dig in to the touchscreen layout customizer, I imagine this will be overhauled quite a bit.  But for now it's familiar and a reasonable half-way.

Once the GalleryActivity and other major contributions are added, I plan to rename a bunch of classes, reorganize some of the packages, and update some xml keys so things follow a more consistent pattern.
Title: Re: Brainstorming Version 3.0
Post by: karl_87 on January 15, 2014, 05:15:19 AM
screenshots of where your at?  ;D
Title: Re: Brainstorming Version 3.0
Post by: gdark100 on January 15, 2014, 07:15:39 AM
Some pics of the new emulation profiles:
http://imgur.com/a/MZ8E6#8 (http://imgur.com/a/MZ8E6#8)

I think the names of emulation profiles could be more explanatory, like "gles2glide64 without frameskip" instead of "Gn" and so on.

Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 15, 2014, 08:54:59 AM
Disclaimer: This is just a starting point to give you an idea of the functionality.  Things like layout, text, styling, ordering, etc. are easy to change and we welcome all suggestions and critique.

To see an image full-size, right-click on an image and select "View Image" or whatever.  Everything in red is just my annotations (not in the actual app).

First, the "gallery activity", the main screen you see after the splash screen when the app launches.  Right now there's just a placeholder Paul's cover art stuff.
(https://dl.dropboxusercontent.com/u/3899306/ver3/01.png)  (https://dl.dropboxusercontent.com/u/3899306/ver3/02.png)  (https://dl.dropboxusercontent.com/u/3899306/ver3/03.png)  (https://dl.dropboxusercontent.com/u/3899306/ver3/04.png)

In the settings menu you can set global preferences, language, and manage the various profiles.  First, the global settings, which is only a subset now of what it is in version 2.  Stuff can be moved into sub-screens later depending on what people think best
(https://dl.dropboxusercontent.com/u/3899306/ver3/05.png)  (https://dl.dropboxusercontent.com/u/3899306/ver3/06.png)

Then the profiles management screens, which are all very similar.  First the emulation profiles management.  There's a main screen to add, edit, copy, rename, and delete profiles.  Editing a profile takes you to a subscreen with the actual profile options (e.g. dynarec, video plugin, etc.).  Built-in profiles are read-only, so you have to copy them first (using the UI) if you want to edit them.
(https://dl.dropboxusercontent.com/u/3899306/ver3/07.png)  (https://dl.dropboxusercontent.com/u/3899306/ver3/07a.png)  (https://dl.dropboxusercontent.com/u/3899306/ver3/07b.png)

And same for the touchscreen and emulation profiles.  The touchscreen profile editor will probably change substantially once the layout customizer is finished.  The controller profile editor should look pretty familiar, but it has fewer items in the option menu (action bar).
(https://dl.dropboxusercontent.com/u/3899306/ver3/08.png)  (https://dl.dropboxusercontent.com/u/3899306/ver3/08a.png)  (https://dl.dropboxusercontent.com/u/3899306/ver3/09.png)  (https://dl.dropboxusercontent.com/u/3899306/ver3/09a.png)

Back to the main screen, if you select a ROM to play, you will jump to the ROM menu screen, which allows you to select particular profiles for each game.  The profiles you select for each game will be remembered, so you don't have to constantly change settings every time you jump between games.  Set and forget.
(https://dl.dropboxusercontent.com/u/3899306/ver3/11.png)  (https://dl.dropboxusercontent.com/u/3899306/ver3/12.png)  (https://dl.dropboxusercontent.com/u/3899306/ver3/13.png)  (https://dl.dropboxusercontent.com/u/3899306/ver3/14.png)

And then the multi-player mapping, in case more than one controller is enabled.  Right now this is the same as in version 2 but we might need to tweak it to be more friendly to gamepad-only (no-touchscreen) users.
(https://dl.dropboxusercontent.com/u/3899306/ver3/15.png)

Cheats are now in a subscreen and can be enabled/disabled as before to speed menu loading.  From that screen you can also add, edit, and remove cheats, using xperia64's new cheats editor:
(https://dl.dropboxusercontent.com/u/3899306/ver3/16.png)  (https://dl.dropboxusercontent.com/u/3899306/ver3/17.png)  (https://dl.dropboxusercontent.com/u/3899306/ver3/18.png)  (https://dl.dropboxusercontent.com/u/3899306/ver3/19.png)

Finally, some other odds and ends.  On the main screen menu, if you press "hardware info" you'll get all your controller and phone/tablet stuff together, and a convenient button for emailing the info to devs or copying to clipboard.
(https://dl.dropboxusercontent.com/u/3899306/ver3/20.png)

There's a lot more to come, but as always, all comments welcome :)





Title: Re: Brainstorming Version 3.0
Post by: Mikhail on January 15, 2014, 02:13:27 PM
How about adding a TV screen as a template to show a in-game screenshot on the gallery, then another template of the n64 with a picture of the inserted game cartridge.
A rom info screen would be nice too showing the rom header info the same as tool64.
(http://i41.servimg.com/u/f41/17/01/76/62/zelda12.jpg)
Title: Re: Brainstorming Version 3.0
Post by: Paul on January 15, 2014, 02:20:42 PM
Well, if it could be done professionally-looking.. I tend to prefer things to be simple but elegant (adding a TV or console and cartridge border around things seems very busy to me).
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 15, 2014, 02:42:38 PM
Also vanilla is easier to maintain.  And easier for new devs to jump in and contribute if stuff follows vanilla conventions.
Title: Re: Brainstorming Version 3.0
Post by: Mikhail on January 15, 2014, 02:47:01 PM
I'll see what I can come up with, what's the gallery screen width / height?
Title: Re: Brainstorming Version 3.0
Post by: gdark100 on January 15, 2014, 02:52:56 PM
Another thing that would be interesting is to separate chetats by category. Each "\" should create a new category (this way should be more easy to find cheats, and would load faster too).. And the name of the emulation profiles should be more suggestive
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 15, 2014, 03:13:06 PM
I'll see what I can come up with, what's the gallery screen width / height?

The entire area between the action bar (top) and navigation bar (bottom).  Obviously varies dramatically between devices both in physical and pixel dimensions.  If you wanted to mock up something in photoshop, you could just take one of the first screenshots above and draw over top of it.  That's a Nexus 7.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 15, 2014, 03:16:12 PM
Another thing that would be interesting is to separate chetats by category. Each "\" should create a new category (this way should be more easy to find cheats, and would load faster too).. And the name of the emulation profiles should be more suggestive

That's a great idea for organization. I like.

In terms of speed it probably wouldn't make a difference.  Speed is related to reading a file and crunching some numbers.  We can probably find ways to speed that up (preload the file once, don't re-compute numbers you already have, etc.).
Title: Re: Brainstorming Version 3.0
Post by: Mikhail on January 15, 2014, 04:54:01 PM
Here's a low quality sample for landscape, i'll do I hi-res one tommorow and neaten it up, then I'll resize it to various resolutions.
Title: Re: Brainstorming Version 3.0
Post by: karl_87 on January 16, 2014, 05:16:49 AM
Screenshots are looking nice!
I have a request for the controller support (not sure how difficult this would be)
Say I have a few controllers connected to the ouya, I then run Mupen, and use the new awesome menu to start a game.
I would like to be able to then press a random button on my controller and a small text overlay appears on screen saying this controller has now been set as N64 controller 1. My 2 friends can then do the same, 1 will press next and become player 2, and the third will then be player 3 etc.
I think method would work great and allows you to get in to the games quickly without shuffling around in the menu's too much. What do you think?
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 16, 2014, 06:01:12 AM
I think method would work great and allows you to get in to the games quickly without shuffling around in the menu's too much. What do you think?

Yeah, I was thinking something along those lines too.  The multiplayer mapping has been a thorn in my side, I've always been looking for ways to improve it.
Title: Re: Brainstorming Version 3.0
Post by: Paul on January 16, 2014, 03:00:38 PM
I would like to be able to then press a random button on my controller and a small text overlay appears on screen saying this controller has now been set as N64 controller 1. My 2 friends can then do the same, 1 will press next and become player 2, and the third will then be player 3 etc.
A challenge with that approach would come when multiple controllers are visible to Android as a single input device (like with Wiimote Controller IME which emulates multiple Wiimotes as keyboard input).  You'd still need an option to say that multiple users are on the same device.  I suppose when that option is checked and the buttons are mapped, then you actually would be able to determine in-game which physical controller was activated.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 16, 2014, 03:18:54 PM
Yeah, I'd still keep the "share controller" checkbox for that purpose.  Right now it's in the global settings.

I was thinking, instead of having the player mapping thing pop up before launch, I'd have a little dialog pop up after launch, and only if player mapping was necessary.  It would just be a notice that player mapping is needed.  Might say "Player 1 press a button on your controller".  Player 1 would tap a button to close the dialog, then a second window would pop up saying "Player 2", and the process would repeat for however many players were enabled.  Then I'd add a menu item in-game in case people messed up and wanted to re-map.  Again, none of this would show up if the players were already mapped OR if only one controller was enabled OR the "share controller" box was checked (i.e. the same logic it has always used).
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 17, 2014, 03:23:17 PM
@Paul - I threw together a simple gridview-based gallery activity last night for the fun of it.  I added some basic implementation for searching and caching rom paths/md5s/cover art, and it's working ok for small numbers of ROMs.  I'll try to polish it up a bit and post it to a branch tonight, maybe use it to stir up discussion or compare notes or whatever....
Title: Re: Brainstorming Version 3.0
Post by: Paul on January 17, 2014, 04:02:50 PM
Ok, sure.  Sorry for the delay, just been crazy this week.  I'll put mine up this weekend.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 19, 2014, 09:53:32 AM
OK, pushed some more things to my simple gallery activity.  It's been a useful exercise for me -- I located some bugs and complexities with some of the ROM detail stuff, and some still remain.  Mostly with ROMs that aren't in the database.  Paul - if you're having edge case issues with your gallery implementation, it would probably be best to discuss here.

One other thing, I did notice that art loading and scroll speed were slow depending on how I implemented some of the gridview stuff.  i.e. loading the bitmap inside the ArrayAdapter.getView() method is really bad.
Title: Re: Brainstorming Version 3.0
Post by: Paul on January 19, 2014, 10:05:59 AM
Thanks, looking at it now.

Does the code you have posted now have the bad scroll speed problem?  I am using a similar strategy from what I can tell at first glance.  What I do is populate the gridview with default coverart image, and load the bitmap (LRU memory Cache, file, or download) on a separate thread.  UI is updated once bitmap is available.  Haven't had any noticeable scroll speed issues (refresh speed is bad when it has to download an image, of course).

For filling in the blanks of missing ROMs in the database, maybe we can come up with some type of test app for folks to run to get them to gather the data we would need to fill in the blanks?
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on January 19, 2014, 11:04:23 AM
My proposal for cheats merging conflicts:
Keep mupencheat.txt as it is. Copy it to /sdcard/mupen64plus/mupencheat.txt and use that one for reading/writing/editing. If new compatibility cheats need to be added on update/first install, keep them in a separate file or res/values/strings.xml, and merge these using the CheatFile class commands, making sure to verify if the cheats are already there and have not been tampered with. The compatibility cheats should also have some special header or something that the interface can read so it knows to hide them from the user and keep them always on.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 19, 2014, 12:04:33 PM
Strange, I didn't get my usual thread notification.

@Paul - the current head of littleguy77/simple-gallery scrolls quickly.  I never published the slow implementation but thought I'd mention it.  The slowness was when I did this:
Code: [Select]
artBitmap = new BitmapDrawable( context.getResources(), artPath );in GalleryItem.Adapter.getView(..) rather than in the GalleryItem constructor.

Regarding filling in the blanks of missing ROMs in the database.  It depends on whether we actually want that.  I would actually see it as a feature if badly-ripped ROMs were ignored during search.  I'm assuming the database intentionally omits bad rips.  On the other hand, in an ideal world expert users should not be prevented from using unknown homebrew ROMs.

My current thinking is that if the ROM isn't in the database, you should still be able to launch the game, but you just won't have the extra meta-info (e.g. goodname) in the UI.  Whether the core can handle a ROM not in its database is another question altogether, and perhaps not one that we need to address right away.  In the short term, expert users should be capable of manually editing the ini file (and backing it up) if they really need to use an unknown ROM and the core requires an entry in the ini file.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 19, 2014, 12:06:13 PM
My proposal for cheats merging conflicts:
Keep mupencheat.txt as it is. Copy it to /sdcard/mupen64plus/mupencheat.txt and use that one for reading/writing/editing. If new compatibility cheats need to be added on update/first install, keep them in a separate file or res/values/strings.xml, and merge these using the CheatFile class commands, making sure to verify if the cheats are already there and have not been tampered with. The compatibility cheats should also have some special header or something that the interface can read so it knows to hide them from the user and keep them always on.

Yes, it seems a bit thorny.  Perhaps you can take the lead, and push stuff to a branch for testing.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on January 19, 2014, 02:23:08 PM
Restructuring some stuff so the editable mupencheat.txt is in /<storagedir>/mupen64plus/CoreConfig/UserData. Also, in the cheat menu, I found that it isn't refreshing newly added or deleted cheats until you toggle the cheats checkbox. Also, the speed toggle button issue is still there :P
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on January 19, 2014, 03:56:31 PM
I added a basic merging handler. Add compatibility cheats to cheat_compatibility in arrays.xml. These will be written on every run.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 20, 2014, 11:27:57 AM
Would be nice if we could achieve the same effect without touching any core source.  If we auto-write cheat files on the fly, how about this concept?

- On install or update, extract mupencheat.txt the way we've always been doing it, to android/data/paulscode...
- After asset extraction, patch the mupencheat.txt file *in-place* with the user's customizations.
- Patch again whenever the user customizes something.

Any new cheats that we as devs add would be straight to the built-in mupencheat.txt file.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on January 20, 2014, 12:10:52 PM
We could extract mupencheat.txt to mupencheat.default,  copy that to the /sdcard/mupen64plus folder like it is in my build now for editing,  and after an edit (or just every time), and  copy that to the normal mupencheat.txt location.
I don't particularly like patching in user customization as it involves possibly both adding and removing items. I think just adding the few compatibility cheats and recopying the entire file is easier than attempting to do a diff-like thing.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 20, 2014, 09:47:13 PM
Yes that would probably be the easiest thing starting with the branch you just posted.  That would allow us to revert the mods to the core.

As for diffing, I wasn't thinking like a raw text diff or anything.  For removals the custom file could just have an extra flag to denote the cheat should be deleted from the merged file.

Oh snap I just remembered it's not a ConfigFile anymore.  That might make my removal idea a bit harder.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on January 21, 2014, 07:35:52 PM
So how about this:
User installs/updates mupen->default cheat file gets extracted to mupencheat.default->copied to mupen64plus save folder and copied to mupencheat.txt in the normal location. The copied one is for user edits and gets compatibility patches on each update via my implementation (these can be denoted with a special title if desired for hiding/force enabling by the UI). Every time the user edited cheat database is saved, it gets copied back to mupencheat.txt in the normal location. mupencheat.default should always have the latest compatibility cheats and should be allowed to be restored separately from the other appdata.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 21, 2014, 07:51:36 PM
Is there something different between your two last posts?  I'm missing the nuance.

So which method do we (as devs) use to modify cheats (e.g. pilotwings)?  Are you saying we edit mupencheat.default, or do we add strings to arrays.xml?  Or both?  Also, are you saying that the default file will only ever be copied one time to the user's non-volatile area?  Or is it copied down regularly (e.g. at startup, before game launch, etc.)?
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on January 21, 2014, 07:58:53 PM
No real difference, just putting the last two idea posts in one. I'm thinking compat cheats should be put in both mupencheat.default and strings.xml, but I guess just strings.xml would do. The mupencheat.default file should only be copied to the non-volatile area once unless the user selects "restore cheat database". After that, it isn't used.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 21, 2014, 08:03:12 PM
Gotcha.

Just occurred to me, for any of these ideas what happens when the user changes the save location (i.e. changes from sdcard/mupen64plus to extscdcard/mycoolstuff...  sigh.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on January 21, 2014, 10:24:15 PM
Gotcha.

Just occurred to me, for any of these ideas what happens when the user changes the save location (i.e. changes from sdcard/mupen64plus to extscdcard/mycoolstuff...  sigh.
Wont matter. So as not to mess with the core like you said, the java side will copy mupencheat.txt to the normal location from wherever the save location is set whenever the database is edited (and/or when the save location is changed.)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 21, 2014, 10:32:47 PM
Here's the sequence that occurred to me
 - Clean install
     - mupencheat.default gets copied from assets to userspace1, renamed mupencheat.txt
     - mupencheat.txt gets copied from userspace1 back to assets
 - User modifies some cheats
     - userspace1/mupencheat.txt changes
     - mupencheat.txt gets copied from userspace1 back to assets
 - User changes to userspace2
     - mupencheat.default must be copied from assets to userspace2 (otherwise the user has no cheats to edit)

I suppose every time the cheat editor is launched, you check to see if userspace/mupencheat.txt exists, and if not you copy assets/mupencheat.default to userspace/mupencheat.txt.

Maybe it's not so hard after all :P
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 21, 2014, 10:38:59 PM
So a slightly cleaner logic would be

User installs app, then does A or B in any order
 A) User launches game
     - app looks for userspace/mupencheat.txt
         - if found, copy userspace/mupencheat.txt to assets/mupencheat.txt
         - else copy assets/mupencheat.default to assets/mupencheat.txt
     - launch game
 B) User launches cheats editor
     - app looks for userspace/mupencheat.txt
         - if not found, copy assets/mupencheat.default to userspace/mupencheat.txt
     - launch cheat editor
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on January 21, 2014, 10:45:35 PM
When changing userspaces though, perhaps copy and overwrite assets/mupencheat.txt in userspace2 so custom cheats are not lost. assets/mupencheat.txt should in theory always have the latest cheat file changes.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 21, 2014, 11:00:08 PM
Yeah, that occurred to me.  But right now, when the user changes from userspace1 to userspace2, nothing else gets copied over so it effectively resets everything to a clean install (no saves, no profiles, no config mods, etc.).  They don't actually lose data since they could always return to userspace1 or manually copy everything from userspace1 to userspace2.  So we probably wouldn't want to copy the old cheats to the new space, just for consistency.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 23, 2014, 10:19:30 AM
Just wrote a script to auto-generate a wiki for all game roms.  Would be easy to add a link in the play menu of the app to take the user to the game's wiki page.  Could do the same for devices and controllers (though we wouldn't be able to pre-populate it).

Here's an example on wikia (which is horribly messy and bloated) but you get the idea.
http://littleguy77.wikia.com/wiki/AllGames

Here's what a user would be redirected to from the play menu of the app.
http://littleguy77.wikia.com/wiki/Legend_of_Zelda,_The_-_Ocarina_of_Time

Obviously could be beautified, but this gives an idea of the kind of functionality possible with only a little bit of effort.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 26, 2014, 04:42:48 PM
@xperia64 Sorry if I seem like I'm dragging this cheats stuff out.  It's just that it's the kind of thing that you want to get right up front, because it's really hard to change the mechanics later.

Another idea I had would be to make built-in cheats read-only, but custom cheats fully writable/deletable.  This matches the idiom I'm using for the settings profiles.  We'd have mupencheat.default with all the built-ins (which the devs can update between releases) and then mupencheat.txt in the userspace that contains only the custom cheats.  Then right before launch, the two are combined into a single cheat file that the core reads, mupencheat.txt.  What do you think?
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on January 26, 2014, 04:54:56 PM
Seems a bit more feasible. As long as we can ensure the CRC and game name are identical in each file than yeah, that should work. Also as mupen64plus reads cheats by number rather than name, cheat name conflicts shouldn't be too much of an issue.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on January 28, 2014, 07:40:33 PM
I know using gestures as controls has been mentioned before, and I just noticed an app called ClassicBoy (probably a clone of RetroArch) has an implementation of gestures and advanced tilt settings. Maybe look at that as an example. I guess if we agreed on the cheat implementation I can shuffle some files around and push a test.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 28, 2014, 07:54:25 PM
Thanks for the reference.  Yep, gestures is still on my personal list of suggestions.  If there's a gesture API baked into android, it should be pretty straightforward (just subclass AbstractController).  The more tedious part would probably be making the java UI to make the mapping easy.

I'm not sure I understand your last sentence. 
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on January 28, 2014, 08:10:21 PM
For cheats, I think http://www.paulscode.com/forum/index.php?topic=1130.msg12485#msg12485 is fair solution so I could get started on that.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 28, 2014, 08:17:55 PM
Sure, that would be great.  :)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 28, 2014, 08:21:20 PM
WHOA That ClassicBoy is not a clone of retroarch... It's a mashup of mupen64plus-ae and a bunch of other emulators.  :o

Major overhaul to the front-end UI, but you can definitely see it was derived from ours.  Pretty nice design actually.  Would be nice to see the source code for the touchscreen customizer.  Wonder if they plan to adhere to the GPL license...  ???
Title: Re: Brainstorming Version 3.0
Post by: littleguy on January 28, 2014, 08:25:36 PM
Basically started with mupen-ae's front-end (I'll take that as a compliment I guess) then reorganized the hierarchy and bent the other emulators to use most of our front-end menus  :o
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 01, 2014, 12:47:39 PM
Should the built-in cheats even be shown in CheatEditorActivity?
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 01, 2014, 01:07:26 PM
Maybe if someone wanted to copy one and tweak it?  Maybe?  Don't know.  That's how the profiles are but I have no idea if it makes sense for cheats.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 01, 2014, 01:24:22 PM
Assuming I can get the number of built in cheats, I guess I could show them, and make them uneditable like profiles. I don't really see why you would want to copy a cheat, but I guess I could add that.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 01, 2014, 01:27:46 PM
I have no idea what actually makes sense, you should be the judge.  I just threw out the only idea I could come up with for showing built-ins.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 01, 2014, 03:18:09 PM
Right. I implemented this method. So what this does is:
User installs app. mupencheat.txt has been renamed to mupencheat.default in assets. mupencheat.default is copied to mupencheat.txt
User selects game and enables cheats. usrcheat.txt (in the Profiles folder) is merged into mupencheat.txt. User cheats are always at the bottom of the list.
User plays game, cheats should work.
For editing cheats:
User edits cheat file, default cheats are populated first, followed by usrcheats.
User saves new cheats/edits. mupencheat.txt has system cheats and user cheats populated for the game. usrcheat.txt is populated with only user cheats.

I created a new class called CheatUtils that handles the common save and populate commands used not just in CheatEditorActivity.

This has not been tested with 'unknown' games.

mupencheat.txt can safely be overwritten on updates, I didn't add the code for it yet though.

Also, could you edit the behavior of the EditTexts for system cheats so they can be copied but not changed? You can check if its a system cheat if the position of the cheat is less than numberOfSystemCheats

BTW, I need git push access on the new repo.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 01, 2014, 04:02:27 PM
Ok you should be able to push now.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 01, 2014, 04:05:46 PM
Check branch new-cheat-merging.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 02, 2014, 06:16:11 PM
Sorry for the delay.. I can't seem to access the forum from my pc, only my phone.  I did a quick build and tested it, seems like it works fine though it did seem quite a bit slower loading the play menu activity.  I'll dig into the source to see if anything obvious jumps out.

Also, unless there's a copy function, I don't see the value of showing the built-in cheats in the editor activity.  But it looks like we only need to comment out one line if we want to remove them.  Nice...
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 02, 2014, 06:21:17 PM
Sorry for the delay.. I can't seem to access the forum from my pc, only my phone.  I did a quick build and tested it, seems like it works fine though it did seem quite a bit slower loading the play menu activity.  I'll dig into the source to see if anything obvious jumps out.

Also, unless there's a copy function, I don't see the value of showing the built-in cheats in the editor activity.  But it looks like we only need to comment out one line if we want to remove them.  Nice...
They don't have to be shown but they need to be loaded as I wipe the entire cheat block for the game each time before writing the contents of the ArrayList. Instead of a copy button I was thinking of showing a selectable TextView instead of an EditText/PromptText to allow copying that way.
Title: Re: Brainstorming Version 3.0
Post by: arrtoodeetoo on February 03, 2014, 01:41:19 PM
Chromecast SDK is out for devs! I repeat: Chromecast SDK is out! :D
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 03, 2014, 02:37:26 PM
Thanks.  I don't have a chromecast dongle (yet) but am certainly curious.  I wonder what the latencies are.  Any specs?
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 03, 2014, 03:06:51 PM
As best I can tell, this is not an easy feature to add.  Basically we'd have to encode the video into a standard format (e.g. H.264) from the user's phone/tablet, on-the-fly, then pass that along with some javascript/html5.  The chromecast dongle is essentially just a lightweight Chrome browser:

Quote
The Cast receiver is a Chrome browser optimized for video playback. As such, WebGL and Chrome Native Client (NaCL) are not currently supported, nor are Chrome extensions.
https://developers.google.com/cast/docs/ux_guidelines

I'll be very curious to see if any other game apps will be able to use the feature...
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 03, 2014, 03:12:13 PM
Btw, I know why its slower loading the play menu. If cheats are enabled, it rewrites the cheatblock every time ad I don't have a method of determining if cheats have already been merged (like after an update). Also,  I know that at least mircast doesn't appear to support mupen that well. Too intense :P
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 03, 2014, 04:19:37 PM
@xperia64 Oh yeah, I see what you mean.  Seems like the only time you'd want to write to to mupencheat.txt would be right after assets are extracted, and right after the user leaves the cheats editor and saves.  In both cases, it seems like you should merge-save, not simply copy the defaults though.

Edit: Oh there's also the issue of changing the user directory.  But I think we can address that separately, since it might affect more than just user cheats.
Title: Re: Brainstorming Version 3.0
Post by: LecktheTech on February 09, 2014, 02:34:29 PM
what about screenshots without a external app?
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 09, 2014, 04:06:32 PM
Yeah, that is on the wishlist.  We'd like to enhance the loading interface to show a screenshot associated with each save.  Once that's working, it should be easy to add an in-game UI to capture screenshots on demand.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 09, 2014, 05:38:39 PM
Could we store the md5sum of usrcheat.txt or an individual cheatblock somehow and use that to determine if cheats need to be merged?
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 09, 2014, 06:38:37 PM
Sure, there's a function in one of the utility classes for calculating MD5's.  Should work for any file type if I recall.  We could cache the value in the AppData or GamePrefs classes probably.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 09, 2014, 06:46:34 PM
Sure, there's a function in one of the utility classes for calculating MD5's.  Should work for any file type if I recall.  We could cache the value in the AppData or GamePrefs classes probably.
So:
User installs app, already has usrcheat.txt. Default md5sum in prefs is 0. User loads game and sees that md5 is different. Cheats are updated for that game. Here is the issue. How do we know which games we have updated?
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 09, 2014, 07:54:07 PM
I think you may be way out ahead of me on this, I'm not sure I'm catching the nuance of your concerns.  My thoughts with usercheats.txt went like this.

User installs app.
First launch, in SplashActivity:
  - mupencheat.default is extracted to volatile area.
  - mupencheat.default and usercheat.txt (if it exists) are merged
  - merged cheats are saved to mupencheat.txt in volatile area

Then later:
  - user makes changes to usercheat.txt
  - when they exit CheatEditorActivity, mupencheat.default and usercheat.txt are merged again and saved to mupencheat.txt

Then later, we update mupencheat.default:
  - mupencheat.default is extracted to volatile area.
  - mupencheat.default and usercheat.txt (if it exists) are merged
  - merged cheats are saved to mupencheat.txt in volatile area

So basically, we re-merge from scratch whenever mupencheat.default or usercheat.txt change.  I'm not sure exactly where the MD5's come in, but I suppose they could be used to determine whether either of those has changed.

Does this mesh with what you had in mind?  Or have I oversimplified it somehow?
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 09, 2014, 07:59:37 PM
usrcheat.txt is currently merged on a game-by-game basis when the game is selected and cheats enabled (hence the long loading time with cheats enabled). I could do a loop of some sort on first run to parse each game in usrcheat I suppose..
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 10, 2014, 07:21:47 AM
Yeah, that was my initial thoughts, just merge all cheats for all games whenever mupencheat.default or usercheat.txt change on disk.  Not when the game is loaded.  Does that take significantly more time to do or is there more to it than that?
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 10, 2014, 07:18:33 PM
Yeah, that was my initial thoughts, just merge all cheats for all games whenever mupencheat.default or usercheat.txt change on disk.  Not when the game is loaded.  Does that take significantly more time to do or is there more to it than that?
Hmm. That would require is parsing through usrcheat.txt, for each game entry find the same game as in mupencheat.default, splice em together and repeat. I guess it would be OK considering it should only happen once in a long while. Definitely would want to add a spinner of some sort to tell the user it's actually doing something and hasn't frozen.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 10, 2014, 11:14:06 PM
Hmm not getting forum notifications again

Yeah my knowledge of how the cheats files work is pretty superficial.  I've been imagining them like the ConfigFile class, where you can just iterate through the sections with a simple for loop and save the result at the end.  Sounds like you're saying the cheats files are harder to work with.  I'm happy to keep tossing out ideas, but don't sink too much weight into anything I say  ;D
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 12, 2014, 10:40:20 PM
Thought I'd post a few teasers for the new touchscreen layout editor.  It's about 95% functional right now and I'm pretty happy with how it's turning out.

I have foregone the drag-and-drop mechanic for positioning the images, at least for now.  A popup is easier to code and is sufficient, and it's a good spot for enabling auto-hold.  The sliders snap to 5% intervals when you drag the slider, and the +/- buttons allow you to tweak the locations in 1% intervals.  The intervals are easy to change later if we want finer granularity.  Buttons can be removed from the layout from the popup or from the action bar.  Buttons can be added to the layout using the same menu in the action bar.

The action bar also has a shortcut to the global preferences.  It's the same preference menu seen elsewhere, except that when it's launched from the layout editor, most of the irrelevant settings are hidden.  So as the user tweaks the layout, they can jump right to the settings and change display scaling, skin, button scale, opacity, etc., then return right where they left off, with all the new settings applied.  Makes it easy to test the layout in many configurations quickly.

I'm using a modified (taller) version of the splash image to represent the rendered portion of the screen.  It scales/crops/zooms/immerses/orients/etc. just like the real in-game video.  The image is actually perfect for the job since it has a subtle grid built-in, which gives you a good idea how aspect ratio distorts if the scaling is set to stretch.  It also gives a good idea of how much is lost if scaling is set to crop.

Comments welcome!

(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2014-02-12-23-14-48.png)

(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2014-02-12-23-15-08.png)

(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2014-02-12-23-15-37.png)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 12, 2014, 10:47:57 PM
Oh yeah, I also had a couple questions about the A/B buttons:

 1. Some users might want to move the A/B buttons independently.  Right now that can't be done since they're lumped together in a single image asset.  Should we separate the assets?

 2. With the exception of the D-pad diagonals, it has never been possible to press two buttons simultaneously with a single finger.  I imagine there are games that require A/B to be pressed at the same time for combo moves, etc.  (Maybe the C buttons too.)  Do we need to add another meta-button to represent simultaneous A/B?  In that case it might be good to keep A/B as a single image so that the masks coordinate properly.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 12, 2014, 10:49:56 PM
Is the location of a button immediately updated when a slider is changed or does OK have to be pressed first? (Obviously cancel reverts either way). If not it may be something to consider so users can easily see where they changed it to without having to re open the menu. Also, can you rotate without having to reload the menu or is it a profile thing like with separate portrait and landscape profiles?
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 12, 2014, 10:56:07 PM
Good questions.  Yes, the images move immediately when you move the sliders, you don't have to wait until you press OK.  And yes, rotation happens automatically when you rotate your device (you don't need to dig into the menu to change that).  The subset of global settings that are shown are
 - Display
    - Position (top/middle/bottom)
    - Scaling (zoom/crop/stretch/none) ("none" acts like "zoom" right now though)
    - Immersive mode
    - Action bar opacity
 - Touchscreen
    - Joystick animation (the editor will display the animated version at rest, but doesn't currently animate)
    - Button opacity
    - Button scale
    - Button skin (aka style)
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 13, 2014, 11:30:35 AM
Ok so to loop through cheats I need to call mycheatfile.getKeyset().toArray() on both cheat files, sort out which ones are duplicates, and move on from there. We can't assume that mupencheat.default has all of the games and base it solely on that in case the user made cheats for "unknown" games.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 13, 2014, 02:48:19 PM
Hmm found a holdup. CheatFile class needs to be modified to also store the country code along with the crc. Personally I fail to see why mupen even needs the country code considering that CRC's should be completely different if the ROM is in any way different.

Edit: nvm, the country code is included
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 13, 2014, 05:53:27 PM
Check the new branch (further-cheat-merging). Merges cheats when mupencheat.txt doesn't exist in SplashActivity. When an update to mupencheat.default is made or the save/profile directory is changed, deleting mupencheat.txt and relaunching SplashActivity will recreate it properly. The cheats in PlaymenuActivity show up faster, plus they now refresh when CheateditorActivity finishes. We really need to add ProgressDialogs (spinners or progress bars) of some sort for these blocking operations (loading game info, merging cheats, saving cheat database, etc).
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 14, 2014, 11:00:15 AM
Awesome, I'll try to take a look today.  I can add the spinners if you like, since I can just grab some code I already wrote for filepwn.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 14, 2014, 11:08:55 AM
Sure. Also, if you want to make like a manual merge button in advanced settings, make a new method with
Code: [Select]
new File(mAppData.mupencheat_txt).delete()and lines 201 through 250 of further-cheat-merging's SplashActivity.java
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 14, 2014, 11:12:20 AM
I did a quick glance at the code and it looks great, nice and clean.  So it looks like no matter what, if all else fails, the user can always "reset app resources" to re-merge all the cheats.  That's a nice outlet to have.

Edit: Ninja'd.  That would work too :)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 14, 2014, 11:24:30 AM
I just pushed a work-in-progress branch for the touchscreen layout editor, in case any devs want to take it for a spin.  Don't bother branching off of it or anything, since it's only a temporary branch.  Just a few warnings:
 - Any custom touchscreen profiles you created previously will not work with the new system
 - The analog and fps images can't be moved yet
 - Autohold might not work (I accidentally removed a menu option)
 - I forgot to remove the haptic feedback item in the global settings of the touch profiles editor
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 14, 2014, 07:39:00 PM
New cheats merging stuff looks great.  I went ahead and merged it into master.  I'll try to get the spinners in there soon.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 17, 2014, 12:38:11 PM
"Unknown" games are still crashing for me in PlayMenuActivity, specifically romMd5 appears to be null on line 161 of GamePrefs, called from line 233 of PlayMenuActivity (in refreshViews()).
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 17, 2014, 12:49:57 PM
Yeah, I need to robustify the RomDetail class a bit still for the corner cases.  Thanks for the pinpoint reminder.
Title: Re: Brainstorming Version 3.0
Post by: Miracle on February 25, 2014, 10:58:45 AM
Sorry, it's me, Lecrayen. I'm the guy that opened the gauntlet legends topic on github. What I was thinking was a verticle list with a small picture of the game (maybe your last save point) on the left, with some details about it to the right kind of like the gmail app's inbox.

In addition, an idea I'd like to toss out there... Widgets. Would it be possible to let users create their own 1x1 widgets which could be set to a certain game? Possibly tap+hold and click a button that says "Create Widget"
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 25, 2014, 12:13:33 PM
Thanks.  Widgets probably wouldn't be hard to implement since games can already be launched from file management apps.  Actually, if your file manager app provides shortcut widgets, you might be able to just add a shortcut to the v64/z64/n64 file.
Title: Re: Brainstorming Version 3.0
Post by: Miracle on February 25, 2014, 02:04:19 PM
From what I understand, though, you can't start playing the game until after you hit play after opening it. What I would enjoy is a widget with an icon that resembles the game, and immediately launches the game when you tap it.

In addition, I just tried adding it to the desktop, but you can only open apps on the desktop, not files.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on November 24, 2014, 10:01:17 AM
I thought I'd revive this thread since things could be starting to heat up again.  Just wanted to post a status update on recent activity.

 - Bugfixes:
    - Gilles has fixed a number of bugs in the dynarec, most importantly the DK64 collision bug!
    - Gilles and Ari64 are working through some details on how the fixes are implemented
    - Once that's settled, Gilles will submit a pull request upstream

 - Upstream developments:
    - There have been a fair number of upstream updates, though I don't recall how significant they are to us
    - We'll do another sync with upstream after Gilles submits his pull request

 - UI developments
    - xperia64's cheat editor has been implemented and integrated (actually happened a while ago)
    - Touchscreen profile editor has been integrated
    - Cover art download machinery is integrated and tested in a proof-of-concept UI (not yet posted)
    - Per-game wiki pages have been stubbed out

 
Some topics for discussion:

 - I believe xperia64 was able to get the Arachnoid video plugin integrated in a test branch.
      @xperia64 is this worth adding to the app?  i.e. does it perform better for certain games?  I combed through your commits and have a local branch containing only the arachnoid feature, so I can test and push to github if we decide to add it.

 - I'm still concerned about publishing version 3 over top of version 2.  There have been so many changes to the save directories (and more I'd like to make).  I'm concerned about bad migrations and people losing (or believing to lose) save and config data.  Also concerned about people feeling forced into the new UI, especially when there will inevitably be bugs.  I'm wondering if we can publish v3 as an "alpha" version, put a link to it in v2.5 welcome screen.  Data files and saves would be completely separate from each other.  The early adopters can be warned of its alpha state.  Eventually, after it matures and we figure out a good way to migrate data, we can push v3 to the main listing on Google Play.  I'd also rather get our new UI out there sooner than later before a free-loader publishes it under their name.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on November 24, 2014, 11:26:47 AM
I don't think Arachnoid is worth adding. It was a pain to deal with because it requires a GLES1.1 surface, so a special exception for Arachnoid has to be added. On top of that, it has a lot of lighting/texturing/polygon miscoloring issues. Smash is a black screen until I press exit, when it shows a single frame for a second. The only benefit is that is supports GLES1.1 devices, but what devices nowadays only have 1.1?
Title: Re: Brainstorming Version 3.0
Post by: Paul on November 24, 2014, 12:17:57 PM
- I'm still concerned about publishing version 3 over top of version 2.  There have been so many changes to the save directories (and more I'd like to make).  I'm concerned about bad migrations and people losing (or believing to lose) save and config data.  Also concerned about people feeling forced into the new UI, especially when there will inevitably be bugs.  I'm wondering if we can publish v3 as an "alpha" version, put a link to it in v2.5 welcome screen.  Data files and saves would be completely separate from each other.  The early adopters can be warned of its alpha state.  Eventually, after it matures and we figure out a good way to migrate data, we can push v3 to the main listing on Google Play.  I'd also rather get our new UI out there sooner than later before a free-loader publishes it under their name.

We could do a short "Alpha" for working out bugs in the UI, but long-term I would like to publish on top of version 2.  We will need to write a migration script to move folders around, and set up various scenareos (like updating from different published versions).

My main concern is the fact that the market is so saturated with clones, that putting up yet another clone will get basically no visibility.  One of the clones which does have the numbers will inevitably take the risk of putting their clone of version 3 over their clone of version 2, thus making themselves the most legitimate-looking to anyone new who goes to try out the top 3-4 N64 emulators to find which one they like.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on November 24, 2014, 12:33:32 PM
We could do a short "Alpha" for working out bugs in the UI, but long-term I would like to publish on top of version 2.  We will need to write a migration script to move folders around, and set up various scenareos (like updating from different published versions).

My main concern is the fact that the market is so saturated with clones, that putting up yet another clone will get basically no visibility.  One of the clones which does have the numbers will inevitably take the risk of putting their clone of version 3 over their clone of version 2, thus making themselves the most legitimate-looking to anyone new who goes to try out the top 3-4 N64 emulators to find which one they like.

I agree with all that.  I would view the alpha as just a way to work out the kinks without frustrating the mainstream users.  I expect it would mostly be just the current users who would know about it and give it a try.  They could be made aware using a popup in the 2.5 release.  Something like the changelog, relatively unobtrusive.

Once the kinks are mostly out we can create the migration script and publish over top 2.5.  I think you are right about a high-profile copycat stealing the thunder.
Title: Re: Brainstorming Version 3.0
Post by: retroben on November 24, 2014, 02:10:32 PM
I was thinking the same way about the migrating of save files before even reading the replies.

I sure hope real-time cheats makes it into this alledged alpha version.

How will you guys fix the terrible issues with some cheats not working?
I've had a number of my own cheats refusing to work when activator lines are added to them.
Some of them work fine with the same activator line,while others don't respond properly.
Is there a way to study PJ64's source code to find out how it does cheats,and then transcode that for Android ARM?

It might be the ASM-based codes not responding as well as they do on PJ64.
Banjo-Tooie has my many customized codes based on SubDrag's and IceMario's pointered size mod.
Then again,most of my simple codes with one line also fail to work right with the activator on Mupen64Plus AE. :'(
I can't stand how that cripples my many alternate-to-default styled codes which use activators to toggle them. >:(

So please,I beg of you to at least try your damndest to fix the crippled cheats system and maybe get it to act more like PJ64's powerful cheat system. :(
Title: Re: Brainstorming Version 3.0
Post by: Paul on November 24, 2014, 03:07:05 PM
So please,I beg of you to at least try your damndest to fix the crippled cheats system and maybe get it to act more like PJ64's powerful cheat system. :(

Have you tested the cheats in question on vanilla mupen64plus?  If the problem exists there too (versus being unique to AE), then you might have better luck discussing these issues with the upstream devs who are more familiar with that part of the code.  Our focus is primarily on the Android aspects of the project (front-end UI, ARM dynarec, and GLES2 video plugins)
Title: Re: Brainstorming Version 3.0
Post by: retroben on November 24, 2014, 10:57:53 PM
You really confused me.
How do I use cheats on vanilla mupen64plus?
How do I test what's not there?
The few alternative ones on Windows don't have any cheat menus.
Could you mean the Linux one?

I even recently tried an update from a little while ago that has a Gameshark plugin,but it is stupidly non-functional.
It will not show up on its respective slot in a games ROM settings,just an empty white list of nothing.
Title: Re: Brainstorming Version 3.0
Post by: Paul on November 24, 2014, 11:35:05 PM
Making some progress on the "page of carousels" UI concept.  Here is a rough demo (not pretty -- just focused on the mechanics at this point):

Page of carousels UI (http://www.paulscode.com/demos/CarouselUI/carousel-ui.apk)

Main mechanical issue left to deal with is vertical scrolling.  A couple of problems with it:

1) It is too sensitive (users will be doing far more horizontal swiping with this UI than vertical swiping, so it should pick up horizontal swipes more readily than vertical swipes).  I've seen some code online related to this.

2) I want vertical scrolling to "snap to" the nearest carousel when the user releases (as horizontal scrolling works).  This will involve a nested pager implementation, which should be interesting to manage (these use adapters that generate the next pages, so the vertical adapter will generate a page that itself has an child adapter to generate the horizontal pages).

Anyway, more work to do, but at least I think I am on the right track.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on November 25, 2014, 05:22:45 AM
Looking good Paul. :)  Remind me again, what will be going into the rows vs columns?

Tried it on my Nexus 7, didn't notice anything strange in the vertical/horizontal sensitivity, but maybe that's just me.
Title: Re: Brainstorming Version 3.0
Post by: Paul on November 25, 2014, 05:58:28 AM
Remind me again, what will be going into the rows vs columns?

Rows would be things like Resume Playing, Favorites, user-defined playlists, etc.  Goal is eventually something like this:

(http://www.paulscode.com/source/Mupen64Plus-AE/misc/mockup_ui.png)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on November 25, 2014, 06:53:06 AM
Ah right.  I really like that design, good use of screenshots and cover art.

I can't remember if you mentioned it, but we can make the player go straight from Gallery -> GameActivity if they press a screenshot tile (i.e. skip Play menu), and go from Gallery -> PlayMenuActivity if they press a cover-art tile.  The activities are already setup to allow that.

Edit: How many rows were you thinking?  I imagine "Resume Playing" "Favorite Games" and "All Games" would be sufficient.

Another idea that just occurred to me would be to make a tile for each of the entries that are currently in the menu at the top.  And then remove the menu.  E.g. one tile for global settings, one for emulation profiles manager, one for touch profiles, etc.  Maybe one for refreshing rom list.  There would be room in the tiles to add summary text (e.g. short help or summary of selected options).  Naturally this would be the bottom row, but would end up being the first thing you see on fresh install by virtue of the other rows being empty (which we could hide in that case).
Title: Re: Brainstorming Version 3.0
Post by: Paul on November 25, 2014, 07:48:42 AM
How many rows were you thinking?  I imagine "Resume Playing" "Favorite Games" and "All Games" would be sufficient.

Initially there would be no games, until the user searches their device for new ROMs.  Once ROMs are found, there would be one carousel for "All Games".  As auto-saves are generated, another carousel for "Resume Playing" would appear.  Using some rules which we'll have to come up with, a third carousel for "Favorites" would eventually appear.  And finally, I plan to create an interface where the user can define their own playlists (and maybe share them.. would have to handle the fact that recipients won't necessarily have all the ROMs)

Further down the road (3.something), I would like to write further logic into the "Favorites" calculations, which could generate a fourth carousel of "Other games you might like", which would behave differently, in that clicking an item would provide general information about a game the user does not yet own.



Another idea that just occurred to me would be to make a tile for each of the entries that are currently in the menu at the top.  And then remove the menu.  E.g. one tile for global settings, one for emulation profiles manager, one for touch profiles, etc.  Maybe one for refreshing rom list.  There would be room in the tiles to add summary text (e.g. short help or summary of selected options).  Naturally this would be the bottom row, but would end up being the first thing you see on fresh install by virtue of the other rows being empty (which we could hide in that case).

Yes, that is an excellent idea as well.  Name of that carousel would be "Menu" or "Settings" or something like that.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on November 25, 2014, 08:19:03 AM
Using some rules which we'll have to come up with, a third carousel for "Favorites" would eventually appear.
Long press on a tile to star/unstar is one idea.  Or long-press to bring up a context menu with other stuff too.  Although a long-press interface suffers from not being obvious, so it might be a bad idea.

Further down the road (3.something) ... generate a fourth carousel of "Other games you might like", which would behave differently, in that clicking an item would provide general information about a game the user does not yet own.

Ambitious.  That's all you :D
Title: Re: Brainstorming Version 3.0
Post by: Paul on November 25, 2014, 09:17:54 AM
Ambitious.  That's all you :D

Haha, yes that is a long-term goal.  I've been planning this UI for a very long time (since before the emulator even ran).  Original plan was to create it as a separate proprietary paid-for front-end that user would install on top of the emulator.  Since then I've drank more of the open-source Coolaid ;D
Title: Re: Brainstorming Version 3.0
Post by: Paul on November 25, 2014, 12:30:42 PM
Long press on a tile to star/unstar is one idea.  Or long-press to bring up a context menu with other stuff too.  Although a long-press interface suffers from not being obvious, so it might be a bad idea.

This might not be too bad of an idea, as long as we don't put anything super-important into the context menu (user should be able to happily use the app without ever knowing about the context menu).  In this case, they would basically just not have a Favorites carousel until they figured out they can long-press.

We could also have a header row in the layout above the very top carousel, which simply says "Long-press an item for more options".  (technically this would be page 0 in the vertical pager, but can simply contain a text view instead of a carousel view)
Title: Re: Brainstorming Version 3.0
Post by: retroben on November 25, 2014, 01:47:26 PM
The resuming screenshots are pretty nice.

Sorry to be a bit hateful and harsh,but...

Using 3G or 4G+downloading cover art=costing $$$ money.
Same goes for the "you also might like" for both downloading and precious storage.

Will there be an option for a more simplistic UI with more freedom of control and customizations?
Like many others,I care way more about functionality,stability,and control than what I do for a "prettyface" interface.

Using pictures of cover art and other colorful details take up RAM,and cover art takes precious storage space on devices limited to 5GB of an 8GB storage that can't directly access external storage.
Title: Re: Brainstorming Version 3.0
Post by: Paul on November 25, 2014, 02:13:16 PM
Using 3G or 4G+downloading cover art=costing $$$ money.
Using pictures of cover art and other colorful details take up RAM,and cover art takes precious storage space on devices limited to 5GB of an 8GB storage that can't directly access external storage.

Coverart images are around 100 KB each. Entire library is 408 images, totaling just over 40 MB.  I don't think that's going to bother anyone..

WRT RAM, the point of a paging controller is that it doesn't need to hold onto more pages than are currently visible plus a few "look ahead" pages.  We could even make the "look ahead" configurable in the settings if user is concerned about RAM usage.


Like many others,I care way more about functionality,stability,and control than what I do for a "prettyface" interface.

Everyone has different skill sets which makes them suited for working on different components of the project (that's the beauty of open-source).  Personnally, I suck at GLES and assembly language, so the front-end is a better fit for me.  Just because I am working on UI components, doesn't mean Gonetz stops working on GlideN64, or Gilles stops working on the dynarec, or Richard and team stop working on the core.  Overall progress continues on, regardless of what any one person is doing (or not doing) at a given time.  It might not be as fast as some would like, but it is always improving.
Title: Re: Brainstorming Version 3.0
Post by: Zaneris on November 26, 2014, 12:10:13 PM
Using pictures of cover art and other colorful details take up RAM,and cover art takes precious storage space on devices limited to 5GB of an 8GB storage that can't directly access external storage.

The only android version that can't access external SD cards is kit kat, and that is easily fixed by rooting the device.
Title: Re: Brainstorming Version 3.0
Post by: Paul on November 26, 2014, 12:58:26 PM
Even if rooting isn't an option, we are talking about at most 40 MB of space for cover art (and that would only happen if user owns all 408 ROMs that have cover art... with ROMs ranging from 4 MB - 64 MB each, what's an extra 40 MB in that case?)  I really think this is a non-issue.
Title: Re: Brainstorming Version 3.0
Post by: retroben on November 27, 2014, 02:48:13 PM
I have an answer about the Gameshark issue for you Paul.

N64oid works fine with the codes that have button activators,and it is based on the same Mupen that yours is based on,thus meaning that yours is specifically having this issue from the looks of it.

Does Ari (or anyone else) know anything about N64oid's cheat system?
Can it be imported to Mupen64Plus AE or duplicated partially?

N64oid does activators correctly while Mupen64Plus AE refuses to respond with most of them.
I really need this problem fixed (please) because of several extra reasons.
N64oid can't run Banjo-Tooie worth a crap since it freezes really early.
N64oid also can't run Majora that well either since it freezes randomly,frustratingly killing all of my progress.
N64oid does not have a cheat editor for easily adding new codes,it does not even have access to the real list!
Finally,I really love Mupen64Plus AE for what it CAN "currently" do (especially now DK64 and Banjo-Tooie with Gillou's fixes),but the Gameshark activator issue takes a lot of the joy out of it since practically hundreds of my codes are completely useless.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on November 27, 2014, 03:37:24 PM
Keep whining and <expletive> and insulting all the devs.  Surely acting like an <expletive> long enough will yield the results you seek.

I for one don't give two <explitive> about cheats.  You can only enjoy these games if you cheat?  Lame.
Title: Re: Brainstorming Version 3.0
Post by: retroben on November 27, 2014, 03:50:39 PM
 >:(
I AM NOT WHINING AND BITCHING ABOUT IT!!!
Nobody can directly tell the mood of someone in mere text alone.
Almost all of my cheats are for after people complete the game.

Quote
I really love Mupen64Plus AE

Here is a testable code.

Jump To Fly (D-pad up/down)
D0081084 0008
8008D3CD 00E0
D0081084 0004
8008D3CD 00C0

It does not respond to the button normally.
However,if you hold and/or mash D-pad up before the game boots,it will let you fly when jumping in Jinjo Village.
It will now refuse to let you turn it off with D-pad Down,which kinda sucks since many will want it to be a choice.
No further bashing intended,but PJ64 responds in real-time for enabling and disabling the same code.
Maybe some of the better Gameshark handling is missing in Mupen64Plus AE?

Edit:It has to be a difference with the handling since all of the sound glitching codes for SM64 refuse to work at all.
And I really wanted to hear that farty sounding Mario again from the "robotic sounds" code. :(
Title: Re: Brainstorming Version 3.0
Post by: retroben on November 27, 2014, 04:16:34 PM
YES!!!!!  ;D

I found out the issue!  :)

It is something to do with the Recompiler itself,and N64oid also can't use the fly code properly.

I swithced to Pure Interpreter,and the code toggled properly to enable and disable the Jump to Fly ability.

So...I kindly ask you,and I beg of you...
Gillou,Could you PLEASE look into this issue and attempt to fix it?
Now we know it has always been the Recompiler's issue since Pure Interpreter can do it correctly.

Edit:It is actually address reading and writing issues.
The address location does not allow changes to work after the game is booted.
Could it perhaps be the "protect memory" function halting access,or some other setting?
Cached Interpreter also refuses to let the code work with activators.
Again,no bashing intended,but the code works realtime in PJ64 with Recompiler obviously,and it is still really fast despite the extra accuracy adopted from interpreter.
Title: Re: Brainstorming Version 3.0
Post by: retroben on November 27, 2014, 08:45:47 PM
Sorry about the triple post...

I have an example code for Super Mario 64.

Scratchy Sound
80315A66 0000
Warning:Pretty loud,start at lowest volume and use earbuds/headphones in hand.

Try this code in Recompiler,and nothing happens.
Then try it in Pure Interpreter to hear the sound become really scratchy as it is supposed to be with the code enabled.

So now,even some individual codes without activators will refuse to function on the Recompiler while Pure Interpreter enables them correctly.
The huge proof is even if you use an activator like D-pad Up "D033AFA0 0008" when on Pure Interpreter during gameplay,you can still activate the scratchy sounds while in-game.
And if I had the default value,I could possibly toggle it back to normal.

Edit:More testing done.

Scratchy Sound (D-pad Directions)
D033AFA0 0008
80315A66 00FF
D033AFA0 0004
80315A66 0000
D033AFA0 0002
80315A66 0080
D033AFA0 0001
80315A66 0024
Up sounds normal,then down,left,and right have scratchy sound.
This one successfully changes in real-time on Pure Interpreter with D-pad Up returning sound to normal and other three directions making it scratchy again.
Not working at all in the Recompiler.

I apologize for my reluctant stupidity about N64oid's source code being false,and for any and all of my harshness throughout my time here.

Have a Happy Thanksgiving!  :)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on November 30, 2014, 08:36:25 PM
>:(
I AM NOT WHINING AND $*(#$% ^ ABOUT IT!!!
Nobody can directly tell the mood of someone in mere text alone.

Sorry retroben for the misunderstanding.  Sometimes when I read posts all I can hear is complaints and it bugs me since we all do this as a hobby in our scarce free time.

BTW You seem to know an awful lot about the N64 emulation landscape.  If you were able to build mupen64plus-ae from source, you might be able to tighten the iterations with other devs and get some of your features sooner rather than later.
Title: Re: Brainstorming Version 3.0
Post by: Paul on November 30, 2014, 09:01:52 PM
BTW You seem to know an awful lot about the N64 emulation landscape.  If you were able to build mupen64plus-ae from source, you might be able to tighten the iterations with other devs and get some of your features sooner rather than later.

Agreed.. you should work on developing your programming skills, so you can work on some of the features you are looking for.
Title: Re: Brainstorming Version 3.0
Post by: Paul on December 04, 2014, 08:30:43 PM
Getting back to 3.0 stuff now that 2.5.0 is pretty much ready to go (unless anything new is found with RC3, of course).  The bounties I posted on Stack Overflow have paid off, and I have a good variety of different perspectives on the UI mechanics (should be able to cherry pick the best concepts at this point).  I'll post another demo when I get it working well.  I will need to see how the different options adapt to various screen sizes.  I can use emulated devices for that.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on December 04, 2014, 08:38:47 PM
3.X ideas:
If compiling Moga with Lollipop is fixed, we should consider giving GB & Froyo users the modern UI. ActionBarCompat in appcompat-v7 is the way to go for older devices if we decide to do that (I'm switching to that from ActionBarSherlock since it's actually viable now)

In terms of the cheat editor, I'd really like the buttons to be actionbar based on 4.X or above at least. Also, when a new cheat is added, I believe popping up the editor dialog immediately rather than forcing the user to scroll to the new one is a good idea. (might add something to prevent the list from rescrolling when the new cheat is added too)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 04, 2014, 08:50:14 PM
Thanks xperia.  I have not looked into the appcompat libraries in detail but if it's not too difficult then it's worth exploring in my opinion.  If it simplifies maintenance in other areas (like removing some of the if AppData.IS_GINGERBREAD clauses) then it could pay for itself.  I'm not entirely sure what you're describing about version 4.x (mupen or android version?) but posting a demo branch would probably be the easiest way to illustrate your point.

As always, I'm happy with you leading all cheats-related features.
Title: Re: Brainstorming Version 3.0
Post by: Paul on December 04, 2014, 08:50:54 PM
Ok, so for that we would need to bump the min sdk version to 7, correct?  I think now it is set at 5.. although to be honest, not sure GLES2 is available on devices with 2.0.x Eclair.. would only be useful to keep it at 5 if we were to add a GLES1 video plugin.

Anyone else see a problem with making the min sdk version 7? (Android 2.1.x "Eclair MR1")
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 04, 2014, 08:55:40 PM
I forgot that we even supported Eclair.  I usually only think as far back as Gingerbread, perhaps because that's the oldest device I still test with (xperia Play).

It would be hard for an Eclair user to see these stats and still expect support:
https://developer.android.com/about/dashboards/index.html?utm_source=ausdroid.net

Edit: Haha notice that Honeycomb isn't even on the list.  The black sheep of the Android family. :P
Title: Re: Brainstorming Version 3.0
Post by: Paul on December 04, 2014, 09:00:40 PM
Yeh, originally my thought was to keep everything basic and support as many devices as possible, and then folks would build front-end apps to control the emulator and custom plugins for different devices.  That never really materialized though (turned out everyone just wanted to post exact clones.. only new development seemed to go into advertisement framework integrations..)  Now that we are looking at making a really nice UI, some of those original decisions can be re-thought.
Title: Re: Brainstorming Version 3.0
Post by: retroben on December 04, 2014, 09:01:52 PM
And yet HoneyComb was vital for the existance of hardware acceleration in Android.
Too bad it got a bad reputation because of the GTV flop.

Wished the Mudlord 6.1.4 version of Rice got ported since it is the fastest version I ever used.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on December 04, 2014, 09:12:07 PM
I'm not entirely sure what you're describing about version 4.x (mupen or android version?) but posting a demo branch would probably be the easiest way to illustrate your point.
Android version, whatever version they first added a proper ActionBar in. Pretty much just move the buttons in the cheat editor above the cheatlist to an AB and overflow menu if needed.

And yeah, it needs to be 2.1 eclair/sdk 7.

BTW, according to GPlay, I have 113  current eclair users.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 04, 2014, 09:28:02 PM
Pretty much just move the buttons in the cheat editor above the cheatlist to an AB and overflow menu if needed.

Fine by me if you're willing to tackle it.  :D
Title: Re: Brainstorming Version 3.0
Post by: Paul on December 05, 2014, 08:08:37 AM
Woah, nice job on cleaning up the graph, littleguy!

(http://www.paulscode.com/source/Mupen64Plus-AE/misc/squashed.png)
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 05, 2014, 08:10:17 AM
Thanks, I feel like I can breathe again! :D
Title: Split Testing 2.5.0
Post by: Paul on December 05, 2014, 11:14:55 AM
Auto still doesn't work for flicker reduction on the S5 and needs to be manually set to O-2.

That reminds me, I think on master we should change the default polygon offset settings to the ones in the O2 profile.  The current default was correct for the majority of devices in the past, but for a year or so, it seems like the majority of new devices are matching the values in the O2 profile.
Title: Re: Split Testing 2.5.0
Post by: littleguy on December 05, 2014, 11:49:07 AM
Haha you said it almost exactly the same way back then:
https://github.com/mupen64plus-ae/mupen64plus-ae/commit/921baccc45882be9093d014e6b7760acd865bfb5
Title: Re: Split Testing 2.5.0
Post by: Paul on December 05, 2014, 12:17:02 PM
Haha you said it almost exactly the same way back then:
https://github.com/mupen64plus-ae/mupen64plus-ae/commit/921baccc45882be9093d014e6b7760acd865bfb5

Oops.. sorry should have looked before I posted  :-[
Title: Split Testing 2.5.0
Post by: littleguy on December 05, 2014, 02:21:34 PM
I will post a modified form of my example gallery tonight or tomorrow.  The current one doesn't scale well to some devices, and there are a few nits to fix.
Title: Re: Split Testing 2.5.0
Post by: Zaneris on December 05, 2014, 02:56:07 PM
I know there's plenty of cover art databases, but due to the limited number of the most commonly played N64 games, I think hosting it on this server and then having the device cache the image would be the best option.

Building the entire cover art database into the app itself would be the second best, but you're probably looking at a few extra MB in that case and the majority only have a few games.

I could always lend a hand, I'm useless for core related stuff but have a strong coding background otherwise.
Title: Re: Split Testing 2.5.0
Post by: littleguy on December 05, 2014, 03:26:36 PM
Actually, the cover-art caching is already implemented in master :D  It downloads the cover-art from this server and saves it to the user's device.  The app uses the cached images from then on.  The user can refresh the cover-art by refreshing the ROM list.
Title: Re: Split Testing 2.5.0
Post by: Zaneris on December 05, 2014, 03:41:34 PM
Actually, the cover-art caching is already implemented in master :D  It downloads the cover-art from this server and saves it to the user's device.  The app uses the cached images from then on.  The user can refresh the cover-art by refreshing the ROM list.
Hey, thanks for the offer to help.  If you don't mind, maybe you could try your hand at implementing a coverart caching system (basically a way to download the art when it is needed, and store on the user's device for quick lookup later).

Looks like littleguy is on the ball, lol. I'll clone the source tomorrow anyway and start getting familiar with the code.
Title: Re: Split Testing 2.5.0
Post by: littleguy on December 05, 2014, 03:43:04 PM
Awesome Zaneris.  Always great to get more devs involved :)
Title: Re: Split Testing 2.5.0
Post by: Paul on December 05, 2014, 04:05:54 PM
Yes littleguy is definitely on the ball.  I haven't gotten to the point of integrating the mechanics of the UI with the rest of what is on master (besides having been inactive on the project for a year).
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 05, 2014, 05:31:02 PM
Looks like we are going to start alpha testing soon.  "Alpha testing" means that the code may be very buggy and features may be missing.

With that in mind, I'd like to propose a few things.  Partly for the sake of alpha testing and partly for the sake of version 3 goals.

The folder restructuring would group the pertinent user data by game.  Each ROM with a unique MD5 would get its own folder.  The folder name would include the goodname for readability and the MD5 for bombproofness.  Screenshots would be taken whenever an Auto/Slot/User save is made, and would reside in the same folder as the savefile.  AutoSaves directory would contain a user-configurable FIFO of time-stamped autosaves.  Coverart would reside in the root of the game's folder (easy for user to find).  If the Rom was unzipped by the app, it would be saved in the game folder.

I'd like to get this kind of stuff sorted out before we start posting alpha releases to testers, because it will be harder to change later.

Thoughts?  If I get the go-ahead, I'll submit a pull request so everyone can see it before merging to master.
   
Title: Re: Split Testing 2.5.0
Post by: retroben on December 05, 2014, 05:40:29 PM
Just thought of something,can you handle the bandwidth and cost of a million people downloading the coverart.
What about those of us concerned about RAM/cache usage including myself that wanna squeeze out as much RAM as possible?
My tablet has only 1GB of RAM to work with.

Can there be an option to never download and cache coverart at all,or to stop the use of it to conserve cache?
You could make a default image for them,and use the same image for unrecognized games.

My tablet is charged,got anything specific for me to try?
I might try both Zelda games myself to see how well they can run on it.
Title: Re: Split Testing 2.5.0
Post by: littleguy on December 05, 2014, 06:00:05 PM
Yes, it would seem natural to include a setting to skip cover art.  And yes, there is a default image already for unknown games, which we could use if the user skipped cover art.  TBH I'm not sure how much RAM it would actually save but there might be enough outcry to make the facts irrelevant.  Perceptions trump facts sometimes.

I too would like to be sure that the server can handle it.  Again, the user would only hit the server when they refreshed their list, which wouldn't be that often (after install and whenever they add/remove ROMS from their device), but still it would be good to get a guesstimate on load.
Title: Re: Split Testing 2.5.0
Post by: Paul on December 05, 2014, 06:08:45 PM
I too would like to be sure that the server can handle it.

I can always upgrade my hosting plan if the traffic increase becomes a problem.  I currently don't get anywhere close to the limit. I prefer to host the default coverart images myself.
Title: Re: Brainstorming Version 3.0
Post by: Paul on December 05, 2014, 06:25:01 PM
Looks like we are going to start alpha testing soon.  "Alpha testing" means that the code may be very buggy and features may be missing.

With that in mind, I'd like to propose a few things.  Partly for the sake of alpha testing and partly for the sake of version 3 goals.

--list removed from quote for brevity--

The folder restructuring would group the pertinent user data by game.  Each ROM with a unique MD5 would get its own folder.  The folder name would include the goodname for readability and the MD5 for bombproofness.  Screenshots would be taken whenever an Auto/Slot/User save is made, and would reside in the same folder as the savefile.  AutoSaves directory would contain a user-configurable FIFO of time-stamped autosaves.  Coverart would reside in the root of the game's folder (easy for user to find).  If the Rom was unzipped by the app, it would be saved in the game folder.

I'd like to get this kind of stuff sorted out before we start posting alpha releases to testers, because it will be harder to change later.

Thoughts?  If I get the go-ahead, I'll submit a pull request so everyone can see it before merging to master.
   


I agree on all points.  Should keep everything organized, and helps to debug the data migration component (running it won't require re-installing the old app if something went wrong during the test and needed to be re-run several times to debug).
Title: Re: Split Testing 2.5.0
Post by: Paul on December 05, 2014, 06:29:01 PM
I too would like to be sure that the server can handle it.  Again, the user would only hit the server when they refreshed their list, which wouldn't be that often (after install and whenever they add/remove ROMS from their device), but still it would be good to get a guesstimate on load.

For getting a guestimate, maybe I should write a web service that the app calls once upon upgrading, reporting the timestamp and the number of ROMs the user has?  That would be a good indicator of what load the server would need to handle over time.
Title: Moved from "Testing 2.5.0" thread
Post by: Paul on December 05, 2014, 06:29:37 PM
I'm going to move a bunch of these posts over to the 3.0 thread..
Title: Re: Brainstorming Version 3.0
Post by: retroben on December 06, 2014, 02:18:42 AM
Two regressions found in RC3.

The Zelda OOT pause menu is slow to open on Glide64 while slick and fast on the 2.4.4 version also using Glide64.
Glide64 is also frequently giving me atari textures while the 2.4.4 version only did it once when switched from Rice.

Something within the GFX Plugin initializing process must be terribly botched.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 09, 2014, 09:59:17 PM
I think I need to make a slight change to the game data directories.  Instead of naming them
   <GoodName>_<ComputedMD5>
I'd rather name them
   <HeaderName>_<ComputedMD5>

Two reasons:
 1. The name in the header is immutable.  No worries about the name changing later (especially relevant if we allow the user to change the goodname for unknown roms).
 2. You don't need the heavyweight RomDatabase to get the name.  Just need a lightweight RomHeader (or path to ROM).  Fewer interdependencies.

Remember the name info is just to make it easier for the user to sift through their game data (the app would still work fine if we just used MD5's for directory names).  So if the header name is "CBFD" instead of "Conker's Bad Fur Day", it's probably not the end of the world.

Before I implement this, was wondering if I should add any other elements.  Perhaps the country code (or string representation) and release to the directory name as well, something like
    <HeaderName>_<HeaderCountry>_<HeaderRelease>_<ComputedMD5>

Other fields are clockrate, pc (?), release, crc, manufacturerId, cartridgeId.  Any reason to clutter it up with those?
Title: Re: Brainstorming Version 3.0
Post by: Paul on December 22, 2014, 11:42:27 AM
Just wanted to post this here, so it doesn't get lost in the shout box.  Things are slow from my end due to the holidays (had my wife's family visiting last week, and this week we are visiting my family).  We'll be getting back home next Monday, and I am anxious to get back to work on the 3.0 front-end.  Don't want anyone to think I have dropped off the radar again.

Also, Littleguy deserves a lot of recognition for putting an enormous amount of work into the project (just take a look at the commit history on github!)  If anyone has good ideas for recognizing his leadership in the project more prominently than his current listing in the credits, let me know.  This project would likely have lost steam and died long ago without him.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on December 27, 2014, 09:31:25 PM
Another random thought:
When connected to a TV with HDMI, maybe have an option to display only the video on the TV and not the virtual controls while using the phone/tablet as a controller.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 27, 2014, 10:04:50 PM
Any idea what Android APIs we'd need to use?
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on December 27, 2014, 10:17:18 PM
This is the API: http://developer.android.com/reference/android/app/Presentation.html

EmuExPlusAlpha uses this (although the JNI isn't helpful):
https://github.com/Rakashazi/emu-ex-plus-alpha/blob/master/imagine/src/base/android/java/sdk-9/imagine/PresentationHelper.java
https://github.com/Rakashazi/emu-ex-plus-alpha/blob/master/imagine/src/base/android/AndroidScreen.cc
https://github.com/Rakashazi/emu-ex-plus-alpha/blob/master/imagine/src/base/android/AndroidWindow.cc

There are probably better tutorials on how to do this, but the gist I get is you get a list of the displays and create the GameSurface on one of those displays.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 28, 2014, 08:45:29 AM
I wonder if this requires a particular casting technology? MHL, Miracast, Slimport.  I'm not up to speed on all the differences.  I think my Kindle HD6 uses slimport, so I have at least one device to test with.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on December 28, 2014, 09:57:33 AM
I know that Slimport and pure mini-hdmi out behave the same, and I'd assume MHL would too, assuming it's on 4.2+.
Not entirely sure about miracast.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on December 30, 2014, 03:00:38 PM
I ordered a $10 slimport adapter to give it a try.  Might be awhile before I get to it though.

On another note, I noticed that Google's cloud save API has been overhauled, I assume to give it more features/capability.  Might want to revisit the cloud save idea, maybe to save SRAM data or even auto/manual saves.  Perhaps not in 3.0, but maybe a later minor release.
https://developers.google.com/games/services/android/savedgames
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on February 25, 2015, 02:15:54 PM
So what's left before 3.0 can be pushed out the door? I have to admit I only started using the alphas fairly recently, but other than a few minor bugs it seemed like it was a finished product. Considering Paul and littleguy have both been very busy recently, and considering how much better the current alpha is compared to the final version on the Play Store, it really seems like more new features and tweaks can wait for a minor release!
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 25, 2015, 02:48:30 PM
The biggest obstacle to publishing is that we still need a 100% bombproof implementation for migrating user data from version 2 to version 3.  It should have a backup capability, and ideally a way to migrate back to 2.x for testers and users who simply don't like the new version after giving it a try.  Keep in mind that we reduce the number in the latter camp the more polished the v3 UI is on release day.  In order of priority for data migration:
 - SRAM saves (aka "in-game") saves
 - Manual (aka User) saves
 - Slot saves
 - Auto-saves

User preferences should probably be discarded going from v2 to v3 since so much has changed.  (Many preferences don't map between versions anyhow.)

The main polish to add is a new gallery screen.  The current one is just a bare-bones stand-in, and not necessarily something that the code should even evolve from.  A well-done gallery screen would allow you to bypass the Play menu and jump straight from GalleryActivity to GameActivity (though the Play menu or similar should still be available to host game-specific settings).  It would include screenshots and feature favorites or recently played games at the top. See previous posts in this thread.

Other features that could probably wait, but are still preferable to get in before publish
 - Timestamped autosaves, with the ability to retain last X number of saves, and UI for loading an older autosave
 - UI that is fully tested on non-touchscreen devices (e.g. OUYA, Android TV)
 - Make final decisions on which settings are global and which are per-game (e.g. display options)

Features that can wait for minor releases are
 - Cloud save for in-game saves, possibly other saves as well (will require careful implementation)
 - Allow custom touchscreen skins (shouldn't be too hard)
 - UI for meta info entry if ROM not found in database
 - Simpler UI for controller->player mapping
 - UI for high-res texture extraction

Those are the big ones off the top of my head.  There are also a fair number of outstanding bugs.
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on February 25, 2015, 04:24:24 PM
Hm, I could have sworn my SRAM and autosaves were imported correctly, although I did have to tell the app to look in the old Mupen64 folder rather than the new Alpha one it created for itself.
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on February 25, 2015, 04:39:37 PM
Is Paul actually working on it, or was it just something he planned on doing? The new gallery design is perfect for the Android Cards UI, where you tap the card to go straight to auto-resume, or tap the "..." overflow menu for whatever else.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 25, 2015, 04:49:29 PM
I haven't heard from Paul lately.  If you know your way around Android UI design, especially the modern designs, then I say start a branch and take a crack at it.  I agree the cards thing sounds like a good fit.

One caveat is that we would prefer to support older devices, and don't want to make separate GUIs for different Android versions.  Currently we support all the way back to SDK 5.  If that's simply not feasible, then we should discuss and find a balance.  I hate to be held back by obsolete devices, but I also wouldn't want to lose users just for eye candy.
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on February 25, 2015, 07:11:06 PM
CardView uses "API level 7", which is still Android Eclair (albeit version 2.1 instead of 2.0). Should be trivial to roll a view subclass if needed, it's not like I haven't done that before (http://ivideoapp.com).
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 25, 2015, 07:19:43 PM
I personally wouldn't oppose bumping the requirement to SDK 7 or even 9 (the oft-requested Xperia Play device runs 9 - Gingerbread).  The overall eclair user base is very small by this point, at least in the general Android user population.
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on February 25, 2015, 07:49:31 PM
Alright, if we allow a bump to 2.1 Eclair from 2.0 using the v7 AppCompat library, that means we'd also get universal support for the ActionBar. I noticed there's a lot of isActionBarAvailable code branches in there right now.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 25, 2015, 09:11:38 PM
I also support bumping the requirement to 2.1.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 25, 2015, 09:45:35 PM
Yes, we've already informally agreed to start using appcompat-v7 for the actionbar thing.  Just haven't started using it yet.  So appcompat-v7 should be fine if you want to start using it.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on February 25, 2015, 10:01:00 PM
Now the question is, do we want older devices to have the newer GUI? Because I can try to transition old devices to the new GUI with an actionbar. Last time I checked on my xplay, the old, barebones GUI was used.
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on February 26, 2015, 05:44:33 PM
Quote
Now the question is, do we want older devices to have the newer GUI?

Of course, that's why Google introduced the AppCompat library. They brought Material design to ancient versions of Android.
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on February 26, 2015, 05:45:54 PM
Don't worry about updating the ActionBar stuff, I'll take care of that as part of the new UI.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on February 26, 2015, 05:53:48 PM
That sounds great.  I can start on the data migration stuff then.  There are some subtleties there and I can probably recycle some code from FilePwn to lighten the burden.
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on March 01, 2015, 03:54:47 PM
Hey so what exactly did you mean about the gallery view not being in a state to build upon in future versions? Only thing I can figure is that since a search field feature was requested, that means we're expecting some people to have a ton of ROMs in their list, which in the current design means it'd attempt to load some 800 bitmaps into memory at the same time. Is that what you were referring to?

If so, we'll need to switch to a RecyclerView and a GridLayoutManager, and load and unload thumbnails as the user scrolls through the list. I have this up and running already in my local branch (not committed), but GridLayoutManager is strangely much less feature-filled than the GridView it seems to replace. In particular I can't find options for controlling the horizontal and vertical view spacing, which means every item in the grid needs to be placed in a container view that handles the padding/spacing there.

I also ran into some issues with switching over to the support library and am going to start over clean with what I learned over the past few days. Problem is that you must subclass from ActionBarActivity to use the ActionBar or Toolbar class, but that's impossible when something is already subclassing from PreferenceActivity, ListActivity, and NativeActivity. My original solution turned into a mess of view hierarchy hacks that need unique code branches for each version of Android, so I'm going to redo that using Fragments instead.

I think it's worth the trouble, though, as it gives you those fancy search fields that are integrated directly into the toolbar and work much better than the older Android search fields. It also gives you support for navigation drawers, where they slide out from the left side and the menu icon animates into a back arrow. Basically it just seems like it will be necessary as the project evolves in the future.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on March 01, 2015, 05:08:50 PM
The current GalleryActivity is a proof-of-concept for working with the game data and other backend machinery.  But it shouldn't inhibit the ultimate design.  As you say, there are various pros and cons to subclassing different built-in android classes, and those should be explored freely.  My guess is that the best gallery implementation will evolve largely from the ground up after taking account of the overarching design goals and requirements.

I know memory management for the loaded bitmaps could be important, and the current stand-in does nothing about that.  I don't know all the options available, but I have heard RecyclerView mentioned more than once on these forums, as a possible starting point.

Deriving from PreferenceActivity is handy and streamlines development for certain types of UIs like SettingsGlobalActivity, which don't need to be fancy but should be easy to maintain and extend.  A version 3 GalleryActivity doesn't seem like a good fit for subclassing PreferenceActivity, so I certainly would not let that constrain you.  The NativeActivity is only subclassed for the Xperia Play variant of the GameActivity, since that is the only way to access that device's touchpad input.  I don't see any need to change anything in the GameActivity, at least for the time being.  The nice thing about the current design is that the activities are well decoupled, so the GalleryActivity can be developed in pretty much complete isolation.  So I say focus on a new GalleryActiivity.

The PlayMenuActivity is also not set in stone, and should be seen as subordinate to the design of the GalleryActivity.  I.e. PlayMenuActivity currently provides complementary game-specific functionality not found in the current GalleryActivity.  Feel free to move functionality between PlayMenuActivity and GalleryActivity, as you ponder the best design for GalleryActivity.
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on March 03, 2015, 12:22:51 AM
My bad, I thought we were updating the ActionBar stuff as part of the new UI commit (see: previous post) so I switched the global application theme over to AppCompat and started updating the existing Activities. The new commit only sets the AppCompat theme for GalleryActivity and leaves everything else alone.

Code: [Select]
super.setTheme( android.support.v7.appcompat.R.style.Theme_AppCompat );
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on March 03, 2015, 03:17:35 AM
Alright, the changes are all implemented. Added a search field and switched to RecyclerView so only the visible thumbnails will be loaded into memory rather than all of them. The ... next to each thumbnail is a stub for now, since I don't know what you want to put in the contextual menu. Tapping a thumbnail still takes you to the options menu instead of directly to gameplay. Also haven't implemented the "Recently played" section yet.

https://github.com/mupen64plus-ae/mupen64plus-ae/tree/New-Gallery-UI
Title: Re: Brainstorming Version 3.0
Post by: littleguy on March 03, 2015, 06:57:46 AM
Thanks, keep up the great progress!

Just to clarify, I don't object to updating the GameActivity as well -- my point was just that GalleryActivity and GameActivity are almost completely independent, so they can be done in isolation.  GameActivity is also a little thornier since it has to deal with native code and lots of subtle lifecycle gotchas.  My suggestion is just to focus on one thing at a time rather than getting spread too thin.

I'll take a look at the new stuff now!
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on March 03, 2015, 04:09:58 PM
IIRC I was updating pretty much everything except GameActivity. Maybe I updated that too, I forget. But yeah I agree there were too many changes being made. I was mostly experimenting with a bunch of changes, but the changes to Toolbar across the entire codebase were meant to be a single commit.

Probably goes without saying, but feel free to make any changes you want to the New-Gallery-UI branch. I'm not going to submit it as a PR until it's a 100% replacement for the old gallery view, which right now it would be if not for the nonfunctional ... views next to each thumbnail.
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on March 03, 2015, 06:26:24 PM
Ended up implementing the contextual menu and the functionality for going directly to gameplay. For some reason sometimes after exiting the game it immediately resumes the game again, while other times it exits correctly. Haven't yet figured out why it does that.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on March 04, 2015, 07:48:23 AM
Holy crap, this new UI is awesome!!!  :o ;D 8)

I am getting a few crashes but shouldn't be too hard to track down.  now that I know how to build with the new appcompat stuff, I can go back and give it a thorough review commit-by-commit.

Keep up the great work!
Title: Re: Brainstorming Version 3.0
Post by: retroben on March 04, 2015, 12:23:58 PM
Is it "context sensitive"?
Sensitive to context?
Do you press B when it tings,makes a ting noise? *ting*
A ting like that...ting noise!

Sorry,couldn't resist. ;D

Can anyone please get screenshots of it?,I wanna know what it looks like.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on March 04, 2015, 04:58:26 PM
(http://i.imgur.com/UYFBDnQ.jpg)

Only complaint I have so far is that it's a bit jerky at times when scrolling. Is it dynamically loading images?
Title: Re: Brainstorming Version 3.0
Post by: littleguy on March 04, 2015, 05:19:23 PM
Yes, it's using the RecyclerView component to cap the RAM usage for the cover art.  So when you scroll the bitmaps are being loaded/unloaded presumably.  This is a standard component so the behavior should be documented somewhere.  There may be some knobs to adjust.
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on March 04, 2015, 05:58:34 PM
Glad you like it! I pretty much scrapped the 2013 mockup since I figured that was back in the wild west days of Android UI design, where they were still looking for their identity. These days you just need to slap in the material theme and you're good to go.

RecyclerView has some configuration options associated with it, but I haven't touched that part at all. You can change how many additional off-screen views to allow before it starts recycling them (resulting in better scrolling performance at the cost of using additional RAM), and ways to tell the view which optimizations it can make. Also you probably noticed there's no scrollbar apparently there's something special you need to do to add support for that, but again haven't looked into it.
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on March 06, 2015, 03:40:01 AM
Here's what the latest version looks like:

(http://i.imgur.com/5ZysI1u.png)

(http://i.imgur.com/2DPj0hO.png)

(http://i.imgur.com/VCFaFFw.png)

(http://i.imgur.com/IBaTAOq.png)
Title: Re: Brainstorming Version 3.0
Post by: Metalmusic3000 on March 06, 2015, 10:06:49 AM
Will this be a part of the next alpha?
Title: Re: Brainstorming Version 3.0
Post by: littleguy on March 06, 2015, 10:15:36 AM
We're working on it, but yes the goal is to have it in one of the next alphas.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on March 07, 2015, 09:09:44 AM
I wonder how many people with FROYO (API 7) will use Version 3?  Would be nice to eliminate the IS_GINGERBREAD (API 9) checks from the code.

It would be really nice to be able to bump to HONEYCOMB_MR2 (API 12), as that would cut way down on the API-specific branch points.  But I'm guessing there are still a sizeable number of GB users out there.
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on March 07, 2015, 10:23:18 AM
With ROM Patcher at least, about 9% of current installs are on Gingerbread or less, which translates to around 900 users.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on March 07, 2015, 11:23:53 AM
Thanks xperia64, that's good to know.

MinSDK is now officially 7 (FROYO) and the appcompat libraries have been pushed to master.

Note to devs:  You will need to import some things into your Eclipse workspace.  Please do step 3 in the new Readme file in the root of the repository (copied here):

Quote
3. Import the Eclipse project and dependencies
    Open Eclipse
    Select File → Import → Android → Existing Android Code Into Workspace, and press Next
    Browse to root of cloned repository, and press OK
    Select all projects, and press Finish
Title: Re: Brainstorming Version 3.0
Post by: littleguy on March 07, 2015, 11:55:25 AM
With ROM Patcher at least, about 9% of current installs are on Gingerbread or less, which translates to around 900 users.

That is consistent with the overall stats as well:
https://developer.android.com/about/dashboards/index.html

The FROYO user base is pretty miniscule at this point but GB is staying strong.
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on March 07, 2015, 10:24:14 PM
Quote
I wonder how many people with FROYO (API 7) will use Version 3?  Would be nice to eliminate the IS_GINGERBREAD (API 9) checks from the code.

It would be really nice to be able to bump to HONEYCOMB_MR2 (API 12), as that would cut way down on the API-specific branch points.  But I'm guessing there are still a sizeable number of GB users out there.

API 7 is Eclair, and incidentally so was API 5. It's just 2.1 Eclair instead of 2.0 Eclair.

I have plans for clearing up a lot of the API checks without having to drop support for anything. A lot of the checks seem to involve full screen mode and the action bar. The action bars can be replaced with the version from the support library, and there's no technical reason we can't use our own fake full-screen mode when immersive mode isn't available. All they do is detect edge swipes and show the status bar, so we can do the same thing.

At some point I also want to replace the (kinda) annoying behavior where the action bar is toggled by overriding the back button, by replacing it with the drawers that slide out from the left. So in immersive mode (whether native or fake) you swipe from the top to show the status bar, swipe from the right (or bottom, depending on the orientation) to show the home/back/task buttons, or swipe from the left for the drawer. And then the back button would actually be a back button.
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on March 07, 2015, 10:45:26 PM
Can we do this for the launch screen?
(http://i.imgur.com/tDNS6M0.png)

Old version, for comparison:
(http://i.imgur.com/VjEg3Zn.png)

It will take a bit more effort than just moving the position of the text field, since that section is also used as an error log when loading the assets, but I could come up with something nice for that.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on March 07, 2015, 11:04:23 PM
I have plans for clearing up a lot of the API checks without having to drop support for anything. A lot of the checks seem to involve full screen mode and the action bar. The action bars can be replaced with the version from the support library, and there's no technical reason we can't use our own fake full-screen mode when immersive mode isn't available. All they do is detect edge swipes and show the status bar, so we can do the same thing.

Yeah it would be nice to eliminate as many API checks as possible.  Does "fake" immersive mode require additional libraries?  I remember looking into that a long time ago and simply couldn't find a way to eliminate the navigation bar at the bottom using vanilla API calls.  It would be a nice-to-have if it's not a lot of work.

At some point I also want to replace the (kinda) annoying behavior where the action bar is toggled by overriding the back button, by replacing it with the drawers that slide out from the left. So in immersive mode (whether native or fake) you swipe from the top to show the status bar, swipe from the right (or bottom, depending on the orientation) to show the home/back/task buttons, or swipe from the left for the drawer. And then the back button would actually be a back button.

As long as the GameActivity is still fully usable without a touchscreen (i.e. with only a gamepad) that would be great.  Many moons ago when we implemented the action bar for that activity, the back-button-toggles-action-bar behavior was the norm IIRC.

Regarding the launch screen, the artwork in both cases was determined by a competition by users on the forum.  The Mario-esque one was for the original 1.x/2.x version.  The simple one was made for the OUYA release (and in fact is substituted if you are running in "big-screen" mode (global settings).  So I would rather defer to Paul since he organized the competitions.
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on March 07, 2015, 11:18:38 PM
The old logo wouldn't have to be removed anyway, it looks quite nice in the About dialog:

(http://i.imgur.com/Z8JXZo1.png)
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on March 07, 2015, 11:21:10 PM
Quote
As long as the GameActivity is still fully usable without a touchscreen (i.e. with only a gamepad) that would be great.

Curious, how does it work right now? Are gamepads expected to have one of their buttons mapped to the Android menu button?
Title: Re: Brainstorming Version 3.0
Post by: littleguy on March 07, 2015, 11:24:59 PM
Curious, how does it work right now? Are gamepads expected to have one of their buttons mapped to the Android menu button?
Yeah, they have to map it in the Controller profile editor screen.  Some of the built-in profiles (e.g. OUYA) map this by default.  It's not ideal, but then again I can't think of a better way...
Title: Re: Brainstorming Version 3.0
Post by: littleguy on March 07, 2015, 11:27:12 PM
And the mario-esque background is ideal for the touchscreen profile editor, since the faint grid makes it clear what the differences are between display zoomed, centered, stretched, cropped.
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on March 07, 2015, 11:34:56 PM
Ah yes, I forgot it was used there. I figured it was there to show you where the gameplay will be, so you can place the controls elsewhere.
Title: Re: Brainstorming Version 3.0
Post by: littleguy on March 07, 2015, 11:39:00 PM
Yes that's the primary purpose.  The grid was pure serendipity that I came to appreciate after the prototype was already built.
Title: Re: Brainstorming Version 3.0
Post by: BonzaiThePenguin on March 09, 2015, 02:08:13 PM
The ActionBar is completely gone in New-Gallery-UI now, but it looks like I won't be able to do anything about the mess that is fullscreen mode. I had no clue Android lacked the option to hide the system bar until KitKat! All of those version-specific flags and settings will have to stay.  :-\
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on June 21, 2015, 09:22:46 PM
I made a new branch that makes sure the xperia-touchpad lib only builds on armv7, and it contains some setup for a dynamic cheat interface (@littleguy I think I'm getting better at this committing thing, but I'll let you be the judge).
Title: Re: Brainstorming Version 3.0
Post by: xperia64 on June 22, 2015, 08:05:06 PM
I implemented the cheat dynamic backend as best I could. See the latest commit of my new branch. I used two separate int arrays instead of 1 2D int array. I added a single cheat and I dynamically toggled that cheat, and both worked. Yet another thing that needs a GUI I guess :P

I've also found that we should be more strict with mandating unique names for cheat codes because the CheatEnabled command takes a cheat name as an argument.

Here is an APK intended for use with Super Mario 64. Open the menu and tap add cheat, and it will apply the cheat I hardcoded. Tap toggle cheat to toggle the added cheat: https://db.tt/zBoGVaa1