Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
micro500 wrote:
At the beginning of 2016 I started working on TASLink in an effort to make robust hardware that we could use at these live events to avoid annoying problems we have had every year, including parts breaking, or generally being unprepared for the event in terms of cables or visualization. I spent the better part of the year improving it and helping make it do everything we wanted. But then at the last minute it was decided we would use different hardware. We ended up having a number of the same problems we have had in the past, including parts breaking and having to fix them, and the hardware was largely untested and we had to work around annoying bugs that we didn't have time to fix in the week we were there. It hurt to have had put all that time and money into building solid hardware only to go to an event I cared about and not use it at the last minute.
Overall I did not enjoy myself at the event. It was all work and no play mixed with sleep deprivation. This past year has worn me down much further than is healthy, and I am exhausted because of it. I have decided I will no longer be working on hardware including TASLink, I have stepped away from the TASBot community, and I have no plans to help out at another GDQ event.
This is a real shame. I'm sure I'm not the only one who was looking forward to TASLink to bring some rejuvenation and standardization to console testing, not to mention ease of use.
Well, thank you for your hard work and time up to now. Hope you can find something fulfilling to do with your talents.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
I tested with 1.11.7 and it does seem to be the case that it runs much faster.
There are only a couple of commits to A7800 between then and now, and nothing that looks like it should be slowing anything down from a brief glance.
Maybe something is being logged in the background by accident somehow, that sometimes the cause of slowdowns like this, I'll look into it.
EDIT: yup, the EMU7800 stuff looks like it got compiled in DEBUG mode which was causing a lot of extra background stuff to happen. I recompiled it in release mode and the speed returned to normal.
I don't know how to fix this in the repo so I'll make an issue about it and it should be fixed pretty easily by someone who knows what they are doing.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
MrWint wrote:
Hardware verification at least for this TAS is very unlikely, the precision required to sync the inputs it up is likely to great. In general, I think it's a reasonable question though whether an actual Game Boy could do what this run did, at least in principle (i.e. rule out that emulator inaccuracies were exploited). The best you can do to test that would probably be to create a custom ROM that does these things without any inputs and flash it onto a cartridge that you can play in a Game Boy. That isn't really a fair test, since the cartridge itself is part of the system under test, and you exclude the whole joypad input side, but it would at least determine the plausibility that GB hardware can achieve what is seen here.
I know it's impractical, but I do kind of wish TASes like this had some kind of requirement for hardware verification to be accepted. The very nature of the run is to push the limits of the hardware, something just seems lacking if it doesnt actually work on it.
I know most runs on the site wouldn't work on hardware anyway, but ones like this that represent the pinnacle of what a TASer can do just seem that much better with a verification movie (like SMB3 or Mario Kart.)
Well as True says I don't think there is much of a hurdle on the bot end, just a matter of emulator development, I do hope it gets there someday though!
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
I like challenge runs like this. Especailly for a sonic game I find this way more interesting and entertaining then a typical sonic run, and the movement isn't as stop and go either.
Voting yes!
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
Very Impressive. Technically masterful and entertaining at the same time.
Would love to see a console verification of this, if such a thing is even possible. Seeing those last two scenes on hardware would be truly amazing.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
feos wrote:
Test!
Frame zero marker is back!
It now also makes a .tasproj file from the .bk2 on opening.
However, the title at the top of TAStudio still says 'default.tasproj'
I'm not sure if this is just not being upodated, or if it is actually running in default.tasproj.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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:
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.