Note that you'll need to match all known TAS records for every course for your TAS to be accepted, so you'll have to perform sufficient optimization to tie or improve these records.
EDIT: I just realized that single track TASes are usually in time trial mode, with no CPUs. So it may be difficult to compare them directly. But there should be no obvious mistakes or omissions of time-saving tricks.
"It would probably mean max coins on every level."
On almost every level you can get an arbitrary amount of coins using various glitches (and not all of them even use cloning). How would that be handled? Stop when you hit 255? 999?
Speaking of episodes, how come on the DOS movies page ( http://tasvideos.org/Movies-DOS-DOOM-Stars-Moons.html ) the Wolfenstein 3D episodes are not in order? I guess we're not sorting TASes for the same game by branch, but rather by some other criteria?
My suggestion would be to have the main TAS be as fast as possible with no tradeoffs, and then have bonus videos for any inhuman but slow routes/segments that you'd like to show off.
The old, 2013 TAS ( http://tasvideos.org/2279M.html ) is in need of a remake, as it is now SLOWER than the RTA WR:
Link to video
Who is brave enough to bear this terrible game? :D
Kinda surprised this game still doesn't have a TAS on tasvideos. There's a TAS on nicovideo (see previous play) and a well optimized RTA WR to go off of. Would be very cool to see!
Dolphin has matured a lot since Soig's NSMB Wii run was published a year ago. Have you thought about trying to improve that one? I'm sure you can learn a lot from it and maybe save some frames with a more stable Dolphin.
Seconding this. Even if the closest you can get is matching Soig's time, you'll have learned a lot about how to optimize NSMB mechanics in the mean time.
Note: It's not that I don't trust you or anything, considering some people experience bugs (example, I don't experience slow down on undo nor crashes) that I don't, but can someone please explain like I'm 5 how come even using bytecode (C# in this case) still somehow has underlying bugs that are OS-dependent? I thought byte code gets rid of that?
Even if the byte code is the same on different OSes, the underlying environment and interpreter that executes the byte code may have differences. In addition, if it ever leads to system calls, the system calls available will not be the same - so that code is inevitably different and so on.
Ah, yes, it is!
So then...
Can you give me some examples of video game enemy behaviors that are not deterministic?
I don't know of an example off the top of my head, but for consoles where two different components are timed in different ways (such as via two different crystals), tiny changes in temperature that cause the relative sync to change could lead to nondeterministic behaviour.
Reading uninitialized memory, as some NES games do (like Final Fantasy 1), can also lead to nondeterministic behaviour. When you power off/on a console, memory is not in a predetermined state.
(Usually when people say 'deterministic' in the context of video game behaviour, they mean 'without even trying to rely on an RNG or anything else that is not visible to the user', though there can be exceptions in the case of simple and easy to manipulate RNG/hidden state like FF1's.)
Link to video
No idea if this is optimal or not. (Surprised that he didn't go into Cool for example.)
I'm not even sure where I should go to find out information about high scoring in PaRappa/Um Jammer Lammy, tbh. Some time I plan on playing through Um Jammer Lammy myself to see what I can figure out, since it seems like a really cool take on the rhythm game genre.
EDIT: Spikestuff pointed out that there are some other PaRappa TASes on nicovideo, I'll just put 'em all here.
Link to videoLink to videoLink to videoLink to videoLink to videoLink to video
'Like the japanese version, you can cancel animations for subweapons. The only way this is done in the run is by activating a subweapon the frame before a character lands from a jump.'
This run IS on the japanese version though, so I think this line needs to be rewritten.