Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
(Configured so the lower the "Main Value" becomes, the better the run attempt is.)
Hello everyone,
I have made a Bizhawk forked experimental build that includes a Genetic Algorithm Bot, based off of the Basic Bot that comes with Bizhawk.
I would like to request for anyone who uses this bot, to see:
* Is the bot helpful for you in creating TAS runs?
* Is there any issues with the bot?
* Any other feedback?
Testimonialsslamo wrote:
genetic algo bot has helped find a new clip (Game: Pac-in-Time (Game Boy))
bpm46 wrote:
In this game, you can do a midair attack that boosts you off enemies higher than if you jump on them. What I did here was jump from the top platform and attack-boost off the enemies, but the bot instead drops onto the ground then jumps on them normally. This seems to have slightly less lag and also lets the player land sooner and jump over the slope at the end.
There's also an interesting coincidence: jumping into the flower at the end doesn't save or lose time here, but if you don't jump, the next level loads several frames slower. The bot didn't know that, its input was set to stop before the flower. I'm lucky it happened to jump there and I noticed it.
Randomno wrote:
Gave it a quick try. I had no idea what to set the probability controls to. I wanted to use as few left presses as possible, so set right and B to 65, A to 25, and left to 5. Main value of the highest X position and 100 frames. It had good results after 75 generations. I kept it going until 180 generations and it hadn't improved. I was able to improve it by a few frames by manually editing the input afterwards to remove a few left presses. My initial attempt had 715 xpos, the bot found 730, and my changes afterwards got it to 741. So a good result for just a few minutes of work, and saved me figuring out a frustrating section to optimise.
How the Botting Works:
When you begin botting, the first thing you do is to set up the parameters and configurations for the bot to know about your game inputs. Things like, how long the input recording should take, how many attempts do you want to do per population generation, how likely it is for the bot to enter in the inputs you wanted during the botting process, and what RAM address values are you expecting by the end of the botting process.
The moment you press the "Run" button, the first thing the bot does is, it stores the current state of your specified RAM address value. This is called the "origin", or the "source attempt".
As it proceeds to enter in inputs, the game will handle what happens after those inputs are sent, and does things in the game. The RAM address values you specify to the bot will change (or not change) depending on those inputs.
By the time the bot reaches the end of the input recording session, which is on the last frame of the entire frame length you specified, it will then log the final RAM address values into a collection. This result is called the "destination" or the "target attempt". The Attempts counter will then increase, and the bot will then proceed to do a new Attempt within the current generation.
When all of the attempts in the current generation is done, and all of the results are collected, it will begin the "evaluation" process. When evaluating, it compares which attempt's results leads to a value that fits the conditions you have set to the bot, and then sets that as the "Best Attempt". if it finds a "Best Attempt", it will log it and displays the information to you, as well as which "Attempt" it was, and from which "Generation". Otherwise, if no results fit your conditions, the results will be discarded, and you would have a blank "Best Attempt". This is intended, so you don't get confused about the "Best Attempt", when it was clearly not the best one.
After the evaluation is complete, it will then begin the crossover and mutation phase, where some of the recordings are "breed" from the previous generation, and may mutate as a result of the crossover.
Finally, we proceed to the next generation, and the generation counter is incremented. This whole process repeats from the "origin", reach the "destination", and evaluate the results at the end of each generation, until you stop the bot.
Your best attempt will be the attempt that matches your set of conditions. If you aren't happy with it, you can restart over by clearing the attempted results with the "Clear" button, and modify the input probabilities (or called "weighted values"), so you can refine the best attempts better.
Changelogs:
v1.0.4 - 2023 August 5
Made a pre-release build.
Updated log entry generation class to reference the newer generator from BizHawk dev build, 2023 May 25.
v1.0.3 - 2023 August 2
Fixed issue related to loading a previously saved BOT file from failing.
v1.0.2 - 2023 April 8
Fixed "Turn Off Audio/Video" setting not reset back to the state it should be.
v1.0.1 - 2023 February 8
Updated the bot to accommodate new External Tools API changes for Bizhawk 2.9 (ETA pending release).
v1.0.0 - 2022 July 28
Used a workaround (thanks to adelikat for the suggestion) to resolve the configuration file issue.
All major bugs are now fixed. Consider this bot to be released as a stable build, and no longer be an experimental build.
v0.1.4 - 2022 July 28
Allows the user to modify the default mutation rate.
Improved tooltip description.
Modified the input control label text, so it is more meaningful.
Fixed Clear button state.
v0.1.3 - 2022 July 27
Fixed issue where you can't do negative values to do comparison checks.
Added upstream fixes with loading BOT files for wrong games.
Use unsigned long integers (unsigned 64-bit integers) for address values.
This should improve compatibility with emulators that requires 64-bit addresses.
v0.1.2 - 2022 July 26
Clear button is not enabled immediately after the first attempt was made.
Added missing Generation label.
Fixed crash when GeneticAlgorithmBot attempts to load BasicBot .BOT save files. It is now compatible with loading BasicBot files. However, it will save as GeneticAlgorithmBot file.
Fixed Generation counter not showing up and properly counting.
Fixed Attempt counter not using the correct variable.
Fixed Best Result not storing Generation counter.
Fixed issue where the Run/Play buttons can get stay stuck in disabled state when entering addresses and sliding the slider controls.
v0.1.1 - 2022 July 25
Fixed issue where the < and <= are not being evaluated correctly.
Increased BotAttempt values from "int" to "uint" type.
Changed value comparison checks to support "long" type as a result.
Restored text fields from being disabled all the time.
Restored functionality with comparison attempts.
Slightly tweaked the UI. Not sure if it will help.
v0.1.0 - 2022 July 25
First minor release.
Ported the experimental build into an external tool.
Removed unusable GeneticSharp library, improving its synchronizations as a result.
Can now set Population Size.
Now displays Generations and correct Attempts.
Now properly evaluates each attempt's fitnesses.
v0.0.4 - 2022 July 22
Fixed the Run/Stop button killing off the population and creating a new one. Made it so that only when you press the "Clear" button, will the current population then be wiped clean.
You will then start with a new population and begin from the initial generation after you press "Clear" and then "Run" button, strictly in this order.
If you click the "Run" button first, and press "Clear", the bot will continue to use the old population, and will continue using this population until you click "Stop". After that, you will no longer be able to recover this population.
Your Best Attempt will be cleared, and you will still be able to get a new Best Attempt while the bot is running.
Run/Stop button will now only advance to the next generation, and they will cause the bot to evaluate the previous generation after advancing.
Attempts will not increase as a result.
Current Best Attempt will also not be overwritten as a result.
Tweaked fitness evaluation.
v0.0.3 - 2022 July 22
Fixed input recording playback problems.
Fixed UI where the logs are not updated correctly.
Miscellaneous bugfixes.
v0.0.2 - 2022 July 21
Fixed issue where the bot was only producing 1 frame of inputs, rather than using the entire frame length (or the frame amount specified in the bot)
Added a bunch of tweaks to make the genetic algorithm work properly.
v0.0.1 - 2022 July 18
Initial release.
Known Issues:
NEW: On Windows 11, your UI may be misaligned. This is caused by Windows 11's new UI design changes, and that's something I cannot handle, since I'm on Windows 10.
[*]NEW: Currently waiting on this issue to be fixed. Github Issue Link (Fixed in v1.0.0)
The next time you open EmuHawk, it will corrupt your config.ini file. Please make sure to make backups of your config.ini file before attempting this bot.
This is the reason why this bot is still an experimental build.
There is an "off-by-one" error. (For example: If frame length is set to 200, recording only saves up to 199 frames of input. If set to 100, you get 99 frames. Etc.)
[*]Basic Bot and Genetic Algorithm Bot cannot be opened at the same time. (Because Genetic Algorithm Bot is a child class of Basic Bot parent class.) (Don't know if this still matters now.)
Put the DLL in the "ExternalTools" folder in BizHawk.
Launch EmuHawk.
Tools -> External Tools -> Genetic Algorithm Bot
The Genetic Algorithm Bot is used just like how you use Basic Bot. The only difference is that it should slowly evolve so that you would get the desired results as time goes on, in theory. However, practice doesn't always follow theories, and there are definitely some kinks in the build.
However, there are many things that I'm still learning and tweaking things as I go. I'm still testing and playing around with the code, and I do plan to continue improving upon it for the foreseeable future.
I do not know if there are any plans to put this bot into Bizhawk proper, but that really depends. We shall see.
Details
This Genetic Algorithm Bot inherits some features from the built-in Basic Bot.
What it does is, it takes in whatever probability you give it, to the control buttons, a determined probability for each button, and the max value you set for the bot.
Then, when it starts the botting process, it begins by setting up an "Adam Chromosome", and generates a pool of population. Each member of this pool is called a chromosome, and are entities that can produce offsprings. Just like in real life, chromosomes are based around the theory of evolution, where future generations should be better and fitter than the parents, as they evolve towards reaching the intended target you set in the bot.
Each chromosome stores an input recording of the play, up to the frame length you specify in the bot. The probability for each button is then used to calculate the likelihood the button is pressed in the duration of the input recording.
Each end of a cycle, it begins calculating and evaluates, out of all the generation cycles, which one has the better fitness. It then uses that to determine the parents of the next generation's offspring. While producing the offspring, the chromosome is then mutated and crossed over with other chromosomes, so that mutations in the chromosomes can become the key to surviving with a better fitness level.
You repeat the process until, in theory, the chromosome with the highest fitness is able to hit the intended target you specify to the bot.
This mean, you should get an optimal solution of input recordings for your TAS runs. (Again, in theory.)
Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
That is an interesting way to customize the Trace Logger. I didn't know about that.
The VDA / RAM Search pairing is used when you don't know the RAM address. But I do agree, once you do know the RAM address, customizing the output of the Trace Logger using Lua scripting helps. Thank you for pointing it out.
:P
Overall, how do you like the proposal?
Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
feos wrote:
I still don't get how making the debugger run by itself makes it easier to track how the needed address got its value than by using a tracelog.
I shall answer this with another explanation:
What makes it better than Trace Logger?
Trace Logger is a Bizhawk tool, which is typically paired with TAStudio, that allows you to record all of the assembly instructions executed within certain number of frames (usually 1). Within a single rendering frame, you can obtain a dump of all of the assembly instructions executed, stored in a way where 1 row equals an instruction step in the emulated core.
However, the downside of using Trace Logger means, you are not able to use other Bizhawk tools to assist you in pinpointing where exactly in the code that would update a specific RAM address with the value you seek in the registers.
With this variable disassembler animation (I'm just going to call this VDA for short from now on), you can choose the animation intervals (between 0 through whatever maximum integer of milliseconds you give it) and watch it cycle through the assembly instructions. While that is going in the background, you can then tell Bizhawk to open up the RAM Search tool, and fill you in on what RAM addresses the core has updated during the assembly animation cycles.
If you set the interval to 0, the VDA will know that you wanted to pause the animation, and will be configured to pause the animation until you are ready to continue. This is a temporarily measure, as this part needs more work, so that there is a checkbox to allow pausing/continuing during VDA cycles.
Another thing to point out in regards to RAM Search and VDA, is the concept of "subframes RAM searching", or "searching for RAM address changes that occurs within a single frame". Currently, you have the issue in Bizhawk where each time a single frame is advanced, you typically have a bunch of RAM addresses getting updated. This means, after a search, sometimes you need to narrow down the criteria a bit further, do repeated experiements by rewinding and fast-forwarding the frames, poke and freeze the addresses, and sometimes do "binary search and freeze" the addresses in bulk, just to narrow things down. (The unit of time here is "multiple RAM addresses / 1 frame" here.)
With VDA, we now shrink the unit of time down to "single RAM address / 1 instruction". With this granularity, you can do RAM searching where the game updates a single RAM address one at a time, allowing you to check the changes on a more granular scale. No more guessing which address is specifically getting updated in between each frame, and no more bulk- poking, freezing and unfreezing addresses to experiment what would occur on the next frame and such. All you see are instructions updating 1 thing at a time.
You know how sometimes, when you do a RAM search at a spot between Frame A and Frame B, 1 frame apart from each other, and you see some RAM addresses have more than 100 changes? VDA and RAM Search can handle that for you here.
Demonstration
Here is me demonstrating quickly how you can pair VDA together with RAM Search. By enabling the RAM Search to search automatically per frame, each time the VDA steps to the next instruction, the RAM search will search and remove RAM addresses that don't fit the search criteria.
You can see it in action as the total number of addresses begin to drop as the VDA animates in the background.
When using Trace Logger, there isn't a way for the Trace Logger to dump the RAM address changes and the search criteria used to keep track of which RAM addresses you are looking for. You have to slowly piece back together what all of the instructions and register values are doing from the trace dump, and it takes time to do. But if you have VDA paired with RAM Search, you have an automated way of searching for the RAM addresses and values quickly and easily.
Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
Actual Usage
I'll be using the GBA game, River City Ransom EX, as an example. I've been using this game for TAS optimization testing/RNG manipulating for a while.
Let's say, you (as ALEX, the main character) are about to enter a new area zone, and you wanted to know how the game uses the registers and the game assembly instructions to set the values up, to prepare the data and information it needs to know about the new area's enemy types (Generic Dudes, Frat Boys, Locals, Jocks, etc.)
The first thing you would do is to use the TAStudio in Bizhawk to rewind / fast-forward to a frame just before the area transition begins. You would stop your pointer to this current frame, and pause the game.
The next step is for you to bring out the Bizhawk Debugger and have it attach to the EmuHawk instance, so that the Debugger is ready to start animating the instructions.
The first thing we need to do is to choose the ARM instruction set for our game. Since we are playing this game on a GBA platform, we need to set the mode to ARMv4 (Thumb).
In the debugger, you would then choose the animation intervals (or called "Intervals" for short), to say, how many milliseconds the debugger would wait until it advances to the next instruction. 1000 is typically 1 second, so when you set the intervals to be 1000, the Debugger will update the register values, the PC, and finally advance to the next instruction in the disassembler list every second.
After the animation interval is set, we then press the Animate button, to let the Debugger begin its "animation". Note that this game has a ton of branch operations (or "opcodes"), so that is why you sometimes see the instructions jump to a different address often.
This is 5 milliseconds intervals:
This is me changing the intervals on the fly after I realized I made it too slow:
That is how you would use the Variable Disassembler Animation. You can change how fast or slow the disassembler is animating, be it updating the game logic, or updating the rendering frame.
How This is Achieved
This requires updating the Bizhawk mGBA core submodule code, to expose the unmanaged code's interface to call directly to the function:
mDebuggerRun()
endrift, the developer of mGBA, mentioned how Bizhawk typically calls on the other function:
mDebuggerRunFrame()
That function would then execute a do...while loop that runs continuously for a duration of 1 frame tick (≈13.333 seconds) invoking the mDebuggerRun() function mentioned above.
What I did is I exposed this function interface, and then created boolean flag to check whether the UI button, "Animate", is toggled on. If yes, it goes into a code loop that executes the mDebuggerRun() function per interval, instead of going to the mDebuggerRunFrame(). I then make sure I keep the Debugger information updated after each instruction has been executed/advanced to the next instruction.
To do this sort of execution loop, I implemented a simple "Unity C# Coroutines" in Bizhawk. It's a very simple concept of invoking the enumeration of the code, and then yielding the execution to the main UI thread, so that the Debugger UI doesn't become unresponsive while the Debugger is actively executing instructions in the background.
If there is anything you wished to know, please feel free to let me know as replies below.
Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
I've also submitted an improvement submission, which is much faster than my submission here.
Submission #https://tasvideos.org/7579S
I would like to request to cancel judgement for this run, in favor of the other submission (after it is ready for judging.)
Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
teoheel wrote:
That was an awesome run. Well done! That was quick and fun at the same time. Juggling Dragon Twins was an awesome moment.
PS. There was one death to save time in the run, so the "I do not use any deaths to save time" line is meaningless.
Nice! I copied my previous submission, and forgot to update that. :P
EDIT: Now updated. Thanks again for catching that.
Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
Samsara wrote:
The ROM you used is good. In the future, check the bottom left corner of the BizHawk window for a green checkmark after loading a ROM to see if it's verified good or not.
I'll keep trying to work on a test file, but good lord this game loves crashing on me (and the boys). Should this submission be cancelled in the meantime?
Thank you for letting me know what the green checkmark is for. I always thought the green checkmark is telling me Bizhawk is "ready" and the application is running smoothly now.
Feel free to cancel it. If the game loves crashing for you, I wouldn't want you to suffer the same pain as I have.
Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
I'll keep working on this game a bit more, after I'm done with my current project.
Before we continue, is my TAS run syncing correctly? Due to recent feedback I have received, some of my runs have desynced because I was unaware they are produced on a bad ROM. And now I'm wondering if I had used a good dump of Nekketsu Koukou Dodgeball-bu.
I did not see the game listed here: https://tasvideos.org/Games/List?SearchTerms=nekketsu&SystemCode=
Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
Executive Summary
"Variable Disassembler Animation" is a feature where you can watch the Debugger refresh or "animate" and update the registers, RAM addresses, values, and more, by reading all the instructions for each subframe. This feature uses the mGBA core as a proof-of-concept to make Bizhawk have a more fine-grained debugging environment to be able to inspect and pinpoint some uncertain code logic where RNG and other important values are calculated / processed.
Details
The Debugger is a tool provided with Bizhawk, where you can inspect and observe the assembly instructions and register values of an emulated core an emulated game is running on. However, there are some areas of interests where it's not enough for the user to be able to use the tool and seek out some critical code where the game hides away potential RNG manipulation from being accessed when doing a TAS run.
With integration with TAStudio, the Debugger can run and rewind the specific instructions the game uses to calculate the values that is placed in the RAM addresses of interests within subframes (or things that occur within a single frame). The purpose is to allow users wanting to be able to inspect and poke around certain addresses, to be able to search for possibilities to manipulate RNG when making TAS runs with the goal of doing RNG manipulations, so having both the TAStudio and Debugger will help let them see the results more easily.
I personally have a strong opinion of not wanting to use the provided Trace Logger. It is useful for dumping the instructions to a file, and we can read the file at once at a particular frame where the code logic happens. However, because there are so many data to parse through, it is often cumbersome to read and it's not easy to jot down notes and figure out where exactly the numbers start to become useful.
Goal and What this feature is used for?
The goal for me is to use Bizhawk with variable disassembler animation, to help me figure out where exactly the RNG is being calculated in the game, and understand how the process is being done. There is a GBA game called River City Ransom EX, a beat-em-up student deliquents RPG where you rescue the girlfriend of the titular character Ryan, as Alex. Using the trace logger will not help me figure out the solution to this, because the game uses the RNG extensively to determine the CPU behaviors, chance calculations, statistics in the game, and more.
I have to use TAStudio to keep the controller input active while the Debugger is in the background animating (or, "emulating while in motion") the instructions until I reached a point where the RNG calculation starts happening in the game. The RNG happens briefly, little enough that the code traces become hidden in the Trace Logger, making it very hard for me to figure out where it's happening.
With this new experimental feature, I was able to deduce the ability to manipulate RNG, and has helped another TAS-er, Chamale, in making better optimizations in a TAS run, linked below.
#7569: Chamale's GBA River City Ransom EX "alternate final boss" in 10:09.75DemoGithub Branchhttps://github.com/tommai78101/BizHawk/tree/experiment-disassembler-animationKnown Issues
- I lack the knowledge domain of how Bizhawk actually works under the hood. Requires extensive code refactoring to properly integrate this feature into Bizhawk nicely.
- Unsure if this feature is useful for TAS production.
- Unable to figure out how to properly calculate lag frames when doing full frame advances while you have instruction advances.
- Not a clear picture of how to refactor the Bizhawk and other emulation cores to be able to implement per-instruction advances properly.
- If the animation interval (in the Debugger window) is less than 10 milliseconds, TAStudio wouldn't be able to pick up controller inputs properly.
- Rendering the updated buffer isn't obvious when animating the instructions.
- Unsure if this feature is welcomed by the TAS community.
Credits
Thanks to feos for suggesting I should make a thread.
Thanks to Chamale for collaborating with me to make a pretty optimized TAS run for a game with poorly-documented RNG.
Thanks to CasualPokePlayer and YoshiRulz for most of the help on C# programming.
Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
Memory wrote:
It appears this TAS uses a bad dump. It doesn't sync on a good one either. Any plans on redoing?
I've collaborated with Chamale on this using a good dump. When I did the run, the dump information wasn't available, so CoolKirby updated the information, and that's what prompted me to collaborate with Chamale. :P
Here's Chamale's submission, with me helping him figure out the addresses and optimizations: #7569: Chamale's GBA River City Ransom EX "alternate final boss" in 10:09.75
Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
Found a useless strategy in RNG manipulation to get 3rd prize Lotto Tix ($1000.00)
There is a random number counter that starts from 0x270 and decrements until it reaches 0x0. When it does reach 0x0, it loops back to 0x270.
Another counter was found where the random value, which I found out, is tied to another value. This value is coined as the "determinant" (by me), where, each time it decreases the counter, it increments itself. It's a 4-byte counter, guaranteeing the Lotto Tix lottery results are unique every 0x270 times.
The trick is to manipulate the CPU enemies to make any actions, to start decreasing the random value, and reach a specific random number counter and determinant as fast as possible, in order to reach a particular combination of the random number counter and the determinant, to get the calculating Lotto Tix prize.
The upside to using this strategy allows you to always get your Lotto Tix prize of whatever monetary value you want, but the downside of using this strategy is it takes a bit of frames to do. Here in the GIF, I'm just lucky that, after exiting the Merlin's Secrets shop, I can get the 3rd Prize within 500 frames from the frame I exited the shop.
Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
CoolKirby wrote:
tom_mai78101 wrote:
I don't know what to say, other than I'll redo the run.
Before you start from the beginning, remember that Chamale is also redoing your run and is already at Rocko. It might be a good idea to work together with him from that point on, to save both of you some work. You can also post updates on your progress here or in the game's thread (linking for those unaware there is a thread).
I'll be sure to send a PM to Chamale, to see if Chamale is willing to collaborate on this. Thanks.
Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
CoolKirby wrote:
tom_mai78101 wrote:
As for the ROM, I just obtained it after selecting a Google search page in the upper 10s. Some dumps of the ROM would have RAM corruptions if you do a RAM search and add those addresses into the RAM Watch window. I consider those as bad dumps, because it's more prone to getting desynced.
We always prefer the good ROM when possible. That RAM corruption sounds like a BizHawk issue. If you can reproduce it, please file a bug report so it won't affect you or others in the future.
I believed I have used a good ROM, the [f_5] version. Are there any issues with the ROM I used for this TAS run, just in case? The RAM corruption issue may have been fixed already, as I was told on Discord my Bizhawk 2.8.0 is pretty outdated, compared to the more recent dev builds right now.
EDIT: I just saw the link you posted, and just saw the [f_5] version is considered to be a bad one. I don't know what to say, other than I'll redo the run.
Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
Chamale wrote:
I'm working on an improvement to this run. I think it's possible to save time by manipulating enemy positions. I'm 966 frames ahead as of the beginning of the Rocko fight, but I don't understand how to do the glitch where you throw him off the map - could you please explain it in more detail?
Also, I can't find the exact ROM you used for this run. The good dump I found has a CRC-32 of 8686436E.
Here are the steps:
1. What you want to do is to make sure you can hold your enemy. This means, either the enemy is on top of you, you are holding them up by the waist. Don't hold them by the legs (it still works, but I think it's slower to pull it off.)
2. Make sure while your enemy is being held, your character needs to be moving towards the left side of the screen. I find moving towards the left side of the screen to be easier to pull the glitch off.
3. As you do, get in position, so that your character is touching the left border of your screen.
4. This next trick involves forcing your enemy out of the screen boundaries. What I mean by this, is:
- If the enemy is on top of you, when you throw the enemy, notice that your character shifts the enemy's position towards your character's back.
- If the enemy is being held by the waist, when you A to attack with the enemy as a weapon, or B to throw the enemy, notice that your character shifts the enemy's position towards your character's back. For A, it will move the enemy to the back by an offset first, then it will move the enemy to the front by another offset from your character's current position.
- If the enemy is being held by the leg, when you are tossing the enemy, the game will auto-shift the enemy's position back into the game boundaries. Just wait until the enemy recovers and jumps out of your hands.
5. Let the enemy recover, by letting them jump out of your hands. They have to do this without you interfering.
6. As they jump, their positions are updated, and they will be out of bounds. You will notice, sometimes when the enemy is out of bounds, they would change directions rapidly. That's because they keep hitting the out of bounds boundary, so they go left/right/left/right rapidly.
As for the ROM, I just obtained it after selecting a Google search page in the upper 10s. Some dumps of the ROM would have RAM corruptions if you do a RAM search and add those addresses into the RAM Watch window. I consider those as bad dumps, because it's more prone to getting desynced.
Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
In my opinion, I think these 3 techniques are all you ever need in a TAS run, be it aiming for the best times, or dealing with secret events.
Swap Dragon Kick with Mach Punch if you're playing as Ryan.
Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
Finished my TAS submission:
#7558: tom_mai78101's GB Nekketsu Koukou Dodgeball-bu in 18:41.61
On the hardest difficulty, the CPUs can easily catch your dodgeballs. The only winning move is to use one of your team members' special move where the dodgeball flies upwards and the drops vertically down from the sky. However, you only have about 70% of the chances to select which player to pass the ball to, to be able to pull this special move off.
It's an annoying run, but once you get the idea of how to play this game, it becomes pretty easy to execute.
Current best run thus far.
Link to video
Experienced Forum User, Published Author, Player
(101)
Joined: 3/16/2015
Posts: 160
Chamale wrote:
I take it the objective is to unlock and win the secret, four-person final boss fight. I like it, this makes it very different from the NES version of the game. Voting yes.
I've published a couple TASes for River City Ransom on the NES. Did the Dragon Kick turn out to be faster than using weapons for fights? I remember how difficult it is to optimize fights with the erratic enemy movement involved. On the NES, the trash can and the metal pipe deal much more damage than fighting with bare hands. I suspect that using Seraph Cola with luck manipulation could give a big boost to your weapon stat of choice - I think it merits testing.
A lot of things are changed in the GBA enhanced version. So much so, that I would say "yes" to Dragon Kick being faster than using weapons, because the response times are much faster. You also kick 4 times in the GBA version instead of 3 times in the NES version.
(Configured so the lower the "Main Value" becomes, the better the run attempt is.)
Hello everyone,
I have made a Bizhawk forked experimental build that includes a Genetic Algorithm Bot, based off of the Basic Bot that comes with Bizhawk.
I would like to request for anyone who uses this bot, to see:
There's also an interesting coincidence: jumping into the flower at the end doesn't save or lose time here, but if you don't jump, the next level loads several frames slower. The bot didn't know that, its input was set to stop before the flower. I'm lucky it happened to jump there and I noticed it.
When using Trace Logger, there isn't a way for the Trace Logger to dump the RAM address changes and the search criteria used to keep track of which RAM addresses you are looking for. You have to slowly piece back together what all of the instructions and register values are doing from the trace dump, and it takes time to do. But if you have VDA paired with RAM Search, you have an automated way of searching for the RAM addresses and values quickly and easily.
This is me changing the intervals on the fly after I realized I made it too slow:
That is how you would use the Variable Disassembler Animation. You can change how fast or slow the disassembler is animating, be it updating the game logic, or updating the rendering frame.
How This is Achieved
This requires updating the Bizhawk mGBA core submodule code, to expose the unmanaged code's interface to call directly to the function: 
Github Branch
https://github.com/tommai78101/BizHawk/tree/experiment-disassembler-animation
Known Issues
There is a random number counter that starts from 0x270 and decrements until it reaches 0x0. When it does reach 0x0, it loops back to 0x270.
Another counter was found where the random value, which I found out, is tied to another value. This value is coined as the "determinant" (by me), where, each time it decreases the counter, it increments itself. It's a 4-byte counter, guaranteeing the Lotto Tix lottery results are unique every 0x270 times.
The trick is to manipulate the CPU enemies to make any actions, to start decreasing the random value, and reach a specific random number counter and determinant as fast as possible, in order to reach a particular combination of the random number counter and the determinant, to get the calculating Lotto Tix prize.
The upside to using this strategy allows you to always get your Lotto Tix prize of whatever monetary value you want, but the downside of using this strategy is it takes a bit of frames to do. Here in the GIF, I'm just lucky that, after exiting the Merlin's Secrets shop, I can get the 3rd Prize within 500 frames from the frame I exited the shop.
Swap Dragon Kick with Mach Punch if you're playing as Ryan.