Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
Dooty wrote:
That's some really good news, Alyosha!
Having someone else to help you out is something of great value, so good luck to you two.
I'd like to be of some assistance, but since I just played the first stage, I'm afraid I can't do much.
In any case, you said you found the right frame to insert the coin. I just like to point out that it's better to insert just one coin at the title screen.
You can insert the other two coins later, while the name of the stage is being displayed, without losing any time.
Again, good luck with your project!
yup, I got that far : )
...but not much further, it seems the game does some weird things with inputs, when I get one character doing what i want and try moving on to the other two, I noticed occasionally that the first character can drop an input somehow. So I've had to take itvery slow and haven't had a lot of time to work on it either.
Being able to edit input in a .csv is the only thing that is saving me. How did you ever do this with a game controller D:
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
^ That was well known to be possible, I think the question that everyone is trying to answer is what to do with the extra elements that the data structure allows. The poster in the doom forum even made a very similar comment when asked about the situation:
I can't think of anything - the game uses the ticcmd_t structure to define the input data for each tic, and the external control API lets you pass arbitrary data to the ticcmd_t structure, which logically includes any and all "legal" configurations.
I do understand the dilemma this presents. The external control API was a real, purposely built part of the original game, with at least one actual driver released for it. It seems somewhat ridiculous to disallow it as a control scheme for demo recording - what, Wingman Warriors are banned? But at the same time, it has zero sanity checking on the data passed to the game that way, and lets you ludicrously do GF127/SR127, which is, oh, a mere 359% of normal running speed.
You couldn't even say "well, allow anything that doesn't result in a %s is turbo message", because the game only checks the forward component for that, so you would end up with demos with GF50/SR127, which would be just awful.
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.)
which indeed seems to be the same thing that remains to be sorted out here. (Well, the issue besides the demo file format itself, which at any rate seems not likely to be resolved easily.)
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
Alright already under 30 now!
Although I think I made the mistake of doing all the easy ones first, so now when I get stuck its hard to tell what to do next. I tried kabuki quantum fighter, and while some frames can be saved here or there it throws things off in other levels, so I have yet to save any frames overall.
Combatribes will probably take a while, so there probably won't be much more movement here until some of the others finish their runs.
As a side note, the other end of the longest non-obsoleted runs list is becoming pretty interesting too. A couple of stars (ninja gaiden 2 and super C), and some other interesting games like Star Fox and metroid fusion appear now. I wonder what can be done with star fox now with the newer emulators.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
Finally starting this run (after becoming frustrated on Kabuki Quantum Fighter)
DiscoRico and I are teaming up!
So far I got a basic input file editor Lua script working for final burn alpha, and with it found the first frame on which you can insert a coin (53) so that is a good start!
I do not expect progress on this to be rapid, but slow and steady should create a good run.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
Truncated wrote:
I also know that turning during strafe50 is not possible with mouse and keyboard. It mostly seems to be a limitation of the original control scheme, because
1) strafe50 is allowed and
2) turning while strafing is allowed.
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.
You could of course argue that the limitation was done intentionally, and turning during strafe50 should be banned. Or that allowing movement larger than 50 backwards and sideways by using a driver was intentional. I don't think so, so that's not how I judged, but I admit we don't know.
The support comes from command line instruction '-control', which as far as I understand it provides an input structure that the driver writes to and then is passed to the game.
The reason this allows strafe50+turns is that the game code won't call the routine that initiates the turn while in the strafe50 state. But the structure can be filled with the a turn value independently and sent to the game anyway, which fails to perform the same check on it. (I hope that is right)
So allowing strafe50+turns is allowing the call of the '-control' instruction, which does seem to mean that all available states would have to be allowed (going backward faster than 50 etc) otherwise it would be a case of saying "you can use '-control' but only to do strafe50+turns" which seems a bit arbitrary. However no runs do that so this is still hypothetical.
I guess my question here is when are command lines instructions such as that valid? Had the instruction simply been '-strafe50+turns' would that be allowed? Or since the game ordinarily doesn't support it would it be considered a cheat? A more obvious example would be '-run at speed 100' or some such thing.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
This is a fascinating technical dilemma, I'll be very interested to see where the line is drawn.
Samsara wrote:
I'm genuinely curious as to what MESHUGGAH had to say, though. Maybe we can call it the "MESHUGGAH Meltdown", in the spirit of whatever the fuck that quoted post was meant to be. Why was none of this brought up sooner in any of the other submissions?
It was, but MESHUGGAH seems to have put some effort into dissecting the game, and raises some real concerns.
As I understand it, the problem is that the replay format bypasses the game engine processes in recreating the movie.
Playing the game: Input->Game Engine->movement
While the replay uses the movements the file contains directly, even though they are not derived from original inputs.
This is complicated by the '-control' command line instruction, which seems to allow for non-standard input, which can none the less be considered 'officially' allowed due to the existence of such a command in the first place.
MESHUGGAH's point (I think) is that the fact that the replay movies sync in the original DOOM does not mean that actual inputs could have produced that list of movements, i.e. playing the replay file is different then playing the game. But, this is what Truncated partly justified the original acceptance of the movie on.
It's an interesting dilemma, but I wonder if it's interesting enough to change the precedent set by the now 3 publications?
