Experienced Forum User, Published Author, Player
(201)
Joined: 11/21/2019
Posts: 247
Location: Washington
Don't worry, the scripts I put together for generating the previews are different from the actual encode scripts. They are much faster and compress aggressively so I can render and upload them quickly, but I used fffmpeg for the colorspace conversion and it didn't handle the black levels correctly.
Here is the output of the actual encode:
The preview youtube videos are so that publishers can look for errors with stuff like subtitles placement/timing, run length, etc. I also only render them at 1080p instead of 4k.
Experienced Forum User, Published Author, Player
(201)
Joined: 11/21/2019
Posts: 247
Location: Washington
UPDATE:
These changes have been integrated into the official 64-bit TASVideos encoding package!
Just download the newest zip of the package at https://github.com/TASVideos/TASEncodingPackage if you don't want to modify anything. The instructions will be left here for posterity.
Original post below
This post is a guide to modifying the official encoding package scripts to use 64-bit programs and plugins, and to take advantage of the multithreading capabilities of AviSynth+. Moving the entire pipeline over to 64-bit programs has the advantage of allowing the encoding script to be previewed in x64 VirtualDub, which handles 4K content much better than its x86 counterpart. Multithreading modifications improve encoding performance in general (especially for 4K encodes). In my case, my encoding speed improved by 4X for the HD encode after these changes.
AviSynth+
For any of this stuff to work, you will need to be using AviSynth+. You can download the installer from here: https://github.com/AviSynth/AviSynthPlus/releases/
I don't know how AviSynth works if you use a "files only" package, so this guide is going to assume that you install AviSynth+. You probably need to uninstall other versions of AviSynth you might have. Back up your plugins directories before you uninstall!
64-bit ConversionDownloads
You will need to get 64-bit versions of all the plugins that are used in the encode.avs script.
Installation
You can just throw the 64-bit plugins into the programs folder and reference them with the LoadPlugin lines in encode.avs, or even better, use AviSynth+'s autoloading feature and instead put your x86 and x64 plugins in C:\Program Files (x86)\AviSynth+\plugins64+ and C:\Program Files (x86)\AviSynth+\plugins+ directories, respectively, and delete the LoadPlugin lines.
For global.bat, the only change(s) that need to be made are to change each instance of avs2pipemod to avs2pipemod64, or just rename the 64-bit version to avs2pipemod and replace the 32-bit version with it. Change the reference to ffmpeg (for VirtualBoy) to point to the 64-bit executable.
Multithreading
Read this wiki for more information on these changes: http://avisynth.nl/index.php/AviSynth+#MT_Notes
Add this line to the top of encode.avs:
This automatically sets all plugins that can use multithreading modes to use a safe multithreading mode.
As you might have read in the linked wiki article, to actually make AviSynth+ use multithreading, you need to add a call to Prefetch to the bottom of your script as well, but there's a complication for us. The ExactDedup plugin requires strictly serial playback of video during its analysis pass, and multithreading will break this in strange and mysterious ways. So, to account for this, add this line to the bottom of the script instead:
Language: avisynth
pass != 1 ? Prefetch(7) : last
This will prevent multithreaded execution for the modern encode that uses ExactDedup during the analysis phase. (NOTE: this issue can also probably be solved using the MT_SERIALIZED mode for ExactDeDup but I have not tested this). Change the argument for Prefetch to a number that makes sense for your system!. Read the wiki for more information on sane values. My system has 8 logical cores, but setting the value to use all logical cores actually causes performance to take a hit, and Windows gets really upset. Setting it to logical cores - 1 gave me the best results for my system.
That's all it takes. I got a very noticeable performance boost for 4K encodes by doing this, and a smaller boost to the SD encodes. VDub64 handles previews for HD encodes a lot better as well.
Experienced Forum User, Published Author, Player
(201)
Joined: 11/21/2019
Posts: 247
Location: Washington
Glad to hear you liked the video! I'm afraid that while Tifa does have Dolphin Blow in her moveset, it does not summon a dolphin on hit. :(
The Django = Red XIII thing is weird in this game. The character is clearly Red XIII, and all of his moves reference Seto, Red XIII, or other final fantasy stuff. His alternate costume color also makes him look exactly like Red XIII, color and all. For some reason though, his name has just been "Django", even in the original arcade release.
The arcade version of this game had Cloud and Tifa as in the PSX version, but they were simply known as "Guardian" and "Summoner" when you fought them. It might be that there was licensing being worked out while cabinets were being shipped.
When the PSX version landed, not only did Cloud and Tifa get their real names, but Sephiroth, Yuffie, Vincent, and Zack all got added to the game as well. However, Django is still called Django. So, I'm not sure what the devs wanted to do with the character.
Experienced Forum User, Published Author, Player
(201)
Joined: 11/21/2019
Posts: 247
Location: Washington
I make tool-assisted playarounds for Ehrgeiz every now and then just as a personal project. They aren't really speedruns, with the goal of "use every move the character has while also being fast." So, the videos aren't really a good fit for the site, but I figure I'll post my newest one here in the hopes that people find it entertaining. They only take like a week to make so there certainly isn't any extremely intense optimization at play here outside of making sure that input is as crisp, well-timed, and minimal as possible.
Link to videoUser movie #64615340919429708
I've also created playarounds for Lee Shuwen, Han Daehan, and Dasher Inoba. They are all pretty bad since I was just barely learning how to TAS (and encode videos) while making them.
An actual any% speedrun of the game would be pretty boring and aggravating to make. The CPU has a bad habit of stalling fights as often as it can by staying in invincibility states (like being on the ground) for as long as it can. It also tends not to be very aggressive, which means you have to find ways to provoke it to attack so that you can counter attack. The CPU also performs interrupts on basically everything, so you are constantly trying to find a single frame out of 30 or more for every move where the CPU decides not to interrupt you.
Someone else should make one because as far as I know, I'm the only person who has created any TASes for the arcade mode of this game rather than the dungeon mode. I'm honestly not that creative and I figure others might be able to put together a really cool show.
Some characters with a LOT of potential for a playaround: Clair/Tifa (complex combo systems), Koji (Parries, throw loop system), Doza (lots of fancy combo variations).
Experienced Forum User, Published Author, Player
(201)
Joined: 11/21/2019
Posts: 247
Location: Washington
Obvious yes vote here. I somehow didn't even know that there was a Crash Bandicoot racing game at all - this TAS was quite an introduction to the game! The edge-riding in some stages is absolutely bonkers! Even though I knew it was a TAS and all was well, it still made me incredibly nervous to see just how far you could hang off the tracks and still manage.
The sheer amount of subversion of the course layout is fantastic. + points for that great UI as well.
Experienced Forum User, Published Author, Player
(201)
Joined: 11/21/2019
Posts: 247
Location: Washington
Preview encode: https://www.youtube.com/watch?v=xcbTRftrjrw
Interested parties: please point out any issues that need addressed. I'll start the full encodes and post them here later if no issues exist.
Experienced Forum User, Published Author, Player
(201)
Joined: 11/21/2019
Posts: 247
Location: Washington
I loved that stage with the bone-snake-Koopa things. Even though it's a TAS and I know it's gonna be just fine, I had anxiety watching all of those close-shaves with death while you danced around.
Rest of the run is stellar of course. Yes vote.
Experienced Forum User, Published Author, Player
(201)
Joined: 11/21/2019
Posts: 247
Location: Washington
Whiteted wrote:
No problem, well done for making your way to the end of it ;)
The body part HUD lua is on my github now. If you want to run it then you also need Wyster's /Data library linked in the readme (though looking at it now it's only for 1 thing). I tried it on 2.4.1 and the bug is still present so expect it to crash pretty quickly.
I watched your Armored Core TAS - very impressive :) , for sure only in the vault because of all the mission skips. The enemy models look to be of a similar complexity to GE's guards, though maybe with no movement of the head / neck? Atleast if you want to include the limbs as well then it looks like it won't be easier than GE.
I ended up finding the motivation to open up Ghidra and spend a lot of time reversing AC for other reasons, and that ended up with me ultimately looking for the model rendering code:
Link to video
It took me probably a week of reversing unrelated code before I could even make sense of the stuff that dealt with 3d projection and rendering, and I spent probably 2 weeks in there before I was sure that I had found the code that walked model vertices. However, I did have the camera's transformation matrix in hand, and with your code for your GE wallhack, I had a great launching point for getting a very basic hack working that just placed a dot over enemies in the game. I have to thank you again for posting your code, without it, the difficulty curve probably would have turned me off from even trying, especially since I ultimately had to learn a LOT about PSX hardware and how it does 3d rendering to get it working correctly.
A discovery I made very late into the process was that AC does not actually use hitboxes at all! It uses axis-aligned bounding-boxes. This was both relieving and disappointing at the same time. I spent a lot of time writing a function that would find model vertices and traverse the skeleton, only to find that every time I thought I had found the right data, I ended up rendering vertices for every single triangle on the entity model. I had passed right over the AABB collision function for the game probably dozens of times and never payed any attention to it because it seemed too simple and didn't reference any model data. One I realized it used AABBs, getting bounding boxes around the entities was a piece of cake.
In the end, I'm glad to have done this and am pretty done with it, but am a little disappointed that my solution did not ultimately actually find model data and walk the structures because that was exercise I wanted to do. It feels like my work is sorta a "fake" wallhack compared to yours in that regard, but the only alternative to what I did would be to invent my own boudning boxes for the game's models based on model vertex data and a bounding algorithm or something, and that is WAAAY more work than I am willing to put into this!
The code for my wall hack (and a number of other scripts for AC) is here: https://gist.github.com/Zinfidel/d47287cec638f0f915c3d99bccef3a7d
P.S.: Thank for the compliment on my TAS! It's boring I know, but it has already inspired another TASer to do a "proper" TAS so that's something to look forward to.
Experienced Forum User, Published Author, Player
(201)
Joined: 11/21/2019
Posts: 247
Location: Washington
It's a shame that the tools had to be disabled, but it'll be exciting when the bugs can be worked out and the PS2 library becomes more accessible for TASing. Unfortunately for me I've become accustomed to the power and convenience of TAStudio and I doubt that software like that will be available for PCSX2 too soon, but a good foundation is of course a good start.
The preview youtube videos are so that publishers can look for errors with stuff like subtitles placement/timing, run length, etc. I also only render them at 1080p instead of 4k.