Posted: 2/5/2016 1:50 PM
(Edited: 2/5/2016 2:26 PM)
Post subject: LibTAS to provide TAS recording and tools?
Quote
klmz
Editor, Emulator Coder, Expert player (2156)
Joined: 5/22/2007
Posts: 1134
Location: Glitchvania
NES TASer of 2018 GBA TASer of 2018 GBA TAS of 2016 Lucky TAS of 2016 GBx TASer of 2008 NES TAS of 2007
I am think of a reusable standalone "standand" TAS library that provides TAS recording ability and related tools like RAM Watch for integreting with existing/future emulators. EDIT: The library should provide at least the facilities for implementing TAS movie recording, in either the frame-by-frame or timestamped way, though bullet-proof-ness is still up to the core. Tools may include Lua scripting engine and its common TAS-wise libs, TAS Studio(tm), RAM Search/Watch (midware?).
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days <adelikat> no doubt <adelikat> klmz, they still do
Posted: 2/5/2016 1:54 PM
Quote
Pokota
He/Him
Joined: 2/5/2014
Posts: 779
Context helps. 
[08:06] <LimmyJee> adelikat said one important point of Bizhawk is that it would be easier to maintain
[08:06] <LimmyJee> but it doesn't look like so
[08:07] <LimmyJee> it's complicated
[08:07] <Mothrayas> it's complicated because it's huge and supports several dozen platforms
[08:08] <LimmyJee> so it's liktely to have bugs
[08:08] <Mothrayas> but the architecture is there, core is separated from gui, it's made to be maintainable C# code, etc
[08:08] <Pokota> LimmyJee: So why not help contribute and iron out the bugs?
[08:08] <Mothrayas> it's likely to have bugs because it has a far greater scope than any other rerecording emulator
[08:08] <LimmyJee> I don't think the direction is right
[08:08] <Mothrayas> and scope = bugs for the most parts
[08:09] <Pokota> In which direction would you rather see tas emulators go?
[08:09] * Pokota came in late to the conversation
[08:09] <LimmyJee> why not make TAS libraries for emulators?
[08:10] <Mothrayas> LimmyJee: that would involve having to do individual work of creating TAS tools for every single emulator
[08:10] <LimmyJee> Bizhawk uses emu cores as libs
[08:10] <Mothrayas> which, prior to bizhawk, is basically what's been done, but adelikat realized that is a very inefficient way of working
[08:10] <LimmyJee> but I think it should go the opposite way
[08:10] <Mothrayas> and not as consumer friendly too
[08:11] <LimmyJee> a "de facto standard" TAS library can solve that problem
[08:11] <LimmyJee> let's call it libtas for now
[08:12] <Mothrayas> LimmyJee: then you'd still have to write hooks to that for every single emulator, which also do all their stuff differently, etc
[08:12] <Pokota> Well, not precisely.
[08:12] <LimmyJee> why "you (we)"?
[08:12] <Pokota> The core library could be made by our community, and then it could be put on emulator developers to add taslib support
[08:12] <LimmyJee> they have their devs
[08:13] <Mothrayas> LimmyJee: https://en.wikipedia.org/wiki/Generic_you
[08:13] <LimmyJee> I mean literaly
[08:13] <LimmyJee> and I knew that semantical usage
[08:13] <Mothrayas> Pokota: I don't think relying on emulator developers for us to go "hey add this library for us" would lead to fast or efficient results, if at all
[08:14] <Mothrayas> because plenty of emulator developers would simply not be interested
[08:14] <LimmyJee> but we have limited human resource for a singular Bizhawk too
[08:15] <Mothrayas> BizHawk has several accomplished emu devs working on it
[08:15] <LimmyJee> we can help them with this lib
[08:15] <Pokota> LimmyJee: Are you going to lead the charge?
[08:15] <Pokota> Right now we as a community are invested in seeing BizHawk rather than taslib
[08:15] <Mothrayas> propose the idea to them
[08:16] <LimmyJee> I don't know if I am the best person for that
[08:16] <Mothrayas> well, it is your idea
[08:16] <LimmyJee> I can propose it at least
[08:17] <LimmyJee> and Bizhawk can use it too
[08:18] <Mothrayas> I'd say, make the proposal and then we can see where it goes
Adventures in Lua When did I get a vest?
Posted: 2/5/2016 2:59 PM
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
Related: http://tasvideos.org/forum/viewtopic.php?p=356544#356544 From IRC discussion though, adelikat hated the idea back then :D klmz is back!!! EDIT: now, my actual thoughts. Before I touched bizhawk code (last summer), I was under general impression that .net/C# is something not so good, especially having not-so-amazing cross-platform compatibility (that would rule the world if it was there, just like Qt is conquering it, but Qt is for C++, and has no C# bindings). Well, the Mono branch works on Mac, but no one yet succeeded compiling it on Linux, and we're not even talking about microwaves android. However, that would be fixable if there was a dedicated Linux dev, and Linux devs hate C#. Then I saw OOP for the first time, while debugging it. That first impression was terrible. Then I actually started committing. And you know what? I love it. A huge part of it is that IDE bends over backwards to make your work comfortable. Especially resources managment, especially after winapi (most emulators I saw, and tasers used, are winapi). I also got hooked by overall language simplicity, unlike in some advanced C++ (well I'm not touching complicated matters, but what I do touch feels very nice). And there's a freaking ton of .net classes for all cases. About bugs. I opened tastudio for a few times during its first years of existence, and... I didn't believe in it. Then adelikat made some amazing progress, based on old legacy of fceux, and on my current notion, then SuuperW joined, and those 2 got the business perk! So when I moved in, it was already a workable tool, but with tons of bugs. So what did I do? I started hunting them down. After half a year, I only know of a couple bugs in tastudio that I just haven't gotten around to fix. That's it! A couple of bugs man. It's fully workable now! It means, it just takes a person who knows what he's doing to come and trace those bugs, they exist because someone haven't yet had time (or interest) for checking all the possible situations. We have tasers for that in a way: they try all possible situations daily. So it only takes a coder interested in getting the tool working. Finally, there's insane interaction between tools, so you won't make it any easier, if each tool goes in a separate dll. And if they go all in one, it will be just as complicated as bizhawk, to say the least. Bizhawk is so huge and complex because the logic it accounts for is that huge and complex. (Generic) you can make it simpler, but without knowing what you're doing it will definitely break something else. So I entrust rerecording to people who've been on the rr-scene for a decade, and also contribute things that I am fully confident in.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 2/6/2016 3:36 PM
Quote
Demon_Lord
He/Him
Joined: 2/20/2011
Posts: 80
Location: Chicoutimi, Qc, Canada
If I can give my 2c on this, I think such a library should only provide the necessary hooks and an external communication API for other tools to bind to it. Simply expose the memory, a few events (read/write, frame advance, etc.) and a communication layer (system socket, TCP, whatever) and then external TASing programs can plug in to any emulator implementing that API. A fake Bizhawk core could even be a simple client to this API and voilà, you already have a TASing tool ready for any emu linked to that lib.