That's the cold harsh truth. Youtube seems to screw up the quality of anything < 720p. I don't like it either. I think all sources should be treated fairly regardless of resolution because resolution does not imply "quality." But apparently google doesn't think so.
Youtube transcodes your uploads. The original file is gone. Saving every 1GB-100GB source does not seem economically feasible.
Sure. I figure as much, but as some have said, apparently some have been able to retroactively make 30 fps sources into 60 fps sources. I can't reproduce that behavior. Uploading new files in 60 fps works, though.
Someone had also said(on reddit gopro post) that if you uploaded 60fps in the past you can go in "edit enhancement" and youtube will go in and switch it to 60fps instead you having to reupload again.
No problems there. Could be related to HTML5 vs Flash, though. I don't use HTML5 because frankly HTML5 video in browsers just suck (flash is so much better, and yet flash is so much worse than desktop players).
TASes have always had unrestricted fps, just not on youtube (downloadable), so this doesn't really change much. Youtube still compresses videos too heavily.
Yeah, but a computer doesn't care about different sectors. It only cares about the information. So it would be natural for an ISO not to store a lot of information about discs such as where exactly on the disc such data is located.
I don't know if a binary 1:1 copy might contain such info, though.
You'd need information about what data lies "where" on a disc to use that kind of emulation. As far as I know, ISOs do not store this kind of information. I don't know if there are other other disc formats out there that do.
I agree that if it's for publication, it should close to as perfect as possible, but that's a long ways off still.
First comes the suboptimal practice runs. Encourage! Encourage! Help build!
Everything must start from something. You can't expect a fully-optimized TAS of a complicated game out of the bat. So what if it will be inferior? Great runs are made iteratively. If a semi-optimized run was done first, the TASers would learn a lot of things, such as how the game works, how the emulator works, quirks, etc. That would translate into experience that the TASers could then use to improve the TAS in subsequent runs and even help them to better understand how the techniques are done and how to properly implement them in the TAS.
Then comes the stage of improving the product even more. A super-optimized speedrun of Metroid Prime did not come in one night. It has come this far after years of iterating improving of old runs. Give the TASers a chance. If they post a WIP, be supportive and help point out things that could be done better. Don't discourage them from not trying at all because then we will NEVER see a TAS.
All speedruns begin with a practice run. Is a practice TAS really so bad?
Do I want to sell our personal assets to fund our trip? No, not at all. Would I do it if I had no other choice, knowing that going means a difference in how much we stand to raise? Absolutely.
Well, that depends on whether or not someone else could help. But anyway, I just don't want you to feel pressed to have to attend there. But I can see where you're coming from.
I don't think there's need for that. I don't think anybody would blame you for not going if you simply can't afford it.
I'm going to agree with that. You shouldn't feel that you absolutely NEED to come to AGDQ. The world will still turn even if you don't show up. It feels kind of horrible that you would sacrifice something you hold dear just to show up. So think of your own happiness - not just others!
Warp wrote:
(As for any unused or extra money, the most logical place to put it would to donate it to the marathon as normal. I don't even know why that would be a dilemma...)
I believe the dilemma not the 10% of the donated travel money that would be donated to the charity.
I think a 100% abc run would be technically interesting but very hard to make. Also some TASes have special encodes but it is always in addition to the standard encode, but the file size for the encode wouldn't be insanely huge because those 11 hours are very repetitive so it should compress decently well.
Well, that would depend on the compression settings and how "repetitive" it is (i.e. how far apart it is repeat in the temporal plane). I would remain skeptical that it is easily compressible.
I find it pretty silly not being able to accept emulation that is not perfect. No emulation will ever be perfect, but that has not stopped the community from producing TASes. Load time emulation will never be perfect, and by that attitude, there will never be a TAS made because of that.
Just my take on the whole, anyway...
Problem is that when you start working with basic libraries (i.e. networking), you're going to run into async tasks. Async tasks are also present in Microsoft's C++/CX. Simply put, it's becoming more and more common, and as such, it is a good idea to learn how to do it.
But the thing is that async tasks really forces the complexity of memory management to surface. I agree, if you're just doing hobby programs without threads and async tasks, you're not going to run into much problems managing lifetime, but you are going to have to think about what to share between data structures.
It's a necessary evil for now.
Remember that all languages have quirks. In garbage collected languages, you have to more mindful of when objects destruct since that can release critical resources such as file handles, etc. I'd see it as a challenge.
Well, yes, that's true, but you're going to get there, eventually. Async tasks and threads are all the rage right now. This is just a detail of C++'s memory management complexities. If you're just doing very small toy programs, you won't encounter much of the complexity of any language.
Nope. Not necessary.
Just put a local variable on the stack, capture it in a lambda that you pass to a thread. Now you have to worry about the lifetime of the local variable.
Is the lifetime of the local function going to outlive the lifetime of the thread? If so, a local variable is fine. You can even capture by reference. It is the reverse? Now you have to worry about it. If you capture by value you have to consider if the variable CAN be copied, if it's expensive to copy and if the local function needs state from the variable. If you can't capture by value, you have to consider allocating on the heap. Then you have to be wary of capturing it right. Capturing it by reference is bug. But also by allocating on the heap, you have to consider the overhead of heap allocation.
The biggest challenge with C++ is getting memory management right.
A lot more goes into the design and testing to get memory management right than other languages. You have to consider object lifetimes and ensuring no cycles. Then you also have to consider sharing data between different threads, async tasks and data structures.
Ensuring object lifetimes does not mean remembering to free what you allocate, but rather that your objects do not disappear before you are done with them. This is typical when you use threads and async tasks, because you have to carefully consider some things.
First, when you use threads or async tasks, you have to consider - do these tasks need some variables from the enclosing scope? If they do, then which ones? And then you have to consider how to share this data. Can you get away with simply copying the data to the tasks? That's the easier solution since you don't have to manage lifetimes or access (i.e. locks, etc).
Otherwise you have to consider if the tasks will outlive the scope of the parent function. If it doesn't, you can just create references to these variables because you can guarantee that they won't be destroyed before the tasks end (because the parent function won't end before the tasks do). If the parent function can end before the tasks, then you have to consider sharing the data through shared pointers. But that gives you the fallacy that you must remember to copy them properly. Creating references to shared pointers is a big no-no.
So you have to be mindful of:
- Do tasks in your function require variables from the enclosing scope?
- Do the tasks end before the parent function?
- Did you properly capture the variables from the enclosing scope?
To make things a little more complicated, you have to consider what can be copied and what can be moved. Some things, like file streams, can only be moved because it usually makes "little sense" to copy a file stream. When you put such an object into a data structure, that structure becomes move-only, and you have to reflect this in your code. Moving local variables can also result in putting moved-from variables into undefined states, which makes you responsible for not using them afterwards. Additional complications arise when you need to capture move-only variables into tasks.
Then you have to consider sharing between data structures. Usually we copy objects because it's easier and more cache friendly. But if you need some data to be up-to-date in several data structures, you need to share that data. Then you have to consider at what granularity you want to share the data. Share absolutely only what is needed or share its parent object, for example. Again, you have to be mindful of the object lifetimes, as copying a shard pointer incorrectly will result in the data it points to being freed prematurely.
Then you also have to consider what happens if you screw up. You considered the sharing, but in reality, there is a bug that causes it not to happen. How do you track it down? How do you detect it? How do you know it's there? How do you know you've correctly managed lifetime scopes of objects?
Finally we have circular references. This occurs in typical structures as linked lists. You have to identify where they may occur and detect that they do not happen because it will leak memory.
It sounds easy to just put a shared pointer in a data structure and be guaranteed it will work, but that's just far from the case. C++ can be scary, but it also gives you a lot of power and speed. If this doesn't frighten you, then you're welcome to study C++. It's not always easy - but then again, the life of a programmer is rarely easy. It's not for the faint of heart, but if you choose to do it anyway, then best of luck to you.