Author Topic: Video plugin initialization mechanics  (Read 1772 times)

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
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.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: Video plugin initialization mechanics
« Reply #1 on: April 03, 2013, 10:14:01 AM »
Ok, I spent some time reworking my mess of local branches and started a clean local branch to test this all out.  Had a minor eureka moment that's making it easy for me to consolidate all the paulscode-specific code into a shared library.  (The eureka was separating the library into two libraries - one for imports, the other for exports, then tweaking the build dependencies.) Thus a lot of the paulscode features/hacks can be consolidated to a single line of code in the plugin/core/front-end/sdl.  And the defines/includes can be consolidated into a single #include "ae_bridge.h".  So the upstream diffs are becoming super clean.  When I finish this I'll push it to public, probably in the next few days if I don't hit a snag.

Some things to keep in mind in the meantime: paulscode customizations should be very easy to
 - integrate into new plugins and dependencies (just a few lines of "black-box" code to add)
 - maintain (no code duplication, centralized location)

This should make for cleaner integrations into glide64mk2.  It should also make it much easier to upgrade to SDL 2.0.  We could even maintain SDL 1.3 alongside it, or even expose it as a preference during testing.  With the bridge in place it should also be fairly straightforward to test the ideas in this post and perhaps fix the ASDP bug.

I'll keep you posted as things progress.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version