Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Thought I should mention that the sword-guy at the end of 3-2 can be jumped over from the high platform with the right values for $B5 and Ryu's position. For various reasons it isn't useful for any%, but pacifist should give ample opportunity for the needed manipulation, though I can't say if it would save time without testing.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Don't forget you can use the interrupts to manipulate stuff without losing time during some wall jumps and when jumping from the first platform at the start of 4-3d and 6-2e.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Looks like you've got $B4 in there, but no $B5. B5 cycles through some values at preset increments for each stage, and is compared to B4 to determine if an enemy spawns, which I think can be up to three or so frames difference in stages with a lot of objects. This is also why, for example, saving or losing a frame before a stage (only $BF affected) or during a stage ($B5 and $BF affected) get different results.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
MESHUGGAH wrote:
edit: it looks like that saving a half pixel loses a frame on boss 1, I've tried my movie and Scumtron's "any%" movie, same result.
Unlike all the other bosses, boss1 inherits subpixel pos and being that half-pixel ahead throws the manipulation off (one of the boxers at the end of 1-1). Every time I looked at saving that half-pixel, I decided against it because it doesn't save any time and I think it looks worse.
MESHUGGAH wrote:
And my movie is also improvable with using the "preserve speed while airborne", but I don't understand which half pixels are good.
Not sure I get your meaning, but most of the time it just doesn't matter, unfortunately.
MESHUGGAH wrote:
Well it looked like they only depend on Ryu's X position. Maybe they have timers too (when to punch)?
IIRC, they do have a timer set when they spawn, but there's no randomness to it.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
feos wrote:
When working on knife thrower, I found out knife timeout decrements NOT every frame (sometimes it doesn't). Will debug tomorrow.
EDIT: When new level block set is loaded into video RAM, object attributes such as timers don't count. Object positioning is still counted in a temp loop. So, since you move at constant speed, you can't manipulate these knife timers by skipping their routines deliberately. Which is sad, will need to get around tossers the hard way...
Sorry you had to figure that out yourself, I could have sworn I'd put something about that in this thread already or on the game resources page, but hey, debugging is fun. There are a few opportunities to manipulate $B5 with that too, but I never found one that saved any time. This run takes advantage of it to manipulate the level timer in 4-2 and to freeze some running dudes while climbing a wall in 5-3C.
Awesome work with those scripts. Have either of them helped any with the pacifist thing?
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
feos wrote:
Scumtron wrote:
moozooh wrote:
I believe nowadays NG2 can be beaten even faster, though; ask Scumtron if unsure.
I actually haven't touched NG2 since my last submission for it, but Xipo recently mentioned that he's found an additional 18 frames of improvement since this submission.
And what do you think of unrejecting this run now?
It's faster than the published run, so that would make it a no-brainer for the vault, yeah? Though as Xipo says in the linked post, he has found additional speed improvements that aren't represented here, which to my understanding would disqualify it from Vault-hood.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Yeah, not sure why I have it and you don't, though I must vehemently deny any accusations of installing printer drivers or adobe software! ;p Anyway, I was prepared to figure out how to compile a version for myself if the font wasn't an issue for anybody else.
Lucida looks rather nice, though anything sans-serif just feels off. Hex editors, like, always have serifs! Does this even matter to anybody else?
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Oh, I should have specified that I'm using XP SP3 too, particularly since I use that 'classic' appearance... though I do have both 'Courier' and 'Courier New'. Anyway, it's probably clear why I preferred the 'old' look the same as it's quite clear that anyone would prefer the bottom over the top in your examples.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Ah cool, I hadn't yet looked into any taseditor.luastuff. Thanks.
AnS wrote:
Hm, good point. Although the new font is actually bigger (height=14 instead of 13), OK, is this better?
That does indeed remedy the 0/D confusion, though your use of "bigger" gave me pause, as I see an 'F' as 7x9 in the old example and 6x7 in the new (ignoring white space) on my 1600x1200 display.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
I was going to suggest an option to "un-greenzone" past a selected frame or a range of selected frames, but feos rightly pointed out that option already exists by simply changing input (and changing it back if needed). But it's possible that such a feature might have some other use that I haven't thought of, so I'm posting this anyway.
The reason I thought of this is I trying to figure out what value a RNG needed to be manipulated to by poking it with hex editor, and kept expecting it not to be restored when I clicked or held the '>' button, like with "normal" TASing.
Speaking of the hex editor, I'm not sure at what point it was changed, but I preferred the old display. 'D' and '0' can be hard to distinguish when I'm leaning back in my chair with the newer, smaller text, particularly when the character to the left of a 'D' is selected.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
I forgot to ask before, but have you tested whether getting the sword upgrade in stage 2 actually saves time? I expect not having it would make you slow down for the fireball in 2-2D at the very least, but I never did check if it saves more time on the boss than it takes to go out of the way to grab it.
Also this might be relevant if it works:
Xipo wrote:
Glitch 2
I can't reproduce it.In good time(Ryu is taken damage when entering BOSS's room),Ryu will not lost "long sword" and "忍" after BOSS fighting.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Hey Marx,
If you're going for a submission then you'd best figure out why you lost the three frames in 2-2D. Very important to watch Ryu's subpixel positions if you're going to improve on this, particularly in vertical scrolling areas.
Here is my memory watch file from when I made the TAS, which may or may not be of some help:
DB X_pos|[scroll]
83 Y_pos|[scroll]
| |
C4 Mans
CD Ninpo
5F Stage
55E X_speed
49C Enemy2
576 Y_sub
58E Y_pos
4FE X_sub
FD X_pos
59 |
| |
82 |
546 Wind|Speed
CE Max|Ninpo
| |
5D6 Y_speed
A8 Enemy1
AD Inv
59 Y_sub|[scroll]
DA X_sub|[scroll]
84 Screen_pos
Nice improvement on Xipo's example of the attack-wrap glitch in 5-3: 78 frames faster than the published run! Shame that it kills what was one of my favorite boss fights though. ;p
Does it work with special weapons too, or just the sword? If it does then maybe the windmill star could get in the first hit even earlier.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Hey you guys, this is the Ninja Gaiden thread, not the Scumtron thread!
Though I guess I didn't explicitly say so in the previous post about it, at the time I was assuming that the $75 glitch could prevent speed from being added to projectile positions at any time the projectiles are on screen, not just on the frame they're spawned. But it actually appears that it does only happen on the frame a projectile is spawned, except the effect is not limited to the projectile being spawned. Though it should be noted that the only instance I've yet found of an pre-existing projectile not having its speed added was when it would have otherwise gone off-screen at the same time another was spawned, resulting in the new projectile taking a different position in memory.
Anyway, what needs to be known if this glitch can applied somehow, is what determines why it only happens sometimes, and short of a detailed disasm I don't have any good ideas about how to go about investigating that... and as I'm typing this it's occurring to me that the number of objects on-screen has to be key... hm.
Side note: I did check if Ryu's projectiles might be similarly affected and they are not.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
I'm still holding out hope that this glitch will have some time-saving application, so I've spent some time trying to better understand it
Demonstration .fm2
Summary of what I think I know: Normally $75 is always 0. It's read from and written to once every frame of player control, and appears to be used simply to set the X register so a DEX will set the N flag (though if that's the intended behavior, why mess with $75 at all when a LDX #$00 could have done the same job?). But if Ryu takes damage at the same time as delivering the killing blow on a boss, then $75 gets set to 4. So, when that DEX mentioned earlier occurs and that N flag isn't set, the game branches into a loop to decrement the X register to the expected 0—a loop that would normally come much later in the frame. In this loop the value of $74 (which appears to be used as an offset for the different object positions in memory, 0-7) is also being decremented, which ends up meaning that speed values are sometimes not added to enemy projectile positions. It's a small difference, but as the linked movie shows, though with an undesirable result, it can be enough to matter.
What I'm missing is why this only occasionally happens. The number of objects on screen and the affected projectile's position (0-7) in the objects active at the time are probably factors, but I haven't picked up on a pattern there yet.
The other aspect I haven't really examined is the initial triggering of the glitch, when Ryu takes a hit on boss death (I'm pretty sure it can happen when other stuff takes damage instead of Ryu too), but here are trace logs feos posted when we were discussing this on IRC a while back: no damage, damage
trace logs comparing normal behavior with an occurrence of a bullet being affected (the 'snips' are for long , identical segments and I was using the begin/end to view the logs in np++ with Ruby syntax so differently branching segments could be collapsed): $75=0, $75=4
EDIT: Couple of things I overlooked. Defeating the Masked Devil/mind-control orb with the sword or jump-n-slash always results in $75=02 and after fast-forwarding through BoltR's and Slotermeyer's runs I noticed that they both finish the level 3 boss with the firewheel which gets $75=04 too, and it turns out that killing any boss with the throwing star, windmill star or firewheel has the same effect—or $75=05 instead of 02 in the case of the first of the final three bosses.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
MUGG wrote:
I need some lua help.
How can I make a lag counter based off my character's speed or position addresses?
So that I can count how many times my addresses haven't updated
Thanks in advance
Something simple to compare the values from the previous frame should be all you need. Here's an example of something I used once to check for when the screen-scrolling was interrupted:
Language: lua
while true do
scroll=memory.readbyte(0x00A3)
if scroll == oldscroll then
gui.text(120,100,"!!!!!!!!!!!!!!!!!","red")
bleh=bleh+1
gui.text(0,8,"" .. bleh)
end
emu.frameadvance()
oldscroll=scroll
end
Though something less simple might be needed, depending on how your game calculates positions.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Following up on this post I made a year ago, here's something from a conversation I recently had via PM on another forum:
MottZilla wrote:
The playfield as I recall uses a sliding window. As the camera moves this window is updated with physics information. This information is at $0300 in memory. It is $C0 in size. Blocks are 16x32. However they are actually 16x16, but the high/low nibble of each byte is related to the top or bottom half of the block. So represented should be a 512x192 area. Not unlike the NameTable/Background layer. The values (remember that each nibble is a block) for blocks are:
0 = Void
1 = Climb while facing left
2 = Climb while facing right
3 = Climb facing either direction
4 = Stand Ontop/Platform
5 = Solid Block when moving to the Right, Void when moving to the left. You can stand ontop of it and you can climb on it when facing right.
6 = Solid Block completely and Climbable from either side.
7 = Stand Ontop/Platform
8 = Solid Block
9 = Ladder Climb when facing right
A = Glitch
B = Glitch
C = Crash/Reset
D = Ladder Area Change (Forward)
E = Ladder Area Change (Backward)
F = Next Sub-Act, Fade Out and In.
For clarity's sake, I'll add that where he says 'climb', 'cling' might be more accurate since ladders (9) are the only thing that Ryu can climb with up/down in NG1. Also, 'C' proceeds to a cinema in the three stages that go directly to one when you exit (4-1, 5-3, 6-3), but elsewhere it will indeed crash the game.
So here's a script (pre-formatted hex-viewer) to display that stuff:
Language: lua
local function viewbg()
local addr = 0x0300
local x=0;y=8
for i = 1, 32 do
for i = 1, 6 do
hi = SHIFT(memory.readbyte(addr),4)
lo = AND(memory.readbyte(addr),0xf)
if hi == 0 then
gui.text(x,y," "); y=y+8
else
gui.text(x,y,string.format("%X",hi)); y=y+8; end
if lo == 0 then
gui.text(x,y," "); y=y+8
else
gui.text(x,y,string.format("%X",lo)); y=y+8; end
addr=addr+1
end
x=x+6;y=8
end
end
emu.frameadvance()
gui.register(viewbg)
With it you can see how annoyingly prevalent 8's are mid-platform in 2-2 (Ryu loses 1 frame of forward movement when landing on anything that isn't a 7), how an 8 or 0 right of a 9 lets Ryu grab a phantom wall section for 1 frame, or how in a few spots the game will load some an F or two tantalizingly just off-screen. Beyond that, I don't see much TAS-relevant use for this for now.
Pasky13: Bizhawk 1.0.5 doesn't seem to like your bitwise stuff: "lua:29: attempt to index global 'bit' (a nil value)." Guessing I'd need an interim build for that.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Pasky13 wrote:
I've also noticed that some enemies that have multiple box types, like the guys on stage one whose box will change when they have their weapon over their head, that area can't be hit with the sword. Not sure how the game determines you can hit them since only one box type is loaded at a time (the etype, which usually shifts between 3 values per enemy)
And it's not as if sword attacks act as if the hit box doesn't change either: they can't hit the vertical extension, but also don't connect with horizontal area that shrinks when the box changes, while the spin-slash and Ryu seem to obey both boxes. Huh.
Pasky13 wrote:
Oh I didn't take it as you requesting for me to do, I was just humbling replying I don't really have the time or interest to look at it. But ya, the boxes were a request from Sinister1 actually, who has been bugging me about it for a couple months haha.
As far as how I got the etype address, I got it by finding ryu's X,Y and a bosses X,Y and getting hit and setting a breakpoint when ryu got hit and tracing up until the breakpoint:
$E144:BC 38 04 LDY $0438,X @ $043F = #$1E A:00 X:07 Y:30 S:F7 P:NvUbdIzc ; Load Enemy type
$E147:A9 01 LDA #$01 A:00 X:07 Y:1E S:F7 P:nvUbdIzc
$E149:85 94 STA $0094 = #$01 A:01 X:07 Y:1E S:F7 P:nvUbdIzc
$E14B:38 SEC A:01 X:07 Y:1E S:F7 P:nvUbdIzc
$E14C:BD 60 04 LDA $0460,X @ $0467 = #$89 A:01 X:07 Y:1E S:F7 P:nvUbdIzC ; Load enemies X
$E14F:E5 86 SBC $0086 = #$80 A:89 X:07 Y:1E S:F7 P:NvUbdIzC ; Subtract Ryu's X
$E151:10 07 BPL $E15A A:09 X:07 Y:1E S:F7 P:nvUbdIzC ; Branch on Plus (taken)
$E15A:D9 00 B3 CMP $B300,Y @ $B31E = #$0A A:09 X:07 Y:1E S:F7 P:nvUbdIzC ; Enemy X Radius (B400 Y Radius base) (Y register = enemy offset) ($B300 is a bankswitched portion of the rom that is located at 3310 inside the games ROM)
$E15D:10 0C BPL $E16B A:09 X:07 Y:1E S:F7 P:NvUbdIzc
$E15F:38 SEC A:09 X:07 Y:1E S:F7 P:NvUbdIzc
$E160:A5 8A LDA $008A = #$A0 A:09 X:07 Y:1E S:F7 P:NvUbdIzC ; Load Ryu's Y
$E162:FD 80 04 SBC $0480,X @ $0487 = #$A0 A:A0 X:07 Y:1E S:F7 P:NvUbdIzC ; Subtract enemies Y
$E165:30 05 BMI $E16C A:00 X:07 Y:1E S:F7 P:nvUbdIZC ; Branch on Minus
$E167:C5 90 CMP $0090 = #$19 A:00 X:07 Y:1E S:F7 P:nvUbdIZC ; compare against Ryu's Y radius
Thanks for that, I get the gist of it at least. Guess I've still got some learnin' to do if I really want to see those walls and platforms visualized.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Pasky13:
Actually it appears that the spin-slash just always goes off the swing animation hit box for the level 1 boss, and probably works similarly for other enemies with variable boxes. Interesting.
You're probably right about the level 3 boss, or could it just be a bug? His effective hit box when jumping always seemed pretty much the size and shape of the crouching hit box that your script shows.
The only other issue I've noticed is with the mind control orb on the 6-4 boss: slashes well outside the script-displayed box do damage. That said, thank you for making this, it's been lovely to see so many things visualized like this.
About the background visualization script: I didn't mean to sound like I was asking you to make it for me. I know you only bothered with this because mikwuyma on SDA asked you. But if you could say a little about how you knew where to find those arrays in the ROM, or how you got to "etype = 0x0438" (I had those addresses tagged as something vague and TAS-irrelevant myself, and had assumed that 0x0400-0x0407 would be the important ones for something like this) I would greatly appreciate it.
feos:
I have indeed watched your WIP, though I haven't analyzed it too closely. Providing some input on it (and finishing the game resource page I started) have been nagging at me for a while now, but I just haven't made the time for it. Do you have a more recent WIP now?
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Pasky13 wrote:
Made this yesterday:
Ninja Gaiden hitbox viewer script:
Super Cool.
Is it possible that the enemy boxes shown with this script don't necessarily mesh up with areas that will take damage from Ryu's attacks? For example, The level 1 boss starts taking damage two frames before the displayed boxes connect, and (rough guess) the top third of the 3rd boss's box doesn't take damage at all.
About the lanterns: seems close enough to me. And like you said, who cares if it isn't perfect?
Could your experience making this script provide any insight into getting something like the image in this post to happen? I figured that some understanding of the ROM would be needed to get the detail I had in mind, but since I felt a bit out of my depth and didn't really expect it to reveal anything useful for making a faster TAS that I didn't already know, I never got back to it.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Yep, that happens when taking a hit from a vertical position of 4, 5, 14, 15, 16, 25, 26, 35, 36, 45, 46, 55, 56, 65, 66, 75, 84, 93, 102, or 111 or jumping from a wall with a vertical position of 73, 82, or 91.
It happens because there is no cap on falling speed and because the game only checks if Ryu is in the eight pixel death zone at the bottom of the screen, but doesn't care if he passes it, so falling from the right position will just make him wrap around to the top of the screen.
I'd love for this to be useful in a TAS, but there just isn't anywhere in the game where it would do anything but waste time. If anyone ever makes a stupidly difficult ninja gaiden hack, perhaps a gap too large to cross without taking a hit and screen-wrapping like this could work though.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Hey, cool stuff.
Looks like glitch 1 saves 15 frames in your example, but I still think the old way looks cooler! Oh well.
If I get your meaning right, glitch 2 could possibly save time in levels 2 and 7 since some time is lost getting the sword upgrade in those levels, but it sounds like it would cost time to set up too so who knows. Also, the sword upgrade could likely be skipped entirely in level 2 to save some time, but I never bothered to check that.
