Ah, I forgot to update that part. :P I'll do it now.
You can see it here at the moment: pxmFileFormat (look at "Control Byte"). That byte tells the emulator what it should do at each frame. If the "movie does use hacks" flag is not enabled in the header, then "Enable/Disable "SIO/SPU IRQ Always Enabled" hack" bit is ignored by the emulator. The same happens for "Enable/Disable cheats".
Those hacks are needed by some games (Metal Gear Solid for example), and cheats may be needed by some PAL games to pass some copy-protections.
Was the control byte added before or after some PXM movies were created that are about to be submitted here? Can it be detected somehow, to know whether a control byte is to be expected or not?
Also, this movie file format you linked to does not indicate which CD is inserted.
And, how is it handled during movie playback? Is the movie watcher expected to change the CD atomically in 1-frame, if such operation was done in frame-advance during movie creation?
How about if the CD case is opened & closed during the same frame? For example, frames 0―1000, "CD 1" is inserted, frames 1001―3000, "CD 2" is inserted.
Consider the possibility that during normal play, while the game is reading data from the CD, the player suddenly takes the CD out and puts another in, changing the game radically.
How about the "enable/disable cheats" -- how does that work? Can it be used to abuse the submission system? If the movie file header attests "movie does not contain embedded cheat list", is the "enable/disable chats" command a no-op?
Was the control byte added before or after some PXM movies were created that are about to be submitted here? Can it be detected somehow, to know whether a control byte is to be expected or not?
Was added after, I guess. There is a tool to losslessly convert old PXM v1 movie files into PXM v2 movie files. It is always to be expected.
Bisqwit wrote:
Also, this movie file format you linked to does not indicate which CD is inserted.
And, how is it handled during movie playback?
Each CD information is saved at the CD-ROM IDs chunk.
During recording, each time the CD case is opened there is a currentCD++, a totalCDs++ and also the new CD-ROM ID is saved.
During playback, each time the CD case is opened, a dialog pops up and tells you which CD-ROM ID comes now, and waits until you insert it.
Bisqwit wrote:
How about the "enable/disable cheats" -- how does that work?
You can enable/disable the loaded cheat list on the fly.
Bisqwit wrote:
If the movie file header attests "movie does not contain embedded cheat list", is the "enable/disable chats" command a no-op?
That's correct. For this reason it cannot be used to abuse the system.
*EDIT:* didn't see these question when I clicked on "add reply":
Bisqwit wrote:
Is the movie watcher expected to change the CD atomically in 1-frame, if such operation was done in frame-advance during movie creation?
There is a dialog which pauses the whole emulator. Until the movie watcher doesn't click "OK", the movie won't advance further.
Bisqwit wrote:
Consider the possibility that during normal play, while the game is reading data from the CD, the player suddenly takes the CD out and puts another in, changing the game radically.
That's a possibility. I don't think there's a reason to keep him from doing that, since that also can be made in a real PlayStation.
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
How about if the CD case is opened & closed during the same frame? For example, frames 0―1000, "CD 1" is inserted, frames 1001―3000, "CD 2" is inserted.
How about if the CD case is opened & closed during the same frame? For example, frames 0―1000, "CD 1" is inserted, frames 1001―3000, "CD 2" is inserted.
It's not possible to be opened and closed during the same frame. I don't understand the second sentence. :/
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
It's not possible to be opened and closed during the same frame. I don't understand the second sentence. :/
The second sentence means: For the duration of the first 1001 frames (frames 0-1000), "CD 1" is and has been inserted in the system.
Then the emulation is paused, CD ejected, "CD 2" inserted and emulation resumed.
From frame 1001 onwards, CD 2 is and has been inserted.
So a CD change event happened on frame 1001: An open & close on the same frame.
What happens if the player attempts to do this?
It's not possible to be opened and closed during the same frame. I don't understand the second sentence. :/
The second sentence means: For the duration of the first 1001 frames (frames 0-1000), "CD 1" is and has been inserted in the system.
Then the emulation is paused, CD ejected, "CD 2" inserted and emulation resumed.
From frame 1001 onwards, CD 2 is and has been inserted.
So a CD change event happened on frame 1001: An open & close on the same frame.
What happens if the player attempts to do this?
It's not possible to open and close the CD case on the same frame, because it is a "toggle" flag which is processed on each frame.
I hope that answers your question, because I'm not sure I understand the problem correctly. I see no issue if what you're proposing would be possible to do.
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
So what happens if the player does as I described above?
I.e. pauses emulator, switches CD, unpauses emulator.
(It's not entirely a hypothetic question: I did precisely this every time I replaced CD during the creation of my Chrono Cross TAS on pSX.)
So what happens if the player does as I described above?
I.e. pauses emulator, switches CD, unpauses emulator.
(It's not entirely a hypothetic question: I did precisely this several times during the creation of my Chrono Cross TAS on pSX.)
Ah, I get it now.
PCSX has no way to detect you've switched CD, unless you use the Open CD Case function first.
So, if he's changing the CD without telling the emulator he's opening the CD case, he would be just creating a desync.
Also, there's no way to switch CDs without opening the CD case first on a real PlayStation.
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
So to change CD during creation of a PCSX TAS, you will have to use the menu function labelled "Open cd case" instead of just pressing the equivalent button in the CD drive?
Is that obvious? Are people prone making a mistake there?
Also, what happens if you hit that menu selection while the emulator is paused? Does it automagically create two event frames to the movie, or what? Does it unpause automatically? How are you supposed to do CD changes frame-precisely?
So to change CD during creation of a PCSX TAS, you will have to use the menu function labelled "Open cd case" instead of just pressing the equivalent button in the CD drive?
Is that obvious? Are people prone making a mistake there?
It's a hotkey. When you are recording a movie and press that hotkey while emulation is paused, a message pop-ups saying "CD Case Will Open On Next Frame", if you press that hotkey again without frame-advancing it will say "CD Case Won't Open On Next Frame". I think it should be obvious what it does and hopefully people won't be prone making a mistake there.
Bisqwit wrote:
Also, what happens if you hit that menu selection while the emulator is paused? Does it automagically create two event frames to the movie, or what? Does it unpause automatically? How are you supposed to do CD changes frame-precisely?
It raises a flag telling the emulator it should Open/Close the CD case on the next frame. It doesn't unpause, and it doesn't create two event frames.
You have the control to tell the emulator on which frames you open and close the case.
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
Blargh, I just noticed that the frame counter no longer goes red to indicate a lag frame now, it simply updates the lag frame counter. I tried swapping the graphics plugin for an older version, but it seems to be unrelated to that.
Blargh, I just noticed that the frame counter no longer goes red to indicate a lag frame now, it simply updates the lag frame counter. I tried swapping the graphics plugin for an older version, but it seems to be unrelated to that.
Uh, yeah. I broke that functionality for the third time now, I think.
Well, it will be fixed for 0.0.7, thanks for reporting. In the meantime, you can download an interim version with that bug already fixed from here: pcsx-rr-v007-beta.7z.
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
Uh, yeah. I broke that functionality for the third time now, I think.
Well, it will be fixed for 0.0.7, thanks for reporting. In the meantime, you can download an interim version with that bug already fixed from here: pcsx-rr-v007-beta.7z.
Thanks, that worked great :)
However, I seemed to have found another problem, this time with savestates and read only that's likely to be a rather sizable cause of rage and desyncs.
The biggest issue here is the savestates , which as a result cause part of the read only issue (which in itself is quite a big point though). Savestates seem to save one extra frame of input for the frame after they're made. Eg. in the current movie I'm (re)making, a savestate (lets call it SS3) I made at frame 2037 contains all the input upto and including frame 2037, but also the input that was present on frame 2038.
I'm able to use the savestate to record new input on frame 2038 and beyond, but the savestate replaces the input that's present on frame 2038 when playing back with that which it has stored (which is different to that which is is used in the movie). I have another savestate (lets call this SS4) at frame 2100 or so just to test other things, and to save the new input I had made.
This leads to the read only issue. Since I haven't reloaded SS3, the input recorded and present in SS4 is what plays back when loaded from SS1 (a savestate made at the beginning of the stage) in read only mode. I can load SS1 and get the same result time and time again without issue.
Now, when I load SS3 in read only mode, since the movie progresses further than frame 2037, the input that's supposed to be present for frame 2038 is replaced by the input stored in SS3 and the movie desyncs. You'd think "ok, that's fine, just don't load that savestate then" but the problem doesn't end there.
When loading from SS1 again without having switched from read only to read+write, playing back the movie again, the movie has all the input from SS4, except for the frame that was replaced when loading SS3, causing the movie to desync when it reaches frame 2038.
Regardless of the fact that the movie shouldn't have been affected by loading SS3 while in read only mode, it seems to replace the input with whatever was present in the savestate and just uses whatever is left in the movie file to fill the remaining frames. Loading SS4 fixes the input that SS3 busted, but at the same time still overwrites input while in read only despite the fact it shouldn't alter it at all.
And that's it.
I hope this wall of text gets through what I mean, because I absolutely suck at describing things.
Let me see if I undertood correctly what you said: do you mean when you load a savestate at frame 2000 in read-only mode it still replaces the current movie input at frame 2001? Is that correct?
Is there also another different issue apart from this one or the other one is just a side effect of this bug?
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
mz wrote:
you can download an interim version with that bug already fixed from here: pcsx-rr-v007-beta.7z.
When I click file - movie - start playback, it crashes the emulator. Is it a plugin issue?
edit: it crashes when doing the same on the 0.0.6 version downloaded on the first post on this topic. It doesn't happen on version 0.0.5 which I have here on my pc.
It only crashes when clicking "start playback". It crashes immediately even before I can browse for files.
It crashes even when there are no movie files inside the movie folder.
Let me see if I undertood correctly what you said: do you mean when you load a savestate at frame 2000 in read-only mode it still replaces the current movie input at frame 2001? Is that correct?
Yes, that's pretty much it. I don't think it'd apply if the savestate was made at the last frame of a movie, but then again, it might just make the next frame have no input. I didn't check.
Is there also another different issue apart from this one or the other one is just a side effect of this bug?
It seems like it could be a side effect, but it might not be related. I didn't check, because a) the movie that I could test one breaks when converting (AngerFist might have asked you about it), and b) I don't have savestates for it to test. But basically I think read-only mode isn't quite as read-only as it should be. loading a savestate that causes a desync while in read-only shouldn't make the desync present in the movie next time it's played back from an early savestate.
When I click file - movie - start playback, it crashes the emulator. Is it a plugin issue?
Uhm, if it only crashes for you since 0.0.6 it must be because it now calls the CheckCdrom() function to get the current CD ID...
Are you using the default TAS CD-ROM plugin or another one?
Atma wrote:
a) the movie that I could test one breaks when converting (AngerFist might have asked you about it)
Nope, he didn't. I'd like to take a look at that movie file if you can upload it somewhere.
Atma wrote:
loading a savestate that causes a desync while in read-only shouldn't make the desync present in the movie next time it's played back from an early savestate.
Loading a savestate should never make a desync. It never loads any input information from the savestate when you're replaying a movie.
It'd be great if you could upload that movie file and those SS3 and SS4 savestates somewhere. If you can't, that's fine too, but it might take a bit more of time until I'm able to reproduce that bug...
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
mz wrote:
Uhm, if it only crashes for you since 0.0.6 it must be because it now calls the CheckCdrom() to get the current CD ID...
Are you using the default TAS CD-ROM plugin or another one?
TAS plugin yes, it crashes. It also crashes if I use PEOpS CDR Driver 1.4.
I could record the movie fine, just can't play it back.
I'm using a game CD (not image), and my cd-rom is standard "D:"
Could you please test with another CDR plugin like Xeven's CDR Plugin on this page?
Also, could you test replaying the movie this way?:
1. Start the game normally using "File->Run CD".
2. Once in-game, press the "Start Playback" hotkey ("Control + R" by default) and let me know if it still crashes.
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
mz wrote:
Could you please test with another CDR plugin like Xeven's CDR Plugin on this page?
Also, could you test replaying the movie this way?:
1. Start the game normally using "File->Run CD".
2. Once in-game, press the "Start Playback" hotkey ("Control + R" by default) and let me know if it still crashes.
Download this test version, please: test.7z. I've disabled the CheckCdrom() function in it.
If it still crashes, I'll have to take a deeper look and find what else could have been changed between 0.0.5 and 0.0.6 there...
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
Yeah, still crashing even when using all types of different plugins and different ways to try to playback the movie. :( Maybe it's my game? I'll try another one. edit: still crashing.
I don't think it could be the game because that menu doesn't load any CD information yet.
Until I can find a cause for that bug, your only choice will be using the "-play movies/movie.pxm" command line parameter. If that still crashes, then... Well, at least I'll be able to narrow down the possible causes of this bug, so please let me know if it does still crash. :P
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
That worked!!! It played the movie I just recorded. (I used the version which had that Checkcdrom() thingy).
The only problem is that it didn't record the buttons (square,triangle, X and O). I guess that's the input plugin. It did record the arrows and START though.