Experienced Forum User, Published Author, Experienced player
(942)
Joined: 9/18/2008
Posts: 154
Location: Japan
Hi, thanks developers.
Not a bug report, but recently I have struggled to run BizHawk 2.10 rc2 correctly on Linux.
Previously, the sound was not working, and the error log says "client-rt.conf is not found". But I installed PipeWire and related dependencies, and now it looks working. (I'm using Debian testing, and resolved the issue by installing pipewire-pulse and wireplumber packages.)
By the way, BizHawk 2.9 works without PipeWire (only with PulseAudio).
If PipeWire is mandatory, it might be helpful to include this information in the documentation.
Experienced Forum User, Published Author, Experienced player
(942)
Joined: 9/18/2008
Posts: 154
Location: Japan
Bigbass wrote:
I've just done some attempts, unsuccessfully. Performing sub-frame replays is a bit, uhh clumsy, on my hardware right now. This'll require some more in-depth investigation to see what precisely is wrong. Easily could be something on my end, not necessarily the TAS or the emulation itself.
I can't read Japanese, but I can tell that whatever is going wrong, happens at least as early as inputting the player's name (it takes a whole lot longer than it should, and the wrong name is typed.)
Thanks for your attempts!
I said "this run doesn't depend on uninitialized values on Save RAM", but strictly speaking, that's somewhat incorrect. This game essentially depends on an initial Save RAM state, so ideally, a verification should start with the exact same state of the Save RAM. Alternatively, the Save RAM should be cleared with in-game initialization functionality. (If you "delete" all heroes and execute "delete" once more, the game prompts to re-initialize the Save RAM. (steps: "edge of town" ("まちはずれ") -> "training grounds" ("くんれんじょう へ いく") -> "delete" (キャラクタをけす))
If your verification started with the same state of Save RAM, I don't have an idea for now.
For reference: Save RAM initialization routine is located at $06:86F8. The game checks a "magic string" at $7FF0-$7FFF, and if it differs from the expected magic string by 7 bytes or more, the game initializes Save RAM.
Experienced Forum User, Published Author, Experienced player
(942)
Joined: 9/18/2008
Posts: 154
Location: Japan
Patashu wrote:
* Why the hero dies instantly, what's wrong with them?
He has 255 (legal or illegal) items, and receives various effects from them. In this case, he has a negative healing value 0x98 (-104) on address $7B36, so a single step will instantly kill him.
* If this can be console verified
Possibly. I believe this run doesn't depend on uninitialized values on Save RAM, but the RNG of this game is very sensitive to CPU cycles, so accurate emulation will be hard.
* Why there's encryption in a NES game. Is it just a copy-paste of PC code (where it DOES make sense to discourage save file peeking) or if they were trying to thwart gameshark users or something.
I don't know (I haven't read the PC version code). But, this game seems to make an significant effort to protect user's savedata. The scramble function swaps the nibbles of the original byte, and the developers might thought that it increases the possibility of successful savedata repairing?
EDIT: This game always enables Save RAM (probably it doesn't have functionality to disable it). So, it's possible that hero structs and their backups occasionally corrupted by some programming errors. The nibble swapping might be a measure to increase survivability of backups? (just a guess)
Experienced Forum User, Published Author, Experienced player
(942)
Joined: 9/18/2008
Posts: 154
Location: Japan
TaoTao wrote:
NESAtlas wrote:
Here is a new Deja Vu discovery. The Capsule Warp!
I took a look at this.
It seems that the place ID ($0514) becomes 0xFF when you use the capsule on any untaken medicine. This is caused by the code $AEE1 (ROM:$1AEE1), and this probably intends to erase a medicine from the inventory.
And, apparently the game sometimes executes a strange address (e.g. $3820) when you "OPEN" somewhere on this glitch (confirmed on Mesen).
I haven't analyzed this game so thoroughly, but this glitch might have potential for further improvements.
When the place ID is 0xFF, the game reads out of bounds of some tables. for example:
* The game reads a minimap portal list pointer 0x3247 from the table $06:9023.
* The game reads a view rectangle list pointer 0x4001 from the table $02:9C00.
But, reading from $3247- or $4001- is open bus access. So, I think it might be difficult to control this as you desire.
Experienced Forum User, Published Author, Experienced player
(942)
Joined: 9/18/2008
Posts: 154
Location: Japan
NESAtlas wrote:
Here is a new Deja Vu discovery. The Capsule Warp!
I took a look at this.
It seems that the place ID ($0514) becomes 0xFF when you use the capsule on any untaken medicine. This is caused by the code $AEE1 (ROM:$1AEE1), and this probably intends to erase a medicine from the inventory.
And, apparently the game sometimes executes a strange address (e.g. $3820) when you "OPEN" somewhere on this glitch (confirmed on Mesen).
I haven't analyzed this game so thoroughly, but this glitch might have potential for further improvements.
Experienced Forum User, Published Author, Experienced player
(942)
Joined: 9/18/2008
Posts: 154
Location: Japan
This game have been one of candidates for a good TAS material in my mind. Thank you.
I watched another TAS on nicovideo long ago, but your run seems to be faster. Yes vote.
Experienced Forum User, Published Author, Experienced player
(942)
Joined: 9/18/2008
Posts: 154
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
(942)
Joined: 9/18/2008
Posts: 154
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
(942)
Joined: 9/18/2008
Posts: 154
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.).
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
(942)
Joined: 9/18/2008
Posts: 154
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
(942)
Joined: 9/18/2008
Posts: 154
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
(942)
Joined: 9/18/2008
Posts: 154
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
(942)
Joined: 9/18/2008
Posts: 154
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
(942)
Joined: 9/18/2008
Posts: 154
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
(942)
Joined: 9/18/2008
Posts: 154
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.
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
(942)
Joined: 9/18/2008
Posts: 154
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
(942)
Joined: 9/18/2008
Posts: 154
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
(942)
Joined: 9/18/2008
Posts: 154
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
(942)
Joined: 9/18/2008
Posts: 154
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
(942)
Joined: 9/18/2008
Posts: 154
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.