Posts for Alyosha


Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Is this still the case for this submission?:
Masterjun wrote:
An important part to note for this run is the fact that it executes controller registers while they are being updated. This is known to not be emulated in a correct way on emulator. This gives this run a high chance of not working on console at all. However, leading the game code to the controller registers is done perfectly fine, so while these exact input sequences probably won't work on console, it's likely there are indeed some inputs which work. The run wouldn't look very different, so we can safely say that this isn't a problem.
Seems kind of hand-wavy to me. If not then cool, nice improvement!
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Maru wrote:
Around a month before this was submitted, Total and I worked on the Super Mario Bros. 2 (SMB2USA) game end glitch. It also takes advantage of the DPCM glitch, but the difference is that a memory setup needs to be achieved in the first level before taking advantage of the glitch. For anyone curious, the documentation can be read here to see how it compares to this SMB3 submission.
The link here is incorrect (it's the smb3 console verification link again.) Will it be submitted?
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
'Freezing' a value in Bizhawk doesn't actually freeze it. What it does is write the desired value at the start of a frame, then run the emulator core for that frame, then write it again at the end of the frame. So in your example, the trace log will still have the proper decrement since the core isn't blocking the write for the decrement. Then it will rewrite the non-decremented value again so you won't see it as decremented in the memory tools. Since you are trying to use a trace log, obviously this is very unhelpful to you. I could make it work correctly for GBHawk at the cost of some % performance, but it's not going to happen for gambatte. Fixing this would be a long term goal.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
For me it's novel enough for a yes vote. Also your commentary is really good.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Cool! So are you working on a new warps run? It is also possible to save 4 frames in 5-2 with a slightly better birdo fight.Not sure what i did here or if it was a real improvement, cant reproduce and d ont have the file.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
6 sided dice roll generator I found a 3 frame time save in the warpless run in 4-2. If you run a bit before pressing down for the super jump, the sliding momentum moves you quite a bit further while building up the jump power. The picture above is the frame I press down. Unfortunately fry guy desyncs due to ??? so it still needs work.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I briefly looked into the random Ridley statue. Looks like a random bit flip hardware glitch. If any bit in 0x366 (kraid statue) or 0x367 (ridley statue) are set at any point prior to entering the room, the statue will rise on it's own upon enterring the room when the statues are loaded. As far as I can tell, these memory locations are not used elsewhere in the game, so if they have a bit flip happen at any time it won't ever be corrected. So basically, with 8 possible bits and an entire run's worth of time, hardware glitch seems pretty likely. EDIT: Actually, a save-quit sequence resets the value, so it would have to be a bit flip after the last save warp.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
this is a game I'm looking at for console verification. Just so it's known, that wall clip is quite a bit slower then just going over the top due to the speed of L + R and the fact that you can't run in the wall.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Sounds like it crashes on a real N64 though. Probably for the best.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Most games I looked at deal with incorrect input either by simply discarding it or falling back to the previous frame's input. So generally speaking I doubt subframe input is widely applicable / necessary. I think only Gimmick is currently known to need it. Maybe there is some potential for ACE type payloads where it's possible. Subframe resets are probably more important, several games would benefit from saveram corruption type effects.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
jlun2 wrote:
Nothing against the run, but how did you figure out what distributions were impossible? That sounds like a fascinating read.
It’s actually not. The game just runs a code loop from power on / reset until a certain point then checks how long it took. It’s a rather long code loop, so we’re not talking about cycle accuracy here , it just needs to be close, within several scanlines. FCEUX is just too far off. There is even a comment about default house state in the rules at speedrun.com. If you look around you’ll also notice most videos and other emulators have the same house state. All FCEUX runs have this same issue. But unless you have sensitive RNG routine it’s not really noticeable, and even if you did it’s not accurate enough in many other respects for it to matter, since it will be wrong anyway. This just happens to be an obvious example. EDIT: actually the FCEUX house arrangement could theoretically be possible from a sub-frame reset on a top loader model NES, because this model doesn’t reset ppu with the reset button, only cpu. Still impossible from power on though. Maybe future work would be to use subframe resets to get an optimal house arrangement , but the emulator currently doesn’t emulate top loader behavior.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Thank you for the temp encode Spikestuff. Yeah I definitely exchanged tricks for lag in this run, but I figured the original really isn't all that entertaining, so I wasn't losing much going for speed. there's enough optimization potential to just make it a normal speed record. That being said, it would probably be faster to just lose customers each day since that means less paper delivery lag and generally less laggy obstacles, but I thought that would just be too boring.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Ok thanks for testing. Pretty sure there is no left-right jump.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Wow I didn’t realize mamehawk was this far along already, great work feos!
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Is there someone who can please test kirby's tilt 'n tumble on GBHawk and let me know what they think of the controls? If someone can just do a quick test and make sure nothing is broken I would appreciate it (I can't do it myself at the moment.) (you need to set the controller to tilt in the GB -> sync settings menu and reboot the core first.) tilt X should be bound to mouse X tilt Y should be bound to mouse Y (maybe inverted.)
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I'm starting to look into nes console verifications again. For now I'm still working along the lines of syncing some runs to mesen start up timings. The first successful one so far is nightshade: http://tasvideos.org/userfiles/info/71845677054219302 I've also has a few setbacks with some games behaving differently even though I otherwise match mesen's start up timings, so there is definitely more to look into.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I wanted to make a quick note about sync here. This run won't sync in the current dev build due to emulation changes. It will however sync with different initial conditions. I'm not sure yet what initial conditions I will set NESHawk too for the next release. Since this run works on hardware the initial conditions for it to work in the current core (which is zero cpu offset) seem like a good choice, but I'm still doing a lot of testing. Unfortunately NES power up state varies widely, so picking one or another state will inevitably cause some runs to work and others not to, just a choice that has to be made.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
You might want to pm asnivor , who is the main author of the Cpc core. He is also on github. I haven’t seen any activity from him in a bit.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Masterjun wrote:
For reference, dwangoAC confirmed this run works on console. Thanks for testing! :D
Awesome! Seeing this running on console makes me hopeful subframe inputs might be more widely applicable. Maybe some long standing runs that failed on console before can be made to work, like Mike Tyson's Punchout or Ninja Turtles. Maybe I'll start looking into it.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Warp wrote:
Warp wrote:
Don't get me wrong. I don't think the Kirby Avalance TAS should be accepted either. It's just that the reason is different from the stated one (ie. "it's replicable via unassisted play"), which I think is a bit silly.
I must admit that I'm enjoying, perhaps in a bit cynical way, the discussion that the new SMB3 submission is generating. I have been asking for years (although can't be bothered to find my own posts about the subject) what happens if a TAS does nothing more than to jump directly from the startup to the ending screen. I even once asked if in the future the site would start consisting on nothing more than 1-second long runs that do nothing more than show the ending screen of the game. Since not many such TASes have existed, it has been a mostly hypothetical question, but it has always loomed in the near future. We are slowly but surely starting to see it happening.
I don’t think it’s a negative. This is just the natural end point in a long stream of developments on nes. The reason it got this far I would say is mainly because this is the reasonable intersection between complexity of the task and desire to exert the effort to accomplish it. Even technically very complicated NES runs are by far simpler then say a moderately lengthy 3D N64 run. Who would even dare to try to make a Jet Force Gemini TAS for example? That’s like a dedicated year of effort at least, with new discoveries likely to invalidate your work in the mean time. So instead people just hammer away at NES/ SNES and similar games. I know that’s what I did anyway.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Maru wrote:
I'd like to raise a few questions here because this TAS has mixed feedback so far. I was very brave to claim this TAS for judgment. This type of TAS is something that has rarely, if not never, been seen here before. With regards to console verification, at the moment of this post, this TAS has yet to be console verified. However, it may be possible with some tweaking of the .r08/.r16m file.
So it doesn't work on console currently? I don't think this run should be accepted unless it actually works on console. This is a purely technical demonstration so I think it should be held to a standard of correctness where it either is right or its technical foul. I can work on anything on the emulation side that needs fixing. (I guess it's also possible that the problem is on the botting side, but that has seemed pretty robust in the past unless there is something unique here that is breaking it.) As for the other questions, in my mind this is just a regular game end glitch run, it should obsolete the current one.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Awesome it’s done! Looks way more complicated then expected, nice work! I really hope this one gets a console verification , doesn’t seem too timing sensitive so I’d think it has a good chance . This is the culmination of a lot effort and work from all directions, so it’s great to see it done. Hopefully some of the ideas here are more widely applicable and this isn’t just a lucky fluke (well it is one , but hopefully not the only one .) Anyway yes vote!
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
warmCabin wrote:
Regarding the console verification thing: the run obviously syncs on FCEUX, but it desynced when I converted it to run on BizHawk. It desyncs at the third dog in Wood with NESHawk, and desyncs almost instantly with QuickNES. None of us have the hardware to test it for real, so we can't say which emulator is the most accurate as of right now.
FCEUX is very likely to be wrong. You can directly load the converted .bk2 file into Mesen too to see if it works there, it's worth a try. It would be strange to obsolete a run that works on console with one that doesn't, that seems like a step backwards.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
In trying to sort out some recent regressions, I noticed some other bugs and also noticed that the core has fallen a bit behind in terms of accuracy and up to date TIA knowledge. I implemented some bug fixes to catch up a bit on some of the basics, but other things are still a work in progress. various timer tests now work (the knowledge to make them work was actually already written down on the document i linked in the first page of this thread,, I guess I just glossed over it!) Also the 32charnew demo which requires writes to RESP to delay the draw command (but not the position counter) now displays correctly. this one was quite tricky since as far as I could tell it's not written down anywhere that this is what happens. Anyway with these improvements the core is now (almost) back up to parity with Stella with the main deficiency being collision detection during HMOVE and hBlank when ENAB is written to. (And Journey Escape which is what originally led to this investigation.)
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I have sorted out the remaining issues and set this core to released, so it should now be fully TASable. Unfortunately since the programmers had complete control of the screen drawing, many games run at highly variable frame rates. In order to account for this I had to set each frame for a constant time and just update the video whenever a frame was actually ended (which mercifully all games agree is at the expiration of timer 2.) This makes sure audio and video always play at the correct rate, but at the cost of having to put the video buffer in the state (actually two versions of it.) Luckily the screen is mostly empty most of the time so the state size compresses down to near nothing.