If I recall the game correctly (and please correct me if I'm mistaken or thinking of something else), whilst they may be called "cheats" they're more along the lines of in-game perks. They're sold at an in-game store, using in-game currency collected throughout the levels. Each "cheat" becomes toggleable after it's purchased and performs a specific task, such as doubling or quadrupling the vale of the currency you collect, thus making goals easier. The developers also made some goals difficult or tedious to obtain during non-tool-assisted play without buying at least some of these cheats.
I'm not as active as I once was, but I can be reached here if I should be needed.
As feos highlighted, there are numerous problems with the Jabo plugin and to quote my last post on the issue, it probably shouldn't be used for anything. I've been over this a number of times in the past, but submissions (specifically Zelda series runs) keep on coming in using Jabo anyway, despite all the evidence I and other staff members have provided. Not only that, but a majority of Jabo runs refuse to sync on other plugins, meaning that fixing these situations is often a nightmare. As an example, the last instance took several months and required over 400 save states and even then, it could not be fixed completely.
As it currently stands, GLideN64 is miles ahead in terms of accuracy and is receiving active bug fixes and improvements. For anyone avoiding using it due to a specific problem, I urge you to report it on the issue tracker if it's not already present. Both gonetz and the other contributors are all usually very willing to help with legitimate problems. It's also currently possible for us to update the plugin after the fact and still maintain sync, meaning video problems still have the potential to be solved after a run is submitted.
I do know that this run was made on a revision prior to GLideN64 being introduced, and so please don't take this post personally. I don't mean to detract from discussion of the submission itself, but as long as this keeps happening I need to keep trying to make people aware of this. Hopefully the updated GLideN64 plugin and the upcoming x86 Bizhawk release feos mentioned will help, too.
I'm not as active as I once was, but I can be reached here if I should be needed.
Before I get started, I'd like to say that I've currently abstained from voting (although this could change in the future). It's also worth noting that Spikestuff already covered a lot of what I think, but given the current situation, I'll elaborate:
This run is quite obviously very impressive. It's great to see improvements still coming to the "warpless" Super Mario Bros. branch, even after all this time, and the run itself is also very entertaining on it's own. The only problem for me is that I find it less entertaining than the current published run. After re-reading some of the boasts on the other submission, such as when HappyLee wrote:
we can submit a TAS right now with equal time but A LOT more entertaining
I'm left a bit baffled. Aside from the fact that this makes the comment feel intentionally spiteful, it's implication meant that I went into this expecting a more entertaining run and was let down. It's always sad to see some of the best artistry get obsoleted and this puts my vote for entertainment somewhere around "meh", depending on what perspective I look at it from.
As for the cancellation, I've seen plenty of entertaining runs get a lot of unexplained neutral and negative votes. It's just one of those things that happens, especially when there's some debate or controversy surrounding a run. Heck, a majority of my votes are silent because I don't think anything useful needs to be added other than the answer to the question of whether or not I found it entertaining. The judges factor all of this in to their decision, and cancelling your submission because "too many voters voted "no" or "meh" for unknown reasons" just implies to me that you think your runs are above the audience input.
Don't get me wrong though, overall I'm ecstatic to see another improvement to such a popular run and the hard work both HappyLee and Mars608 is very evident in the end product. It's just a shame to see a run improved in one way but also degraded in another, even if these differences are both small.
I'm not as active as I once was, but I can be reached here if I should be needed.
Just to update everyone: this publication is back on track.
I think it's worth thanking both DwainiumB and Warepire for their efforts in relation to this run, as DwainiumB was able to provide a dump of the full run and Warepire provided three patched versions of Dolphin, which helped fix known graphical problems.
It will still be a little while longer, but now it looks to be business as usual.
I'm not as active as I once was, but I can be reached here if I should be needed.
So it took a while, but I can verify that this run syncs for me on Dolphin with Dual Core disabled, DSP set to HLE, and with an emulated Wii-Mote present (but with cleared settings).
Not only that, but it was a very entertaining few hours and so I've voted yes! Great job!
Edit: I may as well pre-claim this for publication and get to clearing up hard drive space in anticipation of the several terabytes this dump is going to take.
I'm not as active as I once was, but I can be reached here if I should be needed.
Testing commenced! I’m glad to see this finally released. Hopefully it entices more encoders to try DOS, now that it’s more user-friendly. I’ve spoken to a few people about handling VFR already, but I’ll post my thoughts here so it’s public.
creaothceann wrote:
Least common multiple + null frames
I agree, that was my first thought too. I’m in the process of drafting a few ideas in AVISynth that can handle this and preserve the correct frame times. For the MKV, the rate can be pushed ridiculously high with no ill side-effects in the resulting output file, as it gets dedupped either way. The resulting clip is VFR and only swaps between the frame rates of the input files when done correctly, preserving the correct rate of the segments and the associated frame timings. If we're using the current encoding package and AVISynth, I think this is the best option. The down side to this method is that it delays the first pass, due to needing to analyze all of the duplicate frames. It processes at a much faster fps, but because the frame rate is increased, the overall process is slower (and it gets increasingly slow with more framerate variations). Given that we’re using x264 placebo settings for encoding, in most situations (allowing for 1-3 frame rates) this shouldn't extend the encoding process too much, as the bulk of the MKV encoding time is spent in the second pass and this does not affect that. VFR cases are currently not common, but at least this method means that when they are encountered they can be handled correctly for the time being.
For the Youtube and compatibility MP4 encode (where CFR is required), either the game’s most common (or most significant) rate, or the highest available rate can be forced. Forcing the game's most common / most significant rate would lead to more consistent motion in the majority of the footage, but may have the unintended side effect of dropped frames (Youtube's 60fps cap already does this anyway, so perhaps this is the best option). Forcing the highest available rate would avoid the dropped frames, but would also introduce duplicate frames that would interrupt the motion and lead to stuttering, which is very visually distracting (and could be further hindered by decimation to the 60fps cap, leading to dropped frames anyway, in a less consistent pattern). Neither is ideal, but as CFR is required in these situations a standard should probably be known as the preferred method. I believe the encoding package is currently set up to use a user-picked segment from the dump to set the rate of the output video, which allows easily for either of the above situations, or even a case-by-case subjective judgement.
The same method could also be applied to the MKV encode and it would be both faster and an easier implementation, but I strongly disagree with forcing CFR on VFR content for the reasons mentioned in the previous paragraph. This feels like we'd be taking the easy option, when there is a slower but much more accurate option available. Still, it stands to reason that at some point in the future there may be more situations that result in VFR dumps, potentially even true VFR (rather than just several framerates) that the first method won't handle properly. I know we were intending on moving from AVS to AVS+, but perhaps it's time to look for other more modern alternatives that don't rely on the AVI format. Vapoursynth comes to mind as a potential option (and it's been briefly mentioned before), but I don't know enough about it to give a personal recommendation, nor do I know if it does what we would want it to. I do know it was created with the intention to be a cross-platform successor to AVS, it's Python based, boasts multithreading, and has support for format changes and multiple frame sizes (which if the container supports it, would benefit DOS as well as other consoles that change resolution throughout the dump). There might be other candidates too, although in any case it would require a major rewrite of the script and package, but maybe now's the time.
Anyway, I've written enough for now. These changes to the DOS dumping process were well overdue and are extremely welcome. Thanks for all the hard work, feos!
I'm not as active as I once was, but I can be reached here if I should be needed.
To add on to what Aktan has already said, the encoding package changes often enough that a video guide may need to be entirely remade multiple times throughout a year in order to stay up-to-date, whereas a text guide can be amended if there are changes or if anyone notices a problem that needs to be fixed.
If you're having any trouble understanding a particular part of the guide, or something isn't working the way it should be, we can always try help you work through it as best we can. AVISynth gets a lot easier over time and with practice!
I'm not as active as I once was, but I can be reached here if I should be needed.
As Stovent has pointed out, AVISynth is a requirement for the Encoding Package. All the requirements and prerequisites are listed over here (see: Set up the package > Downloads). If you accidentally miss a step then it likely won't work properly, as it relies on the listed external programs to function correctly.
I'm not as active as I once was, but I can be reached here if I should be needed.
My first thought would be to try change the N64 plugin to Glide64mk2 prior to loading any ROM. Bizhawk uses GLideN64 by default, but the improved feature set and more accurate emulation has a more hefty requirement than some of the alternatives.
I'm not as active as I once was, but I can be reached here if I should be needed.
Try change the N64 plugin to Glide64mk2 before loading a ROM. It defaults to GLideN64 as it's the superior option, but it does have higher requirements than the older plugins.
I'm not as active as I once was, but I can be reached here if I should be needed.
Thank you for posting the BK2 file.
I can see the issue now and that definitely does not behave as it should. The problem seems to improve when the character goes indoors, but that still doesn't eliminate it entirely. I did a few tests on the latest dev build with various settings for GLideN64 and couldn't improve the issue. I also tried Glide64mk2 and it behaved in the same way.
I might suggest opening an issue over at the Bizhawk bug tracker. There are no guarantee that it will get fixed (as it could be a problem with the core itself, for example), but it's worth a shot.
I'm not as active as I once was, but I can be reached here if I should be needed.
Hi WMJ! Glad you've become interested in TASing Body Harvest, it's a great game and I'd love to see a run of that game here!
Whilst I'm not familiar with the specific collision issue, I am familiar with GLideN64, and using the software renderer for "Copy Depth to RDRAM" fixes a number of depth related problems (and it's not just in this title, but in others too). Unfortunately, software emulation of such a process comes with a performance drop, as is the case with some of the other settings which often fix other problems. I don't know if the audio interrupt system in Bizhawk's Mupen64Plus core is similar to Project 64 and if such a setting can be changed, nor am I sure it would be a safe change (as it could very well break other things and will almost certainly affect timings to some degree), but the slowdown shouldn't inhibit TASing too much, as these days frame advance is almost mandatory (in that it isn't technically required, but for the level of optimization required for submission you'll almost certainly need it).
As you've noticed, GLideN64 is currently being actively developed and has a much higher performance impact than some of the older plugins. Jabo's plugin was made at a point in time where computers were less powerful and emulation accuracy was shunned in favor of performance. Now, accuracy is held in a much higher regard, leading to a lot of emulation improvements (likely including the collision detection you've pointed out). Because of this, it is recommended you do your TAS using GLideN64 unless you have a specific reason not to, as sometimes movies have difficulty syncing between the various video plugins. If you're using the latest Bizhawk version, it should default to GLideN64 the plugin anyway (and Jabo's plugin should not be an option, as it was removed during the switch to 64-bit).
The good news is that Bizhawk has built-in AVI capturing which should not be affected by any slowdown you experience, so you can play back your run and dump video after recording it and view it in real time. Just make sure you tick "alternate sync" to prevent audio crackling.
I'm not as active as I once was, but I can be reached here if I should be needed.
Considering it's April 1st in some places, I wouldn't be surprised if this is Google's idea of a joke.
Edit: Upon seeing the error, I thought that perhaps it may have been an poor-taste April Fools joke by Google. On a proper review of the information, it looks like this is indeed serious.
I'm not as active as I once was, but I can be reached here if I should be needed.
I think it will sync for someone, though I strongly suspect a dependence on PC hardware and Dolphin settings (such as resolution or anti-aliasing), like in previous cases.
If we had the original configurations, it might be easier to trial different machines knowing that the emulation settings aren't the problem.
I'm not as active as I once was, but I can be reached here if I should be needed.
For what it's worth, it needs the proprietary DSP LLE roms
I initially tried both the Dolphin versions and the proprietary ones with the latter getting me much further into the run. That information saves me trying to do tests twice (once for each DSP rom set), so thank you!
I've done a number of different tests so far on each of my PCs (Nvidia & AMD), each using a clean extract of Dolphin 5.0-114. Assuming I only change the settings listed in the submission and keep everything else as is (including resolution), my Nvidia PC gets to the first Sirena Beach Shine Sprite but get a different Phantamanta split. This leads some of the water to miss and causes a desync. On my AMD PC, Mario gets stuck and doesn't get past Bianco Hills.
Using my Nvidia Machine, if I set the game to run at 2x Native Resolution, the run desyncs after getting F.L.U.D.D. but before leaving the airstrip. The video backend chosen affects the sync, too, with OpenGL desyncing sooner than Direct3D 11.
I'll be retrying on both my AMD and Nvidia machines at native resolution (as it seems the most promising) using each of the backends shortly, to see if any provide a sync.
I'm not as active as I once was, but I can be reached here if I should be needed.
That was a great way to spend just over an hour, voted yes! Also, I'll take this for publication if this gets accepted.
I'm currently checking emulator sync but haven't had any luck (on two separate machines). If anyone gets it working, please let me know (I'll edit this post once I've managed to get it working).
Edit: Looks like DwainiumB got it to sync, with the requirement being an Intel 3000 Series Integrated GPU. For anyone wondering on how to prevent hardware dependent sync, there is a way to make your Dolphin runs hardware-agnostic. Always check to make sure your information is up to date.
I'm not as active as I once was, but I can be reached here if I should be needed.
Here are some extra encodes of this run. Higher resolutions are based on the game's native resolution and are scaled at 2x:
Direct Downloads:
10bit444 MKV: 480p, 960p
10bit444 MKV at 25% speed: 480p, 960p
Compatibility MP4: 480p, 960p
Compatibility MP4 at 25% speed: 480p, 960p
Torrents:
10bit444 MKV: 480p, 960p
10bit444 MKV at 25% speed: 480p, 960p
Compatibility MP4: 480p, 960p
Compatibility MP4 at 25% speed: 480p, 960p
To download the direct download links, you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
Here are some extra encodes of this run. Higher resolutions are based on the game's native resolution and are scaled at 2x, 3x and 4x respectively:
Direct Downloads:
10bit444 MKV: 224p, 448p, 672p, 896p
Compatibility MP4: 224p, 448p, 672p, 896p
Torrents:
10bit444 MKV: 224p, 448p, 672p, 896p
Compatibility MP4: 224p, 448p, 672p, 896p
To download these files you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
Here are some extra encodes of this run. Higher resolutions are based on the game's native resolution and are scaled at 2x:
Direct Downloads:
10bit444 MKV: 432p, 864p
Compatibility MP4: 432p, 864p
Torrents:
10bit444 MKV: 432p, 864p
Compatibility MP4: 432p, 864p
To download the direct download links, you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
Here are some extra encodes of this run. Higher resolutions are based on the game's native resolution and are scaled at 2x:
Direct Downloads:
10bit444 MKV: 480p, 960p
Compatibility MP4: 480p, 960p
Torrents:
10bit444 MKV: 480p, 960p
Compatibility MP4: 480p, 960p
To download the direct download links, you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
Here are some extra encodes of this run. Higher resolutions are based on the game's native resolution and are scaled at 2x, 3x and 4x respectively:
Direct Downloads:
10bit444 MKV: 224p, 448p, 672p, 896p
Compatibility MP4: 224p, 448p, 672p, 896p
Torrents:
10bit444 MKV: 224p, 448p, 672p, 896p
Compatibility MP4: 224p, 448p, 672p, 896p
To download these files you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
