Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
So as it turns out Atari 7800 was using the wrong palette until now. It was using the A2600 palette instead of the A7800 palette.
So, all A7800 runs look slightly wrong.
Here is Choplifter for example in previous versions (left) and current Dev Build (right.) A quick google search reveals that the one on the right is how choplifter should look (and how the native EMU7800 emulator actually looks.)
So I think at some point the 3 A7800 runs will need new encodes.
vvvvvv Emulation didn't change otherwise so sync should not be an issue.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
pirate_sephiroth wrote:
ThunderAxe31 wrote:
pirate_sephiroth wrote:
The only problem I had was with the conversion from bk2 to tasproj. Every time we launch TAStudio while a bk2 movie is running, it is converted but it still starts a new movie.
The solution seems to be to close TAStudio immediatly after confirming it (maybe the emulator too? I'm not sure), then launch it again and open the converted tasproj.
Try to do this: open TAStudio > File > Open > File type > All files > *your .bk2 file*
Works just fine for me with 1.11.9.1
Edit: Invariel 20 seconds faster :O thankfully my life is not a TASing contest. :)
If I try to convert like that, TAStudio breaks the movie once I modify anything.
All the input vanishes and if I try to open the file again it resumes from where I saved the last branch even though I didn't check the auto-restore box or even save the modified file.
The only way I can use it properly is like I said, open the bk2 in Bizhawk, launch TAStudio, confirm the conversion and close it, then launch TAStudio again and finally open the converted file.
You might want to try the latest dev build. I was having this same problem but feos fixed it.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
feos wrote:
Test now.
State 0 is back now and the recording mode bug is gone, thank you feos!
I do notice a couple different behaviours now. The frame 0 marker is no longer made, and a TASproj movie is not automatically made from the BK2. Are these the expected behaviours?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
feos wrote:
And what exactly happens even if you change 'SwitchToRecord()' to 'SwitchToPlay()' and then do "Open TAStudio->OpenBK2 from TAStudio", again?
If I do that then I can play the movie without it over-writing all the inputs that are already in the Bk2.
Also the recording mode check box then works as expected.
Doesn't fix the non-existent frame 0 state though.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
feos wrote:
When I refined loading the project directly, I had no idea things would break with a converted movie.
It doesn't happen with a regular bizhawk movie does it?
When I do this:
Open BizHawk->Open Rom->Play Movie->Load Bk2-> Open TAStudio
I do not get any errors.
When I do this:
Open BizHawk->Open Rom-> Open TAStudio->OpenBK2 from TAStudio
I get the errors mentioned before.
It happens even for native Bk2s (not just ones converted from somewhere else.)
TASProj files seem to be fine.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
:O
I didn't even know you could do that.
Just tried it now and there are no errors.
So whatever is happening differently when it gets loaded from TAStudio must be the cause. Have you tried loading it from TAStudio?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Pretty impressive.
I'd imagine this type of input (stringed together commands) is probably the future of TAS for newer and much longer games. Pretty neat demo of it using Twitch chat. Even more so that it's reproducible.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
dwangoAC wrote:
I am at an admittedly fragile place - I really, really want to take this fantastic opportunity that has presented itself to attempt to right the wrongs of attribution I erred in but I don't want to cause further damage.
Being desperate to get something off your chest doesn't seem like good motivation to attend an enevt like this. If you can't go there excited to present TASbot and a cool TAS, and the only thing on your mind is righting past wrongs, I would probably suggest sitting this one out.
I think we've all been there when you mucked something up and are anxious for a way to set things straight, but that anxiety can be a bit blinding (believe me I know from experience 8D).
You've made it quite clear that your wife and kids need more of your attention, and if you do decide to attend this event you'll probably be distracted by it until the day comes. You've probably already put too much of your attention into this event just deciding whether to go or not. It will be much easier to focus by staying home (and there's probably a hundred other day trips they'd rather be on then that one anyway.)
Notice the 'SwitchToRecord' there. This is where the recording bug comes from I think.
The exception comes from ToTasMovie(), from right here:
...
tas.TasStateManager.MountWriteAccess();
...
which contains:
States = new SortedList<int>(limit);
Thie erases state 0, which was already created at this point, and thereafter state 0 does not get reinitiialized, so the key 0 in the list will never exist.
So when you hit '<<' and it tries to find States[0].state it doesn't exist (it doesn't show up as darker colored in the piano roll indicating a state is there) so naturally there is an error.
This should definitely result in an error.
@feos: can you see if you are ending up in the same code path? Or if you are somehow getting state 0 re-made somewhere after this point?
EDIT: If I change 'SwitchToRecord()' to 'SwitchToPlay()' in the above then that is clears up the recording bug.
Not sure what to run to fix the savestate bug.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
oh, I forgot that deleting the config file defaults NES back to QuickNES. So that movie was converted with the QuickNES core.
That movie is only compatible with QuickNES then. I guess TAStudio should also pick the correct nes core as well?
Either way I get the same errors opening it in QuickNES.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
http://tasvideos.org/userfiles/info/36685975026438434
feos I narrowed down what was causing the apparent 'recording mode' bug.
I made this movie conversion from the original fm2 (after just deleting the config.ini)
When I open the bk2 in TAStudio and hit play it overwrites the inputs as though its in recording mode. When I click the check box, it does not make a check mark appear, but after a second click a check mark does appear.
Can you open that bk2 file and see if you get the same results?
I also get the same exception as I mentioned before if I let this movie play a bit then hit the '<<' button.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Really cool to see this run!
Another long expected N64 game finally on the workbench, even if it's not quite emulated perfectly that's still progress at least.
Voting yes!
Are there techincal details about the Intro Story Glitch? I'd be interested in seeing exactly what went wrong.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Koh1fds wrote:
I try everything (reloading the core, rebooting emulator). It doesn't work.
I try old version (first one after you fix sound of fds). It doesn't work too.
This was an interesting bug.
Should be fixed now.
Please try Dev Build.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Nach wrote:
What's going on with this run?
Is there a particular file it should be replaced with?
Are you guys still working on an improvement?
Do you want to cancel this for now and come back in a couple of weeks when you figure it out?
I'm not actively working on it, other things need to be sorted out first. A correctly emulated run that works on console is not on the horizon.
I think TASEditor wanted to use this file:
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
at System.Collections.Generic.SortedList`2.get_Item(TKey key)
at BizHawk.Client.Common.TasStateManager.get_InitialState()
at BizHawk.Client.Common.TasStateManager.get_Item(Int32 frame)
at BizHawk.Client.Common.TasStateManager.GetStateClosestToFrame(Int32 frame)
at BizHawk.Client.EmuHawk.TAStudio.StartAtNearestFrameAndEmulate(Int32 frame)
at BizHawk.Client.EmuHawk.TAStudio.GoToFrame(Int32 frame)
at BizHawk.Client.EmuHawk.TAStudio.TasView_MouseDown(Object sender, MouseEventArgs e)
at System.Windows.Forms.Control.OnMouseDown(MouseEventArgs e)
at BizHawk.Client.EmuHawk.InputRoll.OnMouseDown(MouseEventArgs e)
at System.Windows.Forms.Control.WmMouseDown(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Getting this error in NESHawk when trying to use TAStudio. It happens when I hit the '<<' button.
Also it seems like 'recording mode' is defaulting to on even though the check box is not checked (if I just open TAStudio and play a movie it deletes all the inputs.)
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
It's also possible that the probability of success for runs like these is just very low. MM4 only synced once.
I'm able to get almost every desync observed in the console testing with only slight variations in start up timing. The only one I have still never seen is the second pie hit in streemerz mode. That one really is a mystery.
Anyway I'll be putting some time into MM5 now and hopefully have a complete run soon if RNG is friendly.
I am curious about the top loader tests though True, good luck!
EDIT: @True: I also added a mega man 6 run, made from Shinryu's obsolete movie (the published run desyncs much earler.) Shinryu's run desynced in the same spot you mentioned in the verification thread. I resynced it and beat that stages boss so that should be a good test. The run seems to desync pretty badly thereafter, so I didn't go any further, but if it gets through the lag and RNG nightmare in that section a complete run would probably finish.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Patashu wrote:
If it's essentially random whether VBlank starts on or off, and other such things related to startup state, should a NESHawk TAS be able to specify the starting states of such things (similar to how you can specify the starting state of RAM)?
Probably not. All games should clear the first before testing anything.
And actually this is what Streemerz and Battletoads are both doing. It turns out I had made an error in my original testing, so it's not the initial condition of the VBlank flag that is the problem here, it seems to be purely a start up timing issue.
I cleaned up the code a bit but as far I can tell there are no further errors. Both games will desync if start up is different by a single PPU tick. It could be that something is just not quite deterministic here (besides the known case of PPU-CPU alignment.)
I wonder if the NES10 chip is throwing off the start up timing slightly?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
It's not related to the RAM at all. It's related to where in the frame the CPU starts relative to the PPU and the exact cycle alignment between the two. I've tried different RAM states for these runs and it is irrelevent.
And the only reason that even matters is because OAM DMA takes one cycle longer depending on whether it starts on an even or odd cycle, and because VBlank can be delayed by a bit depending on exactly when it is triggered.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
^ Yeah sorry it's not a very good explanation.
Here's the order of events that lead to this point:
1. Pass test ROM's. These make sure the emulator is working right but don't offer any insight into start up behaviour.
2. Make a 2player run of Battletoads sync. With everything else being correct, this game syncs entirely based on an accurate start up state. At the time, this state was borrowed from FCEUX, which has one extra dead frame in the PPU and slgihtly different initial conditions.
3. Match the run that syncs to the start up state here: https://wiki.nesdev.com/w/index.php/PPU_power_up_state
Surprisingly, this worked out quite well.
4. Make other test runs, they failed to sync in what should be the accurate start up state, the one in the current NESHawk release.
5. I checked against the old start up state and the behaviour matched the console tests.
So, something is wrong somewhere. I'm not sure if it's in the NESDev link, my implementation, or something else.
True's tests are pretty definitive that if I change the Vlbank flag at power on I should get one of the 2 desyncs he got. The goal now is to make that happen with a consistent start up state.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I'm making progress in understanding True's console tests.
Several of the runs experienced 2 unique desync modes. As it turns out, I can recreate most of these modes by changing whether or not the Vblank flag is set at power on. This is known to be basically random.
I also reverted BizHawk's start up state back to a previous one similar to FCEUX, this combined with the random VBLank flag and I got precisely the same desyncs as true got on MM4, and Streemerz superb Joe. I also got the same battletoads desyncs, but it required a few more tweeks then just that.
The only desync I have never seen is the second one from Streemerz, Streemerz mode, so that is what I am currently investigating.
The search now is basically for a valid startup state that matches all the desyncs when changes vblank flag.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Challenger wrote:
@feos @Alyosha Any new progress of 2p warpless?
For me at least, on hold pending console tests of NESHawk. I don't plan on working on anything that won't be console verifiable.
NESHawk's current state does represent a valid startup state of the NES, as evidenced by a 2 player warps run syncing, but current testing seems to indicate that this might just be a lucky coincidence (it correctly mimics a valid startup state but isn't the exact same.)
Once I am 100% confident of sync I will be continuing the run, which is currently at stage 4.
That being said, anyone can feel free to make an updated run, as re-syncing it afterwards isn't that hard.
So I think at some point the 3 A7800 runs will need new encodes.
vvvvvv Emulation didn't change otherwise so sync should not be an issue.