Comment by MenhirMike | Hacker News Reader

Comment by MenhirMike | Hacker News Reader

Parent Full thread

The nice thing about High DPI is that you can re-create the aperture grille/shadow mask of a real TV to get the actual sub-pixel pattern. That requires a high resolution since you need both enough pixels (since every original "pixel" requires 4+ pixels now) and small enough pixels (to make the effect not overly exaggerated - unless you want to emulate a low end TV with gigantic dot pitch). Also, no more "fake" scanlines because the entire mask is fake :)

Also, issues with pixel aspect ratio (8:7 vs 5:4 vs 4:3, square vs rectangular pixels) can be resolved while still being able to scale by exact integers rather than floats.

It's funny, but 4K displays might really be one of the best ways to play retro games nowadays, I'm hoping that upscalers (like the Retrotink 4K, or maybe future OSSC upgrades) will bring some of the stuff we've been doing in emulators to real hardware as well (though yes, that thing will cost several hundreds of dollars, so emulation is probably going to stay the preferred option for many).

Now we just have to solve losing the sync signal for games that switch between 240p and 480i during gameplay, or that don't have an exact 60 Hz refresh rate - Variable Refresh Rate displays are actually a real opportunity here as well. Oh, and find a way to all of that without introducing any display processing latency.

So it takes a 14" 4:3 4k resolution OLED display (does such a thing even exist?) and a top-of-the-line GPU to emulate a 30+ year old 14" CRT monitor?

And even then it's probably still not perfect since you're sending to a framebuffer instead of controlling the beam directly, which adds at minimum 1 frame of latency. (Unless there is a "real-time" way to send a picture over HDMI)

Super Mario World and many other SNES (and later) games spends two frames after a controller jump input sending unchanged frames on-screen, before showing a frame where the player is jumping (tested in slow-motion camera). Emulators (and possibly FPGAs) can use run-ahead to skip past one or more of these "no change" frames, reducing input latency to match or surpass console latency (https://github.com/higan-emu/emulation-articles/tree/master/...).

Another strategy is to delay polling input computing the next frame until the end of the previous frame being drawn (RetroArch frame delay). This does not rely on the game not responding immediately to controller input, but is more prone to dropping frames if your CPU gets occupied and can't run your emulator for a few milliseconds.

It is possible to compute and display images in near-real-time over HDMI, but this technique is quite niche (https://blurbusters.com/blur-busters-lagless-raster-follower...).

And it still won't work with light gun games, and the motion clarity isn't the yet.

Yeah, Light Gun games are always going to be an issue. Is it the latency (the white dot appearing too late, after the game code already checked), or the brightness that's the issue? I assume the former.

Yeah, it's the latency. For simple ones like the NES, they've managed to add some lag in emulators to get it picked up on modern screens. Not for more advanced ones like on the Playstation/2, Xbox, Dreamcast though.

Sometimes when people complain about a crt being "too dark", what I've found is it's when they have those 100hz/120hz tube lights on, it seems to interfere with them.

Reply on news.ycombinator.com