replays bug(s)

Open-source port of PoP that runs natively on Windows, Linux, etc.

Moderator: English Moderator Team

User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 3140
Joined: April 9th, 2009, 10:58 pm
Contact:

Re: replays bug(s)

Post by Norbert » January 6th, 2017, 5:49 pm

Also, does the "(none)" under the "Browse..." portion change to something else when you've selected a file?

And, was the name of the file you tried to upload "01.p1r"?

User avatar
oitofelix
Wise Scribe
Wise Scribe
Posts: 202
Joined: February 17th, 2016, 1:59 pm
Contact:

Re: replays bug(s)

Post by oitofelix » January 6th, 2017, 6:07 pm

Norbert wrote:I just tried to upload the file in the production environment (the live website), and for me it works.
Indeed, I could fetch the file you uploaded.
Norbert wrote:Can you tell me what exactly you did?
I chose the option "lvl1" in the choose box, and then clicked "Browse" button, then changed "*.pr1" to "All files" in the file selection dialog box, selected a local version of 01.mrp, clicked in "Open" button of that dialog, and then clicked in "Add" button at the web page.
Norbert wrote:Also, can you retry adding it.
Have tried and obtained the same 404 result.

PS: By the way the site never keeps me logged in, even I requesting it to do so.

Code: Select all

 88888  FFFFF Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
 8   8  F     http://oitofelix.freeshell.org/mininim/
 88888  FFFF  mailto:oitofelix@gnu.org
 8   8  F     irc://chat.freenode.org/oitofelix
 88888  F     Please, support my work: http://oitofelix.freeshell.org/funding.html

User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 3140
Joined: April 9th, 2009, 10:58 pm
Contact:

Re: replays bug(s)

Post by Norbert » January 6th, 2017, 6:14 pm

oitofelix wrote:[...], then changed "*.pr1" to "All files" [...] selected [...] 01.mrp
Okay, that pretty much explains it. I renamed 01.mrp to 01.p1r before uploading. So there's probably an abort missing in the part between where the code doesn't accept files other than *.p1r and where it saves the information in the database. I'll look at that, plus I still need to make these changes that accept *.mrp on the client _and_ server side.

Not staying logged-in: I also have that issue, it's something I need to look into one day.

Falcury
Wise Scribe
Wise Scribe
Posts: 329
Joined: June 25th, 2009, 10:01 pm

Re: replays bug(s)

Post by Falcury » January 7th, 2017, 11:43 am

oitofelix wrote:As I announced here, replays have been added to MININIM. For this feature in action see here. This post is intended to describe MININIM's replay file format and give a rationale for it.
Nice work!
oitofelix wrote:Replay files should carry the absolute minimum information about the engine state (usually only what can be provided by user configuration), and the engine must ensure it can reliably record and reproduce the derivative states in all applicable situations, not allowing the user to interfere in any way with the results (by subsequent reconfiguration of the engine using command line or key bindings, let's say).
Yes, this is also the reason for including many of the configuration options into the SDLPoP replay format. Some of the bug fixes may be very subtle and almost never noticeable... however, they can all be individually configured; and, if the configuration at recording time doesn't exactly match the configuration while replaying, this could cause a replay to become unreproducible.
oitofelix wrote:Doesn't exclude the possibility of movements using two directions in the same axis. MININIM implements smooth command-movement transition, and heavily uses such feature for the player's convenience. As I understand it that would be impossible using SDLPoP's move encoding.
Yes, for SDLPoP it made sense to encode it this way, because it reflects the way movement is handled in the game.
oitofelix wrote:Save states are inherently non-portable. It's prohibitively difficult to make save state information shareable across different sets of architectures (wideness and endianness), after all they are basically a memory snapshot (a very architecture dependent thing), and it's difficult to ensure stability across different releases --- a relatively minor change to the engine may have profound implications on how save states are represented.
You're right of course... Although for SDLPoP, endianness isn't an acute issue for savestates, because the program is not prepared to handle big-endian architectures anyway (it even gives an #error in types.h).

User avatar
oitofelix
Wise Scribe
Wise Scribe
Posts: 202
Joined: February 17th, 2016, 1:59 pm
Contact:

Re: replays bug(s)

Post by oitofelix » January 7th, 2017, 5:05 pm

Falcury wrote:Nice work!
Thank you. :)
Falcury wrote:Yes, this is also the reason for including many of the configuration options into the SDLPoP replay format. Some of the bug fixes may be very subtle and almost never noticeable... however, they can all be individually configured; and, if the configuration at recording time doesn't exactly match the configuration while replaying, this could cause a replay to become unreproducible.
My experience with replays shows that ensuring reproducibility (particularly across releases) is a very delicate and subtle art. Working on this made me realize the intricacy and complexity of the issue --- things I hadn't been aware before.
Falcury wrote:Although for SDLPoP, endianness isn't an acute issue for savestates, because the program is not prepared to handle big-endian architectures anyway (it even gives an #error in types.h).
What about wideness? Are SDLPoP's save states shareable across different widenesses?

Code: Select all

 88888  FFFFF Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
 8   8  F     http://oitofelix.freeshell.org/mininim/
 88888  FFFF  mailto:oitofelix@gnu.org
 8   8  F     irc://chat.freenode.org/oitofelix
 88888  F     Please, support my work: http://oitofelix.freeshell.org/funding.html

David
The Prince of Persia
The Prince of Persia
Posts: 1496
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: replays bug(s)

Post by David » January 8th, 2017, 12:38 pm

oitofelix wrote:What about wideness? Are SDLPoP's save states shareable across different widenesses?
If you mean 32-bit and 64-bit, that was solved here: https://github.com/NagyD/SDLPoP/commit/ ... e2032474bd

User avatar
oitofelix
Wise Scribe
Wise Scribe
Posts: 202
Joined: February 17th, 2016, 1:59 pm
Contact:

Re: replays bug(s)

Post by oitofelix » January 8th, 2017, 3:09 pm

David wrote:
oitofelix wrote:What about wideness? Are SDLPoP's save states shareable across different widenesses?
If you mean 32-bit and 64-bit, that was solved here: https://github.com/NagyD/SDLPoP/commit/ ... e2032474bd
I see those are save state meta-information within replays. I was really thinking about the save state itself. Quickly looking at SDLPoP's source code, it seems the relevant variable is savestate_buffer (replay.c) which is an array of bytes. How is it exactly used? Is all information contained therein stored and retrieved in fields of fixed width?

Code: Select all

 88888  FFFFF Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
 8   8  F     http://oitofelix.freeshell.org/mininim/
 88888  FFFF  mailto:oitofelix@gnu.org
 8   8  F     irc://chat.freenode.org/oitofelix
 88888  F     Please, support my work: http://oitofelix.freeshell.org/funding.html

Falcury
Wise Scribe
Wise Scribe
Posts: 329
Joined: June 25th, 2009, 10:01 pm

Re: replays bug(s)

Post by Falcury » January 8th, 2017, 11:18 pm

oitofelix wrote:I see those are save state meta-information within replays. I was really thinking about the save state itself. Quickly looking at SDLPoP's source code, it seems the relevant variable is savestate_buffer (replay.c) which is an array of bytes. How is it exactly used? Is all information contained therein stored and retrieved in fields of fixed width?
The savestate fields all have fixed width types if I remember correctly... (Though now that you mention it, I am not fully sure that the struct padding is fixed for all struct fields...) The relevant procedure is quick_process() in seg000.c. It is called from quick_load() and quick_save() in seg000.c, as well as restore_savestate_from_buffer() and savestate_to_buffer() in replay.c.

Falcury
Wise Scribe
Wise Scribe
Posts: 329
Joined: June 25th, 2009, 10:01 pm

Re: replays bug(s)

Post by Falcury » January 22nd, 2017, 5:46 pm

In this commit, I fixed replays not ending properly upon reaching the Princess room:
https://github.com/NagyD/SDLPoP/pull/12 ... f940e4ac1b

I also tweaked some other replay-related stuff.
See these pull requests:
https://github.com/NagyD/SDLPoP/pull/120
https://github.com/NagyD/SDLPoP/pull/121
  • Show error message in a dialog box if replay loading failed
    To make it more obvious what went wrong if you double-click a replay file, we can use SDL_ShowSimpleMessageBox to display the error message using a system dialog. (Should be useful, because not everyone would always look at the console output I think...)
  • Don't play end level music while recording or replaying
    The end level music causes problems, because the next level is loaded exactly when the music stops. We can avoid this problem by simply not playing the music in replays (both while recording, and while replaying). This also improves the pace of replays -- waiting time between levels is reduced
    This should make replays fully reproducible across multiple consecutive levels.
  • Don't allow quickloading while recording a replay
    Obviously, quickloading would mess up a recording, because the quickload is not captured into the replay.
  • Replay save dialog
    After recording, display a dialog box to ask for the replay filename. (This replaces the automatically generated replay filenames)
    Replayed can also be discarded by pressing Escape. (That closes the dialog box without saving the replay.)
I attached a test replay, where I played through levels 4-14 consecutively. It's not a very clean playthrough by any means. Just to show that it is possible :)
Note: to view the replay without the game running out of sync after the level transitions, it's necessary to apply the change from this commit:
https://github.com/NagyD/SDLPoP/pull/12 ... 76c7fce90c
Attachments
levels 4-14 playthrough.p1r
(15.65 KiB) Downloaded 9 times
save_replay.png
save_replay.png (6.96 KiB) Viewed 175 times
replay_error_message.png
replay_error_message.png (24.2 KiB) Viewed 175 times

Post Reply