[Dippo]

Hi!

Is there any reason why the savegame subsystem form alpha 7 is not included in alpha 12? I am building the retroplayer-alpha12 branch on linux and maybe I am missing something but it looks like savegames are not present anymore.

Would it be worth the effort to cherry-pick this one:
https://github.com/garbear/xbmc/commit/8...8f28551cb3
or are you working on something completely different right now to make this obsolete?

[garbear]

the reason is the needs to be rewritten. I left it out of the github PR for this reason, and the desire to minimize the patch for reviewability and so it doesn't leak any bugs into the patch. It hasn't made it into alpha 12 (yet) because I based alpha 12 off the pr branch.

a new database abstraction (most likely a pre-existing object-relational mapping library) is needed. I don't wanna leave you guys without savestates though so I'll cherry-pick that commit when I get a chance

[Dippo]

Hi!

I managed to merge the old alpha 7 savegame commits to alpha 12. I pulled in these:

• 8d6ff36e32b46fe76d6fd9f40cbf158f28551cb3
  
• a89e4b6f88309e8feffae97f97c490410804bdcb
  
• 1e0368f1c04cdd9e49271a3765634e7e883f1b3e
  

Cherry picking didn't work for me because it resulted in a lot of merge conflicts and this is the first time I am working with the xbmc codebase.
When I started to work I did not know that the dynamicdatabase was needed so it is only one big commit. Beside some String function rework from upstream xbmc this your codebase.

The DynamicDatabase looks like a pretty generic implementation for this specific use case. Also the upstream signature change in the createTable function prevents the current implementation from recognizing any errors during creation.

I will create a github account when I do have some time on my hands so maybe you then want to pull this in your repository as a new savegame branch? I don't want to split up development ressources but the savegame feature is very important for me.

Dippo

[garbear]

Cool, let me know when you get these changes up on github. We'll get a savegame branch working.

[Dippo]

Here is the branch: github

I will try to keep track with your changes. At the moment I don't know which branch to follow - alpha12 alpha12-libretro or alpha12-joystick?

With your latest changes my gamepad does not work anymore. I have Digital Axes on the gamepad. The buttons are working but the axes are not. I gues the controllerId + DIGITAL_AXIS_MASK doesn't map to the correct controller. This happens with all alpha12 branches. I'm running xbmc on Linux.

Debug output for button press and axis usage (JoypadStart correctly detected, JoypadUp/Down not)

Code:

13:10:47 T:140516559247232   DEBUG: Joystick 0 button 2 pressed
13:10:47 T:140516559247232   DEBUG: -> RetroPlayerInput: Controller=0, button down=2, Action JoypadStart, id=3
13:10:47 T:140515936814848    INFO: LibretroEnvironment query ID=17: GET_VARIABLE_UPDATE
13:10:47 T:140516559247232    INFO: Previous line repeats 6 times.
13:10:47 T:140516559247232   DEBUG: Joystick 0 button 2 unpressed
13:10:47 T:140516559247232   DEBUG: -> RetroPlayerInput: Controller=0, button up=2, id=3
13:10:47 T:140515936814848    INFO: LibretroEnvironment query ID=17: GET_VARIABLE_UPDATE
13:10:49 T:140516559247232    INFO: Previous line repeats 131 times.
13:10:49 T:140516559247232   DEBUG: Joystick 0 axis 2 activated
13:10:49 T:140516559247232   DEBUG: -> RetroPlayerInput: Controller=1000, button down=2, Action JoypadUp, id=4
13:10:49 T:140515936814848    INFO: LibretroEnvironment query ID=17: GET_VARIABLE_UPDATE
13:10:49 T:140516559247232    INFO: Previous line repeats 4 times.
13:10:49 T:140516559247232   DEBUG: Joystick 0 axis 2 deactivated
13:10:49 T:140516559247232   DEBUG: -> RetroPlayerInput: Controller=1000, button up=2, id=4
13:10:49 T:140515936814848    INFO: LibretroEnvironment query ID=17: GET_VARIABLE_UPDATE
13:10:51 T:140516559247232    INFO: Previous line repeats 72 times.
13:10:51 T:140516559247232   DEBUG: Joystick 0 axis 2 activated
13:10:51 T:140516559247232   DEBUG: -> RetroPlayerInput: Controller=1000, button down=2, Action JoypadDown, id=5
13:10:51 T:140515936814848    INFO: LibretroEnvironment query ID=17: GET_VARIABLE_UPDATE
13:10:51 T:140516559247232    INFO: Previous line repeats 3 times.
13:10:51 T:140516559247232   DEBUG: Joystick 0 axis 2 deactivated
13:10:51 T:140516559247232   DEBUG: -> RetroPlayerInput: Controller=1000, button up=2, id=5
13:10:51 T:140515936814848    INFO: LibretroEnvironment query ID=17: GET_VARIABLE_UPDATE

[garbear]

i was looking through the code for your bug and had a revelation for how the joystick api could be re-written to eliminate mass amounts of complexity (and with that, many possible/existing bugs). feel like taking on a cool challenge?

[hubsif]

Hi.

I stumbled across this thread because I had the same problem, which was the digital axes not working on my Dragonrise Gamepad (0079:0006).

I'm not much of a software developer, but what I did is simply to move the DIGITAL_AXIS_MASK from the controllerID to the buttonID. Don't know if this is a fully correct solution, but it's working for me.

Here's my patch (without guarantee!):

Code:

--- xbmc/xbmc/cores/RetroPlayer/RetroPlayerInput.cpp    2014-07-23 20:54:31.000000000 +0200
+++ xbmc.new/xbmc/cores/RetroPlayer/RetroPlayerInput.cpp    2014-07-25 10:54:27.000000000 +0200
@@ -179,12 +179,12 @@

void CRetroPlayerInput::ProcessDigitalAxisDown(unsigned int controllerID, unsigned int buttonID, const CAction &action)
{
-  return ProcessButtonDown(controllerID + DIGITAL_AXIS_MASK, buttonID, action);
+  return ProcessButtonDown(controllerID, buttonID + DIGITAL_AXIS_MASK, action);
}

void CRetroPlayerInput::ProcessDigitalAxisUp(unsigned int controllerID, unsigned int buttonID)
{
-  return ProcessButtonUp(controllerID + DIGITAL_AXIS_MASK, buttonID);
+  return ProcessButtonUp(controllerID, buttonID + DIGITAL_AXIS_MASK);
}

void CRetroPlayerInput::ProcessHatDown(unsigned int controllerID, unsigned int hatID, unsigned char hatDir, const CAction &action)

[ursli]

Sorry to bump this, but if I'm correct there are no savestates in the latest retroplayer13.2 branch right? I've tried creating a patch to get the savegame functionality from Dippo's alpha12 branch but some of the changes in Gameclient.cpp in comparision with the 13.2 branch are too sophisticated for my non existent coding skills.

Did anybody already try to get this working with 13.2 or is somebody willing to give me a hand?

What I did so far:

Create a patch file to see where we may have problems merging alpha12 savegames to 13.2:

Code:

git --git-dir=.git/ format-patch -k -1 --stdout 4af2d59a5b8d7aa84122bff06096203c6b580340 > savegames.patch

http://paste.ubuntu.com/9975222/

Then started to resolve all the merging errors but as mentioned got stuck at gameclient.cpp:

Code:

patch  --dry-run -p1 < savegames.patch | grep -v succeeded > errors.log

http://paste.ubuntu.com/9975273/

[a1rwulf]

Hi.

I stumbled across this thread because I had the same problem, which was the digital axes not working on my Dragonrise Gamepad (0079:0006).

I'm not much of a software developer, but what I did is simply to move the DIGITAL_AXIS_MASK from the controllerID to the buttonID. Don't know if this is a fully correct solution, but it's working for me.

Here's my patch (without guarantee!):

Code:

--- xbmc/xbmc/cores/RetroPlayer/RetroPlayerInput.cpp    2014-07-23 20:54:31.000000000 +0200
+++ xbmc.new/xbmc/cores/RetroPlayer/RetroPlayerInput.cpp    2014-07-25 10:54:27.000000000 +0200
@@ -179,12 +179,12 @@

void CRetroPlayerInput::ProcessDigitalAxisDown(unsigned int controllerID, unsigned int buttonID, const CAction &action)
{
-  return ProcessButtonDown(controllerID + DIGITAL_AXIS_MASK, buttonID, action);
+  return ProcessButtonDown(controllerID, buttonID + DIGITAL_AXIS_MASK, action);
}

void CRetroPlayerInput::ProcessDigitalAxisUp(unsigned int controllerID, unsigned int buttonID)
{
-  return ProcessButtonUp(controllerID + DIGITAL_AXIS_MASK, buttonID);
+  return ProcessButtonUp(controllerID, buttonID + DIGITAL_AXIS_MASK);
}

void CRetroPlayerInput::ProcessHatDown(unsigned int controllerID, unsigned int hatID, unsigned char hatDir, const CAction &action)

I also fixed axis this way and was able to navigate in the menu within my n64 branch.
But it seems that this makes your axis act like a button and you cannot press A for acceleration + use of axis for left/right within mario kart for example.
So this is definitely not a real fix for the axis.

[ursli]

After Dippo was extremely helpful with updating his savegame branch on git to 13.2 I thought I'd try to be helpful too (at least for a small group of people) and get my compiled linux binaries of his branch online. I can finally save my progress with this.

I've tested the i386 deb package on my machine, couldn't test the amd_64 one yet. This should work on any somewhat recent ubuntu (precise onwards) install.

http://1drv.ms/1xg0EYw

edit: almost forgot, I've also cherry picked some of the ios8 fixes from helix, airplay should work with this build.

[natethomas]

Bumping this because I'm also curious about what's happening with save states at the moment. Rewinding is clearly working, since I use it all the time, so I assume there's some kind of state history going on. Have there been any really great thoughts on how to save states?

One idea is that the early version of state saving be almost identical to the current version of play history in videos. Kodi remembers where you stopped the game and asks if you want to resume there or start over. That, combined with some way of saving data in games where data saving is built in (like in final fantasy games, etc.), should probably be all that's really needed from a user perspective.

[garbear]

Save states have several properties:

• The specific edition (URL or crc) that the savestate belongs to
  
• The game client that created the save state
  
• The savestate type (Auto / Manual / Slot 1-9)
  
• The savestate slot (for slotted savestates)
  
• The time created
  
• The playtime, in frame count
  
• The playtime, in wall time
  
• The thumbnail
  
• Anything I'm missing?
  

This entails a database. In Retroplayer 12-alpha7, I wrote basic savestate database. In RetroPlayer 13, I dropped the database for various reasons

I also wrote a savestate manager based on the bookmark manager. When gameplay was stopped, a save state was automatically created. When gameplay resumed, the save state was automatically loaded. I call this "gameplay persistence". You could also press 1-9 to create a slotted savestate, and Shift+1-9 to load the slot. You could also manually create save states, and all savestates could be given a label.

Back to the database. Yesterday I outlined my idea of a "unified content database" (mostly to just get my thoughts down on paper). This wasn't clear, but the idea is to completely decouple the library from scraping. Anyway, the unified content database is designed to handle all Kodi content, and this includes save states.

So once we have a working database, savestates can return

[natethomas]

Fair enough. And save states based on the bookmark manager sound like a great idea. Will try my best not to nag you about databases for at least a while.

[Razze]

Can't the emulators handle save calls? So it would be compatible to every platform where this emulator has been ported to.
It would be awesome to sync your kodi save games to dropbox/etc and load them up on device X with emulator X.

But yeah, we could also force everyone to use kodi on every device

[garbear]

Savestates are only compatible with the libretro core that created them. But how does that restrict everyone to Kodi? RetroArch uses the same libretro cores, and thus the same savestates. You can load saves on any device/emulator that supports libretro