Posted: 4/1/2018 3:28 PM
Post subject: N64 Body Harvest problems
Quote
WMJ
Joined: 5/11/2008
Posts: 21
Location: Netherlands
I have recently become interested in making a TAS for the N64 game Body Harvest. This game has bad collision detection problems with all of the video plugins except the latest release of the GLideN64 plugin. In the settings of that plugin you have to enable an option for frame buffer settings called "copy depth to RDRAM" to "use software render" because otherwise collision detection didn't work on most objects. That does completely fix the issue. Now, the problem is the game has enormous slowdown while using GLideN64 in Bizhawk while the Jabo plugin for instance doesn't have this (but no collision detection). In project64 the game was running fine for me before with the GLideN64 plugin. I went to check again and to my surprise on the latest release of Project64 it has very similar problems to what I experienced in Bizhawk. Checking for the differences there were a few settings that completely fix the slowdown problems. Notably the option AI count per byte. When set to 200 it's almost fixed but at 400 it's completely fixed and the game runs flawless (in Project64). Left image default settings in Project64 2.1.0.1 (the good one) and Project64 2.3.2.202 (with slowdown). Making the settings the same fixes the problem. https://i.imgur.com/ad9NNnG.png I couldn't find any equivalent settings in Bizhawk to change this so the problem of being unable to make a TAS remains. Is this something that's fixable or any other advice? Test video showing the problem: https://www.youtube.com/watch?time_continue=1&v=KSrAbFn1kv4
Posted: 4/1/2018 4:23 PM
Post subject: Re: N64 Body Harvest problems
Quote
TheCoreyBurton
He/Him
Joined: 10/14/2013
Posts: 335
Location: Australia
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.
Posted: 4/1/2018 6:09 PM
Quote
WMJ
Joined: 5/11/2008
Posts: 21
Location: Netherlands
Thanks for the quick reply! I was hoping the slowdown wouldn't affect the end result of the avi capture so I made a quick test TAS for the route of the first level. The youtube video I have linked is made with the Bizhawk avi capture method and with async mode turned on. I have tested another PC but with the exact same results... I have linked the test bk2 movie file here: https://drive.google.com/open?id=1ugDWzs79ucg2sJFPQqk1bitsViTCQHqP If there is a way to capture the avi video without the slowdown and audio issues I would love to know how.
Posted: 4/2/2018 3:04 AM
Quote
TheCoreyBurton
He/Him
Joined: 10/14/2013
Posts: 335
Location: Australia
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.