Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
So I have a quick update Re figuring out if Wile E. becomes more aggressive in the third loop or not.
Based on experimenting with RAM Search and the hex editor, it seems that the Coyote has a position variable stored in RAM, but doesn't have a speed variable stored in RAM. The game probably calculates how far the Coyote should move from whatever it's coordinates were on the last frame based on what level you are in, what state the coyote is in, and if the coyote is about to take damage before the next frame. Here are the relevant addresses in hexadecimal
Address 34: Coyote respawn timer (initialized when the Coyote is killed, and starts counting down to 0. The coyote respawns when it hits 0, and the timer stays at 0 until the next time the coyote is killed).
Address 3E = Coyote State (0 is normal state, in the other states, this variable counts down to 0, at which point the coyote goes back to normal. This count down is used for the rocket ship and the roller skates).
Address 50: Distance of Road Runner from left edge of the screen
Address 51: Distance of Wile E. Coyote from the left edge of the screen
From here, what I would need to do to determine if the Coyote is becoming harder on later levels is to make a graph of Coyote speed over the course of the TAS, with the Coyote state of each segment of the graph also marked. Ideally, I would do this using Lua. However, I don't know how to do Lua scripting at the moment, so I was hoping that somebody could help me figure out how to do this in Lua or how to extract the RAM data from BizHawk so that I could write a program in a different programming language to make the graph for me (I would also make other graphs comparing Coyote speed relative to the road runner and coyote recovery time throughout the TAS).
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
FractalFusion wrote:
Nice! I didn't expect this much of an improvement over the other TASes.
Anyway, I made a 4-way comparison of Pitfall TASes on TASVideos:
Thanks for the video. It really highlights just how cycle based of a game Pitfall! is. This is probably one of the earliest examples of rubberbanding in video games. However, instead of using increased/more dangerous hazards like Mario Kart does, Pitfall! uses the global timer cycle for all hazards to smooth things out.
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
electricslide wrote:
Ultimately, I think this site is primarily about entertainment. Making your movie less good but faster is counterproductive. If it were something that was known to be faster but you weren't quite sure how to implement it, that would be one thing.
I generally feel that way about scoreboards in general. There are games where it's faster to finish second because of victory animations, etc. I'd go so far to say that Victory animations shouldn't count against the player in terms of assessing the speed of their submission, only the actual time that they can control.
This would do away with a lot of the nonsense, where you are slower and less accurate, over an optimal submission in terms of performance.
I'm not so sure if I agree with that premise. What it sounds like you're saying is that the individual components of a TAS should be as optimized as possible, even if the TAS as a whole is slower than it could have been.
To take this to an extreme, suppose you have a video game with 180 rooms in it. If every 10 rooms you can die to save time overall by changing the global timer cycles, then the TAS that seeks to make the fastest overall TAS would die 18 times. If each of these deaths saved 30 seconds in the long run in a 30 minute long TAS, then that would add up to 9 minutes of time save throughout the whole TAS (a final time of 21 minutes). However, if dying was 2 seconds slower than going through a given room without dying (ignoring the 32 seconds of time save that would occur later on), then somebody following your optimization pattern would never implement this strategy.
Thus, by breaking the game down into discrete components with the goal of making each segment as fast as possible from the perspective of making the current segment of the TAS as fast as possible, the TASer would make a suboptimal TAS, which would be less entertaining and optimized compared to the TAS that allows itself to temporarily perform in an "unoptimal" way in order to save time later on.
Essentially, the strategy you're suggesting is easier, since it would require the TASer to just make each room/level in the game as fast as possible in order to finish the TAS. However, if a TAS requires delays for RNG manipulation or some other sort of complex mechanism to get the fastest overall time, then the TAS will miss a lot of possible optimizations due to this policy.
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
@slamo Sorry, I didn't realize that there was another loop before the difficulty stops increasing. I'll submit a new version that completes the first 16 levels later tonight (it shouldn't take too long, since the first half of the TAS will be the same as before).
By the way, does the game only have 100 levels? What happens when you beat the 100th level? @spikestuff
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
feos wrote:
Lobsterzelda , is that the kind of movie ending you intended to make or not? As Fog has requested, please post the movie that does reach the credits.
Sorry for the delay. I couldn't figure out how to get the movie file to go to the ending using a hex editor, so I just played through the userfile movie I made, made a save state at the end of it, triggered the credits, and then made a dtm file from that, which I've posted here http://tasvideos.org/userfiles/info/55849373723630297
It says that the movie file starts from a save state, but based on the number of lines of input in the file, it appears to have stored all inputs from the moment the console was powered on, so this file should work normally without any setup.
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
Alyosha wrote:
Lobsterzelda wrote:
Alyosha wrote:
I'll add it to the list for A2600. Most likely it just needs a database flag.
What is a database flag?
In your BizHawk folder you will find a folder called gamedb.
In that folder you will find various lists of games for different consoles.
In the A2600 file the entry for haunted house is this:
sha1:1476c869619075b551b20f2c7f95b11e0d16aec1 Haunted House (1981) (Atari) A26 m=4K;NTSC=true
A database flag would modify this entry to tell the emulator to do different things with the game while loading.
The two flags are
SP_RESET=true;
and
SP_FRAME=true;
So, just to be extra clear, the above entry for Haunted House would become either:
sha1:1476c869619075b551b20f2c7f95b11e0d16aec1 Haunted House (1981) (Atari) A26 SP_RESET=true;m=4K;NTSC=true
sha1:1476c869619075b551b20f2c7f95b11e0d16aec1 Haunted House (1981) (Atari) A26 SP_FRAME=true;m=4K;NTSC=true
If you want to test and see which one works give it a try.
If neither of those things work the mapper (m=4k) is probably wrong but that's much less likely.
I tested both of them, but neither of them worked.
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
I don't know if this is meaningful or not, but according to Stella, the first frame of Haunted House goes from 0 to the 42nd scanline before going to the second frame. I looked at a few other atari 2600 games and didn't see this number come up on any of their first frames. The only reason why I wonder if this is relevant is that on BizHawk the emulator renders the first frame, and then gets stuck on an endless loop in the second frame due to Vsync never being triggered, which allows the scanline number to increase without bound (if the exception this normally triggers is disabled).
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
I have an update to the error that I saw earlier. I used a debugger when I tried to load Haunted House for the Atari 2600 and traced through the stack, which yielded the following chain of events:
1. BizHawk.client.EmuHawk.Program.Main(String[] args) calls the function SubMain(String[]) at line 83
2. BizHawk.client.EmuHawk.Program.SubMain(String[] args) calls ProgramRunLoop() at line 229
3. BizHawk.client.EmuHawk.MainForm.ProgramRunLoop() calls StepRunLoop_Core() at line 498
4. BizHawk.client.EmuHawk.MainForm.StepRunLoop_Core() calls FrameAdvance(IController, bool, bool) at line 3021
5. BizHawk.Emulation.Cores.Atari.Atari2600.Atari2600.FrameAdvance(IController, bool, bool) calls Cycle() at line 50
6. BizHawk.Emulation.Cores.Atari.Atari2600.Atari2600.Cycle() calls ExecuteOne() at line 390.
7. BizHawk.Emulation.Cores.Components.M6502.MOS6502X.ExecuteOne() calls ExecuteOneRetry() at line 2980
8. BizHawk.Emulation.Cores.Components.M6502.MOS6502X.ExecuteOneRetry() calls ZP_WRITE_STA() at line 2,758. The only line in function ZP_WRITE_STA() is a function call to WriteMemory(ushort, byte) at line 880. More specifically, this function call is WriteMemory(opcode2, A)
9. BizHawk.Emulation.Cores.Atari.Atari2600.Atari2600.WriteMemory(ushort, byte) calls BaseWriteMemory(ushort, byte) at line 182 using the same parameters that were passed to WriteMemory(ushort, byte) one step earlier.
10. BizHawk.Emulation.Cores.Atari.Atari2600.Atari2600.BaseWriteMemory(ushort, byte) calls WriteMemory(ushort, byte, bool) at line 123. The first two parameters passed into the function are the same two parameters that were passed to WriteMemory(ushort, byte) one step earlier
11. At this point, the second parameter passed to WriteMemory (which contains the value of the Accumulator register from earlier) is always 0. However, since this number can’t be Anded with 0 to produce a non-zero number, _vsyncEnabled never gets set to true. Since _vsyncEnabled always starts off being false at the beginning of this function call, the variable will always be false here. _vsyncEnabled being true here is the trigger to start a new frame, so this appears to be blocking the next frame from starting/the first frame from ending. Additionally, because this generates an endless loop, if the line of code that terminates execution when an exception occurs is removed, this will result in the value of the current scan line increasing indefinitely, well past the intended limit of 312.
I have stepped through the code and seen that A is indeed non-zero at several points. In fact, at one point it was 3, which if Anded with 2 would yield a non-zero number. However, whenever it got to the WriteMemory(ushort, byte, bool) function using the value of the accumulator, the accumulator always had a value of 0, which prevented _vsyncEnabled from being set to true (thus preventing the next frame from loading). Also of note is that the instruction ZP_WRITE_STA was always the instruction that was being executed when the WriteMemory(ushort, byte, bool) function was reached.
I don't know if any of this information is helpful, or if this is all already known. However, I am hopeful that somebody who better understands how BizHawk's code works (such as Alyosha) can use this information to help find out what's causing certain Atari 2600 games to crash when their ROMS are loaded in BizHawk.
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
Fog wrote:
Lobsterzelda wrote:
Fog wrote:
You don't need to end the inputs after pressing B at the end of the credits, just the A press needed to actually start it.
I thought that my revised input file did do that.
Sorry about that, I played the wrong file.
Anyways, the current file you posted doesn't actually activate the credits.
What's the last thing that my userfile movie does?
I edited the movie file using a hex editor, so if my movie doesn't end with the credits being activated, I'm not sure what the last thing the movie does is.
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
GJTASer2018 wrote:
@LobsterZelda Might be related to this issue in GitHub: github.com/TASVideos/BizHawk/issues/1524
Haunted House isn't on the list, but does it act the same way as the games described there?
It seems to be related. It crashes with the same error (unable to resolve frame). By using frame advance, I can see that it actually crashes on the second frame after loading the ROM, not immediately after loading the ROM. Here's the full stack trace of the exception:
System.Exception: ERROR: Unable to resolve Frame. Please Report.
at BizHawk.Emulation.Cores.Atari.Atari2600.Atari2600.FrameAdvance(IController controller, Boolean render, Boolean rendersound)
at BizHawk.Client.EmuHawk.MainForm.StepRunLoop_Core(Boolean force)
at BizHawk.Client.EmuHawk.MainForm.ProgramRunLoop()
at BizHawk.Client.EmuHawk.Program.Win32MainLoopCrashHandler.TryCatchFinally(String[] args)
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
I'm not sure if this is just a bug on my end or a bug with BizHawk as a whole, but for some reason, the game Haunted House for the Atari 2600 crashes when you try to load its ROM.
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
There's one spot in level 2 where you could temporarily save about 50-60 frames. However, because it isn't fast enough to beat the next laser cycle, it doesn't change the final time of the game.
If somebody could find a way to save 30 or so frames more in level 2, it may be possible to save another cycle. However, I doubt that there's any other places where time could be saved...
Overall, good run!
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
feos wrote:
If the community agrees to define it as proper full completion rule set, it won't have to be entertaining.
I created a WIP of the 100% route for Montezuma's Revenge, so that people could see what it looks like. I consider 100% to be getting all of the items outside the treasure room, since each item goes away once you get it. The treasure room treasures keep reappearing forever, so I ignored them in my definition.
Here's a link to my encode of the WIP:
Link to video
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
From looking more closely at Spikestuff's movie, it looks like the 128 frames saved is due solely to the death at the end of level 3 in the lava, which skips having to wait for the bridge to re-appear. There are 8 frames saved in level 2, but this is a temporary gain (since it's not fast enough to beat the next laser cycle).
In any event, I don't see any routing changes I could implement to improve upon this time, as these changes would need to be significant enough to beat a whole laser cycle. If I submitted a run with a different route but the same final end time, it would be unlikely to be accepted, since this run was submitted first.
Thus, I've decided to cancel my Montezuma's Revenge any % run in favor of making a 100%/all treasures TAS of the game. I realize that this would have to be accepted into moons to make it onto the site, but I believe that if any Atari 2600 game without a TAS on this site could make it into moons, this game would be it.
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
feos wrote:
Is any work planned? This submission is easily rejectable right now.
Now that I'm done with TASing Pitfall!, I'm planning to look into improving this run. Assuming that the time I finish with ties with Spikestuff's time, will the person whose movie gets published be determined by which movie is more entertaining?
Also, as an aside, I've been considering making an all items play through of this game (by items, I mean the things in the over world outside the treasure rooms, which there is a finite amount of). However, that submission could only be accepted to moons, and while I do find this game entertaining, I'm not sure if other people would find this game entertaining enough for that to be accepted...
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
Musicombo wrote:
Spikestuff wrote:
According to Dolphin. 5.0-10293 was released 10 hours before this TAS was submitted.
I have a lot of doubt on this movie.
Full disclosure: Right before recording this TAS, I was notified of the update to Dolphin and went ahead with it.
Is this not commonly accepted?
I'm assuming that what he was referring to was the fact that this was made on the version of Dolphin that was released 10 hours ago, which would imply that the whole movie was started and finished less than 10 hours ago (which is very quick, especially for a first TAS). Also, your submission says you only had 6 rerecords. I hope that that is inaccurate, because if you really do have only 6 rerecords in a 7 minute TAS, then your TAS would hardly be better than what a human player can do in the game, which would render the TAS pointless.
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
nymx wrote:
Lobsterzelda wrote:
Welp... It looks like I just got usurped.
Oh man... sorry dude.
It's all good. As an aside, I think this may be the last new version of Montezuma's Revenge to be submitted to this site... Unless somebody gets an urge to TAS the ZX Spectrum version of the game or the Apple 2 version of the game.
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
Welp... It looks like I just got usurped. I'm guessing that the net extra timesave in this run comes from going fast enough to make it ahead of another lazer wall cycle, since this is exactly 128 frames faster than my userfile run (and the laser walls flash on and off on 128 frame cycles).
Edit: What I meant to say is that you gain 128 frames by gaining a cycle on the laser walls (including the time it takes to walk through them). The actual laser walls themselves flash on and off in 92 frame cycles)
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
Alright, so I included dying in the first room of each level and the jump at the end of the third level to save time in a new movie, which I have uploaded to userfiles here: http://tasvideos.org/userfiles/info/55422944001805692
I have also updated the encoding of my TAS listed in the description, and I have updated my description of each level accordingly. If a judge could replace my submission movie with the userfile movie linked above, I would greatly appreciate it.
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
Spikestuff wrote:
JUMP!
18 frames shaved from ending input.
Edit: This TAS achieves 2 Death Abuses.
You have 2 and 4 down.
This is 1, 3 and 5 as a single gif:
Lol, I don't know why I always forget to jump at the end of my videos.
Btw, thanks for finding the other spot for death abuse. Once I include that, I believe it should be enough to push this game under 3 minutes in length, which is good, since being exactly 3 minutes flat was annoying me.
Experienced Forum User, Published Author, Skilled player
(1222)
Joined: 3/17/2019
Posts: 280
Spikestuff wrote:
My vote is Meh it was borderline a Yes for me.
I didn't turn off from the video and especially with Wile E. Coyote gaining on you I was actually more focused watching this.
The main curiosity that will drive me to the end will be the mountain ranges.
But it has that improvement of .32 seconds over the previous movie (spiked one) to what I assume came from this level.
It is a much more engaging TAS to watch over the previous one.
