Posted: 9/8/2008 8:26 AM
(Edited: 9/8/2008 10:23 AM)
Post subject: How should VBA with Link & Rerecording work?
Quote
klmz
Editor, Emulator Coder, Expert player (2157)
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
OK, I was working on a VBA branch that would support (re-)recording linked gameplay of GBA games. I've suspended the project because Ithere are some technical problems/difficulties and I don't have enough knowledge/motivation. Here, I just want to have a dicuss on how the emulator should work. Any ideas could be helpful, for someone or I might continue the project (or a better one). First, how should linking be emulated? Linking Model A: One emulated GBA per VBA process An instance of the VBA program is a GBA. You can open as many as you like, and select some of them to join a certain game. One VBA should act as a server and others as clients. Pros: * Every instance can be used seperately. * Possible to emulate cases like disconnecting two GBAs from a 4-player game and reconnecting them together to another GBA to play a new game... Cons: * Inter-process synch seems difficult to behave identically when ported to other systems? Linking Model B: Client(VBAs)/Server(some VBA Server?) Quite similar to Model A, except for an individual server program that handles linking and perhaps movie recording. Pros: * Easier to synch up things than Model A? * Easier to build net-play servers? * Possible to emulate cases like disconnecting two GBAs from a 4-player game and reconnecting them together to another GBA to play a new game... Cons: * Extra program(s). * Hard to show all windows in fullscreen mode. Linking Model C: Multiple (1-4) emulated GBAs in one VBA process Single-thread or multi-thread? Pros: * Likely to have the best performance? * Easier to synch up things than Model A? * Easier window/screen arrangement? * Easier fullscreen mode using MDI-like UI or split screen? * Easy savestates synch. Cons: * Usage can be different from what we are familiar. (ie. one window handle up to 4 games. MDI-like UI solves this?) * Can be hard to use without UI front-end. * Hard to emulate cases like disconnecting two GBAs from a 4-player game and reconnecting them together to another GBA to play a new game... Second, how should movies be recorded? See also the third question below. One movie for all Note: For multi-process emulation, only the Server should record/playe the movie. Pros: * Input animations? * Only one movie file. * Able to record linking events in the movie file. Cons: * Complicated format. One movie per GBA Pros: * Possible to make flexible movies. ** Able to record movies using non-constant amount of GBAs. Cons: * Hard to synch all movies' start-time? * Hard to make input animations using input from all GBAs. * Too many movie files? Third, how should movie-start playback get synched? Emulator(s) should synch movies frame by frame, or we' come into troubles like those with multi-game movies on other emulators. If all input on multiple GBAs is recorded into one movie file, some events can handle this, but possibilities may be limited. A emulator option can be provided to toggle between some synch modes. Thus, this isn't a very big problem for multi-file movies. See also the second question above. Free start-time for multiple movie files Just like how multi-game movies play on FCEUs. Pros: * Very flexible. Cons: * Higher requirement on users' skills? * Difficult to implement in single-file-movie design. Predefined start-time The emulator(s) can start to playback on all GBAs at the sametime, or use some recorded time events to synch. Pros: * Easy playback. Cons: * Inflexible. * To be continued* Note: Net-play support isn't necessary.
<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: 9/8/2008 9:10 AM
Quote
ShinyDoofy
Former player
Joined: 12/5/2007
Posts: 716
First: Model C seems best to me. If this is the one to be used, having it multithreaded would be great so that you could use the power of today's multicore systems (for playback/non-frame-exact recording/avi creation). Second: I'd prefer "one movie per GBA" or at least "one video stream of avi file per GBA". This way you could concentrate on player 1 while player 2 is just helping out offscreen doing rather boring stuff. What would be really neat though is an option to automatically merge multiple GBAs to one avi file while encoding it. This would come in handy when it's important to see each GBA individually taking care of its part in case they both/all are equally important/entertaining.
Posted: 9/8/2008 9:25 AM
Quote
eternaljwh
Joined: 3/11/2008
Posts: 583
Location: USA
Pro of one moviefile across the VBAs: Sync easier.
Posted: 9/8/2008 7:28 PM
Quote
zdude255
Joined: 6/26/2007
Posts: 147
Model C with one movie seems to be the best for usability concerns. I'm not terribly eager to open up 4 windows and load 4 files to play one movie.
Posted: 9/9/2008 8:52 AM
Quote
LagDotCom
Joined: 3/7/2006
Posts: 720
Location: UK
Model C makes a lot of sense, but it does cut out any future additions of netplay (yes, I know you said you weren't interested, but it is just a generalisation of what you are already trying to do), so I would have to go with Model A. For movie format, it should be One movie for all for ease of playback. However, this brings obvious problems - if only the server records, it gets Player 1's keypresses, but Player 2+'s network data, which isn't the same at all, and somewhat unverifiable, like starting from a savestate. I'm unsure what to suggest here; recording all player keypresses would be fine if you use Model C, I guess. I guess sync would have to come from the first turning on of a console, with all the other 'player keypresses' being padded with some byte that says the console isn't even on yet.
Voted NO for NO reason
Posted: 9/9/2008 9:51 AM
Quote
upthorn
He/Him
Emulator Coder, Active player (392)
Joined: 3/24/2006
Posts: 1802
Sega TAS of 2011 Sega TAS of 2010 Sega TAS of 2008 Sega TASer of 2007
I vote for Model A or Model B with One Movie For All. Addendum: I support Model A/B because this way it is possible to expand to support multiple TASers TASing together over the internet.
How fleeting are all human passions compared with the massive continuity of ducks.
Posted: 9/9/2008 8:41 PM
Quote
bkDJ
Joined: 7/26/2006
Posts: 1215
What about if instead of opening up multiple vba's, one vba has the option to open a second GBA (not a second vba) in another window that the main window owns. second gba can load a rom or not depending on what you want to do with the link. Once it works with 2 it should be pretty easy to add spport for up to 4. this way the main window can get all the keypresses and data. the vbm format was already desiged to be able to store 4 player inputs if necessary.
Posted: 9/10/2008 3:52 AM
Quote
pirate_sephiroth
Active player (315)
Joined: 2/28/2006
Posts: 2275
Location: Milky Way -> Earth -> Brazil
New systems TAS of 2009
Yeah, 4 GBAs in a single window, similar to no$gba. That would be nice and clean.
"Genuine self-esteem, however, consists not of causeless feelings, but of certain knowledge about yourself. It rests on the conviction that you — by your choices, effort and actions — have made yourself into the kind of person able to deal with reality. It is the conviction — based on the evidence of your own volitional functioning — that you are fundamentally able to succeed in life and, therefore, are deserving of that success." - Onkar Ghate
Bisqwit wrote:
Drama, too long, didn't read, lol.
Posted: 9/10/2008 10:17 AM
Quote
klmz
Editor, Emulator Coder, Expert player (2157)
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
bkDJ wrote:
What about if instead of opening up multiple vba's, one vba has the option to open a second GBA (not a second vba) in another window that the main window owns.
Hmmm, I think you mean the multi-tread method suggested by Model C.
bkDJ wrote:
this way the main window can get all the keypresses and data. the vbm format was already desiged to be able to store 4 player inputs if necessary.
Yes, it was designed for SGB movies. It can store exactly all input from 4 GBAs, but I don't think the current VBM format will be reused...
<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: 1/23/2009 12:04 PM
Post subject: Don't expect too much right now...
Quote
klmz
Editor, Emulator Coder, Expert player (2157)
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'll stick to Linking Model A as it is the easiest to implement... WIP screenshot: It doesn't work well at present, however it can be a good start.
<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: 5/17/2009 8:44 PM
Quote
Tompa
Any
Editor, Expert player (2215)
Joined: 8/15/2005
Posts: 1941
Location: Mullsjö, Sweden
NES TAS of 2018 SNES TASer of 2017 SNES TAS of 2017 NES TAS of 2014 GBA TASer of 2011 GBA TAS of 2011 SNES TASer of 2010
Was just going to add that I'm very interested in seeing this in the works. Have been wanting to TAS Four Swords for a long time now. Would be awesome if it will be possible as well :).