This almost works for Tekken 3 (The OpenGL file had 1 extra frame which looks like a dup at the end, so I'm not sure if it's due to the spot it was cut). You do first pass of ExactDeDup on both software and OpenGL. Then for OpenGL, you use the OpenGL dup file for the AVS, but use the software times file for x264/MKVToolNix. The thinking is that both have the same amount of unique frames, so you just use the right timing of software and combine with the right unique frames for OpenGL.
As for dumping at the game framerate. I think it would be better to dump at 60, to make sure you have all frames, then you use FixFPS and then ChangeFPS to lower it back down to 30. I'm unsure of this, but we can talk more on IRC/Discord.
But how it works? What mean "use the dup file for AVS"?
How the script have to look like?
The only thing i (guess) got is to do 2 dumps, right? One with OpenGL and one with software
Which software is required to make overlays like the one in this video? Its cool, expecially for the 4:3 videos:
http://tasvideos.org/6509S.html
Just Paint.NET for image editing and then Sony Vegas for combining with the encode. It could probably be done programmatically but for now I just do it by hand.
Previous TASes:
Frogger's Adventures: The Rescue
Paper Mario: The Thousand-Year Door any% x 8
Paper Mario 64
Luigi's Mansion
Sonic Heroes - Team Sonic
Mario Kart Wii ILs
Which software is required to make overlays like the one in this video? Its cool, expecially for the 4:3 videos:
http://tasvideos.org/6509S.html
Just Paint.NET for image editing and then Sony Vegas for combining with the encode. It could probably be done programmatically but for now I just do it by hand.
Ah, you are the TASer of that video; great job and great quality!
Anyway, how do you have the in-game clock on overlay? You had to do refresh every seconds? o.O
RingRush posted this in the discord server but it got buried with other messages, so I’m just going to post it here:
“So question for the encoding type.
I've been working on a v2 DK64 any% TAS for a few weeks, and was informed the other day that maybe I should be playing on GlideN64 instead of Glide64mk2.
1) I notice quickly that GlideN64 has additional graphical glitches not present in Glide64mk2, such as flickering on the main menu and certain things being the wrong color completely.
2) I tried converting what I've done so far but it desynchs in several places. So far it is just trivial desynchs which I can spend the time converting, but if I start seeing gameplay desynchs I'm less keen.
3) Based on the 5th paragraph in this post ( http://tasvideos.org/forum/viewtopic.php?p=453166#453166 ), it sounds like to get this game to encode well it needs to be a splice of glidemk2 and gliden64 regardless. Which would mean converting myself to gn64 might not actually save any encoder time? Which would be the primary reason to even do this
I guess the question is: given the above, am I cool to keep going on Glide64mk2? Is my assumption correct that it will cause light or no headaches for the encoder over switching? Because switching will cause headaches for me and this is the kind of annoying work I'm not patient for unless I'm really helping someone out.“
[14:15] <feos> WinDOES what DOSn't
12:33:44 PM <Mothrayas> "I got an oof with my game!"
Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet
MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish
[Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person
MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol
Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
I asked a similar question a long time ago but what is way to encode GBC,GBA,SMS and Neo Geo as HD for Youtube? It is the same as the SNES setup as the SNES where I have to resize it twice?
Joined: 10/12/2011
Posts: 6437
Location: The land down under.
GB/C - Just do 1440p (x10), doesn't take long since it's a single scale.
As for everything else you'll have to do two resolutions like S/NES.
GBA doesn't get the 4:3 treatment like "everything else".
For SMS pay attention if you're using borders then use the S/NES method there.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
I notice quickly that GlideN64 has additional graphical glitches not present in Glide64mk2, such as flickering on the main menu and certain things being the wrong color completely.
What version of the emulator is being used? or what version of GLideN64? Through development, there have been numerous issues introduced and resolved. I'm aware of a large number of bugs resolved and present. I'd be happy to have a look at it and see what's going on though. Would it be possible to provide a savestate (or savestates) in places where the issues occur, and a small description of what I'm looking for?
EZGames69 wrote:
I tried converting what I've done so far but it desynchs in several places. So far it is just trivial desynchs which I can spend the time converting, but if I start seeing gameplay desynchs I'm less keen.
DK64's a hard game to resync. Generally speaking, the better the emulation for a specific game (or specific section of a game) is, the easier the process has been. Games with relatively stable emulation (like Super Mario 64 and Banjo Kazooie) have typically been able to sync across plugins without any adjustments (or with only minor settings). Games like Donkey Kong 64 or The Legend of Zelda: Majora's Mask have been nightmares. From what I recall, DK64 was a relatively simple run to fix at first. The first desync occured as a result of inconsistent timings when loading Cranky's lab across the video plugins, and so several thousand frames were fine at a time. Once the game begun to be abused however, states were required in intervals of < 5 frames for extended sections, which became incredibly tedious. Additionally, when loading savestates, the native res buffer is displayed until the next update, so we have to load the savestate several frames prior, have the game progress forward to the next frame update, then resume dumping to prevent visual issues. If the interval between the savestates is less than the required distance for the next update, that section can't be synced correctly and some creative handling is required.
EZGames69 wrote:
it sounds like to get this game to encode well it needs to be a splice of glidemk2 and gliden64 regardless. Which would mean converting myself to gn64 might not actually save any encoder time?
A lot has changed in the GLideN64 plugin since then. There's a good chance the encode could be tackled entirely with GLideN64 now, but that'd depend on how the problems look and how they could possibly be resolved. The major difference here (other than emulation accuracy) is that GLideN64 is being actively maintained and improved, and in all tests so far runs which are made with the oldest versions of the plguin sync with new versions without any adjustment. This means it's possible for a visual issue to be resolved, a new version of the plugin to be built, and the encode to be made without any resync required. This happened with Mario Party's Coin Block Blitz. It's worth noting that it's not wise to rely on a possibility, though.
EZGames69 wrote:
I guess the question is: given the above, am I cool to keep going on Glide64mk2? Is my assumption correct that it will cause light or no headaches for the encoder over switching?
I'd say the best option is to be thorough as early on as possible. Let's have a look at those problems and see if we can resolve them, then see what the best way forward is. It's possible Glide64mk2 is still the best option for this game, but it's still very inconsistent. As an example, your previously published run required a resync even with Glide64mk2, as it produces different results on different resolutions during certain moments. If not, the resync process between plugins can take a significant amount of time and effort depending on what is required and how often it desyncs, and depending on the severity and encoder's availability can take several weeks or months.
I'm not as active as I once was, but I can be reached here if I should be needed.
DK64's a hard game to resync. Generally speaking, the better the emulation for a specific game (or specific section of a game) is, the easier the process has been. Games with relatively stable emulation (like Super Mario 64 and Banjo Kazooie) have typically been able to sync across plugins without any adjustments (or with only minor settings). Games like Donkey Kong 64 or The Legend of Zelda: Majora's Mask have been nightmares. From what I recall, DK64 was a relatively simple run to fix at first. The first desync occured as a result of inconsistent timings when loading Cranky's lab across the video plugins, and so several thousand frames were fine at a time. Once the game begun to be abused however, states were required in intervals of < 5 frames for extended sections, which became incredibly tedious. Additionally, when loading savestates, the native res buffer is displayed until the next update, so we have to load the savestate several frames prior, have the game progress forward to the next frame update, then resume dumping to prevent visual issues. If the interval between the savestates is less than the required distance for the next update, that section can't be synced correctly and some creative handling is required.
Joined: 10/12/2011
Posts: 6437
Location: The land down under.
The method is probably mentioned earlier (like 20 pages back or so) but I didn't spot it...
So I followed the page on AviSynth about ImageSourceAnim and that's including updating the libraries, making sure that I have DevIL updated all done.
And came up with is an error that I couldn't find the answer to googling around.
I can just do the simple method of raw avi and dealing with that, but I did want to see the gif method.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
I was messing around with Dolphin and wanted to re-encode Mega Man 9 TAS using Dolphin AVI dumper. I noticed that audio is dumped fine, but was dumped without lag frames, which causes A/V desync unfortunately
I found that issue already addressed here and was fixed by using Xvid codec, but I don't want to use it of course. I know Aktan said that it may be caused by the computer being not fast enough to decode all frames or I/O limitation but I believe it is not a hardware issue as I tested that on a i5-3570 with 8 GB RAM which is enough in my opinion to record AVI fine.
So my questions are: what causes this issue? and how to fix it?
The TAS I'm trying to encode is the published one of MM9 with same version used for creating it of course (4.0-4796).
@Darth Marios: Off memory, a script was used to dump and compare in-game values (such as the player position and orientation) and alert when these values no longer matched. If you'd like more info, I can attempt to dig through some chat logs and files.
@McBobX: I'm not sure if this is directly related as I wasn't aware of the xvid workaround, but which version of Dolphin was used? Versions prior to 4.0-3595 will require an alternative av sync build to get the dump to sync correctly, and whilst 4.0-3595 fixed dumping to no longer require the av sync hack, it became severely broken on Windows systems until ffmpeg dumping was introduced in 4.0-8634. This means that in order to get a reliable dump out of 4.0-3595-4.0-8634, I've always had to use Linux (which already used ffmpeg for video dumping). I honestly dread hearing about this range of Dolphin revisions.
I'm not as active as I once was, but I can be reached here if I should be needed.
I'm not sure if this is directly related as I wasn't aware of the xvid workaround, but which version of Dolphin was used? Versions prior to 4.0-3595 will require an alternative av sync build to get the dump to sync correctly, and whilst 4.0-3595 fixed dumping to no longer require the av sync hack, it became severely broken on Windows systems until ffmpeg dumping was introduced in 4.0-8634. This means that in order to get a reliable dump out of 4.0-3595-4.0-8634, I've always had to use Linux (which already used ffmpeg for video dumping). I honestly dread hearing about this range of Dolphin revisions.
I see. Well, at least later versions (>4.0-8634) have fixed dumping. I guess I'll just use a "worst" way to record AVI using an external screen recorder, cause why not? lol, will try using Linux for dumping and see how it works though.
EDIT: Managed to do encode the run in an NES style. Download the encode here. (MP4 Compatibility).
Used built-in audio dumper, but for video, used an external screen recorder with Lagarith codec, and surprisingly got audio and video in sync.
The method I used is absolutely not recommended (not even good), but I would tell how I did it if anyone interested to know.
[14:15] <feos> WinDOES what DOSn't
12:33:44 PM <Mothrayas> "I got an oof with my game!"
Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet
MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish
[Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person
MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol
Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
g = ms ? g.AppendSegment(ms_base, ms_start, ms_end, ms_format, hd).ConvertToRGB32() : g
audio is the WAV file as loaded in the LEGACY STUFF / PSXjin section of encode.avs.
My understanding of the default AVS file behavior is that the audio dubbing for PSXjin gets done before the multisegment import, so the multisegment import generates a video track with no audio. Does anyone else have a different explanation for the error that EZGames69 posted?
Joined: 11/21/2019
Posts: 247
Location: Washington
I've got a question about official site encodes and horizontal overscan.
For PSX movies, recent encodes retain the horizontal overscan pillarboxes in the video. I'm curious as to the reasons for retaining the overscan. At least on Armored Core for PSX, without overscan clipping turned on, the video output resolutions is no longer 320x240, but 370x240, with uneven pillarboxes on either side of the video.
It seems to me like this abnormal resolution would cause problems when uploading to YT, which is picky about resolutions at least the last time I checked. Also, wouldn't retaining the overscan cause problems when correction the video's aspect ratio?
Older PSX encodes, such as the Castlevania SOTN encodes have no overscan, so it looks like the decision to retain the overscan was made at some point. Or at least, once emulators that supported showing the overscan were starting to be used, the decision was made to keep it.
tl;dr: Why do official PSX encodes retain the horizontal overscan pillarboxes?
I can just do the simple method of raw avi and dealing with that, but I did want to see the gif method.
