January 30th, 2013, 17:33
Possible interface changes
During the course of writing an Android front-end, I've run into two small hurdles which would require somewhat hackish workarounds to avoid modifying the core. These may be very specific to my project and not likely to affect most front-end devs, but I thought I'd bring them up anyway in case they are worth looking at. Also note that I might have missed something already in the API, so feel free to correct me if solutions to these already exist!
The first issue is there is no interface for determining when a save-state has completed. State-changes are not synchronized with save-states, so the state-change callback can not be used to obtain this information (for example, doing M64CMD_PAUSE, M64CMD_STATE_SAVE, M64CMD_RESUME in conjunction with a state-change callback listening for M64EMU_RUNNING is not a reliable way to determine when the save-state is complete). It would be useful to either add a save-state callback, or to add an additional emu state (such as M64EMU_SAVESTATE_COMPLETE, for example), or even to just re-notify the current state (M64EMU_PAUSED or M64EMU_RUNNING) every time a save-state is complete.
The second issue is there is no interface for the Gameshark Button other than assigning it to a key or joystick control in the config file. The actual implementation for this function is hardwired into the core with SDL input listener. For a front-end where input is more abstract, there is no apparent way to access this function other than injecting SDL events. Of course there are a few other functions besides this one that can be assigned to key or joystick via the config file, but all the other functions have obvious interfaces in the API to re-implement them in the front-end. This was the only one that gave me pause (there are a couple I didn't use though, Screenshot and Full Screen).
Last edited by paulscode; January 30th, 2013 at 18:10.
January 31st, 2013, 09:32
Ever thought about talking to the developers through their site? They have an issue tracker.
For example, you also did not respond to my bug thread on 4chan about mupen64plus-ae. I really had got suggestions and patches
February 7th, 2013, 02:54
Sorry, been in a transition period with the move. I'd probably bring this up on in chat, but haven't had time to get on there in a while (I know the devs stop by here from time to time, and this is rather a comment than a question).
Never used 4chan, so that would explain why I haven't responded (you'd have better luck posting on my forum or opening an issue on github). You have a link to the thread in question?
February 9th, 2013, 18:51
paulscode, I'll make changes to the core to address the issue you brought up. I'll try to get it done within the next week. I need to make a development effort for mupen64plus in the next few months and get some long-outstanding things fixed up, and then I think it will be time for a 2.0 release.
Originally Posted by paulscode
February 20th, 2013, 07:26
Okay, I have made some modifications which should address both of your concerns. Please look at commit 6efa07c and let me know if you have any questions.
February 20th, 2013, 07:40
The Great Gunblade Wielder
how about support for cheats in the rdb that work around -not even fixed in mess/mame- emulation issues and lags
Pokemon Snap's first level fix and Zelda64 subscreen fixes come to mind.