Do you even realize how long it would take to make a full TAS of Metroid Prime? You make it sound like a TAS is something that just appears out of nowhere. Are you going to build a house on crappy foundation? I don't think so. It's a HUGE time investment. If you want to see a TAS so bad, do it yourself.
I realize a TAS is a huge time investment, but of course, me not a TASer, I cannot comprehend exactly how much.
I do not have the patience - or currently - skills to make a TAS, so I am not going to do it. I am not going to force anyone to do it. But I am going to encourage someone to do it.
Everything is changing. Software. Hardware. Emulators. Games. And yet, companies keep pushing out new software and hardware, even knowing that it will be obsoleted soon. Yet, even knowing so, they push them out in iterations, iteratively making them better.
I can understand that people are unwilling to commit time to something if they are going to have to undo it later due to changes. I can understand that. I can also understand that unless people are willing to take a risk and making something--anything--things will never become done at all.
I really want people to feel that even if they invest a year in a TAS that is wildly outdated when it comes out, they should feel proud of their investment and the time they've invested in it. They have created a new production that, at the time it was started, took into account the state of the art techniques that existed at that time. Seen from a different perspective, it takes some years from when a new trick enters the pipeline to when it arrives on the other end.
Also, it doesn't need to be a full TAS. A short segment is fine. It doesn't have to use the latest and greatest tricks either. Simply anything at all would be nice.
But let's leave it at that. I don't want to upset anyone, and I don't to force anything upon anyone. I simply want to express my thoughts. That's all. I have uttermost respect for TASers around here and I want it to be mutual.
Save for the fact that you arbitrarily save several minutes from inaccurate load times, as well as changing room/enemy states because of premature loading, and some impossible OoB tricks because loading times are instant?
So?
Different strategies. So what?
You seriously fail to realize how much loading times affect prime games. It changes the run completely.
Try to learn more about the game before arguing about it? <_<
No, I understand completely. I have played the game and I have seen speedruns of it.
Abahbob wrote:
How about you just ask itspersonnal if he wants to make the TAS instead of trying to convince him that being accepted to TASVideos is the most important thing for a TAS to accomplish?
Hey, it's not EVERY battle that you get the HP to 1, that wouldn't be as fast. Actually I think there aren't really many battles where we use that. We basically follow the unassisted route only without all the safe strategies.
From all I've seen, it's basically get mario into peril, boost with peril boosting badges, use power attacks that deals tremendous damage with the boost and kill the bosses in one turn.
*shrug* Guess we'll see how it turns out.
Also, this game is also not only about battles.
Absolutely true, and that is also part of why it still be watchable even if the boss battles become boring.
I fail to see how a "serious" TAS cannot be made. You just have to use different strategies. How is that different from any other run?
All TASes made optimize to run as fast as possible in emulators, DESPITE emulators not being 100% correct. I can apply the same argument here.
Honestly, it is kind of boring when every battle is get mario's hp to 1, avoid attack, then use special attack and kill boss in one turn. No variation, you know? Well, everyone is different, I guess, but I stated my opinion.
It's a shame you've decided to go down this route, but I'll still be happy to see a TAS using this method rather than none at all, so keep up the good work!
It's awesome that we get a TAS of this finally. I just hope it's not another of those "abuse peril" sort of runs where the runner just puts Mario at 1 hp and puts on badges that increase his attack while in peril. They are just two turns massive damage, over. No fun :(
Anyway, good luck and looking forward to more progress.
Do not compare TAS with speedruns! If the TAS looks great it will be published, not because the emulation of the only GC TAS emulator is so bad.
I am inclined to agree with this. Timings are not, and probably never will be, perfect for systems such as this.
Anything is better than nothing. I the result is that it will produce apples and orange which cannot be compared to another, then that's a shame, but it should not stop someone from creating a high-quality work.
arki: I'm trying to be concise but informative. You can call it a documentary, then. That's not a bad term. Also you should wait for a more finished draft with most comments. I have a vision that I'm sure people will be most pleased with.
If you make it into a documentary, then I have no objections ^_^
But it will be no ad. An ad can't be 30-45 minutes long.
Agreed. The draft are documentaries rather than advertisements.
Also agreed on course of action - use some text like "impossible manurers", "superhuman reflexes," etc. Don't drag in history or explain the history of TAS, speedrunning or communities. Use games to show off TAS work. If people are interested, they will seek to know more and that is where you can show history, how TASes are made, etc.
A controller that can replay the button presses you previously entered? Sounds cool. But I doubt it's the right tool to explain to others what a TAS is.
Explaining or demonstrating a subset of what a TAS is goes a long way in explaining what it is. True, savestates, etc are tools used, but they are just that--tools. They do not explain the concept behind a TAS.
But please realize how much longer the beginning of the game is if you don't use superswims at all. If people have to skip through sections, is it really completely entertaining?
Not a problem. It will still be entertaining, if you ask me.
Absolutely, super swimming will remove some redundant and (maybe) boring parts. I'm not arguing that super swimming should not be included. It's a compromise. We get a somewhat inferior TAS because something is added that doesn't add to the entertainment value, but there is still entertainment value left even if you don't use it.
Considering it's so hard to optimize, can we not settle for something less perfect? Something is better than nothing, and perfection comes in iterations.
I'll disagree with this. A TAS isn't about one or two tricks: it's about everything, so if you take away one thing, you still get the rest left.
Beating bosses and dungeons in super human ways are still very entertaining. More so than superswim, I'd argue. Superswimming is cool maybe the first time you see it. Then it's all about sequence breaks.
Anyway, sure, sailing might not be so fun, but who says you can't skip those sections? You don't need to watch it all.
My overall advice is, if you want to avoid the learning curve of C++, or you need to write code for an architecture where no optimized C++ compiler exists, or you want to avoid the long compile times and incomprehensible C++ error messages, you should code in plain C. For all other situations you should use C++.
I disagree. That's just silly. You are advocating a language meant for embedded or otherwise resource constrained systems over modern languages that are meant for rich desktops systems just because of longer compile times and horrible error messages (yes, C++ can have horrible error messages).
C++ also have techniques for reducing compile time. Not something a beginner might want to dive into to solve it right away, of course.
I think it is much better to simply use another high-level language such as C# instead. If you are going C, you will trade compile times and error messages for extreme complexity. That's just silly.
The claim that C++'s generic containers put some performance overhead compared to C is false for most of them.
I don't believe you. Most of these containers have been optimized for performance and is more stable, more secure, have less bugs and are probably faster than equivalent C, because most often, they are hand-rolled, whereas the C++ containers are part of library and hence done by compiler vendors. Yes, sometimes these can be slow or buggy due to compiler vendors writing poor code. It happens. But the same is true for C.
...and the boost ref counting pointers which are now part of the standard are noticeably slower than C pointers and even slower than some garbage collected languages...
Ummm yes, of course they are. You are adding overhead logic wrapped around them, so how they not be slower? But the point is: how much slower are they? If you use them right, it turns out, not so much. An insignificant amount, I'd say. The problems lie in std::weak_ptr and often recursive destruction of the resource they are holding. std::weak_ptr is terribly slow (but often that does not matter) and recursive destruction can cause stack overflow (has happened to me).
But abstraction is always slower. But that's fine, so long as we really don't need that extra speed, and often, we don't.
Smart pointers can be slower than garbage collection, true, but then again, they offer advantages garbage collection can not: deterministic destruction. No sitting on memory or resource longer than necessary.
...and if you do some ugly casts, your code might need RTTI, which reduces performance.
Sure, but such casts are often frowned upon, and they are not so common. If they are, you really should think about your design a little bit more.
That said, though, C++ is so poorly designed that it's embarassing. I love C++, but most of the time I find myself using only object oriented C with a larger standard library, and I constantly have to remind other people not to do what seems to be natural. I honestly think it's impossible for a common programmer to really master C++, there must be at most 10 people who've mastered it, probably all in the standard committee.
Do point out some of these points. What is natural which is bad?
It's true that C++ is very difficult to master, though. This is unfortunate truth but a tradeoff due to the flexibility.
There are a lot of silly details like the difference between "typename" and "class" in template declarations, difference between static functions and functions in an anonymous namespace, using ios::sync_with_stdio() to speed up streams,
Yes, a lot of is to ensure code isn't broken. I think you will see it in "any" language. That's an unfortunate truth that we're just going to have to accept. But that doesn't make it poorly designed.
make_shared() being faster than shared_ptr constructors, etc.
That's because it's not possible to do some optimizations in the shared_ptr's constructor as make_shared can do because it has a bigger picture. That's hardly poor design.
You could argue, then, that we should remove the ability to call the constructor directly and only use make_shared. Sure, that would take care of that nitpick, but it would also break older code and lose flexibility.
* The cascade of constructor calls that may happen when you don't declare them explicit is so ridiculous that one wonders if there's a rational explanation for that stuff (there is, they realized it was a mistake after the first versions, but had to be backwards compatible).
Flexibility and power. It's not silly and it's not ridiculous. It's natural, even. If we have a function that takes a complex number and we supply it with a real number, would you not expect it to work? It's natural in such a way.
Sure, it's also dangerous in some ways, but C++ is a language that does not restrict dangerous features simply because they are dangerous.
* The keyword "register" and, before C++11, "auto" have the exact same meaning as whitespace. However, they are still there to make you confused.
"register" does not have the same meaning as "auto" (even before C++11). But regardless, they exist in C too, so what are you complaining about?
* Names of functions in the STL like fill() and distance() clash with pretty much anything. That means that you have to resort to C-style name conventions or just pepper the code with std:: or "using std::foo;" statements, which is extremely annoying.
Personal opinion. In C, you'd always type of name_of_library_function. How is this different from C++'s name_of_library::function? There is a reason namespaces exist, and if you ignore them, then that's your problem, not the language's.
* Ultimately, even the designers of the language found out that writing namespaces inside deeply nested template functions is annoying, so they made ADL, which has an algorithm so complicated that I've met only one person who understands it (Bjarne Stroustrup, whom I met at one of his talks in Russia). Seriously, not even compiler writers understand it, some time ago I saw code that worked in some compilers and not on others, because the compiler got ADL wrong.
It's necessary due to how operators are created in the language. I do think it could have done better, though, so we could avoid this feature since it can do much Evil™.
I don't think it exists because of the reason you specify.
...and that there'll never be neat IDE features like those of Eclipse for Java.
That's silly. You are right in that it is complex to parse, but that doesn't mean tools will pop up eventually. They are already popping up, and I don't know which things you want exactly.
Anyway, this should not give the impression that I think C++ is a bad language. It has its flaws, like any language, I just rant a little bit because the committee has not learned from its previous mistakes and in C++11 they continue to make the language more needlessly complicated while people still need "idioms" to do basic stuff and fundamental things like concurrent programming are still not implemented.
Oh, I think they've learned something alright. The problem was that they took 13-ish years from the previous full standard (not the minor C++03 standard) to make the next one. Now they're reducing that to 3-4 years and pumping out library updates asynchronously.
But you know, a language is extremely complicated, especially as it gets older. You complain they make mistakes, but can you do better? Can other languages really do better? I'm not so sure.
Idioms exist simply because they simplify things. They exist in all languages. It is not fair to say you need idioms to solve even trivial things. Idioms are what makes and breaks a language. You should learn them.
When coding for Windows only, please explain this, because as far as I know all CRT functions on one level or another maps to the Win32 API. Which means, that you will still end up using it, it just won't be as apparent from the code.
Win32 API is:
- More difficult to use leading to more bugs
- Leads to more security issues being so low-level (eg buffer overflows)
- Inflexible (eg, can't take stateful lambdas as callback functions) which means that the code will be more obscure and uglier
- Difficult to use right, leading to more bugs and longer development time
- Requires manual memory management, requiring you either to fix memory leaks or write wrappers to use the RAII principle
What I dislike most with languages like C# and Java though is that they compile into byte-code instead of actual CPU instructions requiring an extra interpreter / re-compiler layer to exist between the machine and the program in order for it to work, making it slower than it has to be. This is a little less of a problem with C#, but still a problem as it wastes CPU needlessly. While CPU power today isn't as limited as it was before, it's nonetheless slightly limiting the possibilities of your program. But this also depends on what you want to develop after learning the language, because today you will require some really advanced or computation heavy programs to really notice a difference.
Though they will never be as fast as carefully optimized hand code, they are still pretty faster. Dynamic compilation on-the-fly compiles and optimizes the code in the background leads to efficient execution. I would be more worried about handling my resources as you never know when they feel like it's time to garbage collect it. This leads to you not knowing when locks on files are released and possibly also worry about that your program will freeze because the garbage collector must run. It's also an issue that it typically uses too much memory, never releasing memory when it's freed and also keeps the freed memory as a memory pool instead of releasing it to the OS.
Actually, I'd call C++ a pretty bad all-around choice, for much the same reasons ;)
The problem is that you still have to take care of everything yourself, although now you're typically subcontracting the details to various libraries rather than doing it directly; and because C++ gives you so many options, it means that you have to learn all the options to have much of a chance of following someone else's code. I learned C++ back before, say, smart pointers were invented (or at least, had found their way to the textbooks and compilers I used), meaning that I have trouble following anyone else's code that uses them, and they'd likely have similar problems following my old code.
I wouldn't call it bad. It's true that C++ has a higher learning curve, which is one of its disadvantages, but when you get the ball rolling, it becomes easier, so to speak.
When you learn how to put everything together, it becomes as easy as, say, C#. Don't forget that C++ is master of generic, too, so it has advantages no other language has. It's difficult, though, sure. So long as one understands that, I think it's fine.
In general, I prefer languages that are good at one thing, and appropriate for that sort of problem. As such, I feel C is a better language; it's good at something that doesn't come up very often, but it's usually clearly the right language when it does. Languages that try to be good at everything too often end up doing nothing well…
I don't really like languages that are good at one thing, because it means learning so many languages. It means having to use many different environments and compilers, etc. Of course, the reverse is true as you say. Specialized languages tend to be better at what they do.
Anyway, I don't feel like C is a good language. Oftentimes, C++ can do what C does - and better. There are only a few things C can do which C++ cannot, and I think the only one I can think of right now is the initializer syntax from C99. Then there's variable length arrays which has been voted into C++14. But then again, C++ can always use std::vector to get around that.
Even for simple tasks, it should be easy to see that C++'s many advantages makes even simple tasks easier, which is why I definitely would recommend it over C. C is really meant to be a minimalistic language for those exotic embedded systems.
If you badly need to be able to control everything your program does, C is a good choice. But if you're working on a mature platform already (e.g. Windows development), you'll be better off with a language that doesn't force you to do everything yourself.
That depends. C++ is a much better choice than C, where it is possible to use since it allows you full control while remaining a high-end language rivalling Java, C#, etc.
Well, C++ is a pretty good all-around choice anyway since it doesn't restrict you to either high or low-level, is portable, etc.
(Incidentally, if you want to get into Windows development in particular, you probably want to learn C#, which doesn't have much in common with C apart from the name. Too often, though, it seems that developing for Windows in particular isn't actually what you wanted, and you just want a program that anyone can run. In such cases, going for a language that isn't tied to a platform is more worthwhile.)
Yes, for Windows development, C# is a pretty good choice. C++ also works, but is a little trickier (tested with Qt for GUI). Then there's also the Win8 Metro, which works with both C# and C++, though I am inclined to think that maybe C# is a little better in that department as of yet (particularly due to missing await keyword in C++).
Unless you plan to program for limited systems (eg embedded systems) or specific operating systems kernels, there is no point in learning C. In fact, it would only HURT you to learn C.
The way I see it, the movie files, and the encoded video file is all data that belongs to the original author
First yes, second no. You can't just take some videogame footage and claim copyright on it.
You can claim copyright on the actual creation, eg the movie, not the contents of the movie. This is how I interpret it, because if you create something, you are the author. That would mean the file in itself would be copyrighted, no?
Probably required:
-all crystal stars (can see arguments either way on this one)
They are collectibles, and they are all unique, so if you are going to collect all star pieces and upgrades, I can see this making sense...
-all sidequests/bosses (they don't technically make you stronger to do unless they give you a unique item or ability)
In a typical RPG, I could see it making a lot of sense. In this type of game, I don't really know. Still, it's fun, so I'd argue yes.
-all badges (unlike in paper mario, many badges can be accumulated multiple times. so when do you have to stop? 1 or more of every unique badge? enough of each badge type to fill 99 bp?)
Usually you only require at least one of each unique item, so one of each badge should be sufficient.
I might be overlooking something here, movie studio been recording movie in framerate lower then 30 for ages, just a handfull of movie decided to bump it to something like 48 fps (the hobbit is one). DVD standard have been set for a while (and compatibility force them to keep it)
https://en.wikipedia.org/wiki/DVD-Video
Yes, the MOVIE industry does that. Doesn't necessarily mean consumer electronics do.
If you record using a DVD Recorder box (we are talking on the fly here), they have to follow the standard so the movie can be played back on other DVD players.
The only standard that exists AFAIK is the compression standard they use, ie MPEG2. While I am not an expert on the details in the dvd format, I don't think it's limited to 24 fps.
Besides that, I do believe dvd recorders have different options and stuff that may make them incompatible with other players. In this meaning, I think dvd means that it uses dvd as a medium, not that it creates movies that other players may play back (although they probably often can).
HD only means high resolution, blu-ray movies are encoded at 24 fps.
Yes, the term HD refers to resolution, but the standards used for HD is often 720p30, 1080i60 and recently, 1080p60. TV stations tend to broadcast using this. Movies are still 24 fps, though.
I might be totally wrong on this, but I wouldn't count on it. Pal and NTSC don't mean anything here, a movie can be encoded at the 29.97 standard dvd movie fps, and the box can still send the signal at 60 fps to the tv (no clue if it has to, I'm no video signal wizard).
But it does matter. If you don't use the correct standard, the TV cannot interpret it. For older TVs, there was PAL, NTSC and PAL60. That meant 50, 60 and 60 fps, respectively with a little varying resolution. That is the electrical signal the TV could accept. Today is different, though, with TVs being able to accept varying fps, such as 24, 50 and 60, regardless of resolution, all which are popular today.
Because the signal has to be a certain fps, it means that the recorder must change the fps on playback if it isn't the same as the output signal. That means inserted or dropped frames.
DVD recorder/pvrs don't care about source fps (nor do they have any idea what the supposed source fps is). They record at their own fps, set by standards or something. Probably something like 24 fps. They don't add/delete/duplicate, they just take whatever the source is feeding them at that exact point in time and encode it, not caring if that picture is the exact same as the last 3 or completely different.
Not very likely.
We have PAL (50 fps) and NTSC (60 fps) which older consoles output, so that's probably what they record with unless they want to add/drop frames.
For HD, it's a little more complicated, but it's likely to be 30 or 60 fps since those are the most common.