One thing I noticed when we were demo'ing Dexter rev 1 at CAX last year was that sometimes certain incorrect frames would show up at the beginning of scenes. What I wasn't sure of was whether the incorrect frame was due to overrun or due to the ROM seeking to the wrong starting position. Well, I have pretty solid evidence now that the ROM appears to be seeking to the wrong starting position for some of the scenes, such as the "colored balls" scene. My logging clearly shows that it is seeking to frame 26042 which you can see in this screenshot is the combination of the end of the previous scene and the beginning of the next. The thing that puzzles me, however, is, "Why have I never noticed this before?" Surely this must happen on original hardware but I've never noticed it. Has anyone else?
Here's the relevant log snippet:
lair: -> FF
lair: <- E4
lair: -> 8F
lair: <- 64
lair: -> FF
lair: <- E4
lair: -> 6F
lair: <- 64
lair: -> FF
lair: <- E4
lair: -> 3F
lair: <- 64
lair: -> FF
lair: <- E4
lair: -> 2F
lair: <- 64
lair: -> FF
lair: <- E4
lair: -> 8F
lair: <- 64
lair: -> FF
lair: <- E4
lair: -> F7
Search to 26042 received
Edit: Added frame 22738 which is another example.
FYI. Matt, that is the way it has always been. There are scenes that start on the wrong frame and others that overplay the scene in Dragon's Lair. So, it's emulating the game with all of it's flaws perfectly. One thing I did notice is that when the Dragon's Lair game ends on the Heart Freeze Frame, in the original game the scene Freeze Frames on both frames and flickers. Your emulator does the same thing, but without the flicker. It shows it as a double exposed image of both frames without any flickering.
ReplyDeleteWelcome to the wonderful world of interlaced video and 3/2 pulldown. The issue is that the frame chosen has field A from the previous frame and field B from the next. Since DL was all done on film at 24fps, it has to be converted to 30fps for video. If the 3/2 pulldown is done correctly, these frames are flagged to be skipped during freeze frame and shouldn't be assigned a frame number.
ReplyDeleteLord Victorino is right - it's behaving exactly the same way as if you had a player. The program code would need to be modified to skip the offending frames. I think if you are playing the DLE ROMs, the issue is resolved and the 'double frames' on the disc are avoided.