Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
VIs represent vertical refreshes on the actual system, so what you describe seems to be a horrible bug in either (1) the emulation or (2) the process of counting/recording the VIs. If it's the former, I have to wonder if any amount of storing extra input data and markers could be enough to compensate for emulation that is not even "synchronized with itself". If it's the latter, your method might be overkill. It's worth a try either way though.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I made sure the x-velocity (0xBD) was exactly 40 whenever the game checked it to change the P-meter (ram[0x55d] == 2), and slowed down as much as possible while still meeting that condition. Whenever the P-meter (0x3dd) went down instead of up, I knew I'd made a mistake. Note that in the expression (ram[0x55d] == 2), I am not sure where the 2 comes from, but it was the value at 0x55d on the frame before the P-meter value changed. It can be different depending on when you start the level or maybe when you start running. Perhaps 0x55d is some generic counter I stumbled on and there is a better place to look.
Holding B makes absolutely no difference to the rate of acceleration or deceleration, except that you can't accelerate or hold speed at above speed 24 without holding B. It doesn't matter whether you press B within the first 27 frames, and there is no point in not holding it after that.
smb3addrs.txt wrote:
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
okaygo wrote:
Well, basically... if your reading data too fast, its kinda overloading itself. Such in a case were emulation will slow down due to errors, or what be... data gets read to early, and gets missed by the ROM.
Data is read synchronously with the emulation, in the same thread, so the emulation can't accidentally "miss" the data if it's coming in at a different speed. But I guess that doesn't matter... there could be some bug somewhere in the emulation process that makes it act like that, and if the method you're proposing can make the symptoms of that go away (and it remains tamper-proof) then I see no reason not to go ahead with it.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
The recording still needs to use VIs to determine the movie duration, as there is simply no correspondence between frames and time. But, since you plan to make playback independent of VIs, this implies that not everyone who is able to play back the movie will see the movie complete in the same amount of time the movie claims to be. In the interests of keeping the movie duration tamper-proof, you could display a noticeable warning if the playback duration exceeds the (reported) recording duration, but somebody could still edit their movie to contain a shorter duration and then say "it really ran that much faster with my settings, maybe something is wrong with your settings".
okaygo wrote:
That [the OoT pause screen delay] has nothing to do with anything... the whole emulation pauses while that data is loaded if I recall correctly.
The music continues to play during the pause, which I think means the emulation must be continuing. But it appears to be a graphics plugin problem, one that most graphics plugins intentionally ignore for performance reasons. Graphics plugins have access to memory that the emulation core can read, and certain games expect them to write specific things to that memory.
As for reset recording, I tried implementing it but encountered about a 30% chance of desync per reset during playback. It might have something to do with using a makeshift (probably incorrect) hard-reset because of the apparent absence of any support for soft reset in the emulator.
Question: Why do you think the speed throttle settings are affecting playback? There is no inherent reason that an emulator should emulate differently depending on the speed of the system being used to run it, of course. It seems likely that a specific component (or plugin) of the emulation is to blame.
(Thank you for attempting this, by the way.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Dromiceius wrote:
I saved slot 2 on frame 1000, then used slot 0 thereafter. Around frame 2500, when I wanted to go back to frame 1000 to review, slot 2 gave me the "snapshot inconsistent" error.
It's not supposed to do that, is it?
Not unless you loaded some other slot (such as slot 0) after saving slot 2, and that slot you loaded was before frame 1000, and you continued recording from there to frame 2500. Let me know if you have evidence of it happening when it shouldn't, preferably in the form of either movie+savestates or exact directions to duplicate.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
AKA wrote:
Its probally already known but heres a zip I found in the second stage although I doesn't seem be very useful, unless you can do something useful first by going backwards. I recorded from the end of Nitsuja's movie.
Yeah, already found that when doing that stage, there were places to zip or clip through the ground but none of them seemed to be useful. Even using that speed to lodge into the ground under the loop and zip back to the right wouldn't make up for having to go backwards that much.
stanski wrote:
If you want to show something off from another level, just use level select.
That's usually more time-consuming than using an existing movie, especially when you want to show something in the middle of the level as AKA did.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Wordtris for SNES presents a similar challenge for TASing (and has 2-player cooperative as well). The result could be cool but with so many choices it's very hard to plan.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I don't object to what you're saying (I can't argue that adding a flexible system like that would be a bad thing), but I do object to the way you're using what I said as a motivator for it. I did not say I have ever seen the controller-check method fail to catch lag. In fact I wish I hadn't brought it up because I think I was remembering a specific problem I already corrected.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
About the Castle Crush bug, all I know is that when I watched your initial movie demonstrating the glitch, the emulator started doing strange things like requiring I restart it before I could load any savestates, and when I turned on debug mode to investigate, the emulator crashed from illegal overwriting of its own memory when you did the glitch. And when the emulation bug allowing that (wrong instruction call) was fixed, trying to reproduce the glitch froze the game instead. This doesn't mean it's impossible to reproduce the same effect on a console without freezing the game, and if you have gotten it to work in other emulators it is most likely legitimate, but something fishy was going on in the emulation when playing the original demonstration SMV.
EDIT: Yes vote.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
If you really want it to be available for anyone who cares, then post it or a link to it here instead of just saying you know something. It's bad forum etiquette to publically announce that you are holding some piece of information hostage pending further communication.
Also, I have no update, but I wouldn't want to continue something like this without first ensuring I have at least memory watch + cheat search.
EDIT: My apologies if you took offense to that. I meant that saying "I have lots of info" is less helpful than saying what your info is. Also, the way I read your post, you were implying that you would ONLY give your info to the person doing the run if someone offers to do the run... So if nobody speaks up and says "I'm working on it now" then you'll keep it secret from everyone forever. That's obviously not what you meant considering your response, but if it had been (and that's really what it sounded like), it would be accurately described as holding your information "hostage" until your demand is met that someone offers to do the run.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
At least on the SNES, checking for when the input is used will give you some interesting additional information besides knowing when the game is lagging. For example, "oh, it's not even looking at my input while this dialogue box is up, so I don't need to try making it go away on then". So, while it can't tell lag apart from normally ignored input, I would say that's not a bad thing.
One annoying thing about any such indicator is that without it using some rewind mechanism it can only know after the frame if the input was ignored. It would be more helpful to know before the frame is recorded, so you wouldn't have to waste time recording that frame and then mentally subtracting one from the frame count to know which frame the lag happened on.
zidanax wrote:
Less useful lag info? what do you mean?
I meant that initially it would catch some useful things that it really shouldn't have because although it happened to be correct in the game I was testing, other games could do the same thing and not be ignoring the input. I shouldn't have said less useful, it's simply more strict.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
There is a read-only toggle, and the default for it is shift+8.
The state you are trying to load was most likely made after something you re-recorded over, which means loading it in playback mode would result in near-certain desync, so for your own good it doesn't let you.
...Unless it really is giving false-positives, but that can be easily checked: Backup your movie, then load the savestate in writable mode and close the movie, then make another backup, and compare the two backups in a hex editor. If the input has any differences (or if it ends) before the frame of the savestate then it's intentional behavior.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Snes9x 1.51 actually has this. There's a config option called "MovieNotifyIgnored" that shows something in the frame counter if the last frame didn't do any controller reads. It wasn't completely trivial to implement because the SNES has several different ways of doing controller reads. I think one of them was only used by a few games and detecting it made most other games give less-useful lag information.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
AKA wrote:
Last Fight Against Chozen: I couldn't tell if much was improved before the boss but it does seem somewhat improved.
Not counting the boss, the last level was about 50 frames faster, from small changes.
AKA wrote:
I don't understand how you managed to beat the boss in that way, is this some kind of glitch? since he usually comes back to life when he falls over the ledge.
All enemies die when they touch the water. It doesn't work to hit him into the water because he reaches the side of the screen first, but he fell into it normally without me hitting him.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Soulrivers wrote:
Game crashes when I use in-game (S&Q) reset in Link's Awakening.
The game does not crash for me in v20 when doing an ABSs save&quit in any version of Link's Awakening or Link's Awakening DX, so more details would be nice.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
It sounds clearly better to me... less irritating to listen to and more like it sounds on a real NES. But I wonder if the same argument would also point to using an NTSC filter for the video encoding.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Of course, you will have trouble representing enormous instantaneous accelerations when the force along each axis has to fit within 1 byte for the Wii to read it.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
samurai goroh wrote:
So, the problem there's really no tool for the N64 (apart of doing it manually with a HEX editor) is that each game runs at a diferent rate so there's an issue with the frames, and that's why you can't save with the movie editor tool, correct?
That shouldn't be a problem for a movie editing tool. What it comes down to is one number it can't know (movie duration), which isn't used for anything else in the saving process and doesn't need to be exactly right for the movie to play. All it has to do is make a conservative guess about that number (or ask the user to make that guess) then save it like a normal movie.
In fact, if the user can correctly answer the question "what is the average frame rate during the frames you edited", there is no guesswork, that's all the information it needs. (That question should be worded differently to be technically correct, to differentiate between the terms "frame" and "input sample", but it gets the point across.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Yeah, that's a bug. The problem is simply that it's not refreshing the emulator screen while the game is loading. One way to force it to show the actual frame count is to toggle the input display after frame advancing.
