Assuming that everything else is able to go the same up until that set of battles, it looks like roughly 29s/1724 frames could be saved. This doesn't take into account lag management or better optimization. I didn't do much more than a simple test for comparison, though, so I could be off on those estimates.
jlun2: can you list things that need manipulation?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
jlun2: can you list things that need manipulation?
1. The enemies at the 1st boss fight.
2. The first claw in the 3rd stage must drop down by itself (while having the same, or less amount of lag as the current run).
3. The same for the 2nd and 3rd claw encounter.
4. You must have full ammo before the 3rd miniboss.
5. Near the end of the 4th stage, you must shoot a missile behind you and use the ammo drop in the enemy infront of you to score an extra hit on the miniboss. Else you'll run out of ammo in the boss.
6. General lag reduction
7. General ammo manipulation
And that should be the main ones.
The answer is: I don't know.
I managed to save 3 frames through better positioning during the fall, but then I lag more at the circular torrent thing. This may take a while.
The answer is: I don't know.
I managed to save 3 frames through better positioning during the fall, but then I lag more at the circular torrent thing. This may take a while.
while true do
Stage = {
[5] = "STAGE 5",
[6] = "STAGE 5",
[7] = " FINAL ",
[16] = "STAGE 1",
[17] = "STAGE 2",
[18] = "STAGE 3",
[19] = "STAGE 4",
[20] = "STAGE 5",
[21] = "BOSS #1",
[22] = "BOSS #2",
[23] = "BOSS #3",
[24] = "BOSS #4",
[25] = "BOSS #5"
}
-- Don't display the following
Blacklist = {
[0] = "NO",
[1] = "NO",
[2] = "NO",
[3] = "NO",
[4] = "NO",
[5] = "NO",
[6] = "NO",
[13] = "NO",
[53] = "NO",
[55] = "NO",
[57] = "NO",
[60] = "NO",
[61] = "NO",
[76] = "NO",
[77] = "NO",
[89] = "NO",
[90] = "NO"
}
-- Determine whether or not in field
if Stage[memory.readbyte(0x00F2)] ~= nil then
-- General Info
gui.text(107,8, Stage[memory.readbyte(0x00F2)])
--gui.text(0, 0, "Health:"..memory.readbyte(0x00B0))
--gui.text(0, 8, "Ammo:"..memory.readbyte(0x00B1))
gui.text(25,8, math.abs(memory.readbyteunsigned(0x0406)-memory.readbyteunsigned(0x0506)))
gui.text(25,16, math.abs(memory.readbyteunsigned(0x0400)-memory.readbyteunsigned(0x0500)))
gui.text(25,24, math.abs(memory.readbyteunsigned(0x0420)-memory.readbyteunsigned(0x0500)))
gui.text(25,32, math.abs(memory.readbyteunsigned(0x0430)-memory.readbyteunsigned(0x0500)))
-- The player
p = 0x0500
px = memory.readbyteunsigned(p+6)
py = memory.readbyteunsigned(p+7)
--gui.text(px+4, py-7, p .."("..memory.readbyte(0x030037F0)..")")
--gui.text(0, 16, "Character: "..char[p] .." (" ..p ..")")
--gui.text(0, 16, p)
gui.text(px, py, "X:"..memory.readbyteunsigned(p).."."..memory.readbyteunsigned(p+1))
gui.text(px, py+7, "Y:"..memory.readbyteunsigned(p+2).."."..memory.readbyteunsigned(p+3))
--gui.text(memory.readdwordsigned(0x03003950),memory.readdwordsigned(0x03003954),"P")
--The enemies (mostly based on MUGG's Wario land 2 script :P)
for i = 0x0400, 0x04F0, 16 do
if memory.readbytesigned(i+15) ~= -1 and Blacklist[memory.readbyte(i+8)] ~= "NO" then
local x = memory.readbyteunsigned(i+6)
local y = memory.readbyteunsigned(i+7)
if ((memory.readbyteunsigned(p) >= memory.readbyteunsigned(i) and px >= x) or (memory.readbyteunsigned(p) <= memory.readbyteunsigned(i) and px <= x)) and ((memory.readbyteunsigned(p+2) >= memory.readbyteunsigned(i+2) and py >= y) or (memory.readbyteunsigned(p+2) <= memory.readbyteunsigned(i+2) and py <= y)) then
gui.text(x, y-7,memory.readbyte(i+15)) --HP
gui.text(x, y, memory.readbytesigned(i+8).."("..memory.readbytesigned(i+9)..","..memory.readbyte(i+10)..")") --ID(Action,Timer)
gui.text(x, y+7, "X:"..memory.readbyteunsigned(i).."."..memory.readbyteunsigned(i+1))
gui.text(x, y+14, "Y:"..memory.readbyteunsigned(i+2).."."..memory.readbyteunsigned(i+3))
end
end
end
end
emu.frameadvance()
end
Very "hacky" lua script that despite all the patches, still has some bugs regarding off screen enemies.
Also, 2 bugs: Pausing and dying after getting an item
http://www.youtube.com/watch?v=eLBax15zgQg
I was saving this for myself, but I've sort of lost interest in the game.
Hope this helps:
http://pastebin.com/XtwyxFp1
The game uses 2 boxes for each object, a projectile vulnerability box and a 'touch' collision box. Enemies/projectiles will hurt you when their box touches your crosshair, or their crosshair touches your box and vice versa.
Okay, so BADbrakes had this happen to him when he was playing through the game the other day: http://www.twitch.tv/badbrakes/c/3856451
I tried to recreate this in emulator and on console, but had no success. Unfortunately I only have the highlight video to go on, so I have no idea what triggers that and how to get it to happen. Anyone have any ideas?
Also, occasionally after destroying the Stage 1 boss, I've had the game skip right to Stage 2 during the energy refills instead of waiting until after them. I plan on looking into this myself, but I want to find out first if anyone already knows anything about what causes this.
Thanks!
I was looking at this topic again, and tried the twitch link. I got this screen and the video won't load:
I tried clicking on the button, but nothing works. Anyone who can view it can they please make a mirror of it somewhere?
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Works fine for me, using noscript and enabling only the bare minimum scripts in Firefox for Twitch to work makes Twitch work a lot better for me.
Downloading the highlight.
New TAS is published. Sorry that I haven't discussed this project here. I should have found this thread earlier, but I only found it after submitting the run :(
[3380] NES Journey to Silius by Zakem66 in 08:49.86
Found a way to duplicate the BadBrakes death warp. See more information at a thread I had started with this project at NESDev: https://forums.nesdev.com/viewtopic.php?f=2&t=16458&p=204149#p204049
Pertinent Information
017E Spawn Location
0177 Scroll Boundary
0030 Macro Frame Location
0031 Micro Frame Location
0032 Vertical Location
0034 Run Speed
Basic Observation #1
The Run Speed value is added to Micro Frame Location each frame. The Run Speed value has an acceleration stage such that it increases, 4, 8, 12, 16, 20, 24, and then fluctuates between 22 and 26 each frame.
Basic Observation #2
While your character jumps the Run Speed value will fluctuate between 21, 22, and 23, so the length of a jump will also influence the final value of the Micro Frame Location upon reaching the Scroll Boundary.
Basic Observation #3
When the Scroll Boundary value changes, the code increments Spawn Location by 1.
Basic Observation #4
When the Micro Frame Location value exceeds 255 it will roll over to 0 and this will increment Macro Frame Location by 1.
Basic Observation #5
Every 16 counts on the Macro Frame Location value will increment the Spawn Location by 1. The Macro Frame Location value increases with scrolling to the right, and decreases with scrolling to the left. Likewise every 16 counts on the Vertical Location will also increment the Spawn Location by 1. Vertical Location increases with scrolling down and decreases with scrolling up.
Interestingly I can see what is occurring in order for this glitch to work but I do not understand why it happens. And if I could understand why then perhaps that knowledge could be used to determine if it could be exploited in other areas of the game and if so then where.
When you reach the top of the 2nd elevator in Stage 4, when you reach this Scroll Boundary the Macro Frame Location value seems to reach 96 every time, as the Micro Frame Location rolls over around this time. Depending upon the Run Speed values through this section of stage 4, as well as the value changes when in a jump animation, or knock backs, this may cause the Micro Frame Location value to roll over to 0 or it could go as high as 24 depending upon the Micro Frame Location value the previous frame. Such that if the Micro Frame Location value were 230 and the Run Speed was 26 then on the following frame the Micro Frame Location value will roll over to 0. Likewise, if the Micro Frame Location value was 254, then it would roll over to 24 with a Run Speed of 26 the previous frame.
Therefore, when you reach the top of the 2nd elevator in Stage 4, the Micro Frame Location value could be anywhere between 0 and 25.
When you reach the bottom of the 2nd elevator and get hit by an enemy bullet the screen will scroll to the left, and the Micro Frame Location value will decrease by 4 every frame while in the damage animation which scrolls the screen. Depending upon the Micro Frame Location value, such that if it were 24, then it would reach 0 after 6 frames. Interestingly enough each time the Micro Frame Location value decreases by 4 while the Macro Frame Location value is 96, the Spawn Location value will increment by 1 each frame.
Therefore, for some reason, once the Macro Frame Location reaches 95, the Spawn Location will no longer increment even though your character is in the same damage animation scrolling the screen. In other words, it is related to screen scrolling but the magic number seems to be Macro Frame Location value 96. As long as this value is 96, the Spawn Location value will increment by 1 each frame, otherwise it will not.
Here is a video of me demonstrating these additional increments: https://www.twitch.tv/videos/173221791
Here is a video of me demonstrating the strategy I developed in order to get the best death warp 50% of the time: https://www.twitch.tv/videos/173225643
Hi CLChambers00, nice job with this research. I figure your understanding isn't full yet, so here are the steps you need to do to fully debug this.
First of all, add all known memory addresses to a name list file, to be used for symbolic debugging.
http://www.fceux.com/web/help/Debugger.htmlhttp://www.fceux.com/web/help/NLFilesFormat.html
Then record 2 movies in fceux: one that gets the death warp and one that fails, despite of doing basically the same stuff.
Then make a trace log on the succeeded movie of just one frame where the respawn location changes. In the failed movie go to the same spot and make a trace log of that frame.
Open the 2 trace logs in Notepad++ and select the side-by-side view, to skim over the 2 logs and see where they diverge. That would hopefully be the call to some subroutine that finishes the alignment of death warp conditions.
See what makes that call and that is absent from the failed movie. If it's some other variable that's different in the latter, do the same for the frame where that variable changes in the good movie, but not in the failed one. Trace, compare, go back again.
In the end you will have all the variables that are required, all the frames that affect them, all the calls that need to happen. And thanks to symbolic debugging, figuring out what is what will be way easier than when it's just a black box.
Good luck!
http://tasvideos.org/ReverseEngineering.html
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Doing a side by side is what I would like to do but I am not sure I would understand it if I did, but I think someone else may be more willing to tell me what to do from there if I did some of the upfront work. Now, I can collect a single frame worth of info in the Trace Logger by putting a break point on 017E when it is written to due to where I would like to understand why. By setting it one frame earlier in the TAS Editor I was able to collect this data for that one frame alone: https://forums.nesdev.com/viewtopic.php?f=2&t=16458#p204135
What I was not certain how to do was to get the same frame in another state where the increment does not occur to see what may be different beyond what I have observed, but without a break point I don't know how to only get one frame since the trace logger doesn't seem to collect data with a single frame advance, as far as I can tell.
I have Notepad++ and would be able to see the differences if I can get only that one frame. I trust you understand why this extra increment of 017E occurs as I have described?
Thank you for your response.
For every RAM address that I know what does, I have a name, and after the second # I can have a comment, but I never use comments. When your debugger or tracer shows you code, they will put names in place of these RAM addresses, so you will see what variables are concerned. The clarity of that picture will depend on the amount of the addresses you know.
CLChambers00 wrote:
trace logger doesn't seem to collect data with a single frame advance, as far as I can tell
Enable tracing, advance a frame, disable tracing.
CLChambers00 wrote:
What I was not certain how to do was to get the same frame in another state where the increment does not occur
I guess you will have to find some simple input macro that will trigger the glitch, and then remove the macro and make a trace for the frame where the glitch happened just before. If only a small input segment changes, no irrelevant noise should appear when you compare the 2 versions of the same frame.
When I compare frames in Notepad++, I go to the line where they are identical and lock the vertical scrolling. Then scroll down checking if they started diverging or not. And if they did, I make sure it's not such irrelevant noise, but something that actually has to do with the glitch.
Padding tracer output by the stack size is also a nice feature that shows you where subroutines get entered and left.
Have you read the RE page I linked?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Thank you. I did read the RE link. It was helpful. I am very new to all of this. Only a year ago I learned to use the TAS Editor when I TASed NES Jaws. And only recently I began to learn how to look for memory addresses, and very minimal glances at Trace Logger and Debugger when I learned how to manipulate Who Framed Roger Rabbit. All is still very new and most of what people say goes over my head. So please be patient with me if I do not immediately understand what you are saying.
I like the NLFiles idea. I will try it. Right now I am just using a saved list that I call up in the Ram Watch. I have them labeled there for now.
I pull up the Trace Logger and press Start Logging and then I will advance a frame with the arrow in the TAS Editor and then Stop Logging, and it logs nothing :(
I have a TAS file where I can cause the glitch to occur or not to occur so I have something I can work with but what I mean by get Trace Log data from the non working case is that once I get the Trace Logger to capture one frame then I will be fine to compare and see what the glitched variation may be doing differently. It isn't the moment of death, but a boost in an address value that makes it work later on in the level.
I don't know what padding tracer output by the stack size mean.
Thank you for your help!
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Hmm, when I did the frame advance hotkey for that frame it gave me this which does not seem right. This just looks like junk and does not even contain the 017E memory address with incremented during this frame. Did I do something wrong?
That's definitely not the entire frame events. You either never scrolled the tracer up, or simply need to log to a file.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Thanks to Feos I was able to compile this data. Ok, so I figured out how to get a Trace Log snap shot of a single frame of events. I gathered the data on the exact same frame, the first frame of the damage animation when you get hit at the bottom of the 2nd elevator in level 4. You can use the Find function in Chrome to see the only occurrence of 017E in Increment text. I am still working on trying to use Notepad++ of something similar to help me isolate some differences. Help is always appreciated.
Link to Increment - http://wiki.donkeykonggenius.com/Silius_Analysis
Link to Non-Increment - http://wiki.donkeykonggenius.com/~donkeyko/mw/index.php?title=Silius_Analysis&oldid=2435
https://i.imgur.com/9Dt3CAr.png
The value of $0030 makes the difference here. It gets loaded to the A register then bitwise AND is executed between that and 0xF0. The result is compared to the value of $0002 (which is likely some temp variable), and depending on which is bigger, the game either jumps to the subroutine than increments your number, of continues normal execution. The glitch succeeds if $0030 is 0x60, but not if it's 0x5F.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I too have found the $DFB5 Subroutine. $0030 is the Macro Frame Location. I have already observed that if this value is 0x60 or higher then the glitch occurs, and if it is 0x5F or lower then it does not. The question is why? I have not seen this occur anywhere else where $0030 is exactly 0x60. Perhaps it must scroll to the left when $0030 is 0x60 for it to occur. I can experiment by finding such a location in the game but if I can not cause this to happen with those variables then it must be something else.
I tried clicking on the button, but nothing works. Anyone who can view it can they please make a mirror of it somewhere?
Also as far as teseditor's concerned, here's the full manual:
http://www.fceux.com/web/help/taseditor/