MiSTer FPGA Forum

Even if it was accurate at the transistor level it still would be an emulator as it is not the real thing and also it is contained in one chip, not a gazillion.

aberu wrote: ↑Wed Apr 07, 2021 2:45 pm

ExCyber wrote: ↑Wed Apr 07, 2021 2:46 am

aberu wrote: ↑Tue Apr 06, 2021 2:19 pm

MAME for what? Plenty of console drivers in MAME are pretty terrible when compared to Mednafen/bsnes/BlastEm!/etc... As always, the correct answer is "it depends".

I think the key word there is "official", i.e. actively-maintained upstream as opposed to some fork-of-a-fork that is missing years' worth of fixes and enhancements. A surprising number of people still run some variant of MAME 0.78, a version of MAME that's now older than most of its supported games were when it came out.

Yes, officially, current MAME is pretty bad on numerous console drivers. Mednafen has a far superior Saturn emulator, PC-Engine Emulator, etc...

My point was to focus on "official" rather than "MAME" (although MAME is by far the emulator most plagued by purportedly superior forks). Without a specific reason, it's also a good idea to default to using upstream Mednafen rather than "Beetle", for example. There are emulators for which this isn't as true because upstream development pauses or halts, but the typical pattern is that forks start out exciting and then quickly fall behind.

The same principle applies to MiSTer cores as well: you should be using the latest official release unless you have a specific reason to use a fork, and do so with the understanding that it would be very silly to badmouth MiSTer when you run into problems with Super MiSTer 2 Turbo Rainbow Edition (now with Speed Holes). And I say that as someone who has posted multiple unofficial .rbf files.

ExCyber wrote: ↑Wed Apr 07, 2021 2:46 am My point was to focus on "official" rather than "MAME" (although MAME is by far the emulator most plagued by purportedly superior forks). Without a specific reason, it's also a good idea to default to using upstream Mednafen rather than "Beetle", for example. There are emulators for which this isn't as true because upstream development pauses or halts, but the typical pattern is that forks start out exciting and then quickly fall behind.

The same principle applies to MiSTer cores as well: you should be using the latest official release unless you have a specific reason to use a fork, and do so with the understanding that it would be very silly to badmouth MiSTer when you run into problems with Super MiSTer 2 Turbo Rainbow Edition (now with Speed Holes). And I say that as someone who has posted multiple unofficial .rbf files.

I don't think I understand what you mean by the word official here. I'm not talking about a fork of MAME. I'm talking about MAME, IE official MAME. MAME's current drivers are not always forks of other emulators either, they are often their own emulators which use components from other emulators sometimes, but rewritten.

Yes Mednafen is better than the libretro "Beetle" fork (see FF7 Reverb issue recently fixed for instance). I don't get what relevance this has to do with anything though, I'm kinda confused.

Let's break it down again as a recap:

1. Someone claimed that people should just stick to MAME.

2. I replied "MAME for what?" because MAME is good at some things, but not good at all things, in fact it's pretty terrible at console emulation (usually), so their answer was incomplete at best.

3. You introduced the word "official" and talked about people using MAME 0.78 as an example of why they may have a bad experience. That was irrelevant because people can use MAME 0.228 and have a bad experience. It depends on the core. you talked about the upstream, but if the MAME driver I'm referring to isn't a fork of Mednafen/etc..., then bringing up the upstream is again, irrelevant.

4. I reiterated that MAME is pretty bad on console drivers, because I recognized (from my perspective) that your point was irrelevant and was trying to keep it on track with what I was saying.

5. You talked about upstreams again, presupposing that all bad MAME drivers for consoles are just forks, which they are not.

So hopefully you can see why I'm confused

aberu wrote: ↑Thu Apr 08, 2021 3:21 pm So hopefully you can see why I'm confused

I think there's one main disconnect that has us talking past each other:

The post you replied to recommended to "stick to the official MAME". You replied to that as though it just said "stick with MAME", and I was trying to make the point that the "official" part is important (not just with respect to MAME, but for how people perceive emulators in general). I wasn't making a point about the quality of MAME's console drivers at all.

aberu wrote: ↑Sun Apr 04, 2021 1:15 am

MottZilla wrote: ↑Sat Apr 03, 2021 11:43 pm But I think a lot of the dislike of software emulators comes from general inaccuracy related issues and some widely used bad emulator setups like RetroPie/RetroArch. Back in the 90s and early 2000s I played lots of games on DOS and Win9X emulators and did not experience issues like horrible input lag. Even today playing MAME on a modern PC seems to work just fine for me and not have any issues with input lag.

Your memory is probably off then Software emulators all have significant lag when compared to original hardware and something like the MiSTer. The overhead from the emulator running on an OS, the framebuffer of whatever GPU your PC is using, the issue of vsync. I know I know, run-ahead is a thing now, but run-ahead is buggy. I know, I know, groovymame is a thing now, but you literally have to hunt down older graphics cards just to make it work

There is often an extra frame or two of lag or more just from the OS+GPU framebuffer+the fact that the emulator itself has to have some buffering to display right with vsync. The way the MiSTer draws the image directly from the FPGA is cutting out a lot of that lag.

Download bsnes, run it on your modern windows pc, and do the 240p test suite input lag test, and compare to your MiSTer snes core

I think you skipped by part of what I said. I'm talking about emulators for DOS and Windows 9X. I don't believe there were anywhere near the amount issues with input lag back then. I do remember playing games on emulators quite a lot back then and it wasn't an issue as far as I recall. I'm not talking about far more modern operating systems and computer setups in general. While I did mention using MAME on my modern PC, that is about the extent of actually playing games on an emulator for enjoyment that I do. I certainly prefer to use original systems or the FPGA recreations where possible.

I think RetroArch and Retropie are a big reason people are aware of the input latency and related issues. As I said I rarely use emulators for playing games but when I saw RetroPie in an Arcade1Up cabinet mod, the input lag was so noticeable and really quite terrible. And it seems like lots of people do similar mods and I wonder how anyone can stand it. I would not want to play a game with that much latency.

chanunnaki wrote: ↑Sat Apr 03, 2021 7:57 pm I'm also not sure there is value to emulation anymore either.

Preservation. Like it or not, MiSTer has made such explosive progress in large part because of the software emulation and preservation efforts of the thousands of projects that came before it.

Software emulation will never go away. FPGA is absolutely a game changer, and has an enormous array of positives. But software emulation absolutely has its place, particularly in the preservation world.

MILLIONS of people play old games in their browser via archive.org's in browser emulation, which is the midden equivalent of a public library. Ditto for the people buying commercially emulated games from Steam, GOG, and on consoles. I will never sit here and tell you software emulation is perfect, but it remains incredibly accessible for so many people. And at some point, keeping the memory of old games alive is just as important, because without that, they're forgotten and lost.

All of this is why I'm so incredibly grateful for every emulation author, every emulator, every preservation effort, and every "pirate", old or new. New methods bring massive improvements, but they don't nullify but invalidate the need for existing methods. These things can, and should, coexist in harmony, and we don't need to form tribes to war over what's better and what's worse, when we could instead spend that time celebrating all of them and the games that they enable us to play.

MottZilla wrote: ↑Sun May 30, 2021 12:25 am I think you skipped by part of what I said. I'm talking about emulators for DOS and Windows 9X. I don't believe there were anywhere near the amount issues with input lag back then.

I don't think it's your imagination. Emulators from that time could actually change the video mode and control flip timing through direct register writes or via APIs like DirectDraw. Some of these APIs still exist, but are now more-or-less emulated themselves, so they don't offer the kind of control that they once did.

It wasn't DirectDraw. DOS was by far and away the proper environment in those days because of direct register-level access to the video cards, but the challenge was in supporting all the different cards with all their variations of what "Super VGA" was supposed to be. ModeX was fine, but ultimately undocumented, so it was something you could use but not trust.

MottZilla wrote: ↑Sun May 30, 2021 12:25 am I think you skipped by part of what I said. I'm talking about emulators for DOS and Windows 9X. I don't believe there were anywhere near the amount issues with input lag back then. I do remember playing games on emulators quite a lot back then and it wasn't an issue as far as I recall. I'm not talking about far more modern operating systems and computer setups in general. While I did mention using MAME on my modern PC, that is about the extent of actually playing games on an emulator for enjoyment that I do. I certainly prefer to use original systems or the FPGA recreations where possible.

No, I don't think I skipped it, just didn't explicitly mention it outright. There was lag. You will need to objectively test them though to prove your case. Speedrunning and stuff like that was practically non-existent in the late 90's and early 2000s and people weren't really using emulators for all that until about 2003-2004 and later. So I doubt anyone really tested all of that to that degree back then.

That being said, yes there was probably a difference, but I highly doubt it was noticeable. You might get rid of 1 frame with a DOS emulator vs a Windows 10 emulator. That would be my guess. Feel free to test it though, would be interesting to see the results!

MottZilla wrote: ↑Sun May 30, 2021 12:25 amI think RetroArch and Retropie are a big reason people are aware of the input latency and related issues. As I said I rarely use emulators for playing games but when I saw RetroPie in an Arcade1Up cabinet mod, the input lag was so noticeable and really quite terrible. And it seems like lots of people do similar mods and I wonder how anyone can stand it. I would not want to play a game with that much latency.

RetroArch and Retropie don't really have anything to do with this, they may introduce some extra lag if you have misconfigured the settings, sure, but the inherent problem is layers of abstraction between the software emulator and your controller input being far greater than what was on original hardware. As for the Arcade1UP mod... people use goofy HDMI controller boards that might add more lag. The Arcade1Up arcade encoder is also filled with lag, which is part of the problem. I'm watching ETA Prime do it and he also uses those shitty chinese knockoff "zero lag encoder" boards, which are known to have extra lag and also have terrible variable lag. And then... what is the lag on the LCD itself on that system? etc...

So yes, when you add a bunch of variables to the Arcade1UP when combined with a raspberry pi, with misconfiguration, you are going to have lots of variable lag and just lots of minimum lag.

The bigger difference might be that the DOS era was mostly one of CRT displays... an "average" 60hz flat panel isn't impressive in the lag department these days, you generally need a gaming monitor with adaptive sync to even get close.

I understand that a game not working well is off-putting but when I read posts like this, as an emulation author, it seems very entitled and ungrateful to complain about your issue without acknowledging the hard work that people did. Only hearing a complaint about an issue with [insert your favorite game] and why that must mean their work was all for naught -- it just tears people down. I have alternate proposal: Why don't you try to help make it better and/or try to appreciate how far it's come before griping about it. I wasn't happy with the state of Apple emulation a while ago so I went and wrote my own. It's not a necessarily great emulator in every sense, but by participating in the conversation of emulation authorship, I think my contribution was that some features of my emulator inspired others to attempt same-or-better. Now the state-of-art apple emulation provides cycle-accurate video scanning and better ntsc color emulation. Does that mean I take credit for any of it? No. Did my participation help advance things in some capacity? Very possibly, yes. More importantly everyone benefits from it.

If you want the emulator port you're using to improve, just kindly file a bug in the repo where it lives. Be nice. Provide screenshots, logs, whatever helps the author understand the problem. You'd be surprised how quickly of a turn-around you might get sometimes. For example, the GBA core has some rewind bugs fixed recently because of this kind of interaction.

But saying "OMG emulation sucks because I can't play my game" is not going to advance anything forward and only demotivates the people who make these things possible. Have some perspective.

-B

badvision wrote: ↑Sun May 30, 2021 6:56 pm I understand that a game not working well is off-putting but when I read posts like this, as an emulation author, it seems very entitled and ungrateful to complain about your issue without acknowledging the hard work that people did. Only hearing a complaint about an issue with [insert your favorite game] and why that must mean their work was all for naught -- it just tears people down. I have alternate proposal: Why don't you try to help make it better and/or try to appreciate how far it's come before griping about it. I wasn't happy with the state of Apple emulation a while ago so I went and wrote my own. It's not a necessarily great emulator in every sense, but by participating in the conversation of emulation authorship, I think my contribution was that some features of my emulator inspired others to attempt same-or-better. Now the state-of-art apple emulation provides cycle-accurate video scanning and better ntsc color emulation. Does that mean I take credit for any of it? No. Did my participation help advance things in some capacity? Very possibly, yes. More importantly everyone benefits from it.

If you want the emulator port you're using to improve, just kindly file a bug in the repo where it lives. Be nice. Provide screenshots, logs, whatever helps the author understand the problem. You'd be surprised how quickly of a turn-around you might get sometimes. For example, the GBA core has some rewind bugs fixed recently because of this kind of interaction.

But saying "OMG emulation sucks because I can't play my game" is not going to advance anything forward and only demotivates the people who make these things possible. Have some perspective.

-B

actually this kind of collaboration is one of the reasons I love the MiSTer project.. it feels like a true partnership to me, between devs & gamers. many of the intricacies of different cores - only the user will recognize from extended use - so without this input the end product will never be as good as it could be. I wouldn't know where to start to create a core and have major respect for everyone who contributes however massive/small their input.

MiSTer is like the dream console of the 80s kids..For someone who grew up with the snes, nes, amiga, neogeo and arcade of that time, and still enjoy these games far more than the last Call of Doody on PS5, MiSTer is the best gaming investment I ever made. But I cannot say I hate emulation. A lot of work has been done by talented peoples for preserving and dump our beloved old games, it allowed us discover titles we could not afford for whatever reason but also to saves them from disappearing forever.
So yes, we have a better tool to get the job done regarding 80s, 90s retrograming, and it is the MiSTer. its is the greatest retroming project of the decade.
But we may not see a fpga capable of emulating a PS3 before 10 or 20 years. So I ll continue to enjoy and support both. the MiSTer and emulation.

I'll add to what badvision said... Even if you don't have the skills to code your own emulator or contribute code, doing a good job of documenting the issues in a neutral way and showing comparisons to original hardware, etc... can be very helpful. Regular users can contribute to a project as well by editing wiki pages as they discover things, by raising issues for bugs and giving constructive useful feedback/observations. I'm saying this as someone who has just started learning programming in the past year at the age of 36, it's a huge uphill battle.

I think when devs kinda just say "just learn to code or shuttup" (not saying what badvision said is this, but others do say this in varying ways), it's not realistic and it shuts down the potential of useful feedback being provided.

But what badvision said was fine and just needed an addendum in my opinion directed toward people who don't program and don't have any motivation to learn programming.

But just being upset or inflammatory is not helpful. I get it, it's frustrating when something doesn't work right. That doesn't mean you have to take out those frustrations on the person developing something for free as a passion project.

I wish i could learn programing!
But no have been trying many different languages since 1998 and i can learn the absolute basic stuff in no time at all but then i hit a wall.
It´s like i´m 75% dyslexic in programing languages and when trying something over the basic it´s becomes a mess and i can´t even do the basic anymore.

grizzly wrote: ↑Fri Jun 11, 2021 5:45 pm I wish i could learn programing!
But no have been trying many different languages since 1998 and i can learn the absolute basic stuff in no time at all but then i hit a wall.
It´s like i´m 75% dyslexic in programing languages and when trying something over the basic it´s becomes a mess and i can´t even do the basic anymore.

The key is to identify a problem you want to solve and focus on solving that problem with programming. I've learned the most when I want to make a script or program do something specific and I focus heavily on getting it working perfectly.

grizzly wrote: ↑Fri Jun 11, 2021 5:45 pm I wish i could learn programing!
But no have been trying many different languages since 1998 and i can learn the absolute basic stuff in no time at all but then i hit a wall.
It´s like i´m 75% dyslexic in programing languages and when trying something over the basic it´s becomes a mess and i can´t even do the basic anymore.

You cannot go wrong starting with python. There ton of tutorials and fun projects you can do to automatize stuff.
https://automatetheboringstuff.com/
its not only a great language for learning coding, but its also a great tool to get as a professional skill.
I'm working in infosec and cloud stuff and my biggest regret was not starting learning it earlier.

aberu wrote: ↑Fri Jun 11, 2021 1:14 pm I think when devs kinda just say "just learn to code or shuttup" (not saying what badvision said is this, but others do say this in varying ways), it's not realistic and it shuts down the potential of useful feedback being provided.

Well no, I wasn't implying that. Programming is absolutely NOT for everyone. Then again being a good QA tester is not something that every good programmer can even do, but there's a long discussion for another day.

aberu wrote: ↑Fri Jun 11, 2021 1:14 pm But just being upset or inflammatory is not helpful. I get it, it's frustrating when something doesn't work right. That doesn't mean you have to take out those frustrations on the person developing something for free as a passion project.

Yes, absolutely. Programming is not a requirement to enjoy emulation, or any other kind of fun open-source project. But it doesn't cost anything to be nice.

aberu wrote: ↑Sun Apr 04, 2021 1:15 am Your memory is probably off then Software emulators all have significant lag when compared to original hardware and something like the MiSTer. The overhead from the emulator running on an OS, the framebuffer of whatever GPU your PC is using, the issue of vsync. I know I know, run-ahead is a thing now, but run-ahead is buggy. I know, I know, groovymame is a thing now, but you literally have to hunt down older graphics cards just to make it work

There is often an extra frame or two of lag or more just from the OS+GPU framebuffer+the fact that the emulator itself has to have some buffering to display right with vsync. The way the MiSTer draws the image directly from the FPGA is cutting out a lot of that lag.

Download bsnes, run it on your modern windows pc, and do the 240p test suite input lag test, and compare to your MiSTer snes core

When properly developed and configured, no, they don't all have significant lag. This clip demonstrates the fact that even on a PC->CRT configuration, it's possible to get zero latency--i.e., next-frame response. Literally the least possible amount of input lag. You certainly can't do that with every single core, but you can do it with nearly everything 16-bit and earlier. Using RetroArch on my own PC, I get one frame of emulator lag at the absolute most, most of which comes from my display itself. Which means that most of the time, with run-ahead latency reduction, I can beat or match original hardware.

No, run-ahead is not buggy and works flawlessly in any core capable of doing proper save states, which is most of them. You'll get weird things happening if you set it to run higher than the game's internal amount of latency, but that's about the worst of it.

The most inconsistent aspect of emulation is probably sound. Even with a perfect setup, depending on core implementation, you won't get absolutely perfect audio sync, which means you'll get very subtle audio artifacting. Some cores, on the other hand, have perfect audio.

Nearly all of the gripes you mention in your original comment are the result of trying to emulate on a Pi. Yes, if you use the outdated versions of emulators that run playably on a Pi, you're going to have problems. That shouldn't come as a surprise to you. It doesn't impugn software emulation as a whole.

Chopin wrote: ↑Fri Jul 30, 2021 1:51 pm When properly developed and configured, no, they don't all have significant lag. This clip demonstrates the fact that even on a PC->CRT configuration, it's possible to get zero latency--i.e., next-frame response.

Thanks for the reply.

I'll wait for a more proper test demonstration than that video to prove otherwise. The video doesn't compare with original hardware directly, he just says that mario jumps within one frame of lag. There's no test-retest to account for sub-frame variance in lag. He used a "random Displayport to VGA adapter", so there is almost guaranteed more lag than original hardware and analog signals when compared to something like the MiSTer since you still have some video processing lag involved in that signal chain. Did Tyler Loch use a lag tester to do an equipment test on that adapter? There's a reason why someone like Bob from RetroRGB is much more thorough, because he wants to be as sure as possible that his claims are correct, whereas that video doesn't really prove much to me personally.

Also, the CRT connector they are using won't come close to the video output from the MiSTer's Direct Video or analog IO board. There's going to be problems with driving a scaled resolution on a modern display signal out to a CRT like that, no doubt.

Chopin wrote: ↑Fri Jul 30, 2021 1:51 pm No, run-ahead is not buggy and works flawlessly in any core capable of doing proper save states, which is most of them. You'll get weird things happening if you set it to run higher than the game's internal amount of latency, but that's about the worst of it.

Maybe run-ahead has come a long way since I last tried it out seriously.

I remember audio problems in GBA, video problems on the Genesis, inconsistencies between games on the same system sometimes (some would work, others would not), some systems it would only reduce the lag to 3-4 frames from 5-7 frames for instance, etc... Anybody can look up the libretro cores' issues pages and see, I would often find a bug and go see if someone else had reported it and they already did. If I just play any NES game on the NES core on the MiSTer it all just works and I don't have to worry about tweaking the settings to get the latency to work without bugs. It just works. From what I remember of run-ahead the most vivid memory the last time I used it was that Sonic 2 had ghost images of other Sonics popping around occasionally and video stuttering. That was with the recommended settings when I talked to other people who used it.

Not saying you are wrong, but I guess I'd have to go fire up emulators and test them a bunch to figure out if it's significantly better than the last time I used it for any length of time a few years ago. Looking up some test results people had from a year or two ago, they got 7 frames of lag in OutRun and 6 frames of lag in Road Rash II, while there would be supposedly "0" in Terminator (wtf?) and 1 frame of lag in Castlevania - Bloodlines.

Chopin wrote: ↑Fri Jul 30, 2021 1:51 pm The most inconsistent aspect of emulation is probably sound. Even with a perfect setup, depending on core implementation, you won't get absolutely perfect audio sync, which means you'll get very subtle audio artifacting. Some cores, on the other hand, have perfect audio.

100% agree. I'm mostly playing games for the audio anyways, and that's where the FPGA-based emulators shine the most. Blastem (not the libretro core in retroarch, but the standalone emu) syncs on audio and is the most accurate emulator as far as Genesis sound goes so far... except for the FPGA-based emulators of the Genesis. But BlastEm, if synced on audio, is going to obviously video stutter unless you have just the right kind of video configuration.

Chopin wrote: ↑Fri Jul 30, 2021 1:51 pm Nearly all of the gripes you mention in your original comment are the result of trying to emulate on a Pi. Yes, if you use the outdated versions of emulators that run playably on a Pi, you're going to have problems. That shouldn't come as a surprise to you. It doesn't impugn software emulation as a whole.

No. I've barely used raspberry Pi's for emulation at all. I've built them for friends to have in their house casually here and there. The vast majority of the emulators I've used have been software emulators, and I've been using them since the mid 90's. Only in the last 2-3 years have I switched over to FPGA-based emulators and the difference is dramatic. I couldn't stand using a Pi for emulation because it was far worse than running the equivalent emulators (or more often the same but just x86 versions). I tried it out and kinda hated it.

The software emulation experience I'm talking about is using GPGX and BlastEm! as my main Genesis cores in Retroarch, using bsnes standalone, BlastEm! standalone, mednafen for PSX and saturn, etc... on my Windows PC that is much more than capable of handling all of this.

I'm not saying one is objectively better than the other or something, they each have their benefits and drawbacks. Software emulation dominates on the extra features like CRT shaders, the wide range of systems supported, save states, etc... Personally the closest I've gotten to feeling that original feel with original hardware (confirmed by testing against original hardware side by side subjectively in many cases) has been with fpga-based emulation.

Emulation is great. I have Switch, Wii-U, Gamecube, Dreamcast, PS2, PS3 etc on my PC. Obviously the old systems gain a great deal from hardware simulation, but newer machines it's more or less redirected/translated api calls (if I understand how it's done correctly??) so lag isn't so much an issue any more - and newer machines have to deal with laggy flatscreen delays so games don't rely as much on frame accurate inputs?

I love the MiSTer, but emulation is not the devil.

Redream still feels laggy compared to a real dreamcast and dolphin compared to a Wii, I don't know why people keep saying software emulation of newer system will have the lag issue magically solved, it does not. You still have all the same problems accessing USB and outputs quickly on the multitasking OS and are still held up emulating parallel CPUs and specialized chips in a semi-linear way.

It is true though that when HDMI consoles appear game design begins to take into account laggy digital TVs.

Modern games run on an OS that abstracts the hardware away on the actual original machine. Emulation requires that you give the game an API/ABI that's indistinguishable from the original. That doesn't mean simulating circuitry anymore. Modern GPU's etc. are massively more capable so they have the headroom needed to deal with translation. The parallelism is taken care of by the host hardware.

Emulating 8/16-bit machines is different because those were programmed right on the metal, so you must emulate the actual metal for them to work right.

aberu wrote: ↑Sat Jul 31, 2021 3:44 am I'll wait for a more proper test demonstration than that video to prove otherwise. The video doesn't compare with original hardware directly, he just says that mario jumps within one frame of lag. There's no test-retest to account for sub-frame variance in lag. He used a "random Displayport to VGA adapter", so there is almost guaranteed more lag than original hardware and analog signals when compared to something like the MiSTer since you still have some video processing lag involved in that signal chain. Did Tyler Loch use a lag tester to do an equipment test on that adapter? There's a reason why someone like Bob from RetroRGB is much more thorough, because he wants to be as sure as possible that his claims are correct, whereas that video doesn't really prove much to me personally.

Here you are, in that case. This is my own setup, on a 34UC89-G and a Razer Panthera, on Windows 10. I'm using Vulkan and Snes9x, here, with two frames of run-ahead latency reduction. I have an LED diode wired to my button so frames can be counted more accurately, along with a frame counter OSD.

Count the frames yourself if you'd like, the video file is in 240fps, and so displays four frames for each individual frame of gameplay--you'll have to hit the "download" button after opening the link to Google Drive. Most of my inputs have one frame of latency--e.g., you'll see the diode cut out on frame 1 when the input happens, nothing will happen on frame 2, then Mario's animation will begin on frame 3. Some of my inputs have two frames of latency. None of them that I could find have three frames of latency, so as you'd expect, the latency varies by one frame.

It'd be possible to get my latency lower, but my monitor has at least 14ms of latency (the price you pay for an IPS panel, apparently), and the Panthera has at least 4ms of input latency. Which means that I have at least one frame of latency built into my setup itself, which means that RetroArch is indeed responding on the next frame, in at least some instances.

As I claimed earlier, though: even on my non-CRT setup, I'm able to beat or match original hardware input latency in most cases where run-ahead latency reduction is possible to perform. In this case, original hardware performance is two frames of latency--that's what's built into Super Mario World's engine. That's not a matter of speculation, that's just common knowledge. And if I were running my own setup on a CRT with a USB controller capable of 1ms response times, then there would be zero additional input latency over original hardware, even with run-ahead latency reduction enabled, at least for this specific core.

When you say

so there is almost guaranteed more lag than original hardware

it's not clear whether you're understanding what's going on; that CRT video shows next-frame response, which means there's literally zero latency. Original hardware is entirely incapable of next-frame response, and will always have at least one frame of latency. I find it kind of strange that you're having technical discussions about input latency on original hardware when you don't seem to know what kind of latency original hardware has.

The reality is that with contemporary hardware, contemporary video drivers, and contemporary operating systems, a properly coded emulator can get its frames to the display in less time than it takes for the display to process the next frame at 60fps. Which should be entirely unsurprising, considering how much more powerful PC hardware has become in the last decade, and how much of an emphasis there now is on higher framerates and lower input latency when it comes to PC gaming. That's now bled over even to console gaming, where you're seeing 120Hz become a standard for both televisions and gaming consoles themselves.

Thanks for the vid, that is great. It demonstrates exactly what you claim, next frame response consistently, pretty much.

Original hardware is entirely incapable of next-frame response

Not from my understanding but okay. I agree that this is the case more and more from PS1, to PS2, etc... Because they had that lag built in, they added dedicated GPU's which have framebuffer overhead, etc... The games were then designed around input lag being a gaven.

But next frame response being the minimum implies the NES doesn't read and execute a button press in under 16.6667~ms, and it implies that it would take 33.33333~ms to see the video update in response to the button press on a CRT. If this were the case, the Zapper wouldn't work consistently on original hardware hooked up to a CRT either. But it does. The NES itself does respond to the button push nearly instantaneously, it's at an incredibly low level merely electrical circuitry with some incredibly simple digital logic going on. It just can't display the response on the screen until the screen catches up to the update from the analog video chain. If a CRT had a refresh rate of 60hz, then of course you are limited to the TV having a 16.6667~ms response measurably, but the game system isn't updating that way internally, and that doesn't make it incapable of updating the screen within the next frame.

Either way, I have zero problem with and I regularly do say that software emulators have significant advantages in many avenues, and it's mostly dependent upon comparably expensive auxiliary hardware ($1000+ computer, combined with a nice monitor, maybe special hardware form the retro gaming community to do workarounds like GroovyMAME requires, etc...) when compared to the MiSTer. They each have strengths and weaknesses. To my ears, the best implementation of Sega Genesis audio emulation in software still doesn't sound right, whereas the MiSTer core is almost perfect (very few bugs and issues in some games still, but it's getting a major rewrite of the code from my understanding which should address these issues).

aberu wrote: ↑Fri Aug 06, 2021 3:51 pm Not from my understanding but okay. I agree that this is the case more and more from PS1, to PS2, etc... Because they had that lag built in, they added dedicated GPU's which have framebuffer overhead, etc... The games were then designed around input lag being a gaven.

But next frame response being the minimum implies the NES doesn't read and execute a button press in under 16.6667~ms, and it implies that it would take 33.33333~ms to see the video update in response to the button press on a CRT. If this were the case, the Zapper wouldn't work consistently on original hardware hooked up to a CRT either. But it does. The NES itself does respond to the button push nearly instantaneously, it's at an incredibly low level merely electrical circuitry with some incredibly simple digital logic going on. It just can't display the response on the screen until the screen catches up to the update from the analog video chain. If a CRT had a refresh rate of 60hz, then of course you are limited to the TV having a 16.6667~ms response measurably, but the game system isn't updating that way internally, and that doesn't make it incapable of updating the screen within the next frame.

I might be a little more specific: the NES hardware is of course capable of rendering next-frame inputs--but the caveat is that that's only on bare metal. When you're running a game, virtually every game post-early-Atari-era has at least one frame of latency baked into the game's engine, which is probably just a result of the sheer fact that there's not really a compelling reason to aim to design a game engine that's so fast and lean that it runs on less than one frame of latency. Preceding the 32-bit era, the rule of thumb is that basically everything has at least one frame of latency, somewhere between a minority and a majority of games have two frames, and very rarely games will have three or more frames. For example, Super Mario Bros. on NES has one frame of latency, while Super Mario World on SNES has two.

You can verify this using pretty much any core in RetroArch in tandem with the frame advance feature--pause emulation, press input, advance game one frame at a time using hotkey, note when input is registered. That's the standard way of determining how many frames of lag to compensate for via the run-ahead latency reduction feature.

At any rate, I entirely agree that the MiSTer is an amazing piece of hardware and that it provides an emulation experience that's about as good as it gets for a relatively minimal cost. But at the same time, it stands on the shoulders of software emulation giants (especially in terms of the decades of meticulous documentation that were necessary for it to be possible to write FPGA cores), and I'm always quick to point out just how good software emulation can be under the right circumstances, despite the fact that it can be pretty terrible under the wrong circumstances. So I hope I don't come off too abrasively. I'd also never gone through the trouble of performing an appropriate test on my own setup, so it was pretty fun to confirm with my own eyes what I had just assumed I was getting.

No, it's fine. I'm just the type that discusses things back and forth like this enthusiastically too. We actually mostly agree.

Chopin wrote: ↑Fri Aug 06, 2021 8:04 pm When you're running a game, virtually every game post-early-Atari-era has at least one frame of latency baked into the game's engine, which is probably just a result of the sheer fact that there's not really a compelling reason to aim to design a game engine that's so fast and lean that it runs on less than one frame of latency.

I think it boils down to the fact that it's very straightforward for an old-school engine to read the controllers during or immediately after vblank and let all of the code assume that the input is current during the following frame of processing (especially on SNES, which has hardware support for automatically reading input during vblank). As far as I can figure out, significantly sub-frame input latency requires either wasting CPU time or carefully separating the game into input-dependent and input-independent subroutines so that it can delay reading input until closer to the next frame. This is essentially the principle behind RetroArch's "frame delay" feature.

ExCyber wrote: ↑Sat Aug 07, 2021 6:28 pmI think it boils down to the fact that it's very straightforward for an old-school engine to read the controllers during or immediately after vblank and let all of the code assume that the input is current during the following frame of processing (especially on SNES, which has hardware support for automatically reading input during vblank). As far as I can figure out, significantly sub-frame input latency requires either wasting CPU time or carefully separating the game into input-dependent and input-independent subroutines so that it can delay reading input until closer to the next frame. This is essentially the principle behind RetroArch's "frame delay" feature.

Ah, interesting insight. So it's probably just far less complicated from a code perspective to do input at perfectly regular intervals, and the only way to do that is with at least one frame of latency so that inputs executed at different times within the current frame can all be delivered at the same time for the sake of producing the next frame, if I'm interpreting all of that correctly. Otherwise, you'd have to worry about the precise time during which the input was received in the middle of frame generation, and what to decide to do with that input based on the sub-frame time at which it was received.

I'm sorry if responding in old thread isn't okay. I was searching for "duckstation lag emulation" to figure out if it's deterministic and came here. A few of the anti-emulation comments made me cringe but the responses are really impressive. I wanted to cover the greater picture.

FPGA cores such as MiSTer and Analogue devices are emulators too. They emulate at the hardware level using the VHDL, Verilog and/or SystemVerilog programming languages. Hardware method has pros and cons. Probably the biggest con is the cost. I can afford a $300 gaming device living in rich US but not most of my coworkers living in the Philippines and India. I don't think it's fair to compare MiSTeR to a device that costs 10x less without considering price points. Not asking for optimal RetroPie settings is another thing.

I have business refurbished ~$100 Windows 10 PC that plays the SNES and PS1 games I like with no perceptible input lag or inaccuracies*. The emulation was a bonus feature since I bought it to run PCIe capture cards. I had similar controller XInput / Dinput issue as chanunnaki on DuckStation that I solved in 15 minutes.

*No PlayStation emulator emulates disc loading lag correctly. They certainly reduce it.

witinhalf wrote: ↑Wed Apr 07, 2021 3:41 am I've tried to play Yoshi's Island emulated for years. I've tried it with ZSNES, SNES9X, all the retroarch cores, raspberry pi, etc... I was never able to get into the game. It felt like the SNES just wasn't powerful enough to handle such a complex game. I guess that I never played it as it was intended. My friend was over when I got my MiSter and I launched Yoshi's Island to give it a test. The game is not the same game. I love it. Emulation does not cut it for this game.

I'm sorry that no one knew how to accurately emulate the Super FX2 chip of Yoshi's Island until the very expensive and difficult team effort to decap with byuu (Near) in 2010-2012. I see videos of Raspberry Pi 3 and RetroPie 4.4 running Yoshi's Island. SNES9X v1.57 released in late 2018 runs it accurately. RetroArch has cores that can. Seemed accurate to me on Nintendo Switch. Are we living in the same universe?

Chopin mentioned MiSTer benefitting from the work of software emulators going back to the 90s dark ages. I read on shmups forum that the SNES core started as a direct port of cycle accurate bsnes. There was no need to reverse engineer the enhancement chips to play some of the most popular games since this task had been done and open sourced!

Not a con but the reality is running at the cycle level is not the same as being cycle accurate. The Game Boy core originally paled in comparison to Gambatte, BGB and SameBoy but it's become much more accurate thanks to continued development. Several audio errors aside, a few GB and GBC games are not playable. You can see the actual response is asking if any software emulators have coded their memory bank controllers. In other words, the core dev doesn't know how.