Posts for cleartonic


Experienced Forum User
Joined: 2/18/2014
Posts: 6
I believe PXM converter does not work properly in Bizhawk version 2.2.1. Steps taken: Downloaded .pxm file (tasvideos.org/2626S.html) Loaded .cue into Bizhawk for game File -> Movie -> Import Movies... Loaded .pxm file, .bk2 was created Opened TAStudio, loaded .bk2 I then opened the .pxm file in TAS Movie Editor and compared to what was in TAStudio (the newly created .bk2 file) The below album shows the discrepancies https://imgur.com/a/EMXpO I don't know much about this conversion process but I attempted to find any semblance of a pattern among the two files- I didn't find any
Experienced Forum User
Joined: 2/18/2014
Posts: 6
zeromus wrote:
I know the debugger is always broken, but maybe youll know.
What does this mean? Is it known the debugger doesn't work?
Experienced Forum User
Joined: 2/18/2014
Posts: 6
This error happens when I try to run Debugger on a GBA game. Issue present on official releases 2.2 and 2.1.1, and developer release 0.0.0.1798. Can't find any reference to "libdarm.dll". Its not in the dll folder.
Experienced Forum User
Joined: 2/18/2014
Posts: 6
Before you read, I want to say thank you for your time and reading this post. If this post belongs elsewhere, I apologize. But I believe that this is the only place it would fit. Even though my questions are related to RTAs, any information found would certainly help a TASer. Hello. My name is cleartonic, and I am perform RTAs. I wanted to request some help with my latest project, Dragon Quest IX for the Nintendo DS. I have some questions about RNG manipulation methods that I have developed and how the game handles specific RNG seeds. This topic is mostly directed towards those who have had experience dealing with both the console and DS emulator DesMuMe, which I understand to be the preferred emulator of TASVideos. I'm going to try to explain the background explanation and my questions methodically. First, I have a few goals in mind. The following are questions directly related to Dragon Quest IX. You should not need a deep understanding of the game- I will do my best to explain what you would need to know. I would like to understand: 1) How a console DS loads a specific RNG seed from the firmware screen (Power On) to the game 2) Why variations exist in how a specific RNG seed fluctuates from console vs. DesMuMe, given most factors are known and replicable In this first post, I will explain what I believe the easier of the two questions. If I get an adequate response, I'll be inclined to ask the second topic's questions. 1) I will explain how RNG Seed B works. RNG Seed B is relied upon the game for a variety of decision making, which are largely known and have already been identified (including enemy formations upon entering battle, rare drops on bosses, alchemy outcomes, etc.) RNG Seed B is currently manipulable in real time, because it is NOT based on the frame. RNG Seed B is located at 02108DDC and 02108DE0 RAM values. RNG Seed B has history being known as the "Hoimi table" manipulation. The Japanese pioneered a method to calculate in-game values to effectively 'back in' to your initial RNG Seed B, which is determined from Power On of the DS. Once you know your "position" (i.e., what your current RNG Seed B is set to), you can make specific actions to your benefit. Many players during DQ9's heyday would use this to their advantage. The problem was that even though you could manipulate the seed, you did not intially know RNG Seed B. You would have to hard reset the game, then identify the initial RNG Seed B, which is a process that takes about 1-1.5 minutes by using this "backing in" process. Once you found your initial seed, you could then move on to manipulate certain aspects of the game. Here is an example of a hoimi table : yabd.org/apps/dq9/hoimi.php . What you effectively do is cast heal a certain amount of times, write down the amount that you healed for, and then you can figure out what you're starting RNG Seed B was. From there, you can go to a table where you can track your progress, which is used for a variety of predictions of outcomes. My understanding is that while the firmware is loading, or stationary (i.e., you are waiting on the DS firmware screen), the RNG Seed B is fluctuating, perhaps frame based. This is why there's a "backing in" method I explained- the seed isn't the same every time from power on... except: Recently, I found that you can guarantee your seed to be 1 out of 2 possibilities. If you set your console DS to auto-boot the DS card, you can simply hold A, Power On the console, then the firmware will automatically boot to the DS game. Once the game is loaded, RNG Seed B is actually SET. Until you load your game and make actions, it will not change. This is well known, and is easily seen at addresses 02108DDC and 02108DE0 on emulator. Therefore, it theoretically should be the same amount of frames from Power On to loading the game. From here, I am easily able to identify that RNG Seed B is one of two possibilities, based on methods described 2 paragraphs above of "backing into" the seed. RNG Seed B is either set to 318D7 or 318E2 with this method. Every action that affects RNG Seed B will change this seed (such as healing in game, some other actions). Like I stated before, we have a method of tracking what values the initial seed will change in to. The problem has always been identifying the initial seed- and I found a way to narrow it down to 1 of 2 possibilities. My question has to do with the 1 out of 2 possibilities portion. Why would there be any variance in how the initial seed is set when I buffer the firmware? In this case, the fact that a previous process that yielded a large variety of RNG Seed Bs can be narrowed down to 2 seeds, which I can identify easily, is great. But why is it 1 of 2 possibilities? With the method I described earlier of buffering the A button while the firmware loads to the game to a point where the RNG no longer fluctuates, the load time from Power On is consistent (if I did not know better, it would be exactly the same.) Just a point - if buffering from Power On was not a viable way of guaranteeing seeds, it would be obvious immediately - you'd attempt to back into a seed, and it would appear random. The fact of the matter is that I can guarantee 1 of 2 seeds by buffering from Power On. I hope that someone who maybe understands how the firmware works, and why buffering from Power On leaves me with 2 options, when I would expect 1. This is pretty dense stuff, and I'd be happy to provide an explanation video or answer questions. Thanks!!
Post subject: Emulators that eliminate lag?
Experienced Forum User
Joined: 2/18/2014
Posts: 6
Hi, I was wondering if there are emulators out there that are flagged as being inaccurate for the NES/FC because of too much lag reduction (similar to how ZSNES is). Thanks.
Experienced Forum User
Joined: 2/18/2014
Posts: 6
I found a skip while RTAing this game that is not in the TAS https://www.youtube.com/watch?v=q-yjQuDBauA