Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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.
The accelerometer values are short (16 bit values)
The neutral values and ranges are hard coded into BizHawk in GBHawk's controller definitions.
Neutral value is 0x81D0 and range is 125 (so at 90 tilt the accelerometer would read 0x81D0 - 125)
Neutral value is probably variable between carts, I can change it without much issue. Range can also be changed, seems like right now it's not high enough, maybe it should be around 135?
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
Roughly speaking, there should be a point where if you rotate fast enough to the left, kirby will still go to the right. (Or maybe it's the opposite.) I need to get an idea of how fast that is. It's important know how fast it is compared to realistic player movements.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
Seems pretty definitive to me. I'll increase the range to 90.
I also realized my acceleration calculation contain an error, so unfortunately I'll have to break sync after all.
EDIT: for now I just increased the range to 90 for further evaluation. I think I'll have to do some physical testing to nail down the other error.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
I just checked the movie file and the frame before the power button is hit is still at 50000. The correct value seems to be 14199. here is an updated movie file:
http://tasvideos.org/userfiles/info/64459518673915123
New cycle count: 317452060
