I know about the ootake "fiasco", and to be honest, it, and everything you've been asked about input lag in the past really doesn't matter. (If you've ever bee

I know about the ootake "fiasco", and to be honest, it, and everything you've been asked about input lag in the past really doesn't matter. (If you've ever been in a support job, you'll know this is one of the first things you learn). You implied to a poster in that thread that if he upset you, you would ban him. Now I'm not about to tell you how to run your forum (or write your emulator!), but I don't consider that very reasonable. If you don't want to answer questions about latency, why participate in the first place? Secondly, I really don't mean any disrespect, but your article completely misses the point. Competitive gamers don't care about those types of reasons, and not because they are being obtuse or unreasonable - there exists a healthy overlap between software developers after all. We too have been studying the topic for years. For example, you care about faithful emulation more than anything - we don't. We don't mind playing without the sound, or turning off graphics layers, or even turning off a complete subsystem if it improves latency and maintains a faithful framerate (it's no good if it doesn't slow down when it's supposed to - see Cave Shmups - or if it runs too fast - see SF2:HF). We often have different emulators for different games simply because one handles a certain case better than another. We'll use emulators like Shmupmame that use tricks to make the input lag closer to what it's like on the arcade cab. And we certainly don't think in terms of milliseconds (and of course we understand the issues mentioned in your article...). We only think in terms of frames and everything around that. What is the FPS? How often does the game loop run? Once/multiple times every frame? How often is the game state rendered? Can the emulator process everything before the game's internal loop ends? What about if I use tricks like running @ 144hz? What about if we alter the input handler so that it disregards every but player 1's inputs, or "impossible" combinations, or buttons that don't exist in that game? Etc etc etc. And of course we're no stranger to resistance from emulator developers. That's why so many forks exist. I myself have got my own forks of Mame. And, as with everything else, sometimes we are wrong. Sometimes the devs are wrong (recently: see Hunter K's discovery that shaders can in fact introduce latency, like players have been claiming for years). Often both parties are wrong and everyone learns something new. That's just the way it goes. My point is that many of the people you interact with actually do know what they are talking about. They might not know the minutiae about the inner workings of Higan, but often this is exactly why they post on your board, as evidenced by the thread you locked. And in terms of your article, you skip the known methods already used by developers (and hackers), and you don't offer anything else besides something else we already know - getting as close to the bare metal as possible. Is there really anything that you added to the conversation, besides describing how Higan works? Don't get me wrong, it's a useful for someone who doesn't know anything about the topic. But for everyone else? That's debatable. It's completely understandable that you are tired of the subject. But in that case you should just not respond instead of alienating yourself from your users. People will figure it out eventually, or just do what they've been doing for years - use the method that works for them even though they don't fully understand it.