You choose a particular emulation speed, and the next person simply chooses a speed that's higher and beats your run, even if the input is otherwise identical. [...] And, on top of that, to the viewer there's absolutely nothing to see, because ostensibly a DOS game from the mid-80's can probably be completed in a second in a PC running at 100GHz, if that's the speed you choose.
Even if a more modern DOS game did take into account differences in speed of the hardware and future-proofed itself, it may still be possible that with some speeds and/or some combinations of hardware it will exhibit glitches that it doesn't otherwise.
But how can it break something that was implemented since version 1.0?
accurate to hardware
...but that's really ugly.Language: AvisynthAVISource("tuner.avi").AssumeTFF SeparateFields Interleave(last, BlankClip(last)).Weave Crop(34, 41, -36, -55) BilinearResize(Height * 4 / 3, Height)
pleasant to watch
I know it does have a passthrough mode, though I couldnt do this for SNES as i think the elgato hd60 wont accept 240i
...and will process it wrong if it will even see it at all. I know that on some systems the hd60 just shows up a "no signal" so it makes the 480p mode necessary, which in all honesty is one of the sole reason the retrotink exists since many modern stuff and tv's simply cant see, or misread the signal as 480i and interpret it in a weird way.
That's why games for consoles in interlaced mode usually render a full progressive image, and then present it for two fields, getting both the bottom and top.
Actual 240p modes also run at 60fps and in steady scenes using that mode, on a TV you see perfectly steady images.
Probably that's why the interlaced mode wasn't that popular?
...why are they making a big show of Mario's booty definition?
[...] More important that here print is also variable. It's so called global variable. Here it's storing API function provided by environment. So, getting print function is also taking time. Again, more important, that taking here value of print is much slower than taking value of i. Because i here is local variable. Local variables is working faster than global variables, mostly because local variables doesn't have name in runtime, instead of that, they have indexes. And all actions "take local variable value" is just getting value by index, which is fast. On the other hand, global variables are stored in _G table. It's global table for all global variables. And getting some global variable is essentially taking value from table by its name.
NesHawk: 96 FPS bsnes: 113 FPS Vboy: 202 A7800Hawk: 148
