Author Topic: Pak switching mechanics  (Read 1662 times)

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Pak switching mechanics
« on: February 28, 2013, 10:31:15 PM »
In the process of streamlining the native input plugin, I've learned quite a bit.  The plugin interface is really lean, and looks well thought out.  However, there is one thing that I find odd about the core API.  Why are the mempak and rumblepak switched via the input plugin and not the front-end plugin?  All on-the-fly configuration changes (pause, reset, open ROM, frame advance, etc.) are done in the ui-console plugin via the CoreDoCommand function.  Except for the pak switching.

Instead, pak switching is done via the input plugin.  Input-sdl uses some leftover bits in the BUTTONS data structure, bits which are documented in the core (m64p_plugin.h) to be "Reserved".  So that kind of bugs me.  But what really bothers me is that such fundamentally different handling is then required for these two "buttons".  All the other buttons are momentary-on type switches, and by necessity are polled very frequently in the inner event loop.  However, when a pak "button" is pressed, a whole sequence of timers is initiated to simulate manual removal and reinsertion of a physical pak.  This just seems out of place here, and is a nuisance to implement.  And why make every input plug-in re-implement this behavior?  If this sequence of delays is important, seems like it should be implemented in the core.

So I'm sort of at a cross-roads.  I'd like to keep the input-android plugin very thin (300 lines or less), just bridging the Android/Java code with the core.  But this whole timer mechanism is a bother.  I either have to implement it in the native plugin (cluttering it up) or add a bunch of code to my Java class that just seems out of place.

I'm wondering if we even need mempak/rumblepak switching to be mappable.  Given that it's an intentionally delayed procedure, seems like it would work just fine in the in-game menu, which is where I'd much rather wire it to.  Are there any N64 games that require in-game pak switching, and is fingertip access so critical?
« Last Edit: February 28, 2013, 10:36:31 PM by littleguy »
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline beansta

  • byte
  • *
  • Posts: 29
    • View Profile
Re: Pak switching mechanics
« Reply #1 on: March 22, 2013, 02:51:03 PM »
i cant think of any games that require the switching as such, however in games like vigilante 8, the mempak is required but also the game is rumblepak compatible.
Devices:
Samsung Galaxy S3 LTE international
rXtreme v14.1 ROM and Perceus v36.2 kernel
1.7ghz Quadcore CPU and 533mhz GPU
1.77 GB useable RAM

Samsung Galaxy Tab 2 10.1 Wifi
Zap Blaster v2.2 ROM and Next v1.41 kernel
1.35ghz Dualcore CPU and 384mhz GPU
1006MB useable RAM


Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: Pak switching mechanics
« Reply #2 on: March 22, 2013, 05:02:55 PM »
Thanks for the example.  I ended up resolving my questions by just implementing the pak switching via the in-game menu (which seems much more intuitive IMO) rather than a mapped button.  This allowed me to keep the new input plugin nice and simple :).
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version