Hopefully you don't have to encounter a case where the conversion isn't possible, that would be a shame, but I guess we can cross that bridge if we ever come to it.
At least with this series it's likely even in the trickiest cases that going back and changing some earlier input can affect bit deletion on a problem frame. And if speed were the only concern, then it's hard to imagine a truly unfixable situation.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Really pleased to see this project finally leave WIP limbo. And I appreciate the historical breakdown too.
plug: Any future NG1 TASers should also be aware of the bird manipulation tool. It could use a lot more work, and may be meaningless without working knowledge of NG1 TASing, and in hindsight it could probably have been done entirely in Lua, but it really works.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
The text has been updated to (hopefully) better match the final input and include a link to the bird utility.
Also, any future authors should take note of this non-improvement.
We both happily found the same solution in 5-1a.
In 5-1b you saved a frame by delaying the use of the Invincible Fire Wheel.
In 5-1c I saved a frame with a position adjustment and better boost from the spikes over the wall.
But, the 5-1c frame save only works on an 'odd' frame counter alignment, so adding your 5-1b improvement would negate it.
So, we can't have both. Which do we use? (I favor mine, since the extra killing is part of ending the game with an arbitrary score)
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
As observed in the above posts, emulating the DPCM glitch makes this series an extra hassle to TAS with NesHawk, but if for any reason somebody wanted to sync FCEUX input then the below script can help. Import .fm2, load TAStudio (remember to delete a frame before the first start press).
All it does is mark a "lag frame" in TAStudio when DMC interferes with input; desyncs can usually be dealt with by either adding extra button presses that don't change movement (e.g. add an L if holding R) one or more frames earlier or adjusting jumps or slashes by a frame or two.
Download NG_NEShawkFM2sync.lua
Language: lua
local dpcmBool, dpcmed, whichNG = false, 0, memory.readbyte(0, "PRG ROM")
if whichNG == 40 then dpcmed = 0xF9DC -- NG1U
elseif whichNG == 16 then dpcmed = 0xD602 -- NG2U
elseif whichNG == 53 then dpcmed = 0xC791 -- NG3U
end
if dpcmed ~= 0 then
event.onmemoryexecute(function() dpcmBool = true end, dpcmed)
end
while true do
emu.frameadvance()
if dpcmBool then
dpcmBool = false
tastudio.setlag(emu.framecount(), true)
end
end
Here's another dumb thing, though I did actually use it to play back WIPs in Mesen and NesHawk for some audio/visual aesthetic judgements (to questionable utility).
Purpose: play fm2 and save a hacked ROM that will do nothing but play back the input.
Download NG2_TAStoDemoROM_FCEUX.lua
Language: lua
local rb = memory.readbyte
local wb = rom.writebyte
local count, inps, cnts = 0, {}, {}
-- C674D019A200A009A9078D00808C018020C5FB85124514251285138414062DA5250906AA8E0080A51D8D0180E88E0080A51E8D0180062DB0E6
local nmihack = {198,116,208,25,162,0,160,9,169,7,141,0,128,140,1,128,32,197,251,133,18,69,20,37,18,133,19,132,20,
6,45,165,37,9,6,170,142,0,128,165,29,141,1,128,232,142,0,128,165,30,141,1,128,6,45,176,230}
-- A08576A9B08578E674A9042000C04C3FE2A1758574A177A8E675D002E676E677D002E67860
local inihack = {160,133,118,169,176,133,120,230,116,169,4,32,0,192,76,63,226,161,117,133,116,161,119,168,230,
117,208,2,230,118,230,119,208,2,230,120,96}
local add1, add2, add3, add4 = 0x12010-1, 0x13010-1, 0x1D5E6-1, 0x1FBC4-1
local function WriteROM()
emu.pause()
movie.stop()
memory.registerexec(0xD5FE, nil)
print(string.format("0x%X",#cnts))
if #cnts < 0x1000 then
for i = 1, 0x1000-#cnts do
cnts[#cnts+1] = 0xff
inps[#inps+1] = 0x00
end
end
for i = 1, #cnts do wb(add1+i, cnts[i]) end
for i = 1, #inps do wb(add2+i, inps[i]) end
for i = 1, #nmihack do wb(add3+i, nmihack[i]) end
for i = 1, #inihack do wb(add4+i, inihack[i]) end
print"Debug-> Hex Editor...-> File-> Save Rom As..."
end
local function DumpInput()
local inp, inpre, full = rb(0x12), rb(0x14)
local function conc()
cnts[#cnts+1] = count
inps[#inps+1] = inpre
if #cnts == 0x1000 then print"space full"; full = true end
count = 1
end
if inp == inpre then
if count == 255 then conc()
else count = count + 1 end
else conc() end
if emu.framecount() == movie.length()+1 or full then WriteROM() end
end
memory.registerexec(0xD5FE, DumpInput)
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Well, I hope J.Y & aiqiyou (or anybody) will try to reconcile any speed differences we have left. I made a brief effort to work their 5-1 inv. fireeheel change into mine, but it seems my 1 frame improvement in the next room (spike boost) gets wiped by the even/odd rule. Maybe I'm wrong.
I've only done a frame comparison on segments between screen transitions, so there could still be speed diffs beside 5-1b and 7-4.
If it turns out that no other speed improvements can be worked in, and if J.Y and aiqiyou don't object, I could just fix the 7-4 fight in my file and call it done. (and do a long-procrastinated write-up)
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Nice catch waiting to use IFW until after jumping at the pit in 5-1; I wasted a lot of time trying to work out some elaborate bird boost there instead. And, of course, nice job on all the other speed improvements too.
However, very little attention seems have been paid to style.
User movie #75206084705959364
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Meshuggah: I tried to explain that bug a bit better in this post, though I'm not sure I succeeded. Like that second paragraph? I'm describing the NMI routine. Why don't I just say that? Anyway, I don't think there's any way it could screw things up this badly, but I don't really know.
What I do know now though, is that temporarily replacing banks 0-3 with bank 7 (just have everything back to normal once the next stage loads!) reproduces Aquas's clip almost exactly. I have no clue how that could happen, but I'd put my money on the PowerPak being the culprit.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Aquas also uploaded a clip to YouTube. Things seem to start to go wrong during the level fade-out, a few frames before the 0:24 mark in the video. (use "," and ".")
Link to video
As far as I know, there's no technical reason the game has such long fade-outs: IIRC, nothing related to loading the next area happens until after it's fully faded to black. So, if there's nothing particularly special happening at that point, what might cause it to fail like that?
So after a glitchy-looking fade-out and some soft white noise we're on to loading 6-3.
The nuts and bolts of the program still appear to be working as they should, they're just being fed the wrong data. Wrong graphics (duh), wrong music, wrong HUD info (only two parts are readable and have changed: stage and timer), wrong initial position for Ryu, wrong background collision data (we see Ryu briefly grab a wall before jumping over to an "0xF block" to trigger the end of the stage), and presumably wrong everything else that we can't directly observe from the video. Loading all these things relies on using $6D (directly or indirectly) as an index, and since it progresses to 6-4 after garbage 6-3, we can assume that the value stored at $6D isn't to blame.
I was eager to write this off as simply another case of mysterious, un-reproducable flash cart malfunction, but with Sinister's claim of another reported (at least superficially similar) instance, I don't know.
sinister1: Who reported the other instance? Do you know if it was on an original cartridge?
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
So, well-timed pausing/un-pausing during the transition from the end-level elevator screen to the elevator/score-tally screen can keep the game in the proper state to increment the room variable more than it's supposed to. That much was mostly obvious, I guess.
I wasn't able to get it to skip more than 5 rooms (same as shown in WhiteHat's youtube clip linked above) in either FCEUX and BizHawk 1.13.0. Frame-by-frame inputs, per-poll inputs with Lua*, and just trying to mash Start with a controller at any emulation speed all saw the same results.
Freezing address $62A when it's 0x40 during the screen transition does keep it skipping along all the way to the ending spaceship screen ($16 = 0x4D), so hopefully there is way to do the same with pausing.
In lieu of trying to articulate my half-assed debugging, I'll just paste this here:
$0005#TransitionRelevant#b0 set during NMI after room loaded, reset after room++
$0016#Room#
$00BD#someFlag#branch out of polling-purgatory if non-zero
$00FB#Input#
$04BC#FrameCounter#
$0523#Difficulty#
$05FB#Music_setting#
$06AB#ElevatorThingy#No more skips if >= 0x41
$072A#StartPressed#
$072B#Paused#
$0734#AlsoInput#
*this dumb game is constantly polling input, sometimes as much as 70 times per frame, and It seemed like being able to have distinct start presses on adjacent frames would be helpful at one point.
--------------------------------------------------------------------------------------------------------------------------------------------
Edit: Got more skips, but only with poll-based input. Could not reproduce with frame-based input.
Just when I was convinced that a pause and an un-pause had to have an NMI routine between them for a skip to happen, putting a pair on the same frame (3397 here) worked out—and with fewer total start presses too.
This script works with #4971: Randil, Alyosha's FDS Cybernoid: The Fighting Machine in 04:35.78
Language: Lua
poll=0;i=1;frame=emu.framecount()
pauses={ 3390,1
,3396,2
,3397,1
,3397,3
,3406,1
,3418,1
,3435,1
,3444,1
,3451,1
,3452,1
}
function pollAdvance()
poll=poll+1
if (frame ~= emu.framecount()) then poll=1 end
frame=emu.framecount()
if (frame == pauses[i]) and (poll == pauses[i+1]) then
memory.writebyte(0xFB,0x10)
i=i+2
if (i >= #pauses) then i=1 end
end
--print(poll,frame)
end
memory.registerexec(0x830C,1,pollAdvance)
--------------------------------------------------------------------------------------------------------------------------------------------
Another Edit: Floatious told me that simply pressing start every 7 frames got it to skip pretty far, so I started with that, adjusted for when it failed, and got it to skip to the end of the game. This is probably still fairly sub-optimal.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Try to avoid staying down too long in the midnight sea, know what I mean?
----
If you feel like it, record an fm2 of it happening and maybe somebody will decide to look into it. This game's code is like totally grody though.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Here's a TAS that abuses this game's wacky warps and skips most of the content.
When you activate the warp ability ($06:BCEA) the game will call the PRNG function ($07:F39E), AND the value returned with 0x3F, then compare it to a value associated with your current location ($135). If the ANDed value is less than $135, then it sends you there; if not, it tries up to 7 more times before just sending you to the beginning of the level.
I'm not sure what purpose a costly special ability that seemingly was only intended to send you backwards in a level was supposed to serve, but it's abusable for a couple of reasons: not all levels segments are numbered linearly and in some cases holding left can affect where the warp ultimately sends you. I didn't really debug why/how left can have this effect, but it looks like a chain of events stemming from Luke's X velocity being negative when the scene change occurs.
Notes on the linked input file:
WhiteHat worked out most of the potentially useful warp shortcuts, I just applied them to a not-very-good TAS.
Tatooine: Goal here was to get most of the energy needed for 3 warps since the second level is pretty sparsely populated before the point I intended to warp from. Various approaches were tried (see other branches of .fm3) before settling on two goes at the blocks in the second room of the sand crawler and warping to the end of the level. There's also a buggy warp possible on this level (warp target 0xF) but I couldn't find anything useful involving it.
Kessell: Here's the first use of holding left to mess with the warp and having it send Luke "out of bounds" to 0xFF. From there he can go anywhere he pleases, like directly to the end of the level. I considered warping to a screen or two before the end to some nicely clustered enemies for more energy, but the extra Lukes from the buggy warp caused too much lag for that to seem worthwhile. The 0xFF warp on this level and on the Death Star level can have a lot of weird effects, but I'm just not that into this game to spend the time working out how that might be manipulated.
Iscalon: Pretty straight-forward level with one bonus room numbered higher than the rest. Shooty-saber and/or Speed-up should probably have been used here.
Death Star: Here we find the only useful NPC for this route. Leia can double your force energy once a level (to a max of 99, and only when indoors, apparently). It's also convenient that right outside the room you find here in is the best known place to warp to 0xFF in this level. Got lucky here with the instant Vader-death warp that ends the level. Wasn't able to make that work after manipulating RNG before the level so I just settled on waiting a number of frames and getting on with things.
Death Star layout:
56 57
03 04 09 0D 0E 0F 13 20
d 08 14
->00 01 02 07 10 11 12 15 21
06 16
58 59 05 0A 0B 0C 17 22
37 18
38 39 3A 36 3B 3C 3D 19 27 28 29 2A 2B 2C
3F 40 35 41 42 43 1A d d d d d
44 45 34 46 47 48 1B 23 24 25 26 2F -|
49 4A 33 4B 4C 4D 1C 2D 2E<-------------|
4E 4F 32 50 51 52 1D
31 53 54 3E 1E 30
55 1F
->: Start
d: doors
26: Rescue Leia
2F: Compactor fight (call R2-D2 to escape to 2E)
38: Vader fight
58: Millenium Falcon scene(after beating Vader)
not depicted: death barriers between 36/37 and at ends of vertical shafts
*numbers are hexadecimal
Hoth: Pretty simple. Get to the base. Use Leia. Warp to exit for those sweet Chewie smooches.
Yavin: Could probably fit another usage of the Speed-boost ability in here, but it doesn't play well with collecting stuff. The OoB/0xFF warp here doesn't seem to have any weird effects, just another warp to the finish. The shooty-saber ability being active skips the Leia dialogue too! Didn't figure out why, and couldn't get any combination of active abilities to have the same effect for any other dialogue in the game.
Space shooter levels: Frames between TIE fighter spawns are randomized. Time shots and scroll stars off-screen/keep them on screen to manipulate RNG. Low byte of Luke's Y position at the end of a level can also indirectly affect how much the hyperdrive animations advance the random number sequence. Convenient opportunity for free manipulation after meeting the kill quota by destroying/creating more stars.
I think with better planning of energy gathering and special ability use, and proper manipulation of the 0oB/0xFF warp effects this could make a decent TAS.
Some RAM info:
PRNG routine (The game also temporarily stores the initial value of $16 to the stack while it zeroes the rest of RAM then puts it back.):
07:F39E: A5 15 LDA $15
07:F3A0: 0A ASL
07:F3A1: 45 14 EOR $14
07:F3A3: 49 80 EOR #$80
07:F3A5: 0A ASL
07:F3A6: 26 14 ROL $14
07:F3A8: 26 15 ROL $15
07:F3AA: A5 16 LDA $16
07:F3AC: 0A ASL
07:F3AD: 0A ASL
07:F3AE: 38 SEC
07:F3AF: 65 16 ADC $16
07:F3B1: 85 16 STA $16
07:F3B3: 45 14 EOR $14
07:F3B5: 45 15 EOR $15
07:F3B7: 60 RTS
Addresses of all JSR $F39E instructions with descriptions of varying vagueness:
0xF0A8 Every frame
0xBCF4 Use warp ability
0xA30B Title/End screen stars
0xA31E Title/End screen stars
0xD09E Leia hologram fade-in
0xD0FA Leia hologram fade-out
0xD639 Tusken Raider spawn (hop counter)
0xD363 Stormtrooper spawn
0xD389 Stormtrooper shot
0xD1D9 Stars?
0xD1DD Stars?
0xD209 Hyperspace
0xD215 Hyperspace
0x8AAE new star a
0x8AB7 new star b
0x8AC3 new star c
0x822B TIE, frames until spawn
0x823D TIE spawn
0x82F8 TIE spawn
0x8268 TIE spawn something or other
0x8469 TIE movement change
0x8980 TIE shots
0xAFA9 Planet approach scenes(~300 per frame for 3 franes each level)
0xD867 Vader attack timer
0x9803 Yavin Vader
0x9DFB Green dudes (only found behind Death Star doors?)
0x9D07 ST spawns at end of compactor corridor
0x92B3 Trash monster, x2 on enter
0x92D9 Trash monster
0xEE57 Wampa!
0x9522 Trench start
0x99C6 Trench lasers
0x9983 Trench lasers
0x955D Trench spawns
0xB42B X-Wing/MF/DS victory scene
0xA899 Intro Star Destroyer scene
0xA8A9 Intro Star Destroyer scene
0xA8BC Intro Star Destroyer scene
0xA8CC Intro Star Destroyer scene
0xA871 Intro Star Destroyer scene
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
From observing RAM, the game not deducting Ninpo after exceeding 999 and the game not deducting Ninpo if the hidden cheat menu option is enabled (tcrf.net link) do appear to function differently.
Cheat menu sets 0x1FC3 to 0xFF.
The three digits for Ninpo are at 0x1FB8-0x1FBA and exceeding 999 sets 0x1FBB to 0xFF.
Additionally, 0x1FC3=0xFF doesn't prevent Ninpo from being added to the count while 0x1FBB=0xFF does.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Zakem66 wrote:
I don't think there is need to do more research/testing? (even while not knowing how the glitch actually triggers..)
That's up to you. :) I'll go ahead and check out the ship battle now that we know how to trigger it, but I agree that a fuller explanation doesn't seem likely to change much.
edit: like you said, killing the bubble on the frame before it moves off screen is all it takes. It'd be nice to have a better explanation, but I don't feel like it's worth the effort here.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
I tried and failed to reproduce the trick with ship/final boss. Hard to say which object's properties would trigger it there since, unlike the 1st boss, there are about 4 or 5 of them. And yeah, I actually looked at the other bosses after posting and realized that since they're mostly stationary they wouldn't be likely to make it work.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Looks like the trick to the first boss is getting the killing blow while it is moving downward ($4FA == 0xB2) and its y velocity(?) is 243 ($4F5 == 0xF3). Since this game seems to copy everything to temp addresses to do anything with them, those values end up propagating elsewhere and just happen to speed up the transition to the next stage, I guess. The thing with the ship and the final boss probably happens for the same reason, so an input file of that happening might give some clues to getting it on other bosses.
What appears to be happening here is the sword hit sound starting on the same frame as the shift in the music track causes the sound handling routines to take enough extra time that the PPU is further along in its business than the game expects it to be. The exact same thing is often seen in 5-1 and was mentioned earlier in this thread. I was hoping that knowing the exact cause could lead to being able to trigger it multiple times and really break something, but that doesn't seem to work.
On a new frame the game first does some PPU-related junk, reads the controller, handles all the sound-related stuff and then waits for the PPU to get past the status bar and onto the gameplay area (scanline 54) and set the PPUSTATUS sprite overflow bit using this pair of loops:
So when the sound stuff takes a few hundred extra cycles the game gets stuck on those first two lines until the next frame comes along (hence the frame of glitchy graphics) and the main game loop takes over again.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
Warepire wrote:
Alyosha wrote:
Medium: Finding object tables: Usually enemy/sprite/player data used by a game is clumped into tables in RAM, if we could automatically get lists of object slots, hit boxes, attributes, and such that could save a lot of time.
Isn't the hitbox data usually packed in the ROM. Then values in RAM together with some look-up functions in the game code are used to determine the hitbox data for each entity in the game? I am not sure the extraction of hitbox data is a medium-level task in terms of complexity if you want it to work for a big set of games.
It depends on the game. I'll use two examples I know fairly well: Ninja Gaiden uses an "ID" associated with each object in RAM as an offset to look up hit-boxes, points, health, damage in PRG-ROM every time they are needed. Ninja Gaiden II just loads all that into RAM ($0460-$069F) when it spawns things.
I expect (but haven't looked at enough games to back this up) that the former approach was more common in earlier games.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
A couple things about the boss timer double-KO: Ryu dies, so it sends him back to whatever the designated re-spawn stage is for the current boss fight (6-1 for the final bosses, minus 1 otherwise), and the boss dies so the game also wants to go through the motions of doing the score tally then fading out and playing the cut scene. The game determines which scene to play by using the current stage ($6D in RAM, 1-1 = 0x00, final boss = 0x15) as an offset for this table at $AF9A:
If Ryu isn't in a boss room or stages 4-1, 5-3 , or 6-3 (those three stages have a scene triggered by Ryu touching a 0xC block) then it returns 0xFF, which is what results in the unpredictable crash/reset behavior. Since the results can vary with Ryu's actions/position before the fade-out, collecting extra ninpo before entering the boss room could extend the score tally and give more time to make something different happen. Probably wouldn't matter though.
----
Koh1fds wrote:
Wanna post this https://www.twitch.tv/videos/60452856
Seems like a power pack save / load issue, but when it glitches for the first time it blinks every frame with the same graphics as that "graphical glitch frame"
I was thinking that something like this can be done by killing boss at the same frame as "graphical glitch frame" happens, but seems like it can't be done. Seems like graphical glitch frame can happen only if you hit the boss at certain frame and boss have more than 1 hp. But it was looking so real for me
http://i.imgur.com/rGkvsz3.png
The Arcus clip is almost certainly just a PowerPak issue. Do you have any input file showing that graphical glitch when attacking a boss though? It might be interesting to see if it's the same as the sound-induced lag seen most often in 5-1 (and even more commonly in Ninja Ryukenden) or if it's anything like taking damage on the same frame as killing a boss.
Looks pretty explicit to me. Someone who knows the game better could look at the other RAM addresses that are checked (everything after an LDA) and see if they match the requirements for the "code." Also, poke $1ED to 1 and see if that alone enables the debug features, or whatever it is.
Edit: fixed a couple things I had inadvertently altered.
And I should've spared myself that minor hassle and read ruadath's post and found koitsu's much more useful analysis here: https://forums.nesdev.com/viewtopic.php?p=179769&sid=cc28826b29a5d02bd6cd87e575b2c408#p179769
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
feos: Thanks for bringing this up.
I noticed this after the 1.11.7 release, and it happens in all three NG games, though the tweaks since then have changed when it happens with a given input file. My intuition was that input that hadn't been made to account for this behavior would be pretty unlikely to sync on console, but lacked the hardware knowledge to really back that up.
Using the latest build (1.11.6.273) the published NGII run first runs into it at 10273 (or at least that's the first obvious de-sync), but pressing all buttons except B and select lets the input "get through." It happens again at 10892, where UDLRSs_A allows it continue to 11906. Button mashing won't help there since Ryu needs to move to the left.
As for NGIII: 997M @ 3541, 2507M @ 1934 & 1955.
Alyosha: Is the "button mash" effect something you'd expect to work as I described above? Short of hardware testing, what sort of additional information might be helpful?
True: looking forward to hearing about whatever you find.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
MUGG wrote:
What can I edit in memory to turn off the background music? (But keep SFX audible)
Hacking the ROM so it jumps over the music handling code would probably be best, but freezing two bytes at $7B5 and at $7B9 (make them 0) seems to work okay too.
Experienced Forum User, Published Author, Player
(151)
Joined: 5/1/2006
Posts: 150
You just love to make more work for yourself, don't you? ;)
A string of thoughts in no particular order:
A, B:
* more opportunity to show off and differentiate from 'any%' (well, I'm just repeating what you said here)
* If it doesn't affect speed, then I don't think it really matters (so that would a no to health)
* Health would only matter in Acts V & VI, right?
* But if you remove the special weapon limitation, not killing all the bosses exactly as in any% suddenly seems like a pretty arbitrary choice.
C:
* yeah, well, rules and stuff.
I don't know.
