Posts for TaoTao


1 2
5 6
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
feos wrote:
TaoTao, do you have a preference on which file should be used for publication - with or without sound?
I prefer the one with sound. This game changes the music in the ending, so it will help viewers to notice the mini scene change. (This is a tiny easter egg. That is, if you wait for about 15 seconds in the ending, the game displays the messages from the staffs, as shown in my encodes.)
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
NES Adventures of Lolo 3 might also have a DPCM exploit. I was able to cause a CPU stack overflow with subframe inputs (though I haven't investigated whether it leads to credit warp, etc.).
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
DJ_Incendration wrote:
Quick quetion, though. Doen't the NES run at 60.0988139 fps? I'm confused because the submission page says the frame rate is 2269.7553711, much faster.
It's probably because this movie uses subframe inputs (though I don't know exactly about the movie parser on this site). "Frame Count" in the submission page will be actually the subframe count, and "Frame Rate" will be the subframe rate. Indeed, 2041 / 2269.755371198338 ~ 0.90. You can find other examples like this (Might and Magic, Quarth, etc.).
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
GJTASer2018 wrote:
This game also got a sequel on the Game Boy that was localized as "Square Deal: The Game of Two Dimensional Poker".
A sequal of this game was also released for Famicom as "Great Deal". I'm not so familiar with it, but apparently it changed some rules from this game: * Poker hands are recognized also diagonally. * You don't need to erase all the cards to beat a level (except for the last one).
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
In frame ~13150 of your updated movie, it seems that you can open the sack without untrapping. (And, if I remember correctly, sometimes chests are also not trapped) Does this help to save time?
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
Wow, I'm glad to see the skip glitch being used in TAS. Thank you. I quickly checked your movie, and noticed a few things: * In battles, you can charge the gauges faster by rapidly pressing R button. And, the kick is a bit stronger than the normal punch. (I uploaded a sample movie) * After getting the gold cloth, if you fully charge all the gauges, Seiya sometimes wears the gold cloth and his firepower increases. But, due to a bug, if you use the gold cloth once, the next enemy's defence will be increased. You can fix the enemy's defense by calling some ally. (This technique is used in the later Mini4Rider's video) FYI: Mini4Rider uploads a glitchless TAS video (part1, part2). Unfortunately the movie file seems to be unavailable, but it looks optimized well. For example, it seems to take a faster route in a cave.
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
I forgot that I have to treat the last move of the last stage specially, so I fixed my solver a bit. But, this modifications didn't change the solution.
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
I edited some submission texts to reflect the movie replacement.
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
I have no objection to the acceptance, if all the people agree on the theoretical reproducibility as feos mentioned. I appreciate the people who put effort into console testings.
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
feos wrote:
Can you just edit memory to simulate successful botting, as a proof of concept for whatever depends on it?
I tried it, but Mesen didn't behave in the same way as FCEUX/NesHawk. (But, it read script commands from the ppu registers.) For reference, I put scripts to edit memory. * FCEUX: a script to save memory, a script to load memory (use the movie of this submission) * NesHawk: a script to save memory, a script to load memory (use the movie I uploaded above)
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
I still haven't been able to reproduce a fast glitch case on Mesen. It is easy to reproduce the glitch itself on Mesen. But for now, all cases either result in a softlock or fail to enable the "beat Dragonlord" flag. It is a bit difficult to search for a fast glitch case on Mesen, including Mesen2, because they don't seem to support rerecording. And, I wasn't able to write a botting script for Mesen as it appears that Mesen's Lua API is not designed for botting purposes. I'll try it manually when I have time, but please don't expect too much.
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
feos wrote:
How do I make a fceux version of your script that shows which PPU register mirror addresses were read?
Language: lua

local script_ptr = memory.readbyte(0x99)
This does not read script pointer, but lower 8-bit of it. Please try memory.readbyte(0x99) + 0x100 * memory.readbyte(0x9A). EDIT: IIRC, the game also reads script commands at addresses other than 0xBD29. I recommend to use the trace logger.
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
feos wrote:
https://github.com/SourMesen/Mesen2 is newer, and I don't know if it supports rerecording.
Thank you. I have noticed this, but it seems to be under very active development and not documented yet. So for now, I'll try with Mesen-X. On FCEUX and BizHawk, I achieved fast glitch cases with lua scripting, but I don't know it works well with Mesen family.
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
feos wrote:
Can you try reproducing this glitch on Mesen?
Yes, I'll try it. But it might take some time since I have no experience making movies on Mesen. I'll use the HEAD commit of NovaSquirrel/Mesen-X. If you have any recommendations for other versions, please let me know.
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
TaoTao wrote:
Moyou_Jo suggested some improvements for this run. So, I made a improved movie. Please replace my movie with this. And I improved further, so I will post another movie. EDIT: improvement is in the stage 20, 25. I will also update the submission text.
Sorry again, but I improved my movie further (improved the stage 0, 1, 5, 23). Totally, this is faster than the current submission by 589 frames. Please replace the submission with this file.
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
Moyou_Jo suggested some improvements for this run. So, I made a improved movie. Please replace my movie with this. And I improved further, so I will post another movie. EDIT: improvement is in the stage 20, 25. I will also update the submission text.
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
I wrote a Lua script to play a NesHawk movie on SubNesHawk. I confirmed it works for Dragon Quest (J). But I don't know if it works for other games.
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
Bigbass wrote:
The replay works a lot farther than before, and when it's working, all of the NPCs are always where they are expected to be (which indicates the RNG is the same). But it desyncs during the glitch (approx. 05:53 in your video).
Thank you again! It seems that the movie syncs perfectly before performing the glitch. This will mean we can make a (non-glitched) verifiable movie on SubNesHawk. For the glitch, I guess that NesHawk's emulation might be still incomplete for some edge cases. Especially, in the movie, the game reads text script commands from the PPU write-only registers.
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
Sorry to bother you again, but could you verify this NES Dragon Quest (J) movie (recorded on SubNesHawk) ? This is just a resync of this NesHawk movie. If this syncs, it will look like this video: Link to video I expect this to sync at least until 5:38 in the video above.
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
Bigbass wrote:
TaoTao wrote:
But I found a strange quirk. I tried inserting a reset frame at the beginning of my movie
That could just be a quirk of the emulator. The initial boot sequence as seen from a TASing perspective isn't necessarily correct (although NESHawk I think gets it more correct than FCEUX). For example, there are games where you can have exactly the same inputs between FCEUX and NESHawk, but save 2 frames in NESHawk because the number of "lag" frames at the start is different. This was discussed as part of Final Fantasy's stair glitch branch. Furthermore, the experiments you show here don't represent what's happening when I reset the console to begin the replay. The initial reset could happen at any point after the game has started (it's impractical to start the replay within the first 5 frames of the game). It would be as if you inserted potentially hundreds of blank frames at the start of the TAS. Like I said, normally this doesn't matter, and I'm not sure it matters in this game either, since starting from reset always produces consistent results, albeit different from what the emulator expected. Additionally, even if I could start the replay at the same frame the emulator thinks is the start, the reset you're adding to the TAS inputs wouldn't actually be used until the first input poll. This is just due to a limitation of the replay device, as the only way to stay in sync with "lag" frames, is to monitor the composite video output of the console and watch for the VSYNC pulse (which may not be the same way the emulator tracks frames.)
Thank you for the detailed description. Now I understand that it is not a problem about the amount of blank frames at the beginning. The only reason I can guess is that this game sometimes polls input multiple times in a frame (especially when the game is paused). I will try resyncing my movie on SubNesHawk when I have time. EDIT: I guess that the reason is the input polling loop in the title scene. In this loop, the game continues to poll input without waiting for VBLANK (you can confirm this with SubNesHawk). And I waited for a frame in the title scene, in order to manipulate the RNG. Now I believe that I have to at least use SubNesHawk to make a verifiable movie.
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
Still I cannot reproduce this movie exactly on NesHawk, but I was able to reproduce a similar fast glitch case on NesHawk. Here is the encode: Link to video But I don't know whether it syncs on a real console. Bigbass says that he could not verify a NesHawk movie without the glitch. EDIT: Now I think that we have to at least use SubNesHawk to make a verifiable movie of this game. When the game is in the title scene, or the game is paused, the game continues to poll input in a loop without waiting for VBLANK. So, frame-based movies are unlikely to sync on a real console. I'm considering to make another movie on SubNesHawk when I have time. EDIT: I resynced the movie above for SubNesHawk. According to Bigbass, it syncs before performing the glitch on a real console, but desyncs after the glitch. In this movie, during performing the glitch, the game reads some text script commands from the PPU write-only registers. (You can confirm this with this Lua script) I guess that NesHawk's emulation might be still incomplete in such cases. (Or, it might be impossible to deterministically emulate such cases in the first place)
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
Bigbass wrote:
Hmm testing this one out and still encountering desyncs. I'm curious if the replay must be started from power-on. I normally start from reset, because I use an everdrive which means I can't boot directly into a game. For a majority of NES games, this is completely fine, but there are some games, like Hydlide for example, that performs different code on boot compared to on reset. (and some games change where the program flow jumps to at reset, depending on how far into the title screen you go.) You mentioned in the submission thread that the game updates RNG every frame. Now, starting from reset is still consistent between attempts (but different from the submission movie). However, if I don't reset when I start the replay, every attempt is indeed different, often desyncing by running into an NPC, or eventually entering an enemy encounter. What I'm curious about, is if somehow there is an RNG difference between power-on state, and reset state. Or in other words, if there is some part of the game that the reset routine doesn't affect, which results in a different (albeit consistent) result than what is seen in emulator. It is possible to start a replay from the everdrive menu, but it's a bit finicky and my replay device isn't designed to do that, at this time. A couple years ago, that's how I managed to verify Hydlide. I'd rather see someone else attempt this, ideally with either a reprogrammable cart or the original game.
Thank you again for the verification! I have read a large portion of the game code, and I believe this game does not distinguish power/reset in the logic. But I found a strange quirk. I tried inserting a reset frame at the beginning of my movie, and the game takes an inconsistent time to accept the first input: In the 1st picture (the original movie), I did not insert a reset. And I wait for 1 frame to manipulate the RNG at frame 56. In the 2nd picture, I inserted 1 blank frame at the beginning, and reset at frame 0. This syncs (the same as the original movie). In the 3rd picture, I inserted 3 blank frame at the beginning, and reset at frame 2. This desyncs. In the 3rd picture, I expected the game to accept the first input at frame 59, but it actually does so at frame 60. This affects the RNG and the movie desyncs. But, if I insert an extra blank frame at frame 60, it syncs. I don't know why the game behaves this way. I tested some other games (e.g. SMB1), but they do not show such a behavior. Does the desync you mentioned still occur even if you insert/remove a blank frame at the beginning of the movie? (I made such movies: inserted a frame, removed a frame) If so, it might be impossible to make a verifiable movie on NesHawk... For now, I'm considering to make another movie on SubNesHawk, but it might take some time.
Post subject: request for console verification of NES Dragon Quest (J) movie
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
If possible, I want this NES Dragon Quest (J) movie to be verified. This movie proceeds the game just before performing a glitch. I submitted a FCEUX movie of this game, but according to Bigbass, it is unlikely to sync on a real console. So, I decided to make another movie on NesHawk. And in the first place, it will be necessary to verify the base movie above. EDIT: I think this game does not depend on an uninitialized RAM state (although I'm not 100% sure).
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
It seems that pirohiko reproduced a fast glitch case (like this movie) on a real console. Note that he uses "cartridge half-insertion" technique (it corrupts data loaded from CHR-ROM). In this video, he moves to the coordinate (0xFE, 0xFE). But it might be difficult for regular TAS. Because you will warp out of the map when your coordinate is out of bounds. (Bounds are at address $13, $14) In this video, I think that the warp portal data in CHR-ROM is not properly loaded and the warp process is skipped.
Experienced Forum User, Published Author, Experienced player (870)
Joined: 9/18/2008
Posts: 148
Location: Japan
juef wrote:
Is the Mountain Cave bottom floor layout the same as in the US version? I believe the path that first grabs the two side-by-side chests is slightly shorter.
Oh, that was my mistake. Thank you for pointing out. The map is the same as in the US version. And indeed your path is shorter by 2 steps. I want to fix this, but I'm not sure if I can reproduce the glitch later. For now, I will add this to the submission text.
1 2
5 6