So much of the vc vs console discussion has been revolving around the 4f it takes to lock the camera aye?
You can't lock the camera in the castle lobby, and there was a 0x star strategy that required entering parallel universes in the castle lobby, which as a result crashes on a real N64 with no possible workaround.
Any particular reason why at 17:52 (in this video: http://www.youtube.com/watch?v=QDQngaq0O0w ) you don't jump before the ledge and instead fall off it? Wouldn't it be faster?
Well, if you allow for ACE to be used, then literally anything is possible - you could use ACE to write a program in the game that gives you Yoshi whenever you press Select, for example.
So you have to ban ACE to ask if X glitch/interaction is possible or not, because everything is vacuously possible when ACE is allowed.
Does anyone actually know why emulators don't crash when the camera goes OOB?
I think it's because if the camera's position is too large a value, it will overflow an N64, but not a virtual console, because it has more memory and more modern memory management.
Going from a N64 to a VC version of the same game does not change the memory layout or give the game more memory. (This was way, way before console games were designed to be able to handle arbitrary amounts of memory, and no one would ever write a camera's co-ordinate system to have arbitrary sized memory for its numbers, because that is hugely over-engineered. Besides, why would the camera's position overflow if Mario's position is not overflowing?)
I think it's actually to do with exception handling. In general, emulators of games crash on less kinds of invalid instructions/operations than the actual console does, unless coded extremely accurately. Maybe an out of bounds camera causes a floating point exception, or something like that.
I went into this figuring I'd give it a look over for a few minutes, and ended up watching the entire thing through and through. This game puts me in a real good place. The combination of amazing, rhythm game tier music, complex dodging, perfect execution and visual and audio synchronized hypnotic overloads puts me in a REAL good place. Thank you for making this TAS!
Youtube used to have a 1-5 star rating system, and replaced it in favour of the like/dislike system, which was a lot simpler and achieved basically the same intended outcome. Why doesn't tasvideos use a like/dislike, or even just a like, system? (Previously existing ratings could be auto-converted into like/dislike based on whether they're higher than 7 or lower than 5, for example.)
My opinion would be that this should be stated as: hardest difficulty is always publishable/preferred, while any other difficulty is publishable if the audience finds it sufficiently entertaining. This would put difficulty level on the same footing as any of the other category choices besides the default any% / 100% and be less ambiguous. It also means 'easy' difficulty TASes would be rejected/accepted on the grounds of entertainment value, not difficulty level, more in line with other categories.
After reading through this topic, this is the view I agree with the most closely.
Great job, love this game. My favourite was the match against Sakura, where it looked like you were about to die then suddenly win.
This would be a great game for a TAS vs TAS playaround match (probably wait on that until the emulation is better, of course).
