Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Pretty cool how far this is getting. Any plans to improve the command scripting to get more optimal movement? How many unique commands do you think are needed to get optimal looking movement while still being relatively easy and fast to input?
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Oops I don't know how that bug got by me, working on sound fixes should be done when I have a bit more time .
At first I didn't anticipate a need for power/reset but knowing a glitch is possible will motivate me to add it. I'll work on it at the same time I add PAL support.
Thanks for the feedback!
EDIT: Sound is now fixed, please try the dev build.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
It will probably be pretty difficult to seperate emulation differences from strategies unless you can resync the original run (which would also not be easy)
The old run was made at a time when 'frames' were whatever time passed between v-blanks. This is some what variable in A2600 games. At some point frame definition got changed to 262 scan lines . Hero uses 263 scan lines per frame.
I briefly tried to resync the run and did not make it far , so probably other emulation changes are effecting this run .
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
StarvinStruthers wrote:
um ok well then let this be the start of a thousand questions..
so i need to download bizhawk 1.5.3?
download your bkm?
and it will just run no problem?
never heard of a bkm but i assume its about the same as bk2
that being said i dont know how to get a bk2 to play on tastudio
i've only been able to get tasproj to run on tastudio
reminder i'm new
there's no way to get your tas to work on the latest bizhawk?
is this due to the emu lag and inputs getting desynced or for other reasons?
Atari 2600 emulation got an overhaul a few months back. It won't be easy to sync the former run on any newer builds.
Yes you should be able to run the bkm in 1.5.3. Bkm is the precursor (or maybe just renamed) bk2. I'm not sure what utility you'll get out of this though.
To get a bk2 to play in tastudio just open the bk2 and then open tastudio (or the other way around works too.) TAStudio will automatically import the bk2 into a TASproj.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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.
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.