Brainstorming Version 3.0

[littleguy]

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).

[littleguy]

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

[xperia64]

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.

[littleguy]

Good idea.

[xperia64]

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.

[Paul]

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.

[littleguy]

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
       - ...

[Paul]

That looks good to me

[littleguy]

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.

[Paul]

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)

[littleguy]

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,

[littleguy]

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

[Paul]

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.

[littleguy]

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

[beansta]

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.