1 2
7 8
Post subject: AGDQ 2017 planning and feedback thread
Moderator, Senior Ambassador, Experienced player (898)
Joined: 9/14/2008
Posts: 1007
If you do not want to know what is being planned, do not read this thread. I've discovered no one outside TASVideos actually reads the forums and GDQ events now require more manpower than before, hence the more open approach to planning. Each GDQ has its own forum thread. Updated plan as of the start of AGDQ 2017: The NES Classic is a bit of a mess as it filters out things like pressing left on one frame and then right on the next frame so it's really difficult to get anything super accurate or complex. In general, the NES Classic is *not* very good at all, and it's the kind of thing TASBot would look down on for not being perfect. So, uh, we're going to kill two birds with one stone - Since the NES Classic has 30 games on it and a subset of those games are available in all territories, we'll pick that subset of games or a smaller subset and do a death tour, playing the game long enough to do a fastest death and hear the death music then move on to the next game by pressing the Home button to get back to the game selection menu. Going this route might sound a bit strange, but it means that if there is a desync, it will "re-synchronize" at the edge of each game. It'll give us an opportunity to quickly cycle through several games with times ranging from 5 seconds to 20 seconds, although more for some really hard to die in games in which case we may have to skip them. The whole thing will take between 7 to 10 minutes. The alternative is to pick some other arbitrary short goal or use a simple game like Galaga to do a complete TAS with very conservative button presses of which would not be very interesting. I personally think the fastest death tour seems more interesting but we'll have to see how it plays out and I'm open to suggestions. Following that, we'll show SMB3 total control and the GeekPwn payload but with AGDQ graphics and different NSF music - the amazing level 1-1 takeover is too good to pass up and most people haven't seen it. We'll transition away from that console and start playing [redacted] which is when things will really get interesting. Fortunately, [redacted] is a very quick hop into complete control and it has the advantage of [redacted] which means we can easily show [redacted]. At one point, we'll allow Twitch Chat to [redacted] which could get kind of crazy. It's going to look like utter randomness because it's Twitch chat but it should still be fun. From there we'll move to LoZ:LttP which is just long enough for some decent commentary, as in, there's some actual gameplay involved (about 3 minutes), and during that time there's all kinds of crazy things going on thanks to work from Tompa. At the end, we'll trigger a glitch at the Sanctuary which will give us total control, and we'll use it to trigger the mirror effect used to change between light and dark worlds. Instead of transitioning to the dark world, we'll instead transition to [redacted] and show [redacted] which will definitely be the highlight. I've made another update with the start-of-event status which you can read here. Old post below: For AGDQ 2017 I'm hoping to really up our game as a site when it comes to raffle prizes. Please consider making something, donating something, or otherwise pitching in for some really good raffle prizes (or one nice prize - suggestions welcome). Take note that submissions are only open from September 4-10 and can be done one at a time, so I plan to do the last one no later than Sept. 9th. Current list of ideas, updated as we discuss and punt some ideas to later GDQ's (now with holes thanks to moving ideas out): Idea #1 Console chaining, but not that chaining Update, 2016-09-03: In the months (years?) since this idea first came up we've tossed around a number of ways to use this kind of ability. During the last month we've experimented with something related that, if we manage to pull it off, will be truly out-of-this-world amazing. This is about the only thing we're going to be quiet about but it will make sense why. The description of this will probably be "mystery game". Idea #2 (added 2016-07-21): N64 shenanigans In the (very possible) event we can't get chaining to work, I'd instead like to focus on an N64 total control, or at least near total control. There are some really interesting options on the table already and some interesting things we could do after gaining total control but much more work is required. (Update, 2016-08-19: Post DEF CON, the craziness level of some of the propositions is now off the charts but we haven't confirmed we can make some of the ideas work so we might have to submit this one as a mystery entrant). Idea #3 (added 2016-07-21): External control We faked taking over a camera during Pokemon Plays Twitch due to being unable to get the serial commands and cabling worked out fast enough, but it's a very intriguing idea to have TASBot, via a game, take over something outside of a console. Suggestions on what that might be are welcome, as I haven't figured it out yet. :) Idea #6 (added 2016-08-19): Mario Kart 64 remaining cup(s) Weatherton is working toward completion of all Mario Kart 64 cups. We may be able to show one or more cups completed, and this will likely be the last time MK64 is showcased. It may or may not make sense to do this for AGDQ 2017 but it should be good entertainment regardless of the timing. Idea #8 (added 2016-08-19): Something involving Pokemon Go We have absolutely no idea what we would do yet. We know it would be cool to do *something*, though... Update, 2016-09-03: With recent litigation from Nintendo we have to be careful how we approach this but we would still like to fit this in in some way. We don't yet know what that looks like. Idea #9 (added 2016-08-19): A TAS on NES Classic Edition (NES Mini) Seriously, this device is just too cute to not do something with. It's hard to say how much of a hit it's going to be, and we clearly won't know for certain if we can even make something happen before the AGDQ 2017 submissions phase passes as the console isn't even slated to come out until November 11th. Ideas include rapidly beating or breaking several games in succession to figuring out a way to escape the confines of a game and do something interesting with the hardware. We... just don't know what we can do yet. Idea #11 (added 2016-09-03): MK64 Weatherton has finished his MK64 run to the point where it can be demoed, although he plans on finishing it further. We'll pitch different categories with different cup choices and work out good commentary and perhaps donation incentives. This will be the last time for a while that we plan to pitch a MK64 run. Updated 2015-08-08: Added list of volunteer positions needed Updated 2016-07-21: Updated to reflect current thinking Updated 2016-08-18: Clarified chaining / virus idea, added a fair number of other ideas Updated 2016-08-21: Added Tetris TGM Updated 2016-09-03: Punted ideas to SGDQ 2017, added MK64, hinted at new "chaining" replacement Updated 2017-01-08: Added current plan and link to start-of-event status
I was laid off in May 2023 and could use support via Patreon or onetime donations as I work on TASBot Re: and TASBot HD. I'm dwangoAC, part of the senior staff of TASVideos as the Senior Ambassador and BDFL of the TASBot community; I post TAS content on YouTube.com/dwangoAC based on livestreams from Twitch.tv/dwangoAC.
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11264
Location: RU
As was suggested on IRC and sounds best to me, it should start from some (FF?) game on NES, and at the end of the chain it can be taking over the same game on GBA, but while at the first step it's being ACEd, the last step should actually complete the game. Bonus points if it can have a glitched ending on GBA version as well. So this is what I suggest to start testing with: is it possible to "GEG" the GBA version? I would do that if I knew GBA asm, but I only now NES and Genesis. Question: do we have enough speed for data going from NES controller port to successfully and efficiently provide payload to younger consoles?
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.
Warepire
He/Him
Editor
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
I was more thinking, save that big chain ACE for 2018, and start of smaller. Like finding an ACE glitch in one game, and programming it to complete another game. Should definitely keep the idea of using 2 consoles connected with each other. Not sure how feasible it would be to accomplish this, depending on available consoles, length of the game, and how deterministic it is when run on console.
Moderator, Senior Ambassador, Experienced player (898)
Joined: 9/14/2008
Posts: 1007
feos wrote:
Question: do we have enough speed for data going from NES controller port to successfully and efficiently provide payload to younger consoles?
Bare minimum, we can put the first NES controller port in Multitap mode which would be four bytes per frame, or to think of it in SNES terms that would be enough to provide input for two controllers per frame. This would be a horrible minimum, however; that datarate equates to 4*60=240 bytes per second which would severely limit the kinds of downstream payloads we could send. Hopefully we can do something similar to Pokemon Plays Twitch where we polled 8 times a frame by taking control of the latch pin manually - the mechanics would be different because NES generally only reads one byte per controller rather than the SNES's two but that would still get us 4*8*60=1,920 bytes per frame, and my hope is we could get it even higher and shoot for 4*16*60=3,840 bytes per frame. I anticipate the NES payload will be low color, simple graphic blocks / tiles appearing showing what buttons are being pressed but the payload will need to scale down to fit the CPU cycles available after handling payload forwarding. Much experimentation here is still required.
Warepire wrote:
Like finding an ACE glitch in one game, and programming it to complete another game.... Not sure how feasible it would be to accomplish this, depending on available consoles, length of the game, and how deterministic it is when run on console.
I think this can be substantially parallelized - we need people to find total control exploits for NES, SNES, N64, Game Boy Advance, and Game Boy (or alternately, if we instead loop back to an NES game, figure out how to get just Game Boy Advance's Final Fantasy stairs glitch to work so we can start with NES FF and end with GBA FF). In essence, we'll just start with whatever end is easiest and build from there, or we might discover we have to bridge two sets of two consoles or something. With over 18 months to go to AGDQ 2017 we have as of right now plenty of time to determine what's feasible and what isn't. Thoughts?
I was laid off in May 2023 and could use support via Patreon or onetime donations as I work on TASBot Re: and TASBot HD. I'm dwangoAC, part of the senior staff of TASVideos as the Senior Ambassador and BDFL of the TASBot community; I post TAS content on YouTube.com/dwangoAC based on livestreams from Twitch.tv/dwangoAC.
Warepire
He/Him
Editor
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
dwangoAC wrote:
Warepire wrote:
Like finding an ACE glitch in one game, and programming it to complete another game.... Not sure how feasible it would be to accomplish this, depending on available consoles, length of the game, and how deterministic it is when run on console.
I think this can be substantially parallelized - we need people to find total control exploits for NES, SNES, N64, Game Boy Advance, and Game Boy (or alternately, if we instead loop back to an NES game, figure out how to get just Game Boy Advance's Final Fantasy stairs glitch to work so we can start with NES FF and end with GBA FF). In essence, we'll just start with whatever end is easiest and build from there, or we might discover we have to bridge two sets of two consoles or something. With over 18 months to go to AGDQ 2017 we have as of right now plenty of time to determine what's feasible and what isn't. Thoughts?
Personally, I find the FFII Stairs glitch run extremely boring without a RAM display, so I would prefer a different game, though not sure which right now.
Moderator, Senior Ambassador, Experienced player (898)
Joined: 9/14/2008
Posts: 1007
Warepire wrote:
Personally, I find the FFII Stairs glitch run extremely boring without a RAM display, so I would prefer a different game, though not sure which right now.
Noted. The boring nature of the glitch is my number one reason I'm not overly thrilled with that particular proposal unless the glitch can be done very quickly, but at the same time the honest truth is we're at the mercy of whatever games we can find exploits for. My hope is that the entire process takes about an hour and shows interesting games broken in interesting ways, preferably different interesting ways, but hope and reality are two different things. :) We'll obviously have to make some compromises along the way and there's the very real possibility that one console requires a stubborn portion of grinding but we should be able to distract around those portions somehow.
I was laid off in May 2023 and could use support via Patreon or onetime donations as I work on TASBot Re: and TASBot HD. I'm dwangoAC, part of the senior staff of TASVideos as the Senior Ambassador and BDFL of the TASBot community; I post TAS content on YouTube.com/dwangoAC based on livestreams from Twitch.tv/dwangoAC.
Ambassador, Experienced player (696)
Joined: 7/17/2004
Posts: 985
Location: The FLOATING CASTLE
Problem is that getting into a state where controller input programs the game is really hard. The bootstrap program for a total control takeover is much more complicated than the credits jump that is the typical ACE goal. If it is possible in FF1 it might require a very long setup. Jumping to status or equipment or item lists are the likely possibilities and all would take a long time to set up from a legitimate start state. In SMW you can tweak a lot of memory much faster and more easily by eating berries and throwing some blocks around. Or Pokemon where you glitch up the item list then move things around and throw away items to set up the memory both arbitrarily and quickly. Now if we allow for setting up a savegame then I bet we can work something out with either FF1 or FF2 stairs glitch. From a good setup it would only take a few minutes to execute the stairs glitch. The next question is whether or not that savegame state is reachable from a legitimate start. If it is then we could make a verification video (possibly even on console) and post or publish it later.
Moderator, Senior Ambassador, Experienced player (898)
Joined: 9/14/2008
Posts: 1007
TheAxeMan wrote:
Now if we allow for setting up a savegame then I bet we can work something out with either FF1 or FF2 stairs glitch.
Either this or not use Final Fantasy - I'd love to represent Final Fantasy in some way but I confess that the idea of grinding the stairs for 5 minutes seems like a really bad idea. I'm totally fine with using an existing movie, the fact that it's newgame+ is a bigger deal to us than it is to viewers who will be astounded more by the chaining than how Final Fantasy itself was compromised. Thanks for the info, hopefully there's still a way to make Final Fantasy work out.
I was laid off in May 2023 and could use support via Patreon or onetime donations as I work on TASBot Re: and TASBot HD. I'm dwangoAC, part of the senior staff of TASVideos as the Senior Ambassador and BDFL of the TASBot community; I post TAS content on YouTube.com/dwangoAC based on livestreams from Twitch.tv/dwangoAC.
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11264
Location: RU
I love the SRAM idea. Yes, it must be done via valid replay somehow. But unfortunately, even if we console verify the setup movie, we wouldn't have time to show it entirely. I guess we need to post it beforehand somewhere and then just refer to it. SRAM opens another possibility: prepare RAM or SRAM itself so that you could just do a simple jump using controller data, and the destination would be that preset array of bytes that could be executed as code. The most efficient way would be to prepare something like a really short but endless loop to read from one controller and send to another. Shouldn't take too much space, and would be pretty self-managing. We can even reduce payload to not be present on the first step at all. Feeding stripped data is the easiest with this bandwidth.
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.
Experienced player (601)
Joined: 10/23/2004
Posts: 706
I think it would be neat to do something similar to F-Zero VS Link to video For example, create two ROM hacks that pass information between two consoles to enable a co-operative game of some type. I think this would be particularly interesting if the two consoles were different models. So, for example, a competitive (or co-operative) Mario/Sonic game in which one player controls Mario using a SNES and the other player controls Sonic using a Genesis. Seeing these two classic worlds collide would be very interesting and would likely drum up a lot of interest and attention from people who remember these two characters / consoles as arch rivals. Blast processing vs. Mode 7; GO! Thoughts?
Current Project: - Mario Kart 64
marzojr
He/Him
Experienced player (748)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Weatherton wrote:
For example, create two ROM hacks that pass information between two consoles to enable a co-operative game of some type. I think this would be particularly interesting if the two consoles were different models. So, for example, a competitive (or co-operative) Mario/Sonic game in which one player controls Mario using a SNES and the other player controls Sonic using a Genesis.
This would be possible, but a nightmare to synchronize. On the Genesis side, you would need to find one of the rare Sega modems (or build one using the extension port), with neither case giving a large baud rate. And the SNES may have some issues due to its cycle-starved processor (but I can't speak with authority on the SNES). Out of curiosity, what kind of game were you thinking of? A racer like in the video you posted?
Weatherton wrote:
Blast processing vs. Mode 7;
With a good enough hacker/programmer on the Genesis side, these could plausibly compete at an even footing (granting the Super FX co-processor for the SNES, of course).
Marzo Junior
Editor, Player (44)
Joined: 7/11/2010
Posts: 1022
dwangoAC wrote:
feos wrote:
Question: do we have enough speed for data going from NES controller port to successfully and efficiently provide payload to younger consoles?
Bare minimum, we can put the first NES controller port in Multitap mode which would be four bytes per frame, or to think of it in SNES terms that would be enough to provide input for two controllers per frame. This would be a horrible minimum, however; that datarate equates to 4*60=240 bytes per second which would severely limit the kinds of downstream payloads we could send. Hopefully we can do something similar to Pokemon Plays Twitch where we polled 8 times a frame by taking control of the latch pin manually - the mechanics would be different because NES generally only reads one byte per controller rather than the SNES's two but that would still get us 4*8*60=1,920 bytes per frame, and my hope is we could get it even higher and shoot for 4*16*60=3,840 bytes per frame. I anticipate the NES payload will be low color, simple graphic blocks / tiles appearing showing what buttons are being pressed but the payload will need to scale down to fit the CPU cycles available after handling payload forwarding. Much experimentation here is still required.
The way that a NES controller port works, it sends a "ready to read" signal to the controller, then it repeatedly sends "read 1 bit" controller signals to the controller and gets single bits back in response. On an official NES controller, it reads current state of the 8 buttons followed by 1s forever. However, the signals sent, and the number of bits to read, are both fully under software control. The fastest possible data transport to a NES, therefore, is to use a controller with infinitely many buttons, and just read all of them (i.e. you keep sending "read 1 bit" signals forever and get a sequence of bits inbound). I believe this would actually work on hardware if you had a large number of official controllers and swapped which controller was in the port every few clock cycles; our hypothetical TAS superhuman might actually be able to do that. I'm not sure offhand what sort of data rate would be possible because the limiting factor would probably be how quickly you could store the bits in memory. Of course, to test this, you'd also want an emulator that can simulate subframe input with infinite-button controllers. I'm not sure we have any of those yet. Note that we could get a pretty fast data transfer the other way, from the NES to a system connected to it, via use of the "read 1 bit" and "ready to read" signals as sending a 0 and a 1 (or vice versa). If you're trying to make a NES into a programmable SNES controller or whatever, that would probably be the way to go. (One potential problem: the NES would need to be able to write the controller wires as fast as the other console was trying to read them, assuming we're not putting extra hardware in between. It might be necessary to use faster consoles to control slower ones.)
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
dwangoAC wrote:
I hope to chain multiple consoles together and successively take total control of each console, forwarding button presses *out* the second (or higher) controller port by abusing the latch pin. This will require multiple people involved with hardware adaptation boards, total control runs, and payloads on each console.
I think this is a bad idea. For nearly every demonstration till now, you've always had false starts, things for whatever reason not syncing upon the first try to run a game. You've had to clear SRAM and try again multiple times till you got it right. Not to mention potential interference and so on. Say you get the first console all ready to go and it looks like it's playing correctly, how do you know the second one won't false start? If it does, are you going to try to correct that issue, and then start the TAS on the first console again from the beginning? Then this problem might occur again for the 3rd console and so on. I enjoy watching dominoes, but it's easy to knock something over while setting it up, and that's been the track record more often than not. If you were going to film something in your home at your leisure where you can have as many takes as you want, and none of the interference you've seen at GDQ, then I think this is a cool idea. For a live audience, this is asking for trouble, and odds are heavily against you in pulling this off without problems.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Player (38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
ais523 wrote:
(One potential problem: the NES would need to be able to write the controller wires as fast as the other console was trying to read them, assuming we're not putting extra hardware in between. It might be necessary to use faster consoles to control slower ones.)
I quickly looked at this and from what I could tell counting clock cycles the NES is just fast enough to be able to respond in time to the SNES autopoller timings using cycle accurate code. So provided that the SNES reads the controllers sequentially it should be able to provide inputs for four controllers per frame. (This hasn't been tested though so it might be inaccurate, I'm gonna see if I can write some code and put on my NES flashcart to verify) After the payload is written to the SNES this can be increased a bit since it's then possible to just use the controller ports as a general serial link and read/write as fast as the consoles can handle. Another thing worth considering is using a Famicom and hook up the expansion port (or use the NES expansion port, but it has a pretty strange connector afaik). Using the expansion port should make it possible to increase the data rate a bit because of a few more I/O:s.
Post subject: Re: Dominoes
marzojr
He/Him
Experienced player (748)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Nach wrote:
I think this is a bad idea.
Oh, yeah, I forgot to add that Genesis emulation (even GPGX, the core used in BizHawk) is not good enough to guarantee synch on all cases on console unless the game follows some very strict rules.
Marzo Junior
Joined: 7/2/2007
Posts: 3960
Frankly I think that total control TASes are a bit overplayed now. Chaining together multiple consoles is an interesting technical challenge, and it worked well for the Pokemon Plays Twitch demo, but I don't think most watchers are really going to appreciate a show that amounts to "we do what we did last year, only even more so." That, combined with the inherent technical risk that Nach referred to, makes this proposal have a poor risk:reward ratio, by my estimation. I'm not sure what I'd suggest as an alternative, but things that have strong interaction with the audience seem to go over well. Giving runners the chance to play their games in ways they haven't seen before, making nods at Twitch, etc. I suggest focusing on the content of the payload rather than the mechanism of the payload. After all, the content is far more visible to the audience than the little bot and laptop are. I guess one possible suggestion would be trying to rig up some kind of AI to play "against" the player (or at any rate to rig the normal level hazards) in a nominally-singleplayer game.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Derakon wrote:
I guess one possible suggestion would be trying to rig up some kind of AI to play "against" the player (or at any rate to rig the normal level hazards) in a nominally-singleplayer game.
This seems like a very interesting idea. Take a multiplayer game with simple variables like say Super Bomberman 2. How good are players in battle mode against the built in AI? Now let's say we make our own AI which can monitor all the relavent memory variables and send in input via a controller just like a human. Making our own AI to wipe the floor with players is not something we've done before. On the other hand, making AIs isn't speedrunning. I'm not even sure I'd call it a TAS anymore. Otherwise, I think your remarks about focusing on content are spot on. We did some pretty crazy technical stuff this past year with Brain Age, and the real crazy work was wiring up a DS like that. Yet I have yet to see anyone care about that part of it. The end is more important than the means.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Editor, Player (68)
Joined: 1/18/2008
Posts: 663
Before I begin, I will state that I think this idea is dumb. But I guess it will work OK for the intended audience. Hopefully a better idea is chosen. I'll help where I can. This will almost certainly require some protocol adapters between some of the consoles, as mentioned. Thus our output protocols can be non-standard if it helps at all.
dwangoAC wrote:
Bare minimum, we can put the first NES controller port in Multitap mode which would be four bytes per frame
NES doesn't have this like you think it does. This is SNES only. If you want to act like Four Score, then we can emulate that hardware, but at that point you might as well do independent data per latch and disable DMC if it is used. This will require some tool development. (My robots don't support Four Score nor dynamic latch detection changing, though both can be added)
dwangoAC wrote:
Hopefully we can do something similar to Pokemon Plays Twitch where we polled 8 times a frame by taking control of the latch pin manually
Yes, this can be done, but it requires a game that doesn't use DMC DMA or disabling DMC DMA and having some sort of trigger to switch playback mode in the bot. Hopefully by then we can get a higher datarate as well since latchrate was a bot limitation last time.
dwangoAC wrote:
With over 18 months to go to AGDQ 2017
Date?
ais523 wrote:
The fastest possible data transport to a NES, therefore, is to use a controller with infinitely many buttons, and just read all of them (i.e. you keep sending "read 1 bit" signals forever and get a sequence of bits inbound). I believe this would actually work on hardware if you had a large number of official controllers and swapped which controller was in the port every few clock cycles; our hypothetical TAS superhuman might actually be able to do that. I'm not sure offhand what sort of data rate would be possible because the limiting factor would probably be how quickly you could store the bits in memory.
The problem with this is we are no longer acting like a normal controller, and we strive to act like official hardware in the TAS community - be it emulators or emulating controllers. But in addition there are several flaws: 1) Physically swapping a controller several hundred times a second is probably physically impossible (yes, this is a robot and it is virtual, but as I said, we try to emulate hardware very closely...) and generally, controller swapping shouldn't be allowed anyway; 2) Without a latch, a swapped controller will have random contents in the shift register at powerup, and this powerup occurs upon plugin; 3) There is likely settling time so we may need to wait - this will need to be verified in practice and against the datasheet; 4) Assuming the register has power already, without the latch signal asserted, the register will contain the values at the last latch. I guess if we need to act like unofficial hardware for a demo we could, but for practicality, we use latches as a sync point of reference. This is particularly important with cycle-inaccurate emulators.
marzojr wrote:
Oh, yeah, I forgot to add that Genesis emulation (even GPGX, the core used in BizHawk) is not good enough to guarantee synch on all cases on console unless the game follows some very strict rules.
Genesis is non-deterministic. Previous TAS verifies were done with a loader and input file manipulation. Work needs to be done to improve emulation and strip away the need for a loader. ---- Another idea would be creating an AI for a normally multiplayer game, perhaps using computer vision or something. Or even a computer vision robot in a single player game, but in a race. (I already had an idea to make a K3 computer vision bot...) But this is getting away from TAS and more into general neat stuff.
true on twitch - lsnes windows builds 20230425 - the date this site is buried
endrift
Any
Emulator Coder
Joined: 12/14/2014
Posts: 161
I thought the other day about unusual controller hardware and realized it might be interesting to try to do something with Duck Hunt, but I'm not sure what could be done that's actually interesting.
Joined: 7/2/2007
Posts: 3960
Back in college in the early 2000's our robotics lab already had a bot that played Duck Hunt. It's not that interesting honestly. A camera, some servos, and some basic motion-tracking software plus the appropriate aiming code.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
True wrote:
Another idea would be creating an AI for a normally multiplayer game, perhaps using computer vision or something.
I think making such a thing is unnecessary. We have all the ports of the console connected to a computer, we have regular controllers connected to the computer too. The computer is running an emulator with the same game and has access to all RAM and can study all the relavent variables, including what power-ups are where, manipulating random drops and all that. The players' input is entered into the computer which is then fed verbatim to the console, while the computer adds its own input as well for the player it controls. This only works if the emulator is pretty accurate for the game in question and we can get the console to be running in sync with it.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
marzojr
He/Him
Experienced player (748)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
True wrote:
Genesis is non-deterministic.
The only significant source of nondeterminism on Genesis are memory refresh cycles, which are poorly understood and not emulated at all (and may turn out to be deterministic with enough knowledge). And maybe ROM access speeds for older ROMs. The rest is lack of proper emulation either because of lack of knowledge or because no one bothered to emulate it properly: most emulators use incorrect cycle counts for some instructions because the Motorolla manual lists them wrong; bus access contention between 68k and z80 is not properly emulated because that would require much more precise knowledge of the 68k than is available, and would probably require micro-opcode emulation of the 68k (and much better z80 emulation too, as well as keeping them in more perfect synch); keeping the VDP in synch with the other processors because it can cause delay on the 68k if the 68k sends it a command and the VDP's FIFO is full (likely to happen only during active display, but...); and some other things. These all combine to make the 68k run effectively slower, with some nondeterministic slowdown also on the z80 if it is using main RAM (but this is very rare). If the game is sufficiently "simple", these innacuracies will not matter much: if you can guarantee that the game will always finish a frame with "ample" time to spare, poll controllers during vblank interval, don't use computational time as a source of pseudo-randomness (directly or indirectly) and don't do anything too tricky in regards to timing, the game will most likely synch on console with relatively minor changes (say, removing all lag-frame input). Most Genesis games do only one of these (poll controllers onon vblank internal), so the effects of those emulation innacuracies matter a lot.
True wrote:
Previous TAS verifies were done with a loader and input file manipulation. Work needs to be done to improve emulation and strip away the need for a loader.
What did the loader do? I find it odd, as games generally followed the Sega docs closely and cleared all RAM (main and z80) and set VDP, YM2612 and PSG to known states at the first boot.
Marzo Junior
Editor, Player (68)
Joined: 1/18/2008
Posts: 663
marzojr wrote:
True wrote:
Genesis is non-deterministic.
The only significant source of nondeterminism on Genesis are memory refresh cycles, which are poorly understood and not emulated at all (and may turn out to be deterministic with enough knowledge).
Also Z80 R register. Also VDP/CPU clock cycle offset and VDP register state. Also probably other things I can't remember or don't know about right now. It can be made to be deterministic, either with a loader or with some hardware modifications. notaz posted in these forums about his project but didn't provide a ton of information; he was able to sync some Sonic games and Ecco synced with NO input modifications IIRC.
marzojr wrote:
The rest is lack of proper emulation
That's putting it lightly :) Bus access timings and contention are poorly emulated, if emulated at all VDP is poorly emulated Probably much else as you described
marzojr wrote:
If the game is sufficiently "simple", these innacuracies will not matter much: if you can guarantee that the game will always finish a frame with "ample" time to spare, poll controllers during vblank interval, don't use computational time as a source of pseudo-randomness (directly or indirectly) and don't do anything too tricky in regards to timing, the game will most likely synch on console with relatively minor changes (say, removing all lag-frame input).
I would like to test this theory, but all the games I have that have runs available desync nondeterministically. If I had a copy of Ecco I would love to test your point. I've actually calculated some odds for SMS (by empirical testing backed by math) and Genesis (math) and IIRC Genesis was something like 1/1024 or worse for starting state to be consistent.
True wrote:
Previous TAS verifies were done with a loader and input file manipulation. Work needs to be done to improve emulation and strip away the need for a loader.
Look in the console verification thread for notaz posts. We also discussed on IRC. I can't remember the details right now, but it allowed games like Sonic which behave very nondeterministically on console (particularly during SEGA scream) to be more deterministically played back. Doesn't this discussion warrant a different thread, or to be put in Console Verification thread? Genesis wasn't even discussed as a potential target, though admittedly for the original idea to succeed, other consoles will also likely need to be more accurate than listed now.
Nach wrote:
I think making such a thing is unnecessary.
What, computer vision robot? It's a neat thing. Is it necessary? No, none of this is necessary. Yeah, we can illegally run a ROM alongside a game and hope it doesn't go out of sync...or we (or I) can write an AI that beats a game unmodified, like K3, and can adapt this to other platformers. I could even have it press keyboard buttons mechanically :)
true on twitch - lsnes windows builds 20230425 - the date this site is buried
marzojr
He/Him
Experienced player (748)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
True wrote:
Also Z80 R register. Also VDP/CPU clock cycle offset and VDP register state.
Z80 R register is memory refresh :-p But I had forgotten about the starting VDP offset, yeah. A custom game could work around it to a high degree of certainty by waiting for the first vblank interrupt, then waiting for vblank interval to finish, then doing a trick to synchronize the 68k with the raster beam. But stock games are out of luck, though. And you are correct, this should be discussed on another thread; I only mentioned it because of Weatherton's suggestion of tying a SNES and a Genesis together to show why it would be hard, if not impossible, to synch reliably live on AGDQ.
Marzo Junior
Active player (432)
Joined: 4/21/2004
Posts: 3517
Location: Stockholm, Sweden
I offer my 9-run as an alternative in case you find it interesting enough. If I manage to finish it before 2017, feel free to do whatever you like with it. If not, then don't mind me :)
Nitrogenesis wrote:
Guys I come from the DidyKnogRacist communite, and you are all wrong, tihs is the run of the mileniun and everyone who says otherwise dosnt know any bater! I found this run vary ease to masturbate too!!!! Don't fuck with me, I know this game so that mean I'm always right!StupedfackincommunityTASVideoz!!!!!!
Arc wrote:
I enjoyed this movie in which hands firmly gripping a shaft lead to balls deep in multiple holes.
natt wrote:
I don't want to get involved in this discussion, but as a point of fact C# is literally the first goddamn thing on that fucking page you linked did you even fucking read it
Cooljay wrote:
Mayor Haggar and Cody are such nice people for the community. Metro City's hospitals reached an all time new record of incoming patients due to their great efforts :P
1 2
7 8