PaulsCode Forum

Mupen64Plus AE => General Discussion => Topic started by: Paul on December 16, 2012, 08:35:02 PM

Title: Finishing up the final pieces
Post by: Paul on December 16, 2012, 08:35:02 PM
As we get closer to having all the main missing pieces filled in and moving on to stress-testing release candidates in the near future, it will probably start becoming more likely for collisions to start happening between developers.  So I thought I would start a thread, where I can post what I'm working on, to avoid stepping on anyones toes.

The next things I'm working on are fixing the remaining bugs with the cheats menu, and then re-implementing hi-res texture pack importing.  I am currently writing a generic "Please Wait" dialog system for threading process that previously just annoyingly blocked the UI thread.  This will take a context, message, and extension of runnable that implements a callback to hook into to know when the process is complete.  I'm making this generic, since it will be useful in a lot of places (for starters, I need it for reading the CRC header to fill the cheats menu, and for extracting hi-res texture packs).
Title: Re: Finishing up the final pieces
Post by: littleguy on December 16, 2012, 09:13:34 PM
Good idea.  Might also be good to make a working list on the OP of major elements that remain.

Besides the bugfixes noted in the other thread, here's what's on the top of my plate, and the default order I plan to tackle them:
 - Finishing up the Assets unpacker so that we can put raw assets in the repo instead of the zip.
 - IMEs (like USB/BT Joystick Center) are not being heard... I know the problem but it's not a one-line fix.
 - True multiplayer support.  This will require the most creativity... a clear and unobtrusive UI is critical since it will have to be called every time the device reboots or a controller is re-plugged and multiplayer is enabled.
 - User pref to hide overlays while touchscreen enabled (for IMEs that map to touch).  Should be straightforward.
 - Special function mapping front-end.

Paul, let me know if you'd like a different prioritization.
Title: Re: Finishing up the final pieces
Post by: Paul on December 16, 2012, 11:46:29 PM
Sounds good to me.  I may begin calling builds "release candidates" before all of your list there is implimented once the most serious issues are fixed, since I'd like to get published -- really what we have now is a lot further than I was with the first GUI implementation when I published version 1.0 (can be very easy to get caught in the trap of wanting everything perfect first and never publishing, like drk has with nulldce)

EDIT: BTW, I won't actually publish until I get the go-ahead from you guys.  If the app is really not ready to go at that point , then just let me know.  There is definitely a difference between important features and necessary functionality.
Title: Re: Finishing up the final pieces
Post by: littleguy on December 17, 2012, 09:05:58 AM
That sounds wise.  If it were only up to me I'd probably be too perfectionist to ever push it out the door.  We'll just need to be clear what functions don't work when we push so people aren't screaming WTF...
Title: Re: Finishing up the final pieces
Post by: Paul on December 17, 2012, 10:30:33 AM
We'll just need to be clear what functions don't work when we push so people aren't screaming WTF...

That's a good point.  When I publish, I'll be sure to clearly lay out what functionality is hooked up, and what is in the process of being re-hooked up (anything missing that was in the 1.x series).  I also think the fact that I'll be labeling it version Beta 2.0, and the GUI being significantly different than 1.9.2 (and from all the other copycats :P), most folks will understand that the app is undergoing a rather large overhaul of the GUI.  There will of course be the 1-stars from the devices where the app runs slower, a game doesn't work as well, or someone was using a customization or feature that isn't available.  And of course there will still be the 1-stars that say something like "Sucks! Dev took months to update and [insert game title here] still runs like crap on my [insert ARM6 device here]!"
Title: Re: Finishing up the final pieces
Post by: littleguy on December 17, 2012, 11:03:56 AM
LOL!  Yeah for some people free just isn't good enough.

Been thinking for a while it would be nice to have a popup whenever the user first launches the app after an update... like seen in a lot of the major apps.  Would show the new features added and the bugs fixed, and any major items still missing/broken.  Seeing popups like "Multiplayer fully supported now" or "Crash on Zelda OOT fixed" would help ensure our hard work doesn't go unnoticed.  Just imagining users getting the popup and saying Sweet!! and racing to try out the new fix.  I do that all the time when I see a new beta available for Apex launcher.

Anyhow, there's probably an API for that, or at least a general pattern for implementing it.  Maybe you already have some ideas.
Title: Re: Finishing up the final pieces
Post by: Paul on December 17, 2012, 11:12:34 AM
That would be a great idea.  I was going to do something like that with the old GUI, but never got around to it.  Definitely wouldn't want it to be a nag-screen though - it should go away permanently after the first run of an update.
Title: Re: Finishing up the final pieces
Post by: littleguy on December 17, 2012, 11:22:40 AM
Absolutely.  A lot of apps do it, and only do it only on the first launch after an update. 
Title: Re: Finishing up the final pieces
Post by: littleguy on December 19, 2012, 11:47:05 AM
I added the menu/preferences for special function mapping.  Now I need to wire it into the core.  Do you recall how the special functions are invoked from Java?  I can't tell if this translation happens in Java or C.

For example, I could just decode the inputs in Java and call functions like NativeMethods.stateSaveEmulator().  However, only a subset of the special functions are accessible through NativeMethods at the moment.

Alternatively, the C code might decode the inputs and respond accordingly (e.g. something like the C function DoCommand IIRC).  I looked at the old code and it looks like a key map is written to the config file... but we moved away from that approach in version 2.

Currently, button and stick signals are decoded in java and AbstractController passes them to the core via NativeMethods.updateVirtualGamePadStates.  So all else equal, maybe for consistency we decode and invoke from Java for the special functions as well.
Title: Re: Finishing up the final pieces
Post by: Paul on December 19, 2012, 12:54:33 PM
Yes, I think that's how to handle this.  They are being updated on key presses, so not sure if it should be individual JNI calls per function, or a single JNI call that passes an array of press states to a handler function on the native side.  Whichever is easier for you to think about is probably fine.  These will be invoking core commands I think rather than hacking the core for a direct rout (unless we find that this slows things down and we need something more direct)
Title: Re: Finishing up the final pieces
Post by: littleguy on December 19, 2012, 01:55:24 PM
Cool.  I'll just handle the keypresses in Java then.  I'll stub out any functions that don't exist yet so it will be obvious what remains.
Title: Re: Finishing up the final pieces
Post by: littleguy on December 20, 2012, 02:08:09 PM
Last night's commit takes care of special function mapping and the front-end for handling the input.  Just need to implement/call the right functions on the back-end.  I noted a weakness in the UI for it in the commit log, but this should be good enough for now I think.
Title: Re: Finishing up the final pieces
Post by: littleguy on December 20, 2012, 11:00:28 PM
Tonight's commit takes care of multiplayer deconfliction and the UI for defining the controller->player mapping.
Title: Re: Finishing up the final pieces
Post by: Paul on December 22, 2012, 01:01:33 AM
Next I'm going to debug the re-broken "Reset" function, and hook up the missing pieces for the mappable core functions.  I could possibly step on your toes for that last one, so let me know if you'd rather take it, and I'll work on something else.
Title: Re: Finishing up the final pieces
Post by: littleguy on December 22, 2012, 07:22:27 AM
No, you won't step on my toes.  I think for the last one you'll just be creating/extending the java->jni methods, and then just calling them from PeripheralController where all the TODOs are.  If any of the switch cases involve more than a few lines of code, it would probably make sense to encapsulate them in CoreInterface or something to keep PeripheralController clean.

For the reset function, if all else fails, a completely front-end solution is just to kick the user back the main menu and delete the auto-save file.  The next time they launch they'll be reset.

I'm working on IME listening now, and I'll probably put in the Hide Overlay preference at some point when I get distracted :P.  The finer polishes after that will be fixing the screen orientation loss of state for all the custom preferences (it doesn't just affect the cheats preference), I think this just requires getting more into the nitty gritty of Android's documentation.

Edit: One more thing for me before publishing to google is an interface to copy the savegames, skins, etc.  Shouldn't be hard, but just wanted to mention it so we don't forget.

Also, I suppose we can clean up the assets folder a bit now that it's uncompressed in git.  Was thinking some of those text files listing all the skins and stuff can be removed.
Title: Re: Finishing up the final pieces
Post by: littleguy on January 02, 2013, 12:21:58 AM
Removed the "Calibrate" button from the mapping screen.  That was a band-aid, is now replaced with a fix that goes to the root of the problem.  There's a small chance it may fix some of the controller-specific mapping issues as well.

Moved special function mapping inside the normal mapping screen.  This makes for a much cleaner and natural implementation from a programming standpoint, though it remains to be seen how user-friendly it is.  I'm open to suggestions.

Did a lot of cleanup to the input map layout resources.  It may look like a distraction from the IME listening bug, but in fact it's all related and will make the bugfix easy at the end.  Also may lead to a tidy solution to OUYA mapping.

For me, todo:
 - IME listening bugfix
 - Fix touchscreen slide-finger-off bug
 - Redundantly map multiple buttons to a single command
 - Improve multi-controller deconfliction setup (have some new ideas, just need to implement)
 - Hide button overlays while still enabled (for touch mapping IMEs)
 - UI or solution for migrating savefiles
 - Diagnostics utility for controller debugging
 - "About" dialog
Title: Re: Finishing up the final pieces
Post by: littleguy on January 02, 2013, 03:39:05 PM
IME bug fixed, just need to make a final verification tonight with some other gamepads/IMEs.
Finger slide-off bug fixed.
Redundant mapping feature implemented.
Title: Re: Finishing up the final pieces
Post by: Paul on January 02, 2013, 03:43:10 PM
I'll be posting another snapshot built tonight.  Hoping to get some of the core functions hooked up first if I can get some development time in  ;D
Title: Re: Finishing up the final pieces
Post by: littleguy on January 03, 2013, 04:03:02 PM
Implemented new UI for multi-player mapping.  Much easier to use now IMO.  Pushed...
Title: Re: Finishing up the final pieces
Post by: littleguy on January 03, 2013, 10:41:20 PM
Added setting for hiding the touchscreen button overlays.  Added menu item for migrating savefiles.

My plate is starting to clear off finally.  Is there anything else we need to put in place?  I was going to look some more into the auto-crash reporting stuff, and look into APIs for implementing a "What's New" popup.  I seem to recall you had some problems retaining cheat menu state across orientation changes?  If you want, I can take a peek at that and see if I have any ideas.  Besides bugfixes on the snapshot thread, anything else you want me to look at?
Title: Re: Finishing up the final pieces
Post by: Paul on January 04, 2013, 07:10:43 AM
Cheats (play) menu should be fine in orientation changes now (it just refreshes itself from a saved list of preferences).  I'd like to be able to refresh on orientation change only when that section of the menu is open, but that's not really necessary.  Crash menu is probably a good next thing to look at instead.

One more big piece is fixing the read CRC header method so it doesn't have to unzip a ZIP ROM entirely just to read the header (this is really slowing down the play menu, which will make a lot of users angry I think).  Will probably require an implementation in the native code though (not sure how your C programming is - I'll get to this myself soon if it looks a bit too daunting). I feel like we should be able to get to the point of stress testing release candidates this weekend after I have a chance to hook up the core functions and fix that ZIP reading delay.  You've done an awesome job with the input piece!  Sorry I haven't been as active to get my pieces finished yet.
Title: Re: Finishing up the final pieces
Post by: littleguy on January 04, 2013, 07:42:43 AM
Sounds great.  Regarding the crash reporting, I sent you a PM (see below) a while back about creating a Bugsense account.  I think that's the next thing I need from you to proceed.

Quote
... The easiest next step is to use Bugsense (https://www.bugsense.com/), it requires virtually no effort to integrate and is vastly superior to google docs for browsing crash data.  They also make their services available for free to open-source projects (https://www.bugsense.com/pricing).  The kicker is that they don't support logcat in the free plan, though we might be able to sneak the data in the back door using custom data columns.   You do get the exception stack trace for free, and a lot of config info.  Either way, it may be a workable interim solution until we can find something better (e.g. custom database).

When you get a chance, would you mind creating the "official" Bugsense account for Mupen, and contact them about the free services in the link above?  Then add me as one of the "viewers" (see PM for my email address).

BTW - More about custom back-ends for ACRA is provided here (https://github.com/ACRA/acra/wiki/Contributions) and here (https://github.com/ACRA/acra/wiki/AdvancedUsage#wiki-Implementing_your_own_sender).

Edit - Just thought of something.  For getting good logcat info, what if we had a separate app that acted as an add-on to Mupen?  Reading logcat requires the user's device to be rooted, or the app to specify a permission in the manifest... I'd rather avoid adding another permission to the main app if few people really need it.
Title: Re: Finishing up the final pieces
Post by: littleguy on January 04, 2013, 07:48:00 AM
Actually I think the first thing I'll do is reorganize strings.xml.  Put things in a logical order, rename a few keys to follow a consistent naming convention, removed orphaned values, etc.  Long overdue on that.
Title: Re: Finishing up the final pieces
Post by: littleguy on January 04, 2013, 08:14:57 AM
One more big piece is fixing the read CRC header method so it doesn't have to unzip a ZIP ROM entirely just to read the header (this is really slowing down the play menu, which will make a lot of users angry I think).  Will probably require an implementation in the native code though (not sure how your C programming is - I'll get to this myself soon if it looks a bit too daunting).

I can take a look if you point me to the right source files.
Title: Re: Finishing up the final pieces
Post by: Paul on January 04, 2013, 12:10:15 PM
I added you as a viewer to the BugSense project.  I'll let you know when they get back with me about upgrading to the PRO services for free.
Title: Re: Finishing up the final pieces
Post by: littleguy on January 04, 2013, 03:24:58 PM
Thanks.

I did a MASSIVE cleanup of the preference key names, and reorganized the strings.xml.  Key names should be much more coherent/consistent now.  Most importantly, testers will need to reset their preferences from the settings menu.
Title: Re: Finishing up the final pieces
Post by: Paul on January 04, 2013, 04:58:32 PM
I noticed the crash tests are linking to BugSense now.  Nice job!
Title: Re: Finishing up the final pieces
Post by: littleguy on January 04, 2013, 05:00:51 PM
Yeah, I think I got it mostly working.  I'd like to find out how to strip some of the sensitive information though before I push the changes.  And make sure I know the ins and outs of the BugSense dashboard.
Title: Re: Finishing up the final pieces
Post by: littleguy on January 04, 2013, 07:26:51 PM
BugSense makes it easy to track app versions... so might as well start setting it in the manifest.  Continuing with an x.y.z scheme, how about the following:

2.a.XXX - Alpha (snapshot) builds
2.b.XXX - Beta builds
2.c.XXX - Release candidates (if we decide to do that)
2.0.XXX - Market release

So the next snapshot we publish would be
android:versionName="2.a.0"
android:versionCode="16"

And maybe increment versionCode only between minor releases (e.g. 2.a to 2.b, 2.b to 2.0, 2.0 to 2.1, etc.)
One other thing, when do we change the manifest?  I'm thinking maybe right before you publish, since you'll be changing that kind of stuff already and it will be on your mind.

Also, if we start doing this, I might wire up the "About" menu item to popup a simple dialog with basic version info, to help our testers.  Maybe one of the popup buttons takes you to a credits post on the forum.
Title: Re: Finishing up the final pieces
Post by: Paul on January 04, 2013, 07:39:22 PM
Excellent idea.  I vote we start using that in the next snapshot.
Title: Re: Finishing up the final pieces
Post by: littleguy on January 05, 2013, 01:03:26 AM
All set up and ready to go for BugSense.  We can send arbitrary key-value pairs, though long strings will need to be broken into chunks.  The key missing feature is logcat; ACRA will send it in the report, but BugSense won't display it.  Fortunately we can attach ACRA to another (or multiple) backends later if we want.

Check out the dashboard to see some example errors.  It's easy to "resolve" (hide) errors but I can't figure out how to completely delete old reports (maybe they just have to expire out).  If you look at some of the resolved errors you'll see all the gobs of information that gets passed in the default ACRA report - some potentially sensitive.  So I removed that chunk of the report.

I still have to update the About menuitem, but otherwise it's ready for the next snapshot build.  I guess we'll call it 2.a.0.  You probably know this already, but if we bump the version code to 16, users won't be able to install older snapshots without completely uninstalling.  So maybe we keep it at 15 throughout alpha.  Then bump it to 16 for beta.
Title: Re: Finishing up the final pieces
Post by: littleguy on January 05, 2013, 09:11:43 PM
Just added the "About" dialog.  Earlier today I put in a controller diagnostics screen.  For awhile now I've been using a little app I wrote to test controller signals and help debug.  It finally occurred to me that I could just drop this into Mupen as another activity, with almost no change to the code.  So I put it into the Advanced menu.  Should make it easier to work through controller issues now.

My plate is pretty much clean now.  I'll start looking at the CRC header thing you mentioned a few posts back, unless there's something more urgent.
Title: Re: Finishing up the final pieces
Post by: Paul on January 06, 2013, 12:47:55 AM
Do you think the menu strings are likely to be stable now, or any expected changes before publishing?  I should start getting translators involved if were are at a good point for that now.
Title: Re: Finishing up the final pieces
Post by: littleguy on January 06, 2013, 12:58:15 AM
I think the ones that are there are pretty much set.  I seem to keep adding more with each new feature though  :P. I kind of think translation should occur at the end of the beta.  I'm sure as we getnmore testers we'll continue to update stuff based on feedback.  But if you're eager to proceed I guess it's fine.  It does become a maintenance chore if things are still in flux...
Title: Re: Finishing up the final pieces
Post by: littleguy on January 06, 2013, 01:28:30 PM
Important note: I moved the default game save location from <sd>/GameSaves to <sd>/mupen64plus.  I thought this would be most obvious to users what the contents pertain to, and it's a familiar pattern that a lot of apps use.

For the next snapshot, testers should be made aware of a few important things:
 - They should revert to the default settings
 - They will need to rename their gamesave folder (if they've been using the default) or update the location inside mupen.
 - They can start posting bugs/issues/ideas to github, which they can access from the help menu in mupen64plus.

Title: Re: Finishing up the final pieces
Post by: littleguy on January 07, 2013, 09:10:32 AM
Ok, sorry for all the posts.  Just wanted to summarize my suggestions for the next snapshot since a lot has changed:

 - Bump manifest version info to "2.a.0"
 - Start a new thread, call it "Alpha testing" or something
    + Link to latest build
    + Testers can help by
         * reporting bugs using the Help menu on the main screen (also provide direct link)
         * enabling crash reporting in the Advanced menu
    + For controller issues, testers should
         * use the diagnostics screen in the Advanced menu
         * report their observations in a bug report
    + Start a changelog in the second post
         * I'm happy to maintain it if you give me write privileges to that post
 - Update the first post of the snapshots thread saying
    + Alpha testing has begun, point to new thread
    + Current snapshot users should
          * reset to the default settings after updating
          * rename their gamesave folder to 'mupen64plus' (if they've been using the default)
          * or update the gamesave location in the Advanced menu as necessary
    + Consider removing snapshot links in a month or two when they're no longer needed
 - Update the last post of the snapshots thread so that subscribed users are notified
Title: Re: Finishing up the final pieces
Post by: Paul on January 07, 2013, 11:41:41 AM
Ok, but I think instead of "Alpha Testing" (as that could get confusing to folks looking back later on, considering there was already an Alpha Testing phase), instead I will call it "Beta 2.0 Release Candidates".  This will be the final lead-up to the published app.  I think I said that before, but this time we really are very close to the point where we can publish.
Title: Re: Finishing up the final pieces
Post by: littleguy on January 07, 2013, 12:06:36 PM
Maybe I should have asked how many phases before releasing to market.

If this is the last phase of testing before release, I would use either the term "Beta" or "Release Candidate" but not both, since in my experience those are distinctly different things.  If this is the last phase, I would probably use the term "Beta 2.0" and skip right to release (we're not developing an operating system ;D).  Or let Wikipedia be your guide:
http://en.wikipedia.org/wiki/Software_release_life_cycle

Any way you slice it, I'm looking forward to the next release!

Edit: Of course in the subtext of the thread you could use the term "release candidate" to emphasize the nearness to release.  I'm just saying pick Beta or Release Candidate as the official name.  Ok I'll shut up now...
Title: Re: Finishing up the final pieces
Post by: Paul on January 07, 2013, 12:24:40 PM
Good point, since the Beta will not actually be until it is released (kind of redundant).  My thinking was "these are candidate builds for release as Beta 2.0", but of course that is too long of a title for anyone to want to read :)
Title: Re: Finishing up the final pieces
Post by: littleguy on January 07, 2013, 12:32:43 PM
"these are candidate builds for release as Beta 2.0"

To me that is the definition of Alpha, and to avoid confusion just say Alpha 2.0.  It's not at all uncommon to Alpha test when the major version number changes.  Alpha implies "lots of bugs" "incomplete features" "use at your own risk" "don't expect the world" and "I'm not formally testing the product yet, but you're welcome to take a peek and offer feedback".

Edit: Really it's just about managing tester expectations.  If you use Beta or RC when the software is only Alpha level, people can get pissed when they discover all the missing features and major flaws (or lose their data!)
Title: Re: Finishing up the final pieces
Post by: Paul on January 07, 2013, 12:56:38 PM
The actual release will not be perfect, though.  Anyone following the project will be used to that, and I'll handle the nasty emails from those who aren't.  I published Beta 1.0 much more broken than what we have now.  To me, Alphas were what I'd call the snapshot builds, and now we are ready to publish and just need to do stress tests to catch anything major with the crash reports or something.  The thing that muddles this update compared to previous ones is that we are struggling very hard to not regress anything that was working in 1.9.2, so I see where you are coming from.  However, I don't want a long protracted Alpha testing phase -- I feel like we are at a good point to publish now, with maybe a few more bugs squashed first.  I'd really like to publish this coming weekend if humanly possible, and push some quick updates the following week to address any big concerns.  After that I'll be focusing almost exclusively on the Open Pandora and OUYA ports.
Title: Re: Finishing up the final pieces
Post by: littleguy on January 07, 2013, 01:04:07 PM
Cool!  Now I see how you came up with the name Beta 2.0 RC - because you are releasing the beta!  Duh.  In the announcement I would just say Version 2.0 Release Candidate... should be clear enough to testers, and communicates nearness to release.  Then publish as Beta ;)
Title: Re: Finishing up the final pieces
Post by: littleguy on January 07, 2013, 01:08:08 PM
Oh, maybe a good time to list the features in 1.9.2 that still need hookup in 2.0.  Other than special funcs, I can't think of anything off the top of my head.
Title: Re: Finishing up the final pieces
Post by: Paul on January 07, 2013, 01:17:26 PM
Will do.
Title: Re: Finishing up the final pieces
Post by: zack on January 08, 2013, 03:45:49 AM
Just an fyi. I am going to start digging into the code this weekend, and have decided to take a look at our rice plugin first to see what improvements can be made there. Fog I know is one.

I believe that is the most compatible plugin so I feel that should be the one focused on.
Title: Re: Finishing up the final pieces
Post by: Paul on January 08, 2013, 06:05:16 AM
I agree.  I've really considered making it default, but haven't yet because of the speed (it is much slower on most devices, especially with frame skip disabled, which is necessary to avoid frozen video in most games).  I think it could get there with a little more improvement, so glad to see you will be working on it!
Title: Re: Finishing up the final pieces
Post by: littleguy on January 08, 2013, 05:18:18 PM
Paul - I can't remember where you mentioned it, but I think it actually would make a lot of sense to run the Play menu as its own activity.  With preference menus, you only get one opportunity to add/remove preferences and that's in the preference activity lifecycle functions such as onCreate or onResume.  So making the Play menu its own preference activity would really simplify the mechanics.  It would cache the name of the last ROM used in AppData (persisting of course).  On create it would see if the ROM filename changed, and if so would recompute the CRC info (which it would also then persist to AppData).  We should also be able persist the cheat options themselves.  Anyhow if you're dying to implement it go for it, otherwise I'm happy to do it.  Just let me know.
Title: Re: Finishing up the final pieces
Post by: Paul on January 08, 2013, 06:04:03 PM
If you don't mind tackling that one, I would like to look at the rsp plug-in this evening.  I didn't realize more devices were affected by it than the Kindle Fire HD - it could potentially be a problem for a large number of users.
Title: Re: Finishing up the final pieces
Post by: littleguy on January 08, 2013, 06:20:05 PM
Will do.  Nice that you have the other version for direct comparison.

One more request - could you go to the BugSense dashboard and delete the Mupen64Plus AE app, then re-create it?  If you use the same name you don't even need to change the source code.  The reason I ask is because I filled it with garbage during debugging (that was stupid!) and would be nice now if that stuff wasn't in there.  Deleting and re-creating the project in bugsense is apparently the only way to remove crash reports.
Title: Re: Finishing up the final pieces
Post by: Paul on January 08, 2013, 06:50:18 PM
Ok, I deleted it and created a new one with the same name.  Looks like data is still there from before though :/
Title: Re: Finishing up the final pieces
Post by: Paul on January 08, 2013, 06:59:40 PM
Nice that you have the other version for direct comparison.

Interestingly, there really isn't any difference in the code that wasn't there before.  All Sven added was external project files that are not used in the Android build.  Problem must be either in the config file (possibly a version) or in the core attach plug-in.  I'm digging a little deeper to track it down.
Title: Re: Finishing up the final pieces
Post by: littleguy on January 08, 2013, 11:01:15 PM
Implementing the cheats/CRC caching stuff is mostly done, but not yet ready for publication.
Title: Re: Finishing up the final pieces
Post by: littleguy on January 12, 2013, 05:33:29 PM
Can't seem to get the multi-choice cheats to persist.  The basic reason is that OptionsCheckBoxPreference extends from CheckBoxPreference, which persists a boolean.  And we need it to be an int of course.  Basically the child class is fighting with the parent, and whoever tries to persist second generates an FC crash.  Tried a bunch of workarounds so that the implementation can stay largely unaltered (nice implementation by the way!) but no luck.

I'll try writing a unified CheatsPreference that merges the two that you wrote, to handle boolean as well as multi-choice under the same hood.  And long-clicking of course.  With all the practice I've had this week debugging custom preferences, I'm finally getting a sense for the preference lifecycle, so it shouldn't take too long now.

If you can think of higher-priority issues, let me know.  I can't think of any off the top of my head.
Title: Re: Finishing up the final pieces
Post by: Paul on January 12, 2013, 06:08:03 PM
I think everything appears to be shaping up.  I'm mainly looking at the GS3 issue and the OUYA port right now, and I'll add devices to the hardware profiler as the data is reported.
Title: Re: Finishing up the final pieces
Post by: littleguy on January 12, 2013, 11:58:08 PM
All cheats persist now.