Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
Yes, it's hard to notice the lag while you're making a complicated run as this. Only when you watch you'll say "oh s***!!". Unless you were also planning to be careful with that beforehand, which wasn't the case for either of us.
I guess I don't understand frame advance very well. Can Mupen tell the difference between tapping "A" and holding "A"? Whenever I hold "A" and press the frame advance button, it thinks I'm tapping "A" just once.
Borg Collective wrote:
Negotiation is irrelevant. Self-determination is irrelevant. You will be assimilated.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
Games only know that you "hold down" a button when you press it for consecutive frames. This is because it doesn't continuously process instructions. It does so once per frame (this is not exactly how n64 works, but in general). It reads the input, then calculate then draws the screen. So if you released the button while the emulator is paused or not, it means nothing. The game can only read input when it goes to the next frame.
That makes sense, but when you do the BLJ in BOB, do you press A every frame the elevator goes up or every other frame? If you press A every frame, the game thinks you're holding A so the BLJ doesn't work.
Borg Collective wrote:
Negotiation is irrelevant. Self-determination is irrelevant. You will be assimilated.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
laughing_gas wrote:
That makes sense, but when you do the BLJ in BOB, do you press A every frame the elevator goes up or every other frame? If you press A every frame, the game thinks you're holding A so the BLJ doesn't work.
correct. every other frame is the fastest button mashing possible.
I'd say lag is very noticable when using frame advance. Lag is way harder to detect when using low speeds.
I guess you haven't tried minimizing lag in an N64 TAS. Frame advance skips over lag frames, so you can only notice it on playback or by watching the frame counter. Maybe frame advance should be given a configurable framerate, because there's no way for the emulator to tell the difference between a frame of lag that is supposed to happen (which is every other frame when the game runs at 30 FPS) and an additional frame of lag that could be avoided.
laughing_gas wrote:
That makes sense, but when you do the BLJ in BOB, do you press A every frame the elevator goes up or every other frame? If you press A every frame, the game thinks you're holding A so the BLJ doesn't work.
Right. The fastest you can possibly press a button is every other frame. Although BLJ requires even slower than that sometimes, because Mario can't jump again while his feet are still in the air from the last jump.
I guess you haven't tried minimizing lag in an N64 TAS. Frame advance skips over lag frames, so you can only notice it on playback or by watching the frame counter. Maybe frame advance should be given a configurable framerate, because there's no way for the emulator to tell the difference between a frame of lag that is supposed to happen (which is every other frame when the game runs at 30 FPS) and an additional frame of lag that could be avoided.
Perhaps you should have an overlay visible somewhere that shows you the delta real frames everytime you push frame advance. A spike in this number is a pretty good indication of lag. I agree with going for the absolute minimum time in the minimalist run. Its not like we all havent seen DDD before.
This signature is much better than its previous version.
DDD is a super laggy level. It's the only level where I didn't like the camera angles in FODA's run, which he explained was to reduce lag. That tells me that, generally speaking, it's possible to keep lag low without affecting the quality of the movie, with the exception of DDD. Unfortunately, the lag is so bad in that level that it's better to have bad camera angles than to watch the lag, so I agree that frame count is the important thing here. If you're going for the fastest any% time possible, it should be as close to frame perfect as possible.
TASing or playing back a DOS game? Make sure your files match the archive at RGB Classic Games.
Any coins enemy drops move ramdomly and would desync
That's a shame, I was going to hex edit your first star... ok so it's only 1 star, but it's sort of a drag when the first star doesn't look TA.
How does emulator lag work? For the star times competition I've timed strategies on a console as well as emulators, and the emulators were faster because of the console lag.
I've redone the DDD level and will be uploading a comparison video shortly, and you'll see for yourself how much lag is present in DDD, I've improved it overall by 181 frames, although in reality it was only about 40 frames if I was to ignore the lag.
EDIT:
http://www.youtube.com/watch?v=cNQxeDYSU5Q
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
CBright wrote:
How does emulator lag work? For the star times competition I've timed strategies on a console as well as emulators, and the emulators were faster because of the console lag.
The emulator is programmed to work as close to the real hardware as possible. if it lags in the videogame but not in the emulator (or vice-versa) that's a flaw that should be fixed.
The emulator is programmed to work as close to the real hardware as possible. if it lags in the videogame but not in the emulator (or vice-versa) that's a flaw that should be fixed.
You bring up an interesting point... although, some people may say that lag was not intended and avoiding it is an advantage of emulators, even if different from the real hardware. I suspect that the upcoming virtual console emulator will also remove some lag, but we'll have to wait and see...
I must admit I'm surprised that DDD lags on emulators as well, as I've done some tests timing how much faster emulators run (although not in DDD). Some places where you can notice the difference between console and emulator include going to the big house in RR, and opening the front door in BBH.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
When we "remove" the lag in the emulator, we do it the same way as we would do if we were on the console. It's not our fault if the emulator is innacurate, it's our duty to shave off the frames.
... I've done some tests timing how much faster emulators run ...
It matters which emulator(s) you use. They are programmed independantly and thus can (and do) have different timing. However, the CPU is emulated as closely as possible to the original (at a low level, based on how the original behaves), and Mario 64 is probably the most accurately emulated commercial N64 game overall. On the other hand, even SNES emulation isn't perfect yet, and N64 emulation certainly isn't.
CBright wrote:
I suspect that the upcoming virtual console emulator will also remove some lag
I doubt it would. That constitutes innacurate emulation, and similar things in the past (such as PS2 emulating PSX games) have not attempted to reduce lag that was present in the original, despite adding other optional features.
Maybe not writing back to the framebuffer for EVERYTHING gives an emulator makes a slight difference in speed at some points? It could only be a miniscule difference though. I still don't believe lag (in an area where it always lags in a game) is reduced during emulation because there would have to be a special set of instructions for that event. Remember that the emulator may have more resources than the n64 does but it is still has to mimic it for the games to work.
When we "remove" the lag in the emulator, we do it the same way as we would do if we were on the console. It's not our fault if the emulator is innacurate, it's our duty to shave off the frames.
So technically the fastest run could be beaten (in real-time) by a previously slower run just by adding the lag into the emulator...
nitsuja wrote:
It matters which emulator(s) you use.
I have tested Project64, Nemu64 and mupen64; none of them have the slowdown when traveling into the big house. And yet there is still lag for the sub...
L4yer wrote:
I still don't believe lag (in an area where it always lags in a game) is reduced during emulation because there would have to be a special set of instructions for that event.
Try it for yourself, there is noticeable lag on the console in parts of RR. (It's also easily visible in Dragorn's 120 star run, he had a bad camera angle on the carpet.)
It's impossible to compare really, you need the exact same situation at precisely the same memory address so.. yea. If there was only a emulator developer here to say..
When we "remove" the lag in the emulator, we do it the same way as we would do if we were on the console. It's not our fault if the emulator is innacurate, it's our duty to shave off the frames.
So technically the fastest run could be beaten (in real-time) by a previously slower run just by adding the lag into the emulator...
What he's saying is that we remove lag from the emulator the same as on a console (such as, by giving the system less things to draw), so it should have the same effect on both. Basically, there is no lag to add back to the emulator. No emulator is perfect, of course, but they do emulate lag.
TASing or playing back a DOS game? Make sure your files match the archive at RGB Classic Games.
