Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
if you clip one step into the wall at the waterfall at the very beginning of the game, you can press down and fall onto the platform below. Currently testing if this is faster then the first wall clip.
EDIT: result: 110 frames saved! This also saves me some bullets which will save some frames later.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
shooting (and the shooting animation) make the clips go much faster, by bout a factor of 2 as far as I can tell, so the shots are definitely needed.
I will test that route, interesting idea.
@jlun2: good question, I have never tested it, I guess I will throw Harry against a wall for a while and see what happens.
In other news, I just successfully clipped through the 3 walls to get to the girl and saved over 6 seconds! Look like there is still more to this game yet!
EDIT: the new route is very close. So far I have one quick ladder slide and a pretty optimized route, but its 20728 frames new route and 20692 old route.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
mklip2001 wrote:
Nice improvement! The zip that avoids the death over the spike pit was pretty cool, though the escape from the girl's room is also interesting.
Would it save you any frames of input to jump before the ending and let momentum carry you down to the location that triggers the ending screen?
Nope, as soon as you start falling you fall at full speed. The reason I usually jump to get down pits is that when you jump, you can still control left and right movement. When you just walk off, you just fall straight down.
EDIT: Wait, D: I see what you mean now, you are right! Good catch! (fixed)
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
http://tasvideos.org/userfiles/info/24065823953371508
Alright the update is finally done.
In the end it was just under 5:50, so its a 30 second improvement compared to the published run, and ~18 second improvement over my last one.
I even managed to make a video! Link in the submission.
PLease update the movie file with this one.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Death no longer saves time!
With sufficient brute force I was able to skip the second death with a wall clip. Problem now is I don't know how to do the sink into the floor glitch to get the by the second stone head. Once I figure that out run should be quickly finished.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
With my brute force script I'll be starting back from the first clip and just brute forcing my way through.
Since there are ~4^200 ways to press A/B in the time it takes to do a wall clip, I'll just have run it for long enough that the final result is optimal enough.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
So it looks like I will have to delay / cancel this submission after all.
The amount of improvement I am getting from random brute force search is getting pretty large. For example the first wall clip in the original run can be done in under 1 second.
So, stay tuned for a sub 6 minute run!
I have no heuristics to really know when to press buttons, so it's all quite random, and the challenge now will be conserving gun ammo as a variable too.
Which is best, delay or cancel?
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Ahhh I see, good thinking!
Since the glitch seems to be an interrupt timing of some sort, I created a lua script that just blindly tries random inputs over a 600 frame window to try and get through that wall.
Incredibly, the winner so far did it in under 5 seconds.
unfortunately I have had no such luck with the water wall. It takes significantly longer to get through since you need to go through the whole wall. Might be out of luck there.
For now I will implement this and see what happens.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Looking at the map:
http://vgmaps.com/Atlas/NES/SuperPitfall-DarkLair.png
I don't think walking through the wall after getting the girl will save time. There isn't a quick way to get back to the warp point. You have to do a zig zag type path to the left.
EDIT: at the moment I am ~250 frames slower going through the wall, and I got through the wall in ~500 frames. So unless that can be cut in half, looks like it's slower.
Going to the right would work but you have to do another wall clip at the wall below the warp to jump up into it (avoiding the rope swinging.) I tested this, but there isn't enough on screen to make the glitch happen frequently enough to work.
Going through the 3 walls to get the girl would take far longer than 20 seconds based on the testing I've done so far.
not sure about going into the water to go through the wall in challenge 1.
EDIT: you can get through that wall in the water rather quickly, so there might be an improvement there after all!
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Arc wrote:
I've tested two particularly useful spots and found them to be possible to wall clip through. The question of whether the run could be faster depends on how quickly I can get through those walls. I'll have to test completely. One of them looks more likely than the other to be a time-saver.
I had tested a couple of potential wall clips as suggested to me by ventuz, but never came close to saving any time with them. I will be pretty surprised if you are able to get something to work.
good luck!
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Tangent wrote:
jlun2 wrote:
mklip2001 wrote:
If I recall correctly, Arc or FODA figured out this kind of way to trigger the credits around the time of the last published run. There was some discussion in the forums that ultimately rejected this kind of ending for looking sloppy. I guess standards about input endings have changed enough, though, in the last years.
It's a pretty good-looking improvement of a pretty mediocre game. It is annoying how many lives you have to lose, though, to get the Game Over.
I thought it was more acceptable now because this game will be vaulted regardless based on the current movie's rating anyways. :P
Well, this only displays the ending screen. The actual ending has its own music and when you press start goes into a second quest. Pokemon had a similar situation. It looped continuously on ending screens, but didn't actually reach the standard completed state, and that was ruled as being not a valid ending. I'm almost certain something like this has come up with a couple other games too (like, they were supposed to create save data but didn't, I think?), but which ones escape me at the moment.
Oh, this is interesting, I actually didn't realize it didn't reach a normal ending state since I never beat the game normally, (I only was aware of this trick from the AGDQ run)
Well no matter, I can just post an alternate file that beats the game normally, it will still be ~15 seconds faster then the original run due to the first wall clip. A judge can decide what to accept.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
As ventuz is no longer working on this one, I have taken it up and have been doing a bit of investigating into why the walking through wall glitch works, and how to make it faster.
So far what I found is that the glitch appears to be a bit of poor programming combined with a bit of lucky interrupt timing.
Here is the code where everything goes wrong:
$FEA4:85 D5 STA $00D5 = #$94 A:06 X:02 Y:05 S:EC P:nvUBdIZC
.
.
.
$C298:40 RTI A:01 X:00 Y:3D S:7A P:nvUBdIzC
.
.
.
$FD6D:A5 D5 LDA $00D5 = #$06 A:3D X:00 Y:3D S:7D P:nvUbdIzc
$FD6F:60 RTS (from $FDD3) --------------------------- A:06 X:00 Y:3D S:7D P:nvUbdIzc
$EAE9:C9 72 CMP #$72 A:06 X:00 Y:3D S:7F P:nvUbdIzc
$EAEB:B0 21 BCS $EB0E A:06 X:00 Y:3D S:7F P:NvUbdIzc
The problem is that normally, $00D5 is $#94 and the CMP #$72 fails. However, the interrupt call set $00D5 to #$06, so it passes. From there it goes on to increase the players x position. The code seems to reuse a lot of these addresses several times per frame, so its not really surprising something like this comes up.
At the moment I have no idea if manipulating this is possible at all.
EDIT: at the moment, my record for getting through the first wall is roughly 750 frames. I think I can save at least 100 off of that. Actually I'll probably continue from where kyman left off.
EDIT2: I don't think the second death skip will be faster. It turns out that you have to go further through the wall then initially thought using the glitch (since more wall is on the other side) The glitch also seems to happen much less frequently there.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
@Samsara: thanks for the encode! I was going to try making one...but then forgot.
@AngerFist: Thanks!
@mklip2001: The power up is just a projectile weapon that drops from an enemy. It is actually a fairly common drop, I get it right at the start of level 3 (you can tell when the circle appears next to the sword at the bottom of the screen.)
@NitroGenesis: I would say ~85% of the run is the same inputs. Most of it is pretty straightforward stuff, not much point starting from scratch.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I'm also considering a redo on the first stage, but first I need to find out how to reproduce this glitch:
http://youtu.be/LDkal0qreEI
I believe I know why this glitch happens after doing some testing on my own. I haven't gotten that exact thing, but have gotten similar. (Same effect, but it goes away since I keep getting hit.)
It seems like what is happening is the enemy grabbing you falls just in range of a power attack after you knock him off of you (the pink one.) The game immediately adjusts the players position when you are about to execute it, but the enemy stands up on the same frame, so there is no way to complete the animation, leaving the player with hyper speed but no where to go.
It's rare because the enemy lands near you while you face the other way, uncommon and usually he will already stand up before reaching this position.
I've only gotten this glitch when knocking enemies off from the front, as in this video. This seems to be the key, as it for some reason knocks them behind you.
I believe something similar happens when picking up the motorcycle while facing the wrong way. You get warped to the right position (you can even see it happen to yellow player in the demo.) Of course the motorcycle doesn't change its state like the enemy does.
I don't think it is of much use.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
well I am making slow progress on various fronts.
Since Dooty's inputs resync in the piano roll style input format, we'll probably just be continuing on to level 2.
@Dooty do you know anything about RNG in this game?
My next thought is to try and check if levels can be worked on independently and resynced into a complete run later. So far my testing ran into desync do to lag, causing inputs to be missed (I think do to 1 frame inputs) So I would need to figure out how to make inputs robust to lag before continuing down that road.
But there is big gains in simplifying the whole process if it works out, so I'll be putting effort into testing it.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Given the comments by MESHUGGAH, abyrvalg, and Aqfaq on the previous page, there is clearly a lot of room for development here.
And regardless of what the Doom community might have settled upon, the very first line of TASvideos introduction is:
Here at TASVideos, we strive to push games to their limits.
And in this case the limits seem to lie beyond what is currently established.
However I am aware that the biggest hurdle here is simply a lack of interest, and no one can be forced to take interest in something. This is after all merely a hobby. So this thread may have been DOOMed (sorry) from the outset, until someone actually creates something new to make use of all these arguments.
How is it useless? Do you think it is not very optimized? It has 27000 rerecords and looks pretty good to me.
I managed to extract your inputs from the movie into a .csv file, so I'll see what I can do with it looking at different parts of the level, but I try not to reinvent the wheel.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Given this:
Truncated wrote:
The justification was that it is possible with an external driver, which Doom natively supports, so this is what a God player would use. That's what made me say that it was OK.
and this:
Another way would be to say, "well, we'll allow the exact input supported by the default Wingman Warrior driver", which would result in GF100/SR100 with full control: GF50/SR50 via keyboard / mouse, plus GF50/SR50 from the Wingman Warrior, plus turning control from the Wingman Warrior. (Has anyone ever done this IRL? I feel like SOMEONE must have noticed that you could haul ass with one hand on the joystick and the other hand on the keyboard.)
I would say it should be acceptable to use such inputs as drivers such as the wingman warrior can generate.
Even if the warning "... is turbo" pops up, it is still not cheating, since its just exploiting poor programming, which TASes do all the time.
Perhaps DOOM TASes are best split into 2 categories, 1 where -control is not allowed, and one where it is. The first category would be keyboard and mouse only, so they would be directly comparable to real time runs (which at least real time runners would maybe find interesting.)
The second category allowing -control would be open at least to any drivers demonstrated to exist (I don't see why writing your own wouldn't be allowed, but it would have to be demonstrated.) This category would necessarily include the existing TASes, as strafe50 + turns is not available without it.
