[...] it's about reaching the end as fast as possible by any means possible. This run beats the previous one by around twenty minutes, end of story! [...] The Pokémon Red/Blue run also uses memory corruption and is even shorter than this one! All we see is Red walking out of his house into the hall of fame, yet that run got acclaimed by the community.
any keypress, reset or otherwise, happens mid-frame on the actual console. Emulators just decrease input resolution to screen refresh resolution for convenience. On a real console, you can push a button so fast the console won't register it—that wouldn't happen on the emulator.
As I understand it, resetting the console is an inherently analog process -- you're disrupting power to the device. Of course the device needs power to operate, so when you press the button, it has no choice but to stop what it's doing.
I suppose a reset button could also set an interrupt, in which case the CPU would be obligated to go down a different path than it normally would. I'm fairly sure this isn't how it actually works, but even if it did I don't know if it would make a difference in how the reset is perceived. Possibly the CPU would be allowed to finish its current instruction, but it certainly wouldn't be able to finish the entire frame.
This run left my jaw open, but I can easily see this being the only time I'd really watch this--walk around, set flag, win. I'd hate to see the currently published runs become obsolete by something far less entertaining.
Or if you have a wide screen:Language: luafunction InputToggles() keys = input.get() for name, button in pairs(switches1) do if keys[button.toggle] and not lastkeys[button.toggle] then button.on = not button.on end if button.on then joypad.set(1, button.val) end end for name, button in pairs(switches2) do if keys[button.toggle] and not lastkeys[button.toggle] then button.on = not button.on end if button.on then joypad.set(2, button.val) end end lastkeys = keys end
function InputToggles()
keys = input.get()
for name, button in pairs(switches1) do if keys[button.toggle] and not lastkeys[button.toggle] then button.on = not button.on end; if button.on then joypad.set(1, button.val) end; end
for name, button in pairs(switches2) do if keys[button.toggle] and not lastkeys[button.toggle] then button.on = not button.on end; if button.on then joypad.set(2, button.val) end; end
lastkeys = keys
endI think we need these guides updated: http://tasvideos.org/EncodingGuide/HighDefinition.html http://tasvideos.org/EncodingGuide/HybridEncodeScript.html Now as we have tasblend dated and obsoleted by ng_deblink (partial blending using blinkmask, the dream of early HD encoders), I suggest to replace the former with the latter (I'd even suggest reencoding blended runs).
or, to avoid lossy compression, use WAV XD.
width=320
width=256weeeeeeeeeeee
The resulting video was 13 GB, I used the settings from HD Encoding page, but the resolution I use is 1344p, and I didn't use x2 resize in snes9x. It took about 10 hour to encode, but I can't say exactly as I wasn't at home, so I said what was the time estimated by x264 at the beginning of encoding.
The fact that the underlying game image makes it much harder to read
the viewer is supposed to pause the TAS (and thus stop watching anyway)
It can be read on the video description page, or publication page at TASVideos.
Imagine after resizing to 256x224 and compression
sorry if you were making a serious suggestion, but it seems ridiculously bad IMO
I find that somewhat less than completely unreadable. What's the benefit in trying to stuff as much information on the screen as possible, all at the same time, overlaying the game image? Who wants to read all of that instead of watching?
Encoding HD.
I propose that a generic TASVideos logoset be created
... and mandated.
