Posts for Scumtron


Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
TheAxeMan wrote:
I knew about this. I at least remember seeing it done in the pacifist run at one of the GDQs. Yeah, it's way too slow for a TAS. Even in a pacifist run it's a lot faster to play through normally. By the way I keep thinking about taking another pass at the pacifist run. Maybe I'll get to it soon.
Yep, figured the odds were pretty good that you already knew about this. Admittedly, I haven't paid much attention to this game since submitting my version back in 2007. Even being able to fast wall-jump up the wall wouldn't make up for the time lost, and you're stuck holding up since wall-jumps eject Ryu from the wall. I hope you find the time for another go at pacifist; it would be nice to see the no game-over version!
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
Hanging around twitch today, faminesys brought this to my attention: Link to video I did confirm that scrolling the screen up slightly is required (to load some extra squishy floor), but didn't bother with any speed comparison. PHONY EDIT: I did a rough comparison and it was 455 frames slower; all that sinking takes forever.
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
Derakon wrote:
Huh. I don't remember the slash-cancel technique. That kind of renders the jumpslash ninpo kind of irrelevant for fast boss kills!
It's a major part of RTAs for the final two bosses (along with a very awkward way of holding the controller), but it still can't match the 1 damage/frame of the spin slash—frame-perfect or not. There's also the fact that of the four bosses killed with spin slash, three are just dudes standing around where normal slashes aren't in range for most of the jump arc. Also, unlike its sequels, this game does take 3 frames to tally every point of ninpo left over after boss kills into the score.
Aloysha wrote:
Any thoughts of working on the sequel as well?
I'd like to put together a new TAS that includes xipo's improvements. Earlier this year I did some research into some of the glitches with that aim in mind so something new could be shown off too.
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
Here's some half-assed debugging. Frame references from this submission file. At 33015 it takes p2 input and stores it at $0367. Only B was pressed in this example:
07:F8E8:A5 10     LDA $0010 = #$40
07:F8EA:99 67 03  STA $0367,Y @ $0367 = #$40
Then at 33024 we get this:
07:E540:BC AB 04  LDY $04AB,X @ $04B0 = #$00
07:E543:B9 67 03  LDA $0367,Y @ $0367 = #$40
07:E546:A8        TAY
07:E547:D0 1D     BNE $E566
Meaning it will only branch to $E566 if there was p2 input at frame 33015. That eventually leads to here:
06:A768:BD 63 04  LDA $0463,X @ $0468 = #$40
06:A76B:29 C0     AND #$C0
06:A76D:9D 63 04  STA $0463,X @ $0468 = #$40
Depending on what p2 input was at 33015, that will result in storing either #$40 or #$C0 in $0468. #$C0 = drac stays, #$40 = drac goes. And I stopped looking at that point. Obviously, that's not a complete picture. but hopefully it's something to go on. Maybe a conditional (say, if $10 = specific p2 input) breakpoint on 07:F8E8 would turn up something else in another part of the game. Edit: I set p2 input to hold BTULR and set an execute breakpoint on $F8E8 with the condition K==#07 && $10==#5B and came up with this list of frames where p2 input might do stuff. Most of them seem to cause desyncs, but I didn't bother looking into why.
6
281
328
4260
4996
5043
7557
13162
13896
13943
16198
17093
21061
21108
22582
27591
27638
29890
29936
31806
31852
32969
33015
Surely more possibilities past that point too, but I'll leave the rest to somebody else. I'm leaning slightly less towards 'debug feature' now.
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
MESHUGGAH wrote:
This sounds so underrated! I think it's a great achievement you did with "fewer" technology than we have now (mostly referring to TAS Editor and feos' sexy lua script). It's suprising that we still find a way to save a few frames and the way it impacts other screens.
Well, my point (if I had one at all) was mainly the uselessly obvious fact that the more optimized a run gets, the greater the proportion of its duration that can't optimized at all will be. Also, though all of Ninja Gaiden's little quirks and how they interact make for a fun optimization puzzle, it's still a pretty dang simple game. side note: I'm still too stubborn to switch to using TAS Editor. :o
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
MESHUGGAH: Yeah, don't get hung up on that specific instance or anything (or this glitch in general). I just wanted to post some vague info along with an example last night and pretty much any input from NG(U) will desync when played back with NR(J) — usually in 3-1, 3-2 or 5-1. I don't think I've ever seen it happen outside of 5-1 in NG(U). Obviously there was some bugfixing that came along with the localization. Until noticing it messed with the stack yesterday I'd just considered it as a thing to be avoided since the only apparent effect was losing a frame. Anyway, I don't expect much to come of it, and I'd rather get back to adding more damage boosts to 5-1, but due diligence should probably be done to see what exactly is happening. moozooh: Indeed, the published run was done with little more than memory watch and some (mostly) naive assumptions based on that, but when you consider that the game is still primarily around eleven minutes of scrolling the screen at a constant rate and waiting for the next part to load, then it's not surprising how little room for improvement there is.
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
moozooh: MESHUGGAH is continuing work on a pacifist run, not an improvement to the published run. Personally, I wasn't sold on a pacifist run being submission-worthy until feos made some test runs and made clear that, done right, it would take full application of every little thing known about the game—including some stuff that just isn't relevant when you can kill everything. As for any%, thanks to a couple recent finds from MESHUGGAH and feos, I've resumed my sporadic efforts of improving it and it's currently 65 frames faster (should be a few more by later today). MESHUGGAH: Does this mean it's finally time to leave act 5 behind and head into a whole new bunch of headaches in act 6? —— EDIT: Stack corruption? In my Ninja Gaiden? Key elements: Ryu's sword animation, the loading interrupts every 16 pixels of scrolling, $01FC, and then something fishy with enemy projectiles until the end of the current level. Too tired for proper poking right now, but if anyone is curious you can load this userfile with Ninja Ryukenden (J) and look around frames 12353-12354 (stage 3-2).
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
RainbowSprinklez wrote:
also, my original code is acting funky. it seems that it glitches up the overworld. is there any way to have it active ONLY when a lvl is entered?
Calling your code with memory.registerwrite() on 0x7E0046 (a frame counter only active in playable stages, according to this) should probably work.
Language: lua

memory.registerwrite(0x7E0046, function() --[your stuff here] end) while true do emu.framveadvance() end
edit: Or whatever else works! Also, you can edit previous posts instead of multi-posting.
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
Good points, all. And my reasoning with including the iterator was that it would affect the initial tosser position, which is technically beyond the scope of the problem as originally stated, I suppose.
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
feos wrote:
It was very long ago, before I started reversing that function. I also tried to predict it, but gave up after seeing that it would need to include interrupts that you don't know how many will happen and when.
Ah, interrupts: yet another variable that I hadn't even considered. Then you have xsub for the tosser (can probably be ignored) x and y subs for the projectile, iterator for the longer areas, and then the biggest variable: Ryu's path. For example, the first tosser in 5-1 could potentially throw something useful on either side of the pillar it's standing on. Anything else I haven't considered?
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
feos: I noticed you had some shifting and anding of $BF commented out in your script, as if you had something predictive for the tossers in mind. Did you write anything beyond that that you haven't shared? I've been thinking about documenting ideal ranges for $BF for each tosser in the game—or at least each one that can potentially make for a useful boost—for some time, but never got around to doing anything more than thinking about it.
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
MESHUGGAH wrote:
Projectiles that would be nice to manipulate
    2-2 first screen bullet slot 4 - to avoid interrupt or get a half pixel to left 3-1 sprite limit route which depends on last bullet (edit: probably slot 7) shot after a slot gets free 3-2 bullet slot 5 - to avoid interrupt or get at least 1.5 pixel to right (spawn delay misery)
Sprite limit route is letting spawn the bullet guy and respawning a bird between the two guy on the platforms near the end, so Ryu would follow only 2 bullets (closer than he would follow 3 bullets) but in the end the bullet hits him so it becomes much slower. edit: regarding the demon's head, I vote for the pacifist spirit.
Looks pretty unlikely that $75=4 can do anything useful before level 5 at the earliest. Though it would almost certainly put the slot 4 bullet in 2-2A a bit to the right, getting hit in 1-2 still screws up slot 7, contrary to my speculation yesterday in IRC. As for anything in 3-1 or 3-2, it's moot since it doesn't appear possible to get hit and kill the 2-3 boss on the same frame, but I didn't test any method that lost time in the fight. Not having $75=4 for level 3 means no known way to avoid the hit in 3-3 and have $75=0 for level 4.
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
The final boss: it has the head part that you have to kill so the 'core' will drop and be killed quickly as possible or you can leave it alone and messily damage-boost onto the thing and kill it from there.
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
Here's a little function that would have helped find the ''useless'' interrupts earlier:
Language: lua

cnt=0 function JugFinder() Interrupt = AND(memory.readbyte(0x4C),0x40) if (Interrupt > 0) then cnt=cnt+1 else cnt = 0 end if (cnt > 1) and (memory.readbyte(0x1FC) == 0x87) and (memory.readbyte(0x1F3) == 0xD8) then emu.pause() gui.text(1,226,cnt) end end
Maybe it will have some use in the future. Without diving in deep and likely just repeating things you've already tried, I'll have to agree that the early levels should be well optimized at this point. Though I still might spend some time looking for ways to use the $75 thing. Edit: Found the mess of a script I made a couple years ago to look for places where $75=4 might usefully affect stuff
Language: lua

NGtest = savestate.create() local function check75(RAM) if memory.readbyte(RAM) > 0x10 then --excludes normal enemy spawns from the check eX=RAM+0x60;eXf=RAM+0x58 --offset for enemy X position eY=RAM+0x80;eYf=RAM+0x78 --offset for enemy Y position ram=RAM;blah=1 end end while true do savestate.save(NGtest) emu.frameadvance() memory.register(0x400, 8, check75) if blah == 1 then eXa=memory.readbyte(eX)+(memory.readbyte(eXf)/256) eYa=memory.readbyte(eY)+(memory.readbyte(eYf)/256) savestate.load(NGtest) memory.writebyte(0x75, 4) --simulates the glitch emu.frameadvance() eXb=memory.readbyte(eX)+(memory.readbyte(eXf)/256) eYb=memory.readbyte(eY)+(memory.readbyte(eYf)/256) if eXa ~= eXb or eYa ~= eYb then frame=emu.framecount();xdif=eXa-eXb;ydif=eYa-eYb print(string.format("%05d, %02X, %4.2f, %4.2f",frame,ram,xdif,ydif)) --when glitch has an effect, output frame count, column for enemy data, positional discrepancy end savestate.load(NGtest) emu.frameadvance() end blah=0 end
Running this over the current pacifist WIP input doesn't seem to point to any obvious places where $75 looks useful, but since I never bothered to find out why it affects some projectiles and not others, I don't really know if some subtle change could change that. MESHUGGAH: Can you think of any tossed/thrown/shot/spit objects where a 2 or 3 pixel change might matter? Another edit: It pains me to bring this up, but has anybody considered that to be strictly pacifist, the demon's head should not be killed?
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
Idunno, I only stuck my nose into this to try and help with the timer problem that was gumming up the works. I'll give it a look again after Meshuggah resynchs things back to 4-3 (or wherever).
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
Removing input on frames 6994, 6995 solves the 3-3 timer problem, woo. Seems that getting hit as the 2-3 boss dies (so $75=4) makes the hit on the 3-3 boss avoidable, and I have no idea why. I haven't looked into whether $75=0 could be in any way beneficial (or detrimental) for level 4 though.
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
MESHUGGAH wrote:
Would you mind to show a screenshot or movie file? I don't see where did you get a half-pixel forward, maybe at the very end?
In the no-input, mid-jump frames (7483-7492) press R twice before moving L at 7493 and then another frame of L at 7512. This results in reaching the 2-2B exit on frame 7536 instead of 7537.
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
Don't hate me, but taking the boost in 2-2B with Ryu half-a-pixel forward (left) is 1 frame faster. Plenty of space to adjust position in the jump there. Also thought the first bird-boost in 3-2 could be faster, but I guess it has to be that way so the soldier can be frozen/avoided later? Hard to just jump in and change stuff in a run like this without knowing when and where enemy subpixels, etc. are important!
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
MESHUGGAH wrote:
Scumtron wrote:
Sorry if I'm misreading your post, but I think you may be a bit off on the boss timer/3 frame thing. Two relevant variables:
    A: duration of boss fight in frames B: value of timer fractions when boss screen loads
So, if A mod 61 <= B then the game will tick off that extra second that would otherwise take three frames to be tallied into the score.
Well I was wrong in that you need subtimer 0 when pressing B and subtimer 60 on the frame the boss dies. Killing a boss like this will save 3 frames. As far as I know, parity (even/odd) doesn't matters. I could save 2 frames by adding 1 empty frame, which is the "last resort" solution. I still hope for saving 3 frames instead of 2.
Wait, so you're talking about something separate than what I'm talking about then?
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
Sorry if I'm misreading your post, but I think you may be a bit off on the boss timer/3 frame thing. Two relevant variables:
    A: duration of boss fight in frames B: value of timer fractions when boss screen loads
So, if A mod 61 <= B then the game will tick off that extra second that would otherwise take three frames to be tallied into the score.
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
Stumbled upon this by accident yesterday: the Stom skip. If you warp to Leaf after the game moves you into position for the fight, Tornel's victory dialogue pops up and you get the Teleport spell—and it's 105 frames faster, at least in the short term. I couldn't say how an additional warp boot use would affect a run as a whole. Also, warping out after Tornel's pre-fight speech but before the game finishes moving the player character gets some odd results which might be worth a look under the hood. Are there any other instances of scripted sequences moving the character while leaving you able to warp? Or any other spots where a warp might similarly confuse the game?
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
Regarding the 4-1 bat-boost: going off WIP74, it looks a jump on any frame from 16068 to 16072 avoids the bullet. That's one of the two things I consider major mistakes in the published run; the second is dropping down before obtaining the spin-slash in 5-2a, which isn't relevant for pacifist.
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
Is there any non-obvious reason for the 4-1 bat-boost across the gap? Jumping (to avoid hitting the shell) down to the small platform and climbing back up ought to be faster, pacifist or not.
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
feos wrote:
Scumtron, tell us more about "making enemies fall from platforms"! That particular case doesn't help, but overall it can be useful.
Not something I ever looked into too deeply since I couldn't envision any use for it in a standard run. Should be related to the kitties changing direction when they hit the corners just so, though. I know it's not as simple to manipulate as in NGII, where one well-placed frame of backwards movement can make it happen. In NG, it seems that sometimes you even have to back up enough to despawn a thing then resume forward movement so it'll be in the proper spot.
Experienced Forum User, Player, Published Author (150)
Joined: 5/1/2006
Posts: 150
MESHUGGAH: My bad, was posting from memory and had completely forgotten that bird needs to be killed in order to make that jump. Very cool to know why the cats sometimes turn around like that, something that would have probably never come up without this pacifist project.