+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: Game support (https://forum.kodi.tv/forumdisplay.php?fid=292)
+--- Thread: RetroPlayer Test Builds (updated for Nexus) (/showthread.php?tid=173361)
Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
RE: RetroPlayer Test Builds (updated for Krypton) - EMK0 - 2016-05-01
(2016-05-01, 02:34)garbear Wrote: Thanks for the LibreELEC builds. On my part, I've fully implemented rewind & reverse seeking again. New builds will be up shortly.
Rewind relies on save states internally. Now it's simply a matter of writing these save states to the hard drive. The next build will contain save state support. It'll be simple, because there's no game database. Prolly just write a save state to the ROM's filename + .sav. How do other emulators do automatic savestates?
Retroarch saves the saves/save states next to the ROM
for example a SNES game
game name.sfc - ROM
game name.srm - SRAM Save
game name.state1 - Save States
One thing just noticed save stats are very big compared to even the roms
for example
This is a save state for a SNES rom, the rom is 512KB and its save state is game.state1 = 5883KB but zipped = 66KB
maybe in the future they can be compressed? it would save some hard drive space and a lot of space if you do lots of save states over time.
RE: RetroPlayer Test Builds (updated for Krypton) - motamas - 2016-05-01
(2016-04-30, 22:12)lrusak Wrote: More builds will be coming soon, for now Generic and RPi2 builds are all I am providing.
That sounds great! Could it be possible to build a rpi2 build which i can use on a bootloader like berryboot?
I would transform an image file by myself but i don't have a linux distribution where i could create a SquashFS formatted image ;D
RE: RetroPlayer Test Builds (updated for Krypton) - OmniBlade - 2016-05-03
(2016-05-01, 04:45)EMK0 Wrote: Retroarch saves the saves/save states next to the ROM
for example a SNES game
game name.sfc - ROM
game name.srm - SRAM Save
game name.state1 - Save States
One thing just noticed save stats are very big compared to even the roms
for example
This is a save state for a SNES rom, the rom is 512KB and its save state is game.state1 = 5883KB but zipped = 66KB
maybe in the future they can be compressed? it would save some hard drive space and a lot of space if you do lots of save states over time.
Retroarch can be configured with a number of behaviors and I personally dislike save states and SRAM being saved along side the roms. For a start it makes it harder to separate out the saves from the roms if, for example I wanted to move the saves to another system or share them with friends. I also use a fileserver for the rom files where the share is provided read only to most clients (I do this for video and audio as well), so that any compromised clients can't mess up the media store (think crypto locker type malware or just user error). Read only shares can't get saves saved along side the roms.
RE: RetroPlayer Test Builds (updated for Krypton) - zag - 2016-05-03
I actually like save states in a .sav file. Makes them nice and portable.
RE: RetroPlayer Test Builds (updated for Krypton) - longelf - 2016-05-03
(2016-05-03, 11:18)OmniBlade Wrote: I personally dislike save states and SRAM being saved along side the roms.
+1
There should a default folder to use out of the box, user-configurable to be any folder the user wants, with saves stored in sub-folders organised by system name to keep save files for the same game on different systems separate from each other so there is no filename conflict. You wouldn't want your save state for Dig Dug on the Gameboy overwritten when you played Dig Dug for the Atari 2600.
This makes them more portable, more shareable, easier to manage etc.
RE: RetroPlayer Test Builds (updated for Krypton) - zbuzanic - 2016-05-03
(2016-05-03, 15:27)longelf Wrote:(2016-05-03, 11:18)OmniBlade Wrote: I personally dislike save states and SRAM being saved along side the roms.
+1
There should a default folder to use out of the box, user-configurable to be any folder the user wants, with saves stored in sub-folders organised by system name to keep save files for the same game on different systems separate from each other so there is no filename conflict. You wouldn't want your save state for Dig Dug on the Gameboy overwritten when you played Dig Dug for the Atari 2600.
This makes them more portable, more shareable, easier to manage etc.
Folder for system should be optional. You can always add _nes, _c64, _snes, _pcx to filenames
RE: RetroPlayer Test Builds (updated for Krypton) - garbear - 2016-05-04
(2016-05-01, 04:45)EMK0 Wrote: Retroarch saves the saves/save states next to the ROM
for example a SNES game
game name.sfc - ROM
game name.srm - SRAM Save
game name.state1 - Save States
One thing just noticed save stats are very big compared to even the roms
for example
This is a save state for a SNES rom, the rom is 512KB and its save state is game.state1 = 5883KB but zipped = 66KB
maybe in the future they can be compressed? it would save some hard drive space and a lot of space if you do lots of save states over time.
(2016-05-03, 20:25)zbuzanic Wrote:(2016-05-03, 15:27)longelf Wrote:(2016-05-03, 11:18)OmniBlade Wrote: I personally dislike save states and SRAM being saved along side the roms.
+1
There should a default folder to use out of the box, user-configurable to be any folder the user wants, with saves stored in sub-folders organised by system name to keep save files for the same game on different systems separate from each other so there is no filename conflict. You wouldn't want your save state for Dig Dug on the Gameboy overwritten when you played Dig Dug for the Atari 2600.
This makes them more portable, more shareable, easier to manage etc.
Folder for system should be optional. You can always add _nes, _c64, _snes, _pcx to filenames
3 years ago, I did a retroplayer build that had a full-blown savestate manager. It was backed by a database, and supported 0-9 save slots, auto-save every 30 seconds, auto-save on exit, and manual saving. The savestate manager showed which of these types of savestate it was, the time it was created, a thumbnail, and also the total playtime up to that point. Savestates were named automatically, but could be renamed in the GUI.
Internally, savestates were stored in a folder under USERDATA in separate folders named after the libretro core (savestates aren't cross-compatible between cores). The filename was derived from the CRC of the ROM, so the saves followed the ROM even when it was relocated.
This works better than saving next to the ROMs because many locations aren't writeable (e.g. loading a ROM from within a zip) and the name would have to be appended with the full gameclient ID, e.g. game.libretro.snes9x-next, along with the other info (slot number, etc.) so filenames would quickly become unwieldy.
I dropped it from the code because the size of the RetroPlayer patch became too large for me to handle. Now, however, the code is in good enough shape that I can take on a project like this again. Is this something I should reintroduce?
RE: RetroPlayer Test Builds (updated for Krypton) - longelf - 2016-05-04
(2016-05-04, 00:38)garbear Wrote: Is this something I should reintroduce?
Absolutely, IMO a savestate manager is essential to the complete RetroPlayer experience, especially one where the location of the save states can be user configured and everything else is handled by the manager.
That said, in the interest of getting our hands on a fully working RetroPlayer build as soon as possible, it only needs to give us the basic functionality to begin with. All the other bells and whistles (auto-save, auto-load, multiple slots, thumbnails etc) can come later.
RE: RetroPlayer Test Builds (updated for Krypton) - garbear - 2016-05-04
(2016-05-04, 01:07)longelf Wrote: That said, in the interest of getting our hands on a fully working RetroPlayer build as soon as possible, it only needs to give us the basic functionality to begin with. All the other bells and whistles (auto-save, auto-load, multiple slots, thumbnails etc) can come later.
I've picked up the habit of API-first development. The key to this is the separation between abstraction and implementation. Creating interfaces is free, implementation takes work. Counter-intuitively, it is far less work to start with an interface full of bells and whistles than trying to hack them in later. Changing implementation is cheap. Changing interfaces sucks.
So to that end, I'd like to gather all the bells and whistles I can before writing code when it's cheap to do so. Name every feature you can, and I'll write an interface to back it. Once implementation begins, then we can start deciding which features are worth keeping and which we drop.
RE: RetroPlayer Test Builds (updated for Krypton) - delphiactual - 2016-05-04
Dropbox, OneDrive, and/or Google Drive support for saves/states
RE: RetroPlayer Test Builds (updated for Krypton) - garbear - 2016-05-04
That's what I'm talking about
RE: RetroPlayer Test Builds (updated for Krypton) - flipside101 - 2016-05-04
If you go down the Database route for save sates could this be shareable across boxes on the same network, i.e I save the state on box 1 in my lounge and pick it up on box 2 in the man cave ?
RE: RetroPlayer Test Builds (updated for Krypton) - karl_87 - 2016-05-04
I love the save manger idea.
Could we get an IPS manager for roms?
Eg - you click a special button on Super Mario World - then a list of IPS patches comes up. It applies patch to rom automatically. Then when using savestates, its sees the patch + Rom as an entirely new game.
This might also tie in with different regions of the same game. Eg - have Super Mario World in the list, press a special button, pick between euro, usa, japan.
This would take this project to a ridiculously high level!
RE: RetroPlayer Test Builds (updated for Krypton) - zag - 2016-05-04
Shouldn't we try to get retro player merged before starting on things like save game managers?
Just a thought
RE: RetroPlayer Test Builds (updated for Krypton) - Powerhouse - 2016-05-04
Yeah, quit making garbear add in cool stuff, just get RetroPlayer merged (so us regular gamers can drool over it), then add in the fluff.