+- 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
RE: RetroPlayer Test Builds (updated for Leia) - garbear - 2018-06-24
(2018-06-23, 11:21)KOPRajs Wrote: Is there already a way to disable the autosave feature? I believe this is a kind of option that is going to be useful even with the Save Manager in place.
What are the reasons someone would disable autosave?
(2018-06-23, 11:21)KOPRajs Wrote: Also I'd like to ask where can we follow the development? Is everything already merged to upstream Kodi?
Everything has been upstreamed. My builds only contain xml changes. You can track the changes by following github PRs tagged "Games": https://github.com/xbmc/xbmc/pulls?q=is%3Apr+sort%3Aupdated-desc+is%3Aclosed+label%3AGames
RE: RetroPlayer Test Builds (updated for Leia) - KOPRajs - 2018-06-24
(2018-06-24, 07:48)garbear Wrote: What are the reasons someone would disable autosave?Apart from testing e.g. to mimic the original game behaviour or to avoid generating of save files in the ROM directory etc. I believe this should be an optional feature as well as loading the autosave when launching the game. Similar like the promt when you open a video with resume or start from beggining.
P.S. Is there a way to reset the emulator from OSD menu?
RE: RetroPlayer Test Builds (updated for Leia) - Solo0815 - 2018-06-24
It would be nice, if you or milhouse could provide updated addons for Milhouse-RPi builds. Since ~2 weeks the emulator compatibility addon is broken (too old) and can't be activated. I'm looking forward to test all your improvements and fixes.
I tried to start a game, but it didn't work (of course). But afterwards, playing a video didn't work, also Live-TV. A restart did help. I reported this bug some time ago already.
You can reproduce this bug, if you disable the "emulator-compatibility" addon and try to lauch a game. After that, try to play a video or watch Live-TV
No deboug-log atm, my wife is occupying the RPi watcing TV
RE: RetroPlayer Test Builds (updated for Leia) - Julipo - 2018-06-25
I don't like autosave too. The other day I tested retroplayer, clicked in a game and the game openend just in game... was strange.
I always use save state and load state, never autosave.
But we can give some type of games where you don't want autosave: In all games that doesn't need memory (especially multiplayer: open game, click VS, select players, select map... you will need to go back or reset the game)
RE: RetroPlayer Test Builds (updated for Leia) - MrTarantula - 2018-06-25
For the majority of the history of emulation, loading a game has been a multi-step process, usually involving mouse/keyboard. The normal flow has always been Start Game->Load State or loading a save from the in-game menu. Are there even any emulators that have autosave?
One of the ideals of Retroplayer, as I remember reading it, is to have absolutely zero configuration. Literally just plug in a controller and start playing. Simple and effective. Someone starting with zero knowledge of emulators likely won't know what "save state" means. Autosave is simple and effective. It's kind of like sleep mode on a console, but each game "sleeps".
Nothing like Retroplayer has ever existed before. This is already shaping up to be the most comprehensive and accessible 10-foot interface for playing retro games, and it's far from finished (not complaining, I just know there are a lot of features planned but yet to be implemented). Processes that retro gamers have gotten used to or taken for granted may have to be re-examined, and sometimes changed. To be accessible, software has to be opinionated.
Whatever the decision on this, I trust garbear's (and the team's) vision for what he wants Retroplayer to be.
RE: RetroPlayer Test Builds (updated for Leia) - Solo0815 - 2018-06-25
How about a dialogbox, like in Films or TV-Shows if you start a ROM/game:
- Continue last autosave
- Open saved states (Then you can select which one to load)
- Start new game
RE: RetroPlayer Test Builds (updated for Leia) - MrTarantula - 2018-06-25
(2018-06-25, 17:14)Solo0815 Wrote: How about a dialogbox, like in Films or TV-Shows if you start a ROM/game:Would starting a new game implicitly destroy the autosave? Do you think selecting "Start a new game" should also pop a warning saying that autosave progress will be lost? In this scenario I think the warning should be required, but I'm also not a fan of this scenario.Maybe this is already there. Haven't tested since a few weeks. See 3 posts above
- Continue last autosave
- Open saved states (Then you can select which one to load)
- Start new game
The alternative would be to resume from the last autosave, and if you want to reset the game, do so from the OSD menu or hotkey.
RE: RetroPlayer Test Builds (updated for Leia) - Solo0815 - 2018-06-25
(2018-06-25, 17:52)MrTarantula Wrote: Would starting a new game implicitly destroy the autosave? Do you think selecting "Start a new game" should also pop a warning saying that autosave progress will be lost? In this scenario I think the warning should be required, but I'm also not a fan of this scenario.I don't know. Let's hear what garbear has to say
The alternative would be to resume from the last autosave, and if you want to reset the game, do so from the OSD menu or hotkey.
Maybe the autosave can be converted in a savestate if you start a new game. Then it could show something like "Autosave 25 Jun 2018 - 19:00" in the savestate manager (don't know the correct description/word).
RE: RetroPlayer Test Builds (updated for Leia) - MrTarantula - 2018-06-25
(2018-06-25, 19:07)Solo0815 Wrote: I don't know. Let's hear what garbear has to sayI like that idea, but also worry that it could eventually clog up savestates.
RE: RetroPlayer Test Builds (updated for Leia) - garbear - 2018-06-25
(2018-06-25, 17:01)MrTarantula Wrote: For the majority of the history of emulation, loading a game has been a multi-step process, usually involving mouse/keyboard. The normal flow has always been Start Game->Load State or loading a save from the in-game menu. Are there even any emulators that have autosave?
One of the ideals of Retroplayer, as I remember reading it, is to have absolutely zero configuration. Literally just plug in a controller and start playing. Simple and effective. Someone starting with zero knowledge of emulators likely won't know what "save state" means. Autosave is simple and effective. It's kind of like sleep mode on a console, but each game "sleeps".
Nothing like Retroplayer has ever existed before. This is already shaping up to be the most comprehensive and accessible 10-foot interface for playing retro games, and it's far from finished (not complaining, I just know there are a lot of features planned but yet to be implemented). Processes that retro gamers have gotten used to or taken for granted may have to be re-examined, and sometimes changed. To be accessible, software has to be opinionated.
Whatever the decision on this, I trust garbear's (and the team's) vision for what he wants Retroplayer to be.
This. Well said, thanks.
My ultimate value is accessibility. If you're familiar with the concept of the "technical divide", it means that the use of technology requires exposure to technology. Any amount of technical overhead is a barrier to gameplay for someone.
(2018-06-25, 17:14)Solo0815 Wrote: How about a dialogbox
No dialog boxes. In UX design we call this "friction". The time between intending to play a game, and actually playing the game, needs to approach zero. Most users don't want to think. They certainly don't want to read. They want to play. We can either resume from power-on or autosave, and it's better to guess wrong than force the user to make this choice.
RE: RetroPlayer Test Builds (updated for Leia) - garbear - 2018-06-25
(2018-06-25, 19:07)Solo0815 Wrote: I don't know. Let's hear what garbear has to say
I've done some thinking from a 1000 foot view. While building the unfinished Player Manager, I realized what is most important: the people who play. Build an interface that reflects their values, not the problem to be solved.
I'm creating a value framework to drive saved game development. Here are some values I've identified:
Enjoyment
For some, saving means recording a memory. Access to this saved game invokes nostalgia, which is the recollection of the enjoyment experienced during the original gameplay.
- We could prioritize saves. Manual saves (requiring effort) are more important than auto saves. Later saves (with a higher level/stats) are more important than earlier saves.
- We could scrape memory and annotate saves with game details, such as the number of heart containers, levels cleared, or pokemon captured. This includes achievements from retroachievements.org.
Boredom
For some, saving is a tool. It avoids duplicate gameplay. Without boredom the player would play the shortest, highest-dopamine-release segment without end. Boredom forces the player to explore new levels and new games.
- This value is inherent in saving itself, so I'm not sure what design changes to make, if any.
Accessibility
For some, saving is cheating. Old games are difficult. Look at the incentives: arcades want your quarters. Some games are designed to be too difficult at the final levels to keep you jamming in quarters. Instant saving and loading, not intended in the original game, makes some games easier and possible to beat.
- We could show the number of times the user loaded each save.
Free as in beer
For some, saving is cheap. Savestates are small and don't require the purchase of additional storage or other computing infrastructure.
- Saving gets cheaper the older the hardware. It also gets cheaper over time, as storage sizes increase and storage costs fall. Compression algorithms get created, ported and improved.
- This leads to the perfect nexus I call "save everything". What if, like seeking in a movie, you can seek through your entire gameplay experience? Kind of like the "hero's path" mode in Breath of the Wild.
That's all the values I've identified so far. If you think of additional values, let me know.
A lot of details and conjectures have been presented in this thread. Let's analyze each one in accordance with one or more values, and we'll know if it should be included or not.
RE: RetroPlayer Test Builds (updated for Leia) - MrTarantula - 2018-06-25
I don't really have any responses to any of that right now, but I'll give it some thought.
(2018-06-25, 22:12)garbear Wrote: We could scrape memory and annotate saves with game details, such as the number of heart containers, levels cleared, or pokemon captured. This includes achievements from retroachievements.org.This sounds amazing, but it also sounds like a ton of overhead. Is there a database of which bits of saves correspond to those values, for a significant number of games? Or is this a brand new concept, requiring both new functionality and new data?
I'm also not too familiar with how retroachievements works, but I assumed that achievements were (like consoles) per game, per user. Can achievements be quantified per game save?
RE: RetroPlayer Test Builds (updated for Leia) - longelf - 2018-06-26
(2018-06-02, 20:21)garbear Wrote:(2018-06-02, 02:16)longelf Wrote: Seems any time I try to launch a zipped ROM, no matter the ROM or platform, it crashes Kodi.
Let me know what you find. I'll try to reproduce on my end. Thanks for reporting.
I have tried everything short of a complete rebuild of Windows and I can't find the issue. Interestingly, I have your builds running fine under Windows 10 but two machines running 32 bit and 64 bit Windows 7 both crash trying to open a zipped ROM. These two machines couldn't be more different in terms of hardware, so I'm not convinced it's a conflict with anything. Windows 7 is the only thing in common between these machines, and Windows 10 is just fine. Unzipped ROMs work just fine too so it seems to be a VFS / Windows 7 issue of some sort. Crash logs are useless as they don't show the ROM launching let alone the crash.
RE: RetroPlayer Test Builds (updated for Leia) - garbear - 2018-06-26
(2018-06-25, 23:08)MrTarantula Wrote: I don't really have any responses to any of that right now, but I'll give it some thought.
Hahaha I'm totally stuck working on a module that can handle both rewind and savestates, and when I get stuck I get all philosophical and give non-answers. Deal with it
(2018-06-25, 23:08)MrTarantula Wrote: I'm also not too familiar with how retroachievements works, but I assumed that achievements were (like consoles) per game, per user. Can achievements be quantified per game save?
Achievements work by scraping game memory; e.g. if I know that the byte at the RAM address $0010 (hex) stores the current level, then I can activate an achievement such as "Get to level 5" by waiting for this byte to reach the value 5. Achievements are calculated every single frame. So every frame and every savestate we can calculate (certain) achievements.
There is an exception: Some achievements have a "hysteresis". This is a "memory effect", where the achievement depends on previous frames. E.g. to protect against cheating, "Get to level 5" might require the address $0010 to be a 1, then 2, then 3, then 4, then 5, so the user can't load a downloaded savestate and automatically get the achievement.
Therefore, the internal state of the achievement engine must become part of the savestate and be saved alongside the emulator's RAM. Not a big deal, it just requires more work on my part to create an archival format to handle both emulator and achievement state.
To answer your question about per-user:
In RetroArch, you go to settings, then enter your retroachievements username and password. Achievements are reported for this account.
In Kodi, we can trivially do the same. However, this locks us into an architecture with a single global user. And fuck changing architecture; this can take days if not weeks. Instead, from the beginning I'll make savestates centered around the people who are playing. Each player can have their own achievements and saved games, saved games can share users, and users can share saved games.
RE: RetroPlayer Test Builds (updated for Leia) - garbear - 2018-06-26
(2018-06-26, 03:51)longelf Wrote:(2018-06-02, 20:21)garbear Wrote:(2018-06-02, 02:16)longelf Wrote: Seems any time I try to launch a zipped ROM, no matter the ROM or platform, it crashes Kodi.
Let me know what you find. I'll try to reproduce on my end. Thanks for reporting.
I have tried everything short of a complete rebuild of Windows and I can't find the issue. Interestingly, I have your builds running fine under Windows 10 but two machines running 32 bit and 64 bit Windows 7 both crash trying to open a zipped ROM. These two machines couldn't be more different in terms of hardware, so I'm not convinced it's a conflict with anything. Windows 7 is the only thing in common between these machines, and Windows 10 is just fine. Unzipped ROMs work just fine too so it seems to be a VFS / Windows 7 issue of some sort. Crash logs are useless as they don't show the ROM launching let alone the crash.
I'm in Yosemite this week, so I can't reproduce for a while. Also my Windows 7 dev environment bit the dust. Give me another week or two and I'll look into this.