inadvertently admits in boisterous fashion. In the video he comes off as a hard-headed supreme know-it-all loudmouth whose preferences are fact
Actually I didn't get that impression at all. He states his goals and TASVideos' (and SDA's) goals, and notes that they just not align.
An optimized level-1 TAS (without his extra requirements) would be very interesting to see.
This makes me wonder how well consoles would sync between themselves. They might actually not sync in the long run. Sure, they may work identically in all respects, except perhaps one: Their CPU clocks might not tick exactly at the same rate. If there's even a tiny fraction of a difference in their clockrate, that will probably cause a desync eventually.
According to byuu, real hardware units do differ slightly from each other. Usually that's not a problem, except when you have multiple clock sources (like CPU and APU).
Warp wrote:
(On the other hand, that might not be the case if they sync to the TV's refresh rate. In other words, if they do some work to calculate the next frame, wait for the TV to start vertical retrace, do work to calculate the next frame, and so on. Since the TV is synced to the 50 or 60 Hz mains, that ought to keep all consoles in sync. Or at least this was so in the past.)
No, the console sets the timing (of course roughly within the boundaries of NTSC spec and mains frequency) via the sync pulse. Remember that a TV has to be flexible enough to lock onto any broadcast channel's video signal, with no way to know when a field starts except from the signal itself.
Consoles even twist the signal a bit to achieve a progressive picture, and the resulting number of frame per second is different from the 30 (NTSC b/w) or 30/1.001 (NTSC color) frames per second.
Derakon wrote:
you could theoretically play networked multiplayer games on the original SNES. Each player's input would be read by the device, streamed over the network, and sent to the other player's console via a custom controller.
e.g. 7E0B56 - 7E0000 = 0B56, which is what you use in Bizhawk but can't understand why you need to do this
Because Action Replay cheat devices use the bus value (the number placed into the CPU's address register). The bus is mapped to many devices though: WRAM, cartridge (which can have its own mapping too, e.g. SRAM), PPU (video), APU (audio), ... whereas in BizHawk you access the device's memory directly.
The DS turns off only if you keep the power button pressed. If you press it briefly, it returns to the home screen. (But as said, this might just be the equivalent of a soft reset. I think the game/program that was running is terminated.)
If there are games that are known to crash then it might be easy to find out if the soft reset is handled by the game.
is it possible to reduce the formula or function to a simpler one?
I don't think so. You could put the results into look-up tables, but that wouldn't make it simpler. The
rng1, c = ASL(rng1)
rng2, c = ROL(rng2, c)
part could be rewritten to treat [rng2, rng1] as one 16-bit value etc. but in the end that doesn't make the algorithm shorter either and only introduces the possibility of bugs.
If you end the input when no further input is required to reach the ending, you end up with ridiculous TASes where the game ends minutes after the input has ended, which calls into question how long the TAS actually is.
It's not ridiculous imo; anyway, what happens after the gameplay should not be a consideration for the TAS.
What is the ideal ratio between Rerecords and movie length? Taken over all movies, does it converge on any interesting number? Imagine if it was the golden ratio.
"Rerecords" is the number of times a TASer discards input to try something new. So it only depends on the game and the TASer.
My computer is seemingly unable to operate BizHawk above ~20 fps.
Just FOI, what specs?
Brookman wrote:
BizHawk is much more laggy than SNES9x and just getting through the Capcom screen, start menu and up to the dragon I am already behind SNES9x by 100 frames from lag.
It's not that BizHawk is too slow, it's that SNES9x is too fast. ;)
The Brookman wrote:
The only thing you have to do to enable YT's high-quality mode is to increase the video size to 720 lines or more. So just install x264vfw, load the video dump (which ideally was created with the ZMBV codec) into VirtualDub, add the resize filter, set the compression options in x264vfw (e.g. CRF=20) and encode. Optionally you can compress the audio too.
