Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
http://tasvideos.org/userfiles/info/65037296378073579
Here is a console verified version of Zen for GBHawk. This run actually failed at first because of behaviour of writing to the LY register. The GB CPU manual states that writing here resets the counter, but even if this is true for the GB, it is definitely not true for GBC, as the run will fail to console verify if this is the case. I have committed a fix accordingly. So this process has already revealed some important information. (Zen is the only game I know of that tries to do this, and does so for no real reason, it writes zero but then just waits for VBL shortly after.)
I have also verified a version of the Donkey Kong Land 2 TAS I have been working on up to beating K. Rool for the first time, so that was cool to see as well.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
RetroEdit wrote:
But that leaves a question: We have gotten a movie file that represents more accurate emulation, namely the movie file that has been resynced to real-console. How do we proceed? How do we treat the original publication?
...
But waiting around for emulation to be "fixed" doesn't resolve this either. One reason being our movie rules don't allow movies with identical gameplay to obsolete prior movies (unless you disagree with that rule?)
If our goal is to actually improve emulation, it would be better to improve the ability to communicate the console-verification status of a movie, rather than obscure that by making console-verification completely black and white. Having the site index this is much more convenient than requiring independent efforts to keep track of "verified but somehow not verified" movies.
I think a dedicated forum thread or github is a better place for movies that don't quite work then attaching them to a publication. An issue tracker is a great format for compiling these cases.
I do disagree with the rules requiring gameplay improvements, and think that a console verified version should obsolete an older de-verified one (with the caveat that authorship remains with the original author.)
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
RetroEdit wrote:
But I also think there's a huge difference between being able to verify a movie by adding a few frames to adjust for certain transition screens and not being able to playback on console at all.
I don't think so. If you have to modify it, then you aren't verifying the movie. Even if it's only one frame, the solution is to fix the emulator so it works correctly. I disagree with the rules here, and think the emulation environment is an important part of a TAS. I think a movie that works on a NES should be considered superior to one that only works on Not-A-NES.
In the particular case of mario advance, having a movie that creates the SRAM I think would be an ok solution to avoid non-deterministic stuff (although that sounds like something that needs a technical explanation) as there are already standards for movies that start from SRAM, but that would still leave the 10 loading frames inconsistency, which I personally don't agree with excluding and calling it verified.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
http://tasvideos.org/userfiles/info/64991397408720138
Not a GBHawk movie, but here is a console verified version of Zen Intergalatic Ninja by EZGames69. I'll try to get a GBHawk version too. There is a lot of lag and sprites and scrolling all going on at the same time in this game, so it's a good one to verify.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
http://tasvideos.org/userfiles/info/64970777987927243
Battletoads by lobsterzelda.
Apparently GBI doesn't play the last input in it's file, so I had to extend one frame so the last input would be empty, otherwise the last boss is left with 2 health. Otherwise, easy resync.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
http://tasvideos.org/userfiles/info/64967031374165337
I can finally get GBHawk runs console verified now. you can run the above script with a GBHawk movie and get an input file that works with GBI.
In it's current form it only works with single speed mode movies, but I'll be expanding capabilities to double speed and subframe in the future.
I have verified this version of Kwirk with it already:
http://tasvideos.org/userfiles/info/64882123397930984
More to come as I figure out the process a bit better.
I don't have a capture device so no video right now though.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
EZGames69 wrote:
The problem is you can’t expect console to be 100% deterministic, in the case of SMA4, the entire save data screen had to be removed in order to work properly. The time it takes to create is not deterministic and would be impossible to get right. Not only that but if this was the requirement, then the verifications would have to be removed from plenty of other games, such as Sonic Advance, Sonic Advance 2, chip n dale 2 players and 1 player, Pokemon Yellow, anything listed here basically http://tasvideos.org/ConsoleVerificationTests.html. I dont think it should wait until emulation is 100% accurate, because like I said before, emulation will almost never be 100% accurate to console, as console has weird quirks that an emulator would not be able to emulate in a deterministic way, like the save data thing with SMA4.
So you think Sonic Advance should have it removed only because it needed one lag frame added, but not say the same thing about NES? I find it really difficult to understand this position.
We have, and we always will. Part of the process that I mentioned in Case 2 was to ALWAYS provide documentation on what failed and what was required to get consistent sync. But the goal of console verification should not be a test of how accurate the emulation is, but rather a test of how accurate the gameplay in the TAS is. Do the inputs work on console? Do they produce the same results as on console? It just seems unfair to exclude verification if the only thing is loading time, which can be easily adjusted.
I'd be fine with removing the flag from NES games where extra obscure steps are needed. But, I'm also fine with verification that is accomplished through a consistent process even if the underlying emulation isn't 100% correct. This is because the verification flag is attached to a publication, so it should represent what the movie (combined with the emulator it was made on) can do by themselves.
There are other ways to present console verified input that aren't attached to specific movies, maybe make a page specifically for them. But for the actual flag that gets attached to publications, little to no modifications should be allowed.
Also, loading data is an essential part of what consoles do, I consider it pretty important to get the timing of that right.
Chanoyu wrote:
Would it be helpful to have a tiered system?
At least in my opinion, the movie file is source from which the verification either works or it doesn't, so I don't think any kind of tier is needed.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I prefer strict rules regarding what movies can be considered console verified. If you have to add or subtract frames, then the movie is not console verified, only the input file is. Personally I think of console verification of a movie file as a standardized and ideally reversible process. Take your movie file, run this standard script, use the resulting input file on playback device. If you need to add additional steps in there, like manually editing in frames, or per-game hacks, then you do not have a verified movie.
In practice, this does lead to cases where a movie can be verified according to a standard process but still be emulated incorrectly, as is the case for NES games where only input latches are used, so if lag frames show up in the wrong places it doesn't matter (sometimes) since they are ignored anyway. I believe this is the case for SMB2 at least. But, since the standard process was followed, it can still be considered a verification. This doesn't work for GB/A though, where cycles and not latches are used, so cases like Sonic and Mario Advance which require manual editing, are not verified.
I do agree that there should be a process where if a movie file can be imported into a more accurate emulator where manual editing is not required for console verification then this movie can be placed alongside the original movie in the publication and be considered verified.
EDIT: also if you are able to detect emulator inaccuracies in loading times etc please report them so they can be addressed.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
http://tasvideos.org/userfiles/info/64926196486444191
Here is a resync of the old pokemon yellow ACE movie for Pi Day.
It works except that it writes to VRAM at times that it's not accessible, so the result is glitched in appearance. If I let VRAM writes always succeed (not console accurate) it does look the same as the original.
My ultimate goal is to use SubGBHawk to have a console verified version of MrWint's new Pokemon Yellow ACE run, this test was just a first step. I'm not sure exactly how that will work out yet though.
Also I'm getting into console verification with GBI myself, and I'm open to suggestions on what existing GB runs people might want to see resynced and console verified. I think any game not using double speed mode or using hard rests or uninitialized memory should be verifiable now. But, the more games that get tested the more edge cases might pop up, so I'm just going to be testing all kinds of games.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I'm not sure what you mean, but the returned cycle count accurately keeps track of time at a resolution of 4 MHz. , regardless of what speed mode the system is in at what time. Just divide the returned cycle count by 4194304 to get the time in seconds.
Thanks for this tutorial, I followed all the steps but it failed to load the files from the SD card. I think my SD card has too high a capacity, the website says 4 GB limit, but mine has 64 GB. Probably good to mention that somewhere for the tutorial.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
CasualPokePlayer wrote:
Oops, seems like the 12 cycle improvement was actually a 24 cycle improvement. I forgot to account that Gambatte's cycles are in double speed mode while GBHawk uses single speed mode cycles. Updated movie file: http://tasvideos.org/userfiles/info/64667814141526578
GBHawk counts single speed cycles, gambatte counts half speed cycles.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
phoenix1291 wrote:
I will (re)test PAL games and G7400 in next days.
I have test several US games and it work great, even the voices in "Spike".
Thanks for all your work Alyosha!
Don't bother testing G7400 yet, it's just WIP and the graphics pipeline isn't coded yet. I just roughed in the framework so I can work on it as I have the time.
Also I don't believe there is an O2 version of chat et Souris (Mousing Cat in english.)
What 'Spike'? I can only find a Vectrex version of that.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Chat et Souris is fixed, I misread the cpu spec and was dividing by the wrong number for the timer. Somehow no other game that used the timer cared about being off by a factor of 5, so I never noticed it.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
http://tasvideos.org/userfiles/info/64683214002008391
Here is V3, about 200 frames faster then V2, with various time saves throughout. World 3 is done, as is most of world 4 except for Parrot Chute Panic where I still am about 2 seconds behind in the second half of the level. Not counting the 2 bios loading screens, I'm finally ahead of the Nico Video TAS by a couple seconds, getting close to a final product.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Congrats on a new job, and thanks for this report, it's certainly eye opening to see how things add up.
~$16000 total in 'tech stuff' in one year sounds like a lot considering TASBot has been around for a quite a while already. Do you project this level of equipment spending to continue?
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
90 degree per frame is pretty fast, a back of the envelope calculation puts that at about 20 - 40x gravity. But limiting user input would be quite a big departure from standard practice. I think a human could do 1/3 of that (30 degree per frame.) I'm not sure what a robot or something could rotate at, but 90 degree per frame (or 700 RPM or so) doesn't sound impossible.
Overall I'm not inclined to limit user input automatically.
EDIT: Oh, but Blazephlozard is banned now I see. I'll still be doing physical testing on my own end, maybe starting next week, it would be nice to finalize this for stability.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I was testing out the homebrew game Pong, and noticed it was failing the PAL console detection. Looking over the code it looked like just a timed loop in Vblank. In order to pass the time had to be significantly longer then nominal PAL vblank time. I think maybe PAL games just have the same resolution as NTSC games, meaning Vblank time goes from 240 to 312. That's a lot of time, so maybe that's why PAL games weren't working so well, since before I was only going from 288 to 312.
I made this change in dev build, so please test some PAL games and let me know if there is any improvement.
EDIT: also I'm going to be working on support for the G7400 as well.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Ok, range changed to 216.
Fixed savestates, I was missing a variable, should be good to go now.
The flicking part of the code is wrong, I'll fix it once the static cases are nailed down.
