Topics

1

General Discussion / Mupen64Plus-AE now mirrors upstream Mupen64Plus

« on: January 10, 2015, 08:48:56 PM »

At long last.  The day has finally come.

Mupen64Plus-AE now uses 100% standard implementation for all Mupen64Plus plugins.
 - mupen64plus-audio-sdl
 - mupen64plus-core
 - mupen64plus-rsp-hle
 - mupen64plus-ui-console
 - mupen64plus-video-glide64mk2
 - mupen64plus-video-rice

Mupen64Plus-AE maintains additional plugins that aren't in upstream
 - mupen64plus-input-android
 - mupen64plus-video-gln64

And for those keeping track, Mupen64Plus-AE uses SDL release-2.0.0, with one line of code changed.

2

General Discussion / Android-SDL-Mupen64Plus Lifecycle Mechanics

« on: December 03, 2014, 08:47:06 AM »

I just wanted to get this discussion all in one place for posterity.  It's a complicated design problem with many subtleties.

Last year, for version 3.0 I refactored all the lifecycle mechanics.  The goal was to make the GameActivity robust to the lifecycle that the Android O/S imposes on all apps:

Code: [Select]

(start)
    |
 onCreate <-- (killed) <---------\
    |                            |
 onStart  <-- onRestart <-----\  |
    |                         |  |
 onResume <----------------\  |  |
    |                      |  |  |
 [*onSurfaceCreated*]      |  |  |
    |                      |  |  |
 [*onSurfaceChanged*]      |  |  |
    |                      |  |  |
 [*onWindowFocusChanged*]  |  |  |
    |                      |  |  |
 (running)                 |  |  |
    |                      |  |  |
 [*onWindowFocusChanged*]  |  |  |
    |                      |  |  |
 onPause ------------------/  |  |
    |                         |  |
 [*onSurfaceDestroyed*]       |  |
    |                         |  |
 onStop ----------------------/--/
    |
 onDestroy
    |
 (end)
 
[*non-deterministic sequence*]

The design philosophy that I took was this:

• First and foremost, we must acknowledge that GameActivity will always be created, started, resumed, paused, stopped, and destroyed on Android's whim.  Whether we like it or not, Android -- not the mupen64plus core or SDL -- is the true dictator here.
• The Java code in GameActivity should explicitly handle all of Android's lifecycle callbacks.  I.e. follow the "Android way" and be a good Android citizen.
• The Java callbacks are responsible for keeping mupen64plus-core's state compatible with GameActivity's Android state.  E.g. when the GameActivity stops, the core should be stopped.
• Mupen64plus-core's state should be managed using the native mupen64plus API, not the SDL API.  I.e. follow the "mupen64plus way" and be a good mupen64plus front-end.  E.g. don't stop the core by issuing an SDL call; use the mupen64plus API instead.
• The only interaction we should have with SDL is to implement SDL's callbacks.  These are: createGLContext, destroyGLContext, flipGLBuffers, audioInit, audioWrite*Buffer, and audioQuit.
• We have the option of implementing SDL callbacks in Java or C++.  Since GL state management must also be coordinated with the GameActivity lifecycle and the Java SurfaceView element, I chose to implement the callbacks primarily in Java.
• The Java SurfaceView has its own lifecycle (create, change, focus, destroy) that interleaves with the GameActivity lifecycle.  Unfortunately, this interleaving varies depending on the Android version, so we cannot assume any lock-step ordering between the lifecycles.
• For robustness, we should assume the Java surface lifecycle is completely independent of the Java activity lifecycle.  This means that when handling surface lifecycle callbacks, we should condition our response on the activity's current state.  When handling activity lifecycle callbacks, we should condition our response on the surface's current state.

One extra complication is that the mupen64plus native code (particularly ui-console) contains a number of static variables.  On the PC these would normally be reset on launch, as the ui-console process would be completely reloaded, triggering a reload of the other mupen64plus modules.  However, we are using ui-console as a library rather than an executable, so the core modules are only loaded once when the Android app starts.  I.e. the ui-console isn't reloaded automatically when GameActivity starts.  Therefore we must manually force ui-console to reload whenever the GameActivity is created.  Due to vagaries in how JNI loads and (only sometimes unloads) native modules, this requires careful structuring of the module dependencies and careful (un)loading at run-time.

The process of reimplementing the lifecycle mechanics was a bumpy road, as can be seen in this thread:
http://www.paulscode.com/forum/index.php?topic=1199.0

and these commits:
https://github.com/mupen64plus-ae/mupen64plus-ae/commit/3cc146ef37cc26a3f6298ea094a79d3f6c667274
https://github.com/mupen64plus-ae/mupen64plus-ae/commit/f65585de2b27c545412a81b7436960000596ab44
https://github.com/mupen64plus-ae/mupen64plus-ae/commit/d01ca2c4d34774ea061e0f57431e5604afe4fca4
https://github.com/mupen64plus-ae/mupen64plus-ae/commit/49acad8648ed78258caa5f2db2af8ce6f0935df2
https://github.com/mupen64plus-ae/mupen64plus-ae/commit/dcdb3cf65f337e88aeb202247e1761e02e94ca27
https://github.com/mupen64plus-ae/mupen64plus-ae/commit/59ba2bc8f425a2a5c3b9d34e2bfbfa47b83ba870
https://github.com/mupen64plus-ae/mupen64plus-ae/commit/6d0973941f22c498042782f94934cdb9b661a352
https://github.com/mupen64plus-ae/mupen64plus-ae/commit/2ff6c50bb26737fd62f9af9d812bbfd03b21edaf
https://github.com/mupen64plus-ae/mupen64plus-ae/commit/2e4f3c70c477a1ac96745d061f141af2066d8a97

@Gilles With all this in mind, could you please (re)explain the purpose of the changes you made in this branch?
https://github.com/mupen64plus-ae/mupen64plus-ae/commits/Gillou68310/sdl-bridge-front-mods
Which of these changes should be integrated into the master branch?  Which should not?  What bugs do these fix?

3

General Discussion / GLIDE: List of problem games

« on: January 31, 2014, 03:46:32 PM »

For test and debug purposes, I need a list of "problem games" for the glide plugin.  By "problem game" I mean any game that
 - Does not display properly, or
 - Is *significantly* slower than the other video plugins (minor slowdown is not a problem)

If the problem is just at a particular point in the game, it would be very helpful if you could post a save state to make it easy to test.  Else, just be as specific as possible.  Thanks...

4

General Discussion / Upstream Synchronization Strategy

« on: January 20, 2014, 09:36:34 AM »

I'd like to take the lead getting our stuff synched back upstream over the next few weeks.  I thought I'd get the discussion going here on a few strategic matters.  There has also been some discussion in the upstream channels about libretro-mupen synchronization.

1. In case anyone's not aware, the upstream source has been migrated to github, and now contains some additional video and rsp plugins, e.g. the ones wahrhaft was maintaining.  This makes it easier than ever now to sync with upstream.

2.  Paul and I formed the mupen64plus-ae organization on github.  The idea is that the organization may be easier to find, and we can collect all mupen-ae related business under one place.  This is where we would house our forks of the various upstream repositories.  Right now I'm using it as a sandbox to test and verify some git mechanics, so don't put any stock into it for now (i.e. don't submit pull requests).

3. I did some experimentation and discovered that it is feasible to move the plugins outside the JNI folder and still get proper Android builds.  It only required a few changes to jni/Android.mk.  So organizing it something like this will work, if that's what we want:

    - (new repository root)
        - mupen64plus-ae
            - (contents of current repository, minus the jni subdirectories listed below)
        - mupen64plus-audio-sdl
            - (contents of current jni/audio-sdl)
        - mupen64plus-core
            - (contents of current jni/core)
        - mupen64plus-input-android
            - (contents of current jni/input-android)
        - mupen64plus-rsp-hle
            - (contents of current jni/rsp-hle)
        - mupen64plus-video-glide64mk2
            - (contents of current jni/gles2glide64)
        - mupen64plus-video-gln64
            - (contents of current jni/gles2n64)
        - mupen64plus-video-rice
            - (contents of current jni/gles2rice)

4. For best upstream synching, we should maintain our plugins as separate, independent repositories, each a fork of its upstream parent.  So we'd have a git repo for mupen64plus-audio-sdl, another for mupen64plus-core, etc.  We should try to keep the master branch as clean as possible to make it easy to diff/merge/cherry-pick between up- and downstream.  We could generally push new changes to branches, then clean them up before putting them over to master.

5. This then leads to a big question: What do we keep in the mupen64plus-ae repository?  The options that I can imagine are
    A. Keep a copy of plugin source in the ae repository.  This is what we're doing now.  The only thing we'd change is the upstream location in the git-subtree pull script (see tools folder of current repo).
    B. Remove all plugin source from the ae repository.  The user would clone all the mupen64plus-ae organization's repos into a common directory, then ndk-build from the mupen64plus-ae subdirectory.
    C. Same as B, but add the compiled binaries to the ae repository.  That would make it much easier to traverse the git history for bisecting and so forth.  The right plugin version would be associated with each commit in the ae repo.
    D. Use git-submodule.  I'm only saying it for completeness.  Everything I read about it is that it's a nightmare to use and requires all devs to be git gurus.

I personally feel that git history traversal with the correct plugin versions is very important, so I favor options A and C.  I think I lean towards option A since it keeps things simple (no change to current practice, and we wouldn't even need to reorganize directories as in item 3) and makes it easy for new devs to jump in and add fixes.  I personally don't mind if the commits are messy, because I can always clean them up before synching back our own plugin fork.  That would keep our fork repos clean for easy upstream synchronization and reuse by other projects (e.g. mupen64plus-pandora).  To maintain cleanliness, we might consider giving only a few devs write access to the plugin forks, but support pull requests.

5

General Discussion / Calling all Shield, JXD 7300/7800, Archos Gamepad, and GameStick owners

« on: December 18, 2013, 08:20:25 AM »

Version 3.0 will have an overhauled button mapping system with a lot more built-in profiles.  I'd like to create default profiles for as many devices as possible.

What I need:
 - The key codes/axis codes for the various buttons/sticks/triggers on the device/controller
     - Settings -> Input -> Controller -> menu -> Controller diagnostics (press buttons/sticks to detect codes)
 - Screenshot of the analog info window:
     - Settings -> Input -> Controller -> menu -> Analog info
 - Screenshot of the device info
     - Settings -> Advanced -> Device info (scroll down to bottom before taking a screenshot)
 - Which Android ROM you're using (e.g. stock, Sxelrom, CyanogenMod, etc.)

Still needed
Archos Gamepad
GameStick
JXD S7300

Complete
iControlPad
JXD S7800
Mad Catz C.T.R.L.R (M.O.J.O controller)
MOGA (Pro, Pro Power, Hero Power)
Nyko Playpad series
OUYA
PS3 (wired and wireless via Sixaxis app)
Rumblepad series PC controllers
Shield
USB N64 adapters
Xbox360 & XInput-based PC controllers (e.g. Logitech F710)
Xperia Play

6

General Discussion / Master list of games that require D-pad/L-button

« on: December 07, 2013, 05:36:46 PM »

Can anyone give me a list of games that require
 - (D-Pad and L-button) only
 - (D-Pad and L-button) and (Analog and Z-trigger)

Do any games exist that require (Analog and L-button) or (D-pad and Z-trigger)?  I'm guessing no but want to be sure.

D-pad/L-button only
Dr. Mario 64
Kirby 64
Pokemon Stadium 1
Pokemon Stadium 2
? Pokemon Puzzle League

D-pad/L-button and analog/Z-trigger
Doom 64 d-pad is redundant, nonessential
Duke Nukem 64
F-1 Pole Position 64
WWF No Mercy

7

Your Projects / Web app development framework

« on: August 15, 2013, 03:20:45 PM »

@Paul and anyone else who knows a thing or two about this stuff...

I'm looking to build what I'm guessing is a straightforward web app.  The user will fire up a browser and fill out what is essentially an adaptive questionnaire.  That is, they will be greeted with a standard web form with text boxes, radio buttons, etc., and whenever they fill out a field, some new fields will be shown and/or re-ordered and some output displays will be refreshed with new numbers.  Users can populate fields in any order, and the decision about what gets shown next isn't something that can simply be hard-coded (e.g. a tree structure, lookup table, etc.).  Rather, the decision is made by a server-side algorithm that interfaces to some third-party library (bindings for Java/C/C++/C#) and a database.  The server will almost certainly be a LAMP stack, though I suppose nothing has been ruled out yet.

I can't imagine this being a challenging task for anyone with a bit of web app experience.  We could always farm this out to a subcontractor, though there are some technical and strategic benefits to doing it in-house even if we're not web dev specialists.

So my question is, if we do it in-house, what approach would you take?  Obviously we could code HTML files by hand, but in this day and age I'm guessing there are a lot of higher-level frameworks where all the nuts and bolts are already done for you and you can focus on the general architecture and business logic.  Our main priorities are flexibility and maintainability, since this might evolve significantly over the next few years into something much grander.  I don't mind sinking some up front time to climb a learning curve, and long-term I imagine it best we invest in html5 or at least AJAX approaches.  Paul, you mentioned Symfony2 a couple weeks ago, sounded pretty enthusiastic about it.  Does that fit the bill here?  Basis for comparison?

8

Support / FilePwn: File manager for OUYA

« on: July 15, 2013, 07:56:49 PM »

It was driving me kind of crazy that there were no file manager apps available in the OUYA store.  Sideloading is easy... if you can manage to sideload Dropbox or a file manager app first. So I went ahead and published one myself.  It has a "touchless" interface that was designed specifically for use with gamepads.

Right now you can find it in the Sandbox section.  Or just search by name (FilePwn).  If you like it, please give it a thumbs up to help it out of the sandbox.  A description of the app can also be found on this page.

BTW I added some subliminal advertising for Mupen64PlusAE in the screenshots

9

General Discussion / Brainstorming Version 3.0

« 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?

 

10

General Discussion / Preparation for version 2.3 release

« on: May 21, 2013, 09:47:31 AM »

With the Adreno 320 (and possibly 225) lag issues apparently fixed, I assume we'll want to push out another release soon.  Just wanted to coordinate with everyone to make sure there weren't any dangling show-stoppers in the current head of the master branch, or any branches that should be merged first.

Some thoughts:
 - Let's verify that Adreno 225 (SGS3) lag is fixed so that the changelog can be written accurately.  We want the fix to be really obvious to all those users.
 - This will be the first release with SDL 2.0.  Volunteer testers have been in short supply lately, so it's possible that some users will see regressions.
 - Regarding feature branches in general, I would suggest not merging them yet, just so we can focus on any SDL2 regressions that might arise.
 - I think Kris and Paul are in the best position to say when the glide branch is ready for release, so notwithstanding the previous bullet I'll defer to them.
 - The new-screensizing branch could probably be merged without any issues, but again I'd rather just be safe and keep it out until 2.3.1 or something.  Plus I still need to add the zoom feature (trivial to implement, just a question of how complex we want the preference menu to be).
 - The fix-asdp branch is not ready yet.
 - I don't believe there's anything critical in any of the upstream/ branches (mostly Linux makefile stuff IIRC), so I don't think we need to worry about that.

11

General Discussion / Video sizing implementation

« on: May 17, 2013, 01:04:50 PM »

Been curious about this for a long time, so I did some quick experimentation.  We can do all the video sizing operations in Java, during the initialization of the GameSurface.  All we need to do is set the layout parameters of the GameSurface view (size and position) and pass the size values accordingly through the standard config files.  All video plugins would be hard-coded to stretch, which would simply fill the GameSurface at whatever size it's defined in Java.  The benefits would be

• Easy way to implement screen position (top/middle/bottom) for glide
• Easy way to fix the junk graphics on the side in Rice on some devices
• Reduces the amount of custom code we add to the video plugins and simplifies ae-bridge
• Would be easy to extend the video preferences to allow more customization

For example, the video options might look like this:

• Screen orientation
  
  • Landscape (default)
  • Reverse landscape
    
  • Portrait
    
  • Reverse portrait
    
• Screen position
  
  • Top-left
  • Top-center (default)
  • Top-right
  • Middle-left
  • Middle-center
  • Middle-right
  • Bottom-left
  • Bottom-center
  • Bottom-right
• Screen size
  
  • Maintain aspect ratio (default)
  • Fill screen
  • 800x600
  • 640x480
  • 480x360
  • 320x240

Has the Java-side video sizing been explored already?  Does this have any known drawbacks?

12

General Discussion / RGBA_8888 mode

« on: April 26, 2013, 08:02:40 AM »

Is this option still necessary?  If so, shouldn't the default be enabled?

When it's disabled, we ask for a 16-bit color context, but the OpenGL spec requires egl to return the deepest color context that matches the requested config.  So in virtually any modern device we will get a 32-bit context regardless (unless the device drivers are buggy).  In other words, the same context config is used regardless of the option setting, and therefore the option has no impact on performance or visual quality.

Note that the original rice plugin always asks for 32 bits by default, and only asks for 16 if an obscure option is enabled.

It seems we could remove the option, and always request a 32 bit context.  If context creation fails, we could try again with 16 bit depth for the obscure device that only has 16 bit color (but do we really need to support such a low-performance device?).  Another approach, we could provide an advanced option to force 16-bit mode (disabled by default), in which case we'd have to manually check the EGL configurations in GameSurface.java to be sure a 16-bit config is selected (since the list will also include 32 bit configs per spec).

13

General Discussion / Junk graphics on the side of mario, with rice

« on: April 12, 2013, 08:20:04 PM »

Ok, I think I'm going insane.  After the bridge merge I noticed that on my Xperia Play, rice is giving junk graphics on the sides where the black pillarboxes should be - in Mario 64 no less.  Naturally I panicked... So I started going back, back, back to 2.1.0.  Complete reinstall, complete clean build.  Problem is still there.  I'm going to keep going back in time...

Did I miss something or did rice always do this on the Xperia Play?  I could have sworn I never had this problem before.

14

General Discussion / Video plugin initialization mechanics

« on: April 02, 2013, 10:43:51 PM »

Kris's massive progress on the glide plugin, as well as my recent integration work for the Rice plugin, has sort of lit a fire under me to understand the native implementation better.  Paul's issues with glide's depth buffer prompted me to start this thread in the off chance any of my thoughts are related.

So lately I've been looking at the whole initialization sequence for each of the video plugins.  Reading through the Mupen64Plus documentation would suggest that the core provides a complete abstraction to initialization process, and that SDL functions need not be called directly.  I.e. you just need to implement a few callbacks for your platform to provide the core with a rendering context, resize, etc. and it takes it from there.

I'm ignorant of all it took to get it working originally (I'm sure a lot!), but it struck me as a bit odd that we add so much custom stuff to initialize the video plugins, and call a lot of the SDL initialization API directly rather than using the core's abstraction.  I've highlighted these customizations here.  I also wasn't sure why we use SDL_android_main.cpp in the build - it seems like front-end (ui-console) should be running the show and managing SDL state, not the other way around.

I started tinkering around by removing the ae-customizations from Rice and reverting to the upstream version.  Then I called front-end directly rather than going through SDL_android_main.cpp (which I didn't compile at all).  With audio and video disabled, the app seems to run.  When I enable Rice video, the startup sequence seems to fire properly but then I get a segfault before it completes.  I'd push the code to a new branch for all to see, but right now it's a giant merge soup of several of my local experimental branches.

Anyhow, if you have a clearer picture of what's going on behind the curtains, I'd love to know.

15

General Discussion / SDL 2.0

« on: March 24, 2013, 01:37:54 PM »

Looking forward to SDL 2.0 integration.  After working with gles2rice for awhile now I must say it would be really nice if we can maintain a reference to the upstream source, the way Sven does with the core and plugins.  Was this the plan?