• 1
  • 68
  • 69
  • 70(current)
  • 71
  • 72
  • 165
RetroPlayer Test Builds (updated for Nexus)
(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.
Reply
(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
Reply
(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.
Reply
I actually like save states in a .sav file. Makes them nice and portable.
Reply
(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.
Reply
(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
Reply
(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?
Reply
(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.
Reply
(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.
Reply
Dropbox, OneDrive, and/or Google Drive support for saves/states
Reply
That's what I'm talking about Smile
Reply
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 ?
Reply
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!
Reply
Shouldn't we try to get retro player merged before starting on things like save game managers?

Just a thought Wink
Reply
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.
Reply
  • 1
  • 68
  • 69
  • 70(current)
  • 71
  • 72
  • 165

Logout Mark Read Team Forum Stats Members Help
RetroPlayer Test Builds (updated for Nexus)16