FPGA discussion split from Analogue Pocket thread

[tomwhite2004]

runahead can't always account for 2 or even 1 frame.

that isn't true, you can always account for being able to remove at least a single frame of latency with run ahead.

brunnis has been doing input lag tests in retroarch for some time now and even before run ahead was a thing was able to consistently get to within a frame of real hardware mainly just by using as much frame delay as his cpu would allow.

https://forums.libretro.com/t/an-input- ... n/4407/424

https://forums.libretro.com/t/an-input- ... n/4407/524

[ZellSF]

runahead can't always account for 2 or even 1 frame.

that isn't true, you can always account for being able to remove at least a single frame of latency with run ahead.

Unless RetroArch's documentation and/or implementation is incorrect, there are games where you can't run ahead even a single frame (for example Eye of the Beholder for the SNES).

[tomwhite2004]

Unless RetroArch's documentation and/or implementation is incorrect, there are games where you can't run ahead even a single frame (for example Eye of the Beholder for the SNES).

that's interesting, there's always a sodding exception to prove me wrong isn't there lol! but I'm still not going to change my "safe" global setting of a single frame of run ahead with snes games because of a single documented game. apparently there are a few nes games where the menu and pause screens are also lagless so any run ahead you apply starts skipping frames, whilst in game you still have a frame of lag to all actions, i wonder if it is because of a difference in the way the games poll the controllers in those instances, i'm not smart enough to know!

[donluca]

run ahead is a bad attempt at copying GroovyMAME's frame_delay which is now evolving into frame slicing and other, better ways to kill that last frame of lag due to vsync.
Retroarch should have never existed, IMHO, it has done an ungodly amount of damage to the quality of the emus themselves for the sake of convenience, but i'll keep that rant for another day/thread.

Here's a nice thread with lots of measurements: http://forum.arcadecontrols.com/index.p ... 722.0.html

There are lots of other threads over there with actual measurements showing you that you can get less than a frame of lag (remember, each frame of lag = 1/60 = 16ms).

It's all up to the other emu devs to adopt such measures to get the lag inherent to their emus down to 0.
On hardware side, 1000hz usb polling with good arcade sticks/pads and proper configured OS and low lag monitor (or CRT) will eliminate the remaining lag.

EDIT: some more measurements: http://forum.arcadecontrols.com/index.p ... msg1694671

is 1.6ms (1/10 of a frame) lag good enough for you?

[tomwhite2004]

run ahead is a bad attempt at copying GroovyMAME's frame_delay

I don't see how targeting the removal of latency from the game itself via save state manipulation is copying a technique that delays when the next frame of emulation is processed by ms increments?

It's all up to the other emu devs to adopt such measures to get the lag inherent to their emus down to 0.

And that is why people use Retroarh cores, because they don't.

[donluca]

Because retroarch's approach is basically a hack asking for trouble and GM's is the correct way.

That's really it, nothing more nothing less.

There are other ways to shove down lag, you can see all the hacks which have been made in the old ShmupMAME, but that's going to cause issues sooner or later (and, besides, those exploit the games themselves to remove their inherent lag).

Again, and for the last time: the only thing FPGAs have on their own side is convenience since they can achieve lagless input/output without the user actually doing anything, while on PCs there's quite a steep learning curve to learn how to configure OS and emu properly.

It has been demonstrated that PCs can get down to less than a frame of lag which, IMHO, is "good enough" even for demanding game genres such as shmups.

[Xyga]

The difficulty with RA is that it's doing its lag reduction in three different steps, dealing with sync queue, input polling, and the run-ahead trick.
Groovy at least with MAME achieves near-lagless while keeping sync (and perfect refresh + portaudio if your hardware allows) without allowing to go sooner than the emulated game's delay as it's supposed to be.
RA is less efficient on the sync and input side of the job therefore you have to use run-ahead for the last frame..or is it ?
With Groovy it's been cleanly tested with a dedicated tester and LUA plugin, in RA though from what I've read the amount of frames you're supposed to run-ahead isn't clear for every core and game case, yet in most it shouldn't be more than one, and rarely two if something's fishy, although that should be verified with similar test, and against the hardwares.
It's work but not that much, it just has to be done for every core and a database maintained if needed.
Instead people count a game's frames for reference of how many they should attempt to remove, which doesn't make sense as it's not counting what one should aim to eliminate.
With Groovy at least you can't be mistaken nor get weird skipping frames errors, unless mamedev have purposedly or mistakenly added another frame that shouldn't be in a driver, you get nearly the same lag as you should on the real hardware and done, it's straightforward, nothing in the method is left to guess, impossible to ruin the accuracy (you may need a damn strong PC if you're playing on a HD and up display tho)

If beam_racing ever becomes a reality (*cough*) that'll be even better indeed, but right now you can already have the same ideal results with VRR anyway, assuming nothing gets in the way. Groovy tested on VRR was basically perfect, other emulators should at the very least be tested and eventually modified for that to begin.
Run-ahead is cool for it's simplicity but shouldn't be used beyond reason, unfortunately it is exactly how it is often used and RA encourages that, overall I don't think it is a good method for the general area of emulation, it should be bridled in a per-case fashion.

[tomwhite2004]

Because retroarch's approach is basically a hack asking for trouble and GM's is the correct way.

Still doesn't make it a copy, especially when you take into account where run ahead actually originated, how long ago that was and who bought it to Retroarch...

"The first time I saw RunAhead was in the Gens-Rerecording Sega Genesis Emulator, used by the TASVideos community. According to the Github logs, Nitsuja added the feature in July 30, 2008. At the time, the motivation for that feature was to see Sonic respond within one frame when using Frame Advance while making TASes of Sonic the Hedgehog. The feature was named "Video Latency Compensation". Then I brought it to the attention of the RetroArch forums in March 2018, and implemented it in RetroArch soon afterwards."

https://www.reddit.com/r/emulation/comm ... n/f3xxkrg/

[donluca]

I may have used the word "copy" improperly.

We could argue frame_delay wouldn't have existed if run ahead wasn't already there with the idea of shaving down lag by pre-rendering frames (something which nVidia actually lets the user do in their control panel IIRC, you may want to check on that as I may recall wrongly).
I'm probably making a stretch here, but we may say that frame_delay is an evolution of run ahead as it took the original idea and implemented it properly. (I wish Calamity would still be here posting as he has the ability to explain this way better than me)

Anyway, it wasn't until people started noticing the improvements frame_delay brought to emulation that they started asking retroarch devs to do something similar and they decided to use run ahead to give the users a way to reduce lag.

The whole point of the discussion is that it *is* possible to get almost 0 frame lag on a general purpose PC so what's left in the FPGA is purely convenience, an instant-on system without the need to configure anything, a true plug-and-play experience.

It's an important aspect of emulation, don't get me wrong, we all love instant-on systems like Mega Drive, SNES and PCE, but to boast on your website in all bold capital letters, taking half of your screen, "FPGA IS NOT EMULATION" is just purely a marketing gimmick and, while on a purely semantic analysis it might not be completely wrong (as is: it doesn't suffer from common problems found in software emulation), it is definitely not true.

[tomwhite2004]

Anyway, it wasn't until people started noticing the improvements frame_delay brought to emulation that they started asking retroarch devs to do something similar and they decided to use run ahead to give the users a way to reduce lag.

But Retroarch has supported frame delay for years now, so that line of thought isn't remotely true. If you read the quote above that I posted it should be clear that Retroarch didn't decide to use run ahead in response to anything, they were completely unaware of it existence, the PocketNES dev stumbled on it seeming by chance and decided to add it himself so it could be used by as many emulator cores as possible.

[orange808]

About beam racing:

Don't know if everyone saw this one earlier this year:
https://forums.guru3d.com/threads/rtss- ... st-5549072

RTSS beta added beam racing in May and we finally got to explore how it performs with real win32 games--and found the limitations of using it. It's an interesting toy to play with.

(FYI: Please don't post in that thread. It's an active development thread.)

[donluca]

But Retroarch has supported frame delay for years now,

run ahead has been implemented in retroarch in 2018.
That's not "years", it's literally not even 2 years ago.

frame_delay has been in GroovyMAME for as long as i can remember, but *at least* since 2015 since that's when I started using it: http://forum.arcadecontrols.com/index.p ... c=148347.0
probably it has always been there from the start.

I don't know about the PocketNES dev story, only thing I know is that ~2 years ago people have started asking retroarch devs to come up with something like frame_delay, it might be coincidental that the PocketNES dev had found out about it and applied to the rest of retroarch.

Anyway, this doesn't really matter nor interests me. If you want we can discuss this matter on another topic.

This topic is to debunk (for the 937593850345th time) the myth that FPGAs are inherently better than software emulation and have some magic in them which make them more accurate.

[tomwhite2004]

But Retroarch has supported frame delay for years now

run ahead has been implemented in retroarch in 2018.
That's not "years", it's literally not even 2 years ago.

Anyway, as you said let's end this tangent now, sorry to go off topic.

[donluca]

Ow, sorry, I somehow tunnel-visioned on run ahead and mis-read your post.

I didn't know frame delay was ever implemented in retroarch, that's completely news to me.

I've tried a quick googling to see when it was implemented and the earliest post talking about it is, again, in 2018.

I've also read people setting various values on frame delay on retroarch, often higher than 9 (which is the maximum in GM) which has led me to think that their implementation is somewhat different from GM's approach.

Anyway, back on topic and hopefully this thread won't just die due to being in the off-topic section.

If it does, I'll definitely make another one in the Hardware subforum so we can keep discussing about this and its evolution in, hopefully, a civil and informed manner, instead of quoting random gibberish and fanboyism.

[tomwhite2004]

've tried a quick googling to see when it was implemented and the earliest post talking about it is, again, in 2018.

I've also read people setting various values on frame delay on retroarch, often higher than 9 (which is the maximum in GM) which has led me to think that their implementation is somewhat different from GM's approach.

I bought my PC in early 2016 and frame delay was already there, it's pretty easy to find various forum and reddit posts discussing it from around that time too.

In Retroarch it is configured in ms increments from 1 to 15.

[Xyga]

I think frame_delay started in Groovy in 2013 or something (edit: 2012). 'When' doesn't matter anyway.
Frame-delay and run-ahead are completely different features, and I think the former isn't implemented exactly the same way in GM and RA. In GM it's sewn in and tied to syncrefresh while in RA I'm not sure on which layer it acts for doing its job as RA takes over handling the output differently.
Also GM compared to baseline uses d3d9ex, buffers less and removes that unmoveable frame from baseline, so when you use a baseline core in RA you start with more lag than GM anyway, and you have to use hard-gpu-sync, frame_delay, and run-ahead, it's a very different design in three possible adjustment steps I'm not sure the relationship is documented well-enough nor broadly understood.
Anyway last time I checked baseline MAME didn't work well with run-ahead in RA, or only with old builds maybe which sucks, GM is always up-to-date. So unless fine with the FBA/FBN core the way to go for full arcades or ifyw the best MAME experience is defo GM. But it's not very popular because kind of an advanced user type of build too demanding for the average user who just wants to play on any computer and monitor (GM works best w/ a few monitor, gpu and cpu requirements) with a nice selection of shaders and 'fancy' UI, then push the featured lag reduction(s) until it feels responsive-enough for them even if what's really happening in that aspect might not be very clear nor accurate.

[tomwhite2004]

that's all great for arcade emulation (btw i completely agree that retroarch integration of mame sucks) but what if i want to use frame delay with sameboy, mgba, mesen or one of the many mednafen cores etc ? groovymame alone being a shining example of how things should be done is absolutely no use to me whatsoever with anything else i may want to emulate, so to retroarch i go.

[Xyga]

Oh that, I don't really care about the non-arcade systems, as I said GM is better for emulating arcades. As donluca said once iirc it is 'mame done right', even if almost reserved to reasonably advanced users, I'd say it is the bleeding edge of arcades emulation.
Maybe FBN will catch up some day but it's only just resurrected.

You can emulate consoles and PCs in MAME too (therefore GM and therefore benefit from the same improvements) but it's annoying, unintuitive, and you have to grab the 'software list' roms which are even more trouble to use/find/update than the arcade set (which is already a real pain to maintain if you don't know where to look)
The console drivers are also often still rather WIP compared to the standalone emulators used as cores in RA, so of course it's better to use RA for everything else.

[donluca]

As donluca said once iirc it is 'mame done right'

As much as I love and follow GM development, I don't think I've ever made such statement, LOL.

Remember that while GM brought a lot of improvements over baseline MAME (although some of those have found their way into base MAME by now), it is still mainly aimed at CRT users.

MAME is an amazing project and a great starting point but to be "done right" (AKA easily useable by users, the retroarch way) it needs lots of things like an integrated clrmamepro like which checks your library and fixes your ROM library.

In an ideal world, you should be able to get *any* ROM set, no matter how old, and this integrated clrmamepro should fix your ROMs to get them up to date with the latest revision so that everytime a new MAME is released, there will be an interface which will notify you of the new version, update it, then run the integrated clrmamepro, fix your current rom set and then present you with a nice UI to choose and start your game and proper (drop down) menus to easily access all the options and change what's needed.

I went again offtopic, I think I'll just stop replying until some meaningful post is made about FPGA/emulation.

[Xyga]

As much as I love and follow GM development, I don't think I've ever made such statement, LOL.

I think you did not so long ago, maybe a year or two. Well doesn't matter.

Remember that while GM brought a lot of improvements over baseline MAME (although some of those have found their way into base MAME by now), it is still mainly aimed at CRT users.

In recent years Calamity brought so many improvements for flat panels use as well that it's not really the case anymore. Getting the exact rates, smooth, nearly all video/input/audio lag removed all together, I mean it's the only build that does it, the only downside being that it is quite demanding on PC hardware and to get all aspects coverd you need a compatible panel and an AMD.

MAME is an amazing project and a great starting point but to be "done right" (AKA easily useable by users, the retroarch way) it needs lots of things like an integrated clrmamepro like which checks your library and fixes your ROM library.

I meant right technically-speaking, as it covers everything and more without sacrificing accuracy.
But yeah useability-wise it's basically MAME with an increased amount of stuff to read and learn, so of course it's not for everyone.
MAME itself is a long way from being user-friendly so I understand that people are even more confused with Groovy after seeing the walls of tutorials and concepts to assimilate.

In an ideal world, you should be able to get *any* ROM set, no matter how old, and this integrated clrmamepro should fix your ROMs to get them up to date with the latest revision so that everytime a new MAME is released, there will be an interface which will notify you of the new version, update it, then run the integrated clrmamepro, fix your current rom set and then present you with a nice UI to choose and start your game and proper (drop down) menus to easily access all the options and change what's needed.

That couldn't be without downloading missing material anyway, right ? so it won't happen. The problem for a while has been that practically all roms joints but two have been carrying up-to-date roms, one in direct dld, one in a strict private torrent. The requirements have also become overall stricter because of the number of bios and devices, as well as extremely frequent romname's changes, that your ability to launch a game depends on, and users can't follow.
In short MAME has become an overwhelmingly complex and unfriendly software, or the giant museum only specialists enjoy visiting. I don't think it'll improve any if at all, I think it might get even more complex with time.

Which brings us back to FPGA !
Those in my eyes are yet another side-effect of what emulators have become over time; either stuck in development, or too complex or limited in results/accuracy if you can't go the many extra miles to get them to produce their best, so it's almost certain we'll see more and more FPGAs for arcades, consoles, even old PCs maybe.
And emulators use will concentrate on the higher-load stuff FPGAs can't do, but then stuff like MAME wich was already almost marginalized by RA & Co., will become even more niche.

[ahaddow]

This thread is pretty spicy but here's my ice cold take:
well coded FPGA cores are better than poorly coded emulation and poorly coded FPGA cores are worse than well coded emulation

If there was a handheld device that ran bsnes at full speed on a great screen I would most definitely not turn my nose up at it.

[orange808]

I rather liked the general idea of Puppy Arcade. Too bad it never came close to realizing its potential. MAME would benefit from running inside its own bootable partition. A fork of FreeDOS would be most intriguing.

[donluca]

FPGAs opened the door for a new business which are "proper" console clones.

Let me ask you (not you, xyga, in general) a question: who would pay for an emulator which runs on your PC?

Let's say that higan, the best SNES emu, suddenly becomes commercial and you have to pay for it... would you pay for it?

And yet, people buy FPGAs because they like the instant-on feature and ease to use. Analogue knows this and has capitalized in one of the most profitable ways possible.

It's not bad, I'm not blaming them (if any, we should blame those who buy them, but we all like convenience, otherwise we would still be using newsgroups and having command lines OS without a GUI), it's business at the end, but what really irks me is the misconception about FPGAs being inherently better than software emulation.

Again, it's marketing, it's a vital part of business, would you imagine looking at a promo where the guy goes "uuuh... and well, yeah, you know, you can get the exact same experience on your PC for free, but you have to download illegal ROMs and wait for your PC to boot (which, btw, is probably already on since you're watching this) and you're just paying for a nice plug-and-play box". This couldn't work of course.
But they could very well shut the fuck up and let it be, let the users decide for themselves instead of shoving this bullshit down their throats.

Ah well.

There will be the day eventually when FPGAs really become powerful enough to match the original hardware and be completely indistinguishable and that day I'll eat my own words.

[it290]

I think all of the back-and-forth about FPGA vs software kind of misses the point, which is that a well-designed FPGA system is capable of producing an extremely good facsimile of the original hardware experience while offering clean digital output and supporting original and high-quality repro controllers without extensive configuration. You plug it in, slap in a cart or select a game from a menu, and you're getting an experience that is on par with the best software emulation with very little fuss. At present, that isn't really something that is super-feasible with standalone plug and play software emulation today. It's almost inevitable that we'll get to the point where 'classic mini' type systems will have enough horsepower to achieve lagless or near-lagless emulation via software—the demand is there and people are getting slightly more discriminating about what they buy—but we're not there yet, and it's still incumbent on the manufacturers to actually care about that level of precision.

If your goal is to play the best, most precise, most lag-free facsimile of Dodonpachi possible none of this is really relevant, since any FPGA version of that will never be a consumer product and you'll always be playing it with a custom stick or other input device of your choice, but if you want to play an SNES game authentically then not having to fuck around with settings, swapping controllers out, etc. is actually a really big deal and software is not currently able to achieve this in the same way an FGPA device like the Super NT can.

[Bassa-Bassa]

On hardware side, 1000hz usb polling with good arcade sticks/pads

That only depends on the stick/adapter you use and you can do nothing really useful in Windows configuration to globally set it, right? Is there a list of adapters and/or controllers which polls at 1000Hz you know of?

[donluca]

That only depends on the stick/adapter you use and you can do nothing really useful in Windows configuration to globally set it, right? Is there a list of adapters and/or controllers which polls at 1000Hz you know of?

This is a common misconception. Hardware polling is set at the OS level and is independent* of the hardware used.

The ambiguity was born thanks to Razer's mice and keyboards marketed as "1000hz polling rate". What those do is nothing more or less than telling windows to poll 1000hz on the USB port their peripheral is connected. You can do that with a simple software which will tell windows to poll all USB ports at 1000hz (word of warning: this might cause some issues with other USB devices), just google it.

*There are indeed some corner cases of odd or very old sticks/mice/keyboards which won't benefit from the 1000hz polling rate but those are few and all of the modern ones will benefit from it, even the "zero lag" chinese boards which go for $5 or so on ebay.
So, to reply to your question: anything new will do.

[Bassa-Bassa]

Understood, thanks. My misconception may come actually from Raphnet's adapter series, which seems to also poll at 1000Hz without any futher Windows configuration, or so they say.

Googling the subject a bit, found some tools for USB polling config., hopefully they work well for most gaming-only devices:

https://www.mikemartin.co/system_guides ... lling_rate

https://www.nextlevelgamer.com/tweaks/o ... lling-rate


And for testing the device's polling:

https://docs.microsoft.com/en-us/window ... dfrom=MSDN


I guess that DirectInput and RawInput behave the same regarding this subject.

[orange808]

That only depends on the stick/adapter you use and you can do nothing really useful in Windows configuration to globally set it, right? Is there a list of adapters and/or controllers which polls at 1000Hz you know of?

This is a common misconception. Hardware polling is set at the OS level and is independent* of the hardware used.

The ambiguity was born thanks to Razer's mice and keyboards marketed as "1000hz polling rate". What those do is nothing more or less than telling windows to poll 1000hz on the USB port their peripheral is connected. You can do that with a simple software which will tell windows to poll all USB ports at 1000hz (word of warning: this might cause some issues with other USB devices), just google it.

*There are indeed some corner cases of odd or very old sticks/mice/keyboards which won't benefit from the 1000hz polling rate but those are few and all of the modern ones will benefit from it, even the "zero lag" chinese boards which go for $5 or so on ebay.
So, to reply to your question: anything new will do.

Be extra careful.

I got a crappy free mouse with an Alienware machine last Xmas that won't do 1000hz. That's pretty new.

Also, be careful overclocking USB devices, because it can cause system instability in some cases with Windows 10.

You also never know when something is going to change. The W10 update cycle is never going back to the old days (and the security pitfalls of doing that would be disastrous!). IMHO, you're better off using devices that have some sort of officially supported 1000hz drivers from the device manufacturer.

[donluca]

I'll never get tired of repeating this over and over again:

build yourself a damn emulation box, a PC dedicated to JUST ONE THING.

You can even use old windows XP which will let you do anything you want without getting in the way, just make sure not to give the machine access to the internet.

This way you can get way better performance and much faster boot times (you can even hide all the windows interface and boot straight to your launcher of choice).

[orange808]

I'll never get tired of repeating this over and over again:

build yourself a damn emulation box, a PC dedicated to JUST ONE THING.

You can even use old windows XP which will let you do anything you want without getting in the way, just make sure not to give the machine access to the internet.

This way you can get way better performance and much faster boot times (you can even hide all the windows interface and boot straight to your launcher of choice).

Already have one. Actually, I have two. I also have an XP machine for Cubase and MIDI.

There's a reason I started buying prebuilt machines, though. Let me explain how to maintain a PC gaming rig. You can guess the first requirement: money.

I'm a PC gamer in every sense of the term. I haven't purchased a console from Sony or Microsoft since the PS2/Xbox/GCN/Dreamcast era.

For modern PC gaming with maximum settings and 60fps, we all know it's expensive. The good thing is, you save money you have already have money to spend. It's unfair, but that's the way it goes.

The cheapest way is: to buy a prebuilt top spec machine on Black Friday; you can't build them for less. Use it only for gaming, make sure to sell it before November, and roll the value over into a new top spec machine every year. Keep as much data as possible on an external drive. Don't keep it long enough to let the value depreciate to nothing.