Posts for TheCoreyBurton


1 2
12 13
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
@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.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
EZGames69 wrote:
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.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Note: This isn't an error report. It's an AVISynth suggestion to help deal with the problem fsvgm777 mentioned in the previous post. Oh dear. Thanks for bringing this up, that looks awful. It's good to see them working on the decoder still, but it'd be nice if we got some actual progress rather than what appears to be the systematic destruction of things that worked perfectly fine this time last year. I have been point resizing up (using the smallest factor that is larger than the destination dimension) and then Lanczos resizing down to the exact dimensions since moving to 8K. In my tests, it gave a better result than letting YouTube handle the downscaling anyway. I made a few adjustments to my scripts to accommodate this automatically back then. I don't have access to the exact scripts, but here's the gist of it (segmented, for explanation): 1) Quick calculation of the target dimensions. This would need to be modified in order to be compatible with the encoding package, to allow proper width and height definitions, along with aspect ratio adjustments, based on encode types. Off-hand, I don't know the variables used and so I've just defined it for Youtube use, with YoutubeHeight in this case being assumed to be defined as 2160.
# Calculate the output dimensions
Height = YoutubeHeight
Width = Float(YoutubeHeight) * ARWidth / ARHeight
2) This is optional, but I'd recommend it. It ensures that the video is not only width limited, but also height limited. This means the video's maximum width when the height is set to 2160 is 3840. It does not affect the resulting aspect ratio, only the resulting dimensions to ensure they fit within Youtube's specifications.
# Limit the output dimensions
Scale = (Width > (Height / 9 * 16)) ? ((Float(Height) / 9 * 16) / Width) : 1
Height = (Scale == 1) ? Int(Height) : Int(Height * Scale)
Width = (Scale == 1) ? Int(Width) : Int(Width * Scale)
3) This is already present in the encoding package and ensures the resulting dimensions are multiples of 4.
# Ensure the output dimensions are divisible by 4
Height = (Height % 4 == 1) ? Height + 3 : (Height % 4 == 2) ? Height + 2 : (Height % 4 == 3) ? Height + 1 : Height
Width = (Width % 4 == 1) ? Width + 3 : (Width % 4 == 2) ? Width + 2 : (Width % 4 == 3) ? Width + 1 : Width
4) This is the actual scaling code. If you're after that exclusively, this is what you want. For anyone unfamiliar with the Ceil function, it rounds the value up to the nearest whole number. This means that the source will be Point resized by integers to either the output dimensions (if they're evenly divisible) or to the lowest value that exceeds these dimensions, after which the clip will be Lanczos resized down.
# Scale the source clips
PointResize(Last.Width * Ceil(Float(Width) / Last.Width), Last.Height * Ceil(Float(Height) / Last.Height)).LanczosResize(Width, Height, Taps=2)
It's also worth noting that AVS handles each dimension exclusively and does not perform any resize if the dimension is already correct. This means it's possible to have the original dimensions as the destination dimensions, with the resize making no change at all (this can be verified using subtract). It also means that if one dimension can be reached via exclusively resizing by integers, this dimension can be point-resized to directly and it will then not be adjusted during the LanczosResize. This means that the original resolution MKV encode will not be processed at all, and the AR-corrected MP4 encode will only have one destination dimension adjusted (and in cases where the source width is less than half of the destination width, this will produce a clear result than simply Lanczos resizing, due to having being Point resized first). This effectively means that the resize method is both automatic, has consistent pixel sizes and is universal across all encode types. Plus, due to only performing the required resizes, if a dimension happens to align via an integer multiple, it benefits from the sharpness and clarity of a point resize and processing time is reduced appropriately. Hopefully something there proves useful, it's nice to have something automatic for things like this. I'd also recommend briefly testing it before proper use (just to be safe), as whilst I've used this idea extensively, I still don't have PC access and this has been transcribed from memory and a screenshot I had on a mobile device. This is also a good time to announce that I'm taking bets on what Youtube will do next. 3:1 odds, will they break 1440p or will they fix either 5K/8K? Who knows!
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
In addition to the encodes available on the publication page, here is an extra downloadable encode for this run: Lossless: Direct Link | Torrent 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.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
I should have known not to let curiosity get the better of me.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Spikestuff wrote:
8k is working again on TVC.
This doesn't appear to be definitive yet. I tried the upload once more and the video is outright unavailable. The same goes for the one I previously uploaded, which had processed to 360p. It could be that this is the processing screen for them finally handling the 8K uploads properly but I'm not holding my breath.
I'm not as active as I once was, but I can be reached here if I should be needed.
Post subject: Re: Shadow Man
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
WMJ wrote:
For some reason loading screens are a bit longer on emulator so on a real n64 it should be sub 31 minutes.
What graphics plugin did you use? I honestly doubt it's the cause, but there are a few fringe cases where some of the older plugins cause issues regarding loading times or transition times to (or between) menu screens.
WMJ wrote:
I started from a save state on the title screen because I wanted to turn the sfx volume a bit down as it's so loud in certain parts that it causes clipping (when loading the gun for example which happens frequently). Not sure if it can be submitted here but I am anyway happy with the result and had a lot of fun making this run. I'll have to look into the regulations for submitting it.
For this particular question, you might want to try the ask a judge thread. I'm a publisher and don't have much to do with the judging process, so what I think doesn't matter all that much on that front, but I do handle a lot when it comes to presentation. To me, if there's an in-game setting that doesn't affect gameplay and can prevent an intrusive artifact from being present in the final product, I'm all for it being set to the appropriate setting. You later mentioned that it would cause you to lose frames though, so I'm honestly not sure where this would stand. Testing could always be done to see if the clipping can be removed some other way, but I've ran into a bit of computer trouble lately which makes such a test difficult. I would recommend working this out before starting your second run though, as I'd like to see this run improved and submitted!
grassini wrote:
it is allowed to set option to make the run more enjoyable, the doom run does it cause the game is super dark
Correct me if I'm wrong, but I don't think that option affected gameplay at all. Another example like Doom 64 would be the Wolfenstein 3D games, where the screen size was maximized in the menu in the run prior to starting the episode for a better viewing experience, but again, the only frames these options cost were the frames it took to set them. I don't think they had any actual gameplay implications and so it's tough to use them as direct precedent. That being said, these things were done for entertainment and speed / entertainment tradeoffs are common in many runs. It's definitely something to look in to, audio clipping is not a pleasant thing to repeatedly have to hear.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
I tried uploading to TVC and it got stuck on the 360p & Invalid 720p streams again, despite my success on my personal channel. I'm currently not sure if the "broken" step is now a normal milestone in processing (and perhaps it will still succeed in a few days time), or if it's broken again, channel specific, or just fickle like before.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
I did a few tests on my personal Youtube account and although they all briefly stopped at 360p and said they were done, a refresh some time later revealed that they all successfully processed to 8K. It looks like this may have finally been resolved.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
For whoever takes this for publication (as I'll be unable to), it syncs fine with GLideN64 (though I'd strongly recommend updating the plugin first to get some of the visuals right). I briefly updated the GLideN64 dumping information for Bizhawk as well.
I'm not as active as I once was, but I can be reached here if I should be needed.
Post subject: Added some links
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Mihoru, please be very careful and pay close attention to what Spikestuff is telling you, and to what judges have told you before now. You've already got a run published on the site, so we know you're capable of making runs which meet our well-published standards. I'd really like to see you improve your TASing skills and get more of your runs published in the future, but right now you're in danger of having your submission privileges revoked. Please don't be disheartened though. As Spikestuff said, if English isn't your preferred language we might be able to find someone who can help translate the rules and discussion for you. If you're having difficulty understanding or interpreting the rules, we can help with that too. You're welcome to ask as many questions as you want here. The community and staff are all really friendly and we're all here to help, but this requires communication from you as well.
I'm not as active as I once was, but I can be reached here if I should be needed.
Post subject: Re: I got it
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
MagikGimp wrote:
I had the wrong MVS Japan dipswitch setting (there are four of them). Version 6 is what's needed for that game.
I'm glad you had some success. Sometimes it's a bit of trial an error and there's no harm in some experimentation. With the more difficult cases, other users may have also had trouble and so it's always worth reading through the discussion thread in case a solution has been posted. If not (and you've exhausted reasonable options), it certainly can't hurt to ask for assistance there.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Sometimes the settings which can cause desyncs can be unexpected. It could even be a setting that isn't mentioned (as it may have been the default at the time). Off the top of my head as a relevant example perhaps, I know there are a few FBA movies that require 44100hz for the audio sample rate, otherwise they desync despite the dumping instructions suggesting use of 48000hz.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Radiant wrote:
I'd say that eleven such options is a bit too much
I know it's not directly related, but I've had a think about this in the past. I feel a drop-down selection containing labelled encodes could be a better solution, with the current MKV and MP4 labels being the default available options. This would also leave the option to have publishers add additional encodes with custom labels should the game require it. Right now, if we add a few extra alternate encodes for these infrequent cases, it becomes hard to distinguish what encodes is what and often leads to confusion on the publication page or links being posted elsewhere, such as in the discussion thread.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
I originally downloaded MP4 when I first came to the site (2010, maybe?) due to not being very familiar with MKV and not understanding the differences beyond file size. Eventually, I did a comparison and looked into the differences (most notably, differences in chroma and scaling), and I've never used the MP4 option again. I've also never used in-site streaming, it's always been externally via Youtube, or by downloading one of the encodes. For the past 5-6 years, I typically make my own quick dumps and watch them, occasionally watching in emulator if it's a short run or if I want to investigate a particular segment more thoroughly. This happened because there was typically no "best" encode available in my eyes. MKV: The CRF here leaves the quality too low. Noticeable visual artifacts often hinder the experience significantly for me, though I do know I'm more sensitive to this than other people (the same goes for aliasing in 3D games). The other downside is that for 3D games which were rendered in higher resolutions for Youtube are typically only available in the native resolution here. The benefits here are that the game's frame rate is kept in-tact, duplicate frames are removed, the chroma's resolution isn't reduced and VFR is supported. This all makes for a reasonably good viewing experience. MP4: This has the same CRF and 3D resolution pitfall as MKV, but with a lot less of the benefits. Duplicate frames are left in and the chroma is reduced to 4:2:0 (half vertical and half horizontal resolution, for anyone unsure). This means that colors appear smeared across pixels in 2D games where sprites are pixel-specific. The good side is definitely compatibility here, though I've never had trouble (on any device) playing the MKV encode. The labeling of these two can be a bit confusing to new users though, so perhaps something like "MKV HQ Standard" and "MP4 LQ Legacy" would be a better distinction. Youtube: Definitely the most convenient of the options. If I want to quickly watch a run, this is where I go to. The major downside in the past was the 30fps limitation, but now that it's no longer a problem Youtube has become significantly more relevant to me. Choice of resolution and convenience are definitely the high points here. The negative side concerns that there's no "native" resolution option for 2D games (and even if there were, it would be horribly encoded, blurred via resize and chroma subsampled) and FPS limitations. A 60fps cap isn't very intrusive, but for non-standard rates in games, there's a lot of duplication or dropping of frames. As an example, for a ~70fps game that lags every second frame, the only option to avoid frame drops is 60fps, which also leads to a motion inconsistency. Though, because Youtube is using 60fps as opposed to 30fps, this is not very noticeable (and probably a negligible point). Alright, so that was longer than I expected, sorry for submitting an essay on this one. For me, there are just pros and cons to each viewing method and so I find the best way to avoid these pitfalls is to watch in an emulator or dump the game myself. This is also the reason I try to always provided a collection of extra downloadables on my publications. It's originally based on what I personally would want to see. Edit: I also don't use torrent here. Archive downloadables are resumeable and I prefer direct links.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Upload it to a an image-hosting site and post the link.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
I've never run in to this with FCEUX, but it sounds like some kind of external overlay. My first suspicion would be that it could be the Windows Game Bar: If not, could you please post a screenshot of the offending icons?
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
creaothceann wrote:
Wouldn't that be up the container?
I believe so, and MKV should have no issues with VP9.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Habreno wrote:
Thank you for your work.
You're very welcome! :D
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
In addition to the encodes available on the publication page, here are some extra downloadable encodes for this run: Lossless encodes: Native*: Direct Link | Torrent Additional resolutions**: 720p: Direct Link | Torrent 1080p: Direct Link | Torrent * Encodes marked with a single asterisk are done at native resolution with no graphical enhancements (such as anti-aliasing or anisotropic filtering). ** Encodes marked with a double asterisk are done at enhanced resolutions with graphical enhancements (such as anti-aliasing or anisotropic filtering). This introduces some minor visual problems related to light rays and the mini-map, which is why they were not used for the actual publication. These encodes are provided here instead, for people who don't mind those problems and who would prefer to watch the run with increased resolution. 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.
Post subject: qMakeTorrent discussion
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Currently, there's no clear specification for torrents creation in the Publication Manual. Whilst I've used qBitTorrent as my default client for several years, I switched from uTorrent to qMakeTorrent when my computer crashed recently (on an old recommendation from Fog that I had forgotten about) and have had a very good experience. It's quick, simple and doesn't come with ads bundled in (a problem I always had with uTorrent). I think it'd be nice to include it in the publication guide (and potentially in the encoding package), especially considering it's default prompts require minimal changes to follow our current scheme. This thread also might be a good place to investigate and discuss CLI torrent creation from the batch itself, but I haven't gone that far myself yet. This is more of a post so I don't forget to actually suggest my suggestion.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Don't worry about it! I was just unsure if there was a specific problem with GLideN64 that required usage of Glide64mk2 instead, and if so, I was going to attempt to resolve that problem for the future. Whilst GLideN64 probably should have been used, the naming scheme is somewhat misleading and so text was recently added to the N64 plugin selection, encouraging GLideN64's use. Glide64mk2 is definitely the second best option though, and has the best chance of syncing up with GLideN64. I went ahead and tried this out right away (on Bizhawk 2.3.1) and didn't have any problems reaching completion of the movie, so there's no reason to beat yourself up over it. Do please try use GLideN64 in the future though (if your system supports it), as these things don't always go as well as this one did. As for the run itself, I've finally finished watching it and have voted yes. Nice improvement over the existing run. Great work!
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Why did you use Glide64mk2 over GLideN64?
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Youtube have opened up two support items related to the problem, both stating to check back for updates on the issue(s): Slow video processing times after creators upload a video Video processing stuck at 0% Edit: Both issues have apparently been resolved now, though a test will need to be to see if they have really been resolved. Spikestuff is all over this already.
I'm not as active as I once was, but I can be reached here if I should be needed.
Post subject: Re: YouTube's a buggy mess, but we knew that already.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Spikestuff wrote:
And for the one that only affects me (unless someone does the same thing I do)
...Uh-oh. So from what feos has told me and from what I can see here, I take it that means my recently uploaded 8K Twilight Princess encode is going to stay broken? Is there any current benefit to re-uploading it or is it just going to break no matter what?
I'm not as active as I once was, but I can be reached here if I should be needed.
1 2
12 13