Posted: 7/26/2006 2:45 PM
Post subject: Possible bug to watch for when "Starting from reset"
Quote
JXQ
Experienced player (761)
Joined: 5/6/2005
Posts: 3132
NES TAS of 2008 Speedy TAS of 2008 SNES TASer of 2007 TAS of 2007 SNES TAS of 2007 Funny TAS of 2007
When you record a new movie, you can record from "Start", "Reset", or "Now". The correct choice, when submitting a movie here, is "Start", which is a hard-reset, or power-on. I've had an error twice now that I haven't noticed until the run was finished. The submission php denies my file with the error message "FCM error: Movie does not begin with a reset". I think FCEU may have a problem when creating movies under certain circumstances, although I haven't been able to reproduce it yet. To make sure that your movie files are safe, use a hex-editor to check for the following: 1) Look at the values in offset 001C through 001F. Take the four bytes and read them in reverse order (this is called "little endian" order). For example, if your four bytes read B4 34 01 00, then reverse the bytes (not the half-bytes), to get 00 01 34 B4. This value is the beginning of your controller input data. In this case, 134B4. 2) Check this new offset. The value of this offset MUST be 82, which is controller code for a hard reset. Although the game may start at a reset (as this is also checked in offset 08, bit 2), the php of the site will not accept the file if the first controller byte is not 82. In both cases this has happened to me, simply inserting a reset command at the beginning of the controller input, and increasing the value in offset 0014 by 1 (which represents the length of the controller input in the file) has fixed it without desync. (0014 is also 4 bytes long and in little-endian order) I'll be keeping an eye on my movie files; if I'm able to consistently reproduce this bug then I'll let everyone know.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Posted: 7/26/2006 3:51 PM
Quote
hanzou
Player (21)
Joined: 10/14/2005
Posts: 317
I've been aware of a bug along these lines since I fixed your SMB3 run, but I wasn't sure if this issue was worth raising back at the time. Since it has already happened a second time and it'll probably happen again, I guess we should do something about it now. The problem with your SMB3 run was not that it had 81 (reset) rather than 82 (power-on). I think the submission page is designed to still accept even reset-based movies. The problem with that file when I looked at it in a hex editor was that it contained neither 81 nor 82. However, FCEU still reported that file as reset-based. Old (non-rerecording) versions of FCEU can still play these .fcm files, right? Because FCEU defines the standard, I think the bug may be in the submission webpage not the emulator itself. Here is a possibility. Perhaps we can take the guarantee that 81 -> reset and 82 -> power-on, but due to compression it cannot be assumed that reset -> 81 nor power-on -> 82? (Read the '->' symbol as 'implies'.)
Posted: 7/26/2006 4:20 PM
Quote
JXQ
Experienced player (761)
Joined: 5/6/2005
Posts: 3132
NES TAS of 2008 Speedy TAS of 2008 SNES TASer of 2007 TAS of 2007 SNES TAS of 2007 Funny TAS of 2007
In this second case, it wasn't a bug in the submission webpage (Bisqwit showed me the code for it). It does allow 81 or 82 (I believe). My Little Samson movie that didn't work didn't have 81 or 82, it had 23, which is a press of the start button. So it never put that reset (soft reset OR power-on) in at all. I know I didn't record from "Now" or a savestate, so I think it's a bug in the emulator, although I don't know how to reproduce it. I believe FCEU still reports the file as reset/power-on based on byte 08. However, I seem to be the only person to have done this, so it's possible that it's something I'm doing as well.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Posted: 7/26/2006 4:21 PM
Quote
Bisqwit
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
hanzou wrote:
Here is a possibility. Perhaps we can take the guarantee that 81 -> reset and 82 -> power-on, but due to compression it cannot be assumed that reset -> 81 nor power-on -> 82? (Read the '->' symbol as 'implies'.)
No, these values are correct. It is only if the power-on or reset does not happen at the first frame (i.e. there's delay before the reset/poweron happens), that the byte may be different from 81 or 82. By the way, I remind that there exists this cool FCM parser which tells you what each byte means. http://bisqwit.iki.fi/utils/fcmparser.php
Posted: 7/26/2006 5:06 PM
Quote
JXQ
Experienced player (761)
Joined: 5/6/2005
Posts: 3132
NES TAS of 2008 Speedy TAS of 2008 SNES TASer of 2007 TAS of 2007 SNES TAS of 2007 Funny TAS of 2007
That's a neat utility. On a side note, after learning the FCM format a little better, I think it's dumb to have FCEU include a savestate on a movie that starts from reset. Either it's pointless because it's all changed to default values once the reset command is reached, or it's somehow used, which would compromise the integrity of the format.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)