|
I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
#378841 - 10/07/18 01:53 AM
|
|
|
In case one of the many devs here were interested, the bounty for an A64 dynarec is up over $1,600. Feel what you like, for or against RA, but at least they are non-profit. It's always free, cross-platform, and this bounty is a pool of donations from the community.
https://www.bountysource.com/issues/63766562-bounty-write-an-arm64-dynarec
|
Just broke my personal record for number of consecutive days without dying!
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: URherenow]
#378842 - 10/07/18 04:16 AM
|
|
|
I'd be on this bounty like white on rice if it were better-defined what the end goal is.
As I understand it, RA isn't an emulator itself but more of a frontend for other peoples' emulators, except with the emulators integrated at an API level rather than how something like a MAME frontend operates.
Unless RA supplies a shared DRC/JIT system that the emulators all use, writing an AArch64 recompiler would ostensibly mean writing one for all of the possible emulators that have DRCs: Dreamcast emulators, N64 emulators, PC emulators, MAME, and so forth.
If that is in fact the case, then while 1600 bucks is certainly not chump change, it's also still nowhere near commensurate with the amount of work needed to implement.
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: MooglyGuy]
#378844 - 10/07/18 08:03 AM
|
|
|
> I'd be on this bounty like white on rice if it were better-defined what the end goal
> is.
>
> As I understand it, RA isn't an emulator itself but more of a frontend for other
> peoples' emulators, except with the emulators integrated at an API level rather than
> how something like a MAME frontend operates.
>
> Unless RA supplies a shared DRC/JIT system that the emulators all use, writing an
> AArch64 recompiler would ostensibly mean writing one for all of the possible
> emulators that have DRCs: Dreamcast emulators, N64 emulators, PC emulators, MAME, and
> so forth.
>
> If that is in fact the case, then while 1600 bucks is certainly not chump change,
> it's also still nowhere near commensurate with the amount of work needed to
> implement.
yeah, I saw this and thought exactly the same thing.
it pretty much highlights the entire problem with the RA design, and why anybody calling it an 'emulator' or even 'the best emulator ever' is seriously annoying because it's anything but, it's just a glorified frontend that annoyingly requires things to be compiled in a custom format just to use with it, stripping away any identity the emulators had and expecting them to work basically like a SNES would.
There's no sharing of emulation between modules, it's literally just other peoples work glued together as single system libraries, code duplication galore. It's the opposite of the design of a good emulator when you develop cores for actual components and make sure those cores work correctly with every system that uses them (and as such everything you emulate acts as evidence towards that)
It's the 'easy' option, but it isn't one that leads to better development which is one of many reasons why I continue to consider it a dangerous project.
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: MooglyGuy]
#378850 - 10/07/18 12:23 PM
|
|
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: URherenow]
#378860 - 10/07/18 05:02 PM
|
|
|
From what I just read they think the CPU emu is a drop in. For some emus you could pull that off. But others not so much. Even then it is quite a bit of work. 1600 buck *is* a lot of money. But that is basically 3-6 days of 8 hour days of work. Probably not enough to actually do it at least on a contract basis. For someone who was going to 'do it anyway' then it would be a nice bonus. But to try to entice someone capable of doing it may be a bit short. They can make more at a 'real' job.
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: lharms]
#378861 - 10/07/18 06:02 PM
|
|
|
In the meantime, the idea might pique the interest of someone capable, who takes their sweet time doing it for no other reason than they want to give it a shot. Meanwhile, nobody else may have done it, while this $1630 goes up and up, and next thing you know, said person is done and nobody else has claimed the bounty yet.
I just know MAMEDEV are capable of this sort of thing, so I wanted to make sure the info was out there. Nothing more, nothing less.
|
Just broke my personal record for number of consecutive days without dying!
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: Haze]
#378862 - 10/07/18 06:52 PM
|
|
|
IMO, RA fills a void that no one else wants to deal with.
Until something else comes along thats more competent, it will remain.
They make it clear on the front page of their site that they're a front end for emulators.
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: DiodeDude]
#378864 - 10/07/18 07:49 PM
|
|
|
> IMO, RA fills a void that no one else wants to deal with.
>
> Until something else comes along thats more competent, it will remain.
>
> They make it clear on the front page of their site that they're a front end for
> emulators.
it fills a void by taking every ugly shortcut possible, doing everything in the worst possible way, overselling features that actually have as much as a negative affect on the scene as anything else (at this point due to their 'run ahead' crap absolutely zero emulation records can be considered legitimate anymore as it's literally built in undetectable cheating)
it's just a horrible, horrible project, it's the heroin of emulation or something like that.
competing with it would mean sinking to the same lows.
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: Haze]
#378865 - 10/07/18 09:20 PM
|
|
|
> it fills a void by taking every ugly shortcut possible, doing everything in the worst
> possible way, overselling features that actually have as much as a negative affect on
> the scene as anything else (at this point due to their 'run ahead' crap absolutely
> zero emulation records can be considered legitimate anymore as it's literally built
> in undetectable cheating)
>
> it's just a horrible, horrible project, it's the heroin of emulation or something
> like that.
>
> competing with it would mean sinking to the same lows.
Most people don't care about that stuff unless its someone like you who is actively involved in a preservation-focused project or a Gamophile that obsesses over every possible detail. If it loads the game and its accurate on the surface, then its GTG. I've never met a single person that messes with emulators (locally) that cares. This goes against what you're trying to achieve, but as with pirates vs the music industry, those people were never customers. People using RA were never going to do anything to forward MAME's goals.
As you know, the draw with Run Ahead latency reduction is to help make up for the shit lag associated with modern TVs and whatever the emu adds. I use it on some console games. Its not a perfect solution and its not the most convenient to use as its per-game, but its a workable solution until something better comes along. I'm already reading about the beam racing method being looked into on their forums. For now, I'm happy that options are available.
My RA usage is for console alongside Launchbox. Vanilla MAME gets used for Arcade stuff primarily. MAME's big disadvantage is its performance on low end SBCs like the Pi. No one can really use it on those devices unless its a hack of an older build. Unfortunate but unavoidable.
As for Hi score records...I just don't care. I get that some do though. Maybe some sort of custom binary w/accompanying Hash values to prove authenticity?
Not taking sides or defending one project over the other. Just offering my opinion as a lowly user.
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: lharms]
#378866 - 10/08/18 05:50 AM
|
|
|
> From what I just read they think the CPU emu is a drop in.
LOL
> 1600 buck *is* a lot of money.
Hahaha....
> But that is basically 3-6 days of 8 hour days of work.
Bwahahahaha....
If there's one thing I've always wished I had time to do, it was an A64 backend for MAME's DRC. A64 is a slick architecture and super nice for dynamic codegen. It would be a fun project.
But let's be honest, $1600 is chump change for any kind of financial incentive. It would take me (who wrote MAME's DRC system in the first place, including both x86 and x64 backends, AND who has written two A64 backends for commercial work) waaay longer than 3-6 days to complete and debug. 3-6 weeks, maybe, not even factoring in the long tail of bugs.
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: DiodeDude]
#378871 - 10/08/18 12:11 PM
|
|
|
> > it fills a void by taking every ugly shortcut possible, doing everything in the
> worst
> > possible way, overselling features that actually have as much as a negative affect
> on
> > the scene as anything else (at this point due to their 'run ahead' crap absolutely
> > zero emulation records can be considered legitimate anymore as it's literally built
> > in undetectable cheating)
> >
> > it's just a horrible, horrible project, it's the heroin of emulation or something
> > like that.
> >
> > competing with it would mean sinking to the same lows.
>
> Most people don't care about that stuff unless its someone like you who is actively
> involved in a preservation-focused project or a Gamophile that obsesses over every
> possible detail. If it loads the game and its accurate on the surface, then its GTG.
> I've never met a single person that messes with emulators (locally) that cares. This
> goes against what you're trying to achieve, but as with pirates vs the music
> industry, those people were never customers. People using RA were never going to do
> anything to forward MAME's goals.
>
> As you know, the draw with Run Ahead latency reduction is to help make up for the
> shit lag associated with modern TVs and whatever the emu adds. I use it on some
> console games. Its not a perfect solution and its not the most convenient to use as
> its per-game, but its a workable solution until something better comes along. I'm
> already reading about the beam racing method being looked into on their forums. For
> now, I'm happy that options are available.
>
> My RA usage is for console alongside Launchbox. Vanilla MAME gets used for Arcade
> stuff primarily. MAME's big disadvantage is its performance on low end SBCs like the
> Pi. No one can really use it on those devices unless its a hack of an older build.
> Unfortunate but unavoidable.
>
> As for Hi score records...I just don't care. I get that some do though. Maybe some
> sort of custom binary w/accompanying Hash values to prove authenticity?
>
> Not taking sides or defending one project over the other. Just offering my opinion as
> a lowly user.
If people wanted lag reduction for arcade games they could have used GroovyMAME since, what, 2013? even before? I don't remember. Can't cheat with it, as it's not designed to defeat the emulated hardwares natural lag, only that which comes after the core emulation which is essentially the video/sync and input lag.
And decent nearly or completely lagless flat panel TVs and monitors that don't break the bank have also been available without much effort since around that time.
I think lots of people use run-ahead to almost completely eliminate lag regardless of that of the hardware they play emulated 'just because they can' thanks to that feature, not because they care about realistic emulation.
Aside from that questionable 'too much', careless side of run-ahead, I think RA attracts people because of the multi-emulators aspect, but also a lot because of the great shaders, some of the convenience features, and maybe also the fancy UI.
Nothing of that in RA would be bad per-se if it wasn't going too far and messy in places. Though IMHO the opposite (too rigid, complicated and austere) is also bad because it's a stinker for the user.
Best world would be 'as much optimization and convenience as possible as long as it doesnt break emulation and respects peoples work', but today it's more like opposing parties each radicalizing on their own ideologies.
I think ultimately MAME will be almost everything people wish for and more, maybe by itself, maybe with the help of a much polished dedicated external FE.
But since MAME's busy being much, MUCH more than just a frontend with features, takes no detours and is very strict, also now does a lot of obscure niche machines emulation for expanded preservation, it all naturally takes a lot of time, during which it's beaten in popularity by opportunist things like RA that are not nearly as busy, don't care about doing it dirty and speak only to retro arcade & console games fans who are the considerably bigger demographics. Easy.
Easy, yet that pocket money bounty shows a pathetic side of their project. Did MAME ever buy development?
|
> MAME isn't about playing the games anyway.
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: LensLarque]
#378872 - 10/08/18 12:37 PM
|
|
|
> Easy, yet that pocket money bounty shows a pathetic side of their project. Did MAME
> ever buy development?
No, we've tended to discourage it as for the most part it results in rushed solutions that meet the criteria rather than correct ones which suits RAs model to the ground because they only have to consider one system at a time in most cases. This works because they don't care about emulating anything correctly meaning it's often money wasted, not money well spent, unless all you care about is playing a specific game (which unfortunately is a bigger draw than doing things properly, and pulling emulation in the wrong direction) Some of the bounties I've seen are for literally breaking the proper emulation and changing how things work just because somebody prefers that over how it's meant to be.
I took the one for the CPS3 bug because it was originally my driver in the first place and was something I was already looking at and an easy fix, but that's going straight back into investments for MAME (or at least will when I sort out the payment system)
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: Haze]
#378880 - 10/08/18 04:00 PM
|
|
|
Maybe you used to laugh at the shmups lords praising ShmupMame in the past, now I've just heard about something else...if you fancy a good seizure I suggest you google 'ShmupArch'.
They're even porting it to the Switch, which isn't powerful-enough to push run-ahead much, and will therefore ironically have the users of that port play with more accurate delay times (how sad)
Yes, because their original purpose (with a preconfigured RA build for PC) is every game down to 1 frame period.
Apparently it's even got the support of big name scorers/streamers.
A given that shooters fans love accuracy. Because they're serious players they know their shit. They're experts.
Thanks RetroArch. Thanks internet.
|
> MAME isn't about playing the games anyway.
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: AaronGiles]
#378885 - 10/08/18 05:15 PM
|
|
|
> > From what I just read they think the CPU emu is a drop in.
>
> LOL
>
> > 1600 buck *is* a lot of money.
>
> Hahaha....
>
> > But that is basically 3-6 days of 8 hour days of work.
>
> Bwahahahaha....
>
> If there's one thing I've always wished I had time to do, it was an A64 backend for
> MAME's DRC. A64 is a slick architecture and super nice for dynamic codegen. It would
> be a fun project.
>
> But let's be honest, $1600 is chump change for any kind of financial incentive. It
> would take me (who wrote MAME's DRC system in the first place, including both x86 and
> x64 backends, AND who has written two A64 backends for commercial work) waaay longer
> than 3-6 days to complete and debug. 3-6 weeks, maybe, not even factoring in the long
> tail of bugs.
1600 is a lot of money to a lot of people. I sure would not turn it down... But your and my point is it is nowhere *near* enough to accomplish it. I was also being *very* 'nice' with the per hour rate to make the 'customers' money last longer. However, for someone who knows how to do a task like this, I am 100% sure I am off by a factor of at least 2x-3x on cost. The money would probably run out in less than 2 days. I was back of the envelop specing 2-3 months to get it right. Probably less if you know what you are doing (like you do).
Even then I would probably start with putting the thing in a hotspot analyzer and see if there is any low hanging fruit for some easy gains. Then see if there is any data arrangement that could help with cache hits. Then look to seeing if you can eliminate any unneeded branching. You know, typical optimization stuff. Only then would I reach for a full out alg restructure such as dyn-rec.
But yeah probably would be fun to do.
Edited by lharms (10/08/18 05:27 PM)
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: LensLarque]
#378886 - 10/08/18 05:18 PM
|
|
|
> Maybe you used to laugh at the shmups lords praising ShmupMame in the past, now I've
> just heard about something else...if you fancy a good seizure I suggest you google
> 'ShmupArch'.
>
ShmupMame was an abomination of things done wrong, even one of the devs I believe eventually agreed that. Seeing videos people have uploaded that are recorded with it is just gross, especially as the games were otherwise well emulated.
> They're even porting it to the Switch, which isn't powerful-enough to push run-ahead
> much, and will therefore ironically have the users of that port play with more
> accurate delay times (how sad)
>
> Yes, because their original purpose (with a preconfigured RA build for PC) is every
> game down to 1 frame period.
> Apparently it's even got the support of big name scorers/streamers.
>
> A given that shooters fans love accuracy. Because they're serious players they know
> their shit. They're experts.
>
> Thanks RetroArch. Thanks internet.
Yeah, taking out lag that wasn't in the games in the first place isn't good emulation, sometimes that lag was *intentional* as part of the game difficulty balance (it's a cheap way to make things slightly more difficult, I've worked on a codebase where that choice was made before and even commented as such) As I said, it's built in cheating, and any play on such builds is 100% invalid.
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: Haze]
#378888 - 10/08/18 05:38 PM
|
|
|
The MAME info screen at game launch, or mame.info, shoud tell the hardware's default original lag like it does resolution and refresh.
That would maybe stop people from doing silly tweaks with no idea about what lenght of delay they should seek for accuracy.
Ideally there would be a button to press ingame (like F11 for speed) so the delay information would appear in a corner of the screen ingame, with the game's and the sync option if any used, for instance;
[GAME: 2 frames, SYNC 3 frames]
This could be then required to appear in a replay video for it to be trustable.
Of course RA by its design could still get around this, unless there's means to prevent even that.
|
> MAME isn't about playing the games anyway.
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: LensLarque]
#378890 - 10/08/18 06:38 PM
|
|
|
> If people wanted lag reduction for arcade games they could have used GroovyMAME
> since, what, 2013? even before? I don't remember. Can't cheat with it, as it's not
> designed to defeat the emulated hardwares natural lag, only that which comes after
> the core emulation which is essentially the video/sync and input lag.
> And decent nearly or completely lagless flat panel TVs and monitors that don't break
> the bank have also been available without much effort since around that time.
> I think lots of people use run-ahead to almost completely eliminate lag regardless of
> that of the hardware they play emulated 'just because they can' thanks to that
> feature, not because they care about realistic emulation.
>
> Aside from that questionable 'too much', careless side of run-ahead, I think RA
> attracts people because of the multi-emulators aspect, but also a lot because of the
> great shaders, some of the convenience features, and maybe also the fancy UI.
> Nothing of that in RA would be bad per-se if it wasn't going too far and messy in
> places. Though IMHO the opposite (too rigid, complicated and austere) is also bad
> because it's a stinker for the user.
> Best world would be 'as much optimization and convenience as possible as long as it
> doesnt break emulation and respects peoples work', but today it's more like opposing
> parties each radicalizing on their own ideologies.
>
> I think ultimately MAME will be almost everything people wish for and more, maybe by
> itself, maybe with the help of a much polished dedicated external FE.
> But since MAME's busy being much, MUCH more than just a frontend with features, takes
> no detours and is very strict, also now does a lot of obscure niche machines
> emulation for expanded preservation, it all naturally takes a lot of time, during
> which it's beaten in popularity by opportunist things like RA that are not nearly as
> busy, don't care about doing it dirty and speak only to retro arcade & console games
> fans who are the considerably bigger demographics. Easy.
>
> Easy, yet that pocket money bounty shows a pathetic side of their project. Did MAME
> ever buy development?
How is GroovyMame dealing with input lag? My understanding is they only just recently implemented the beam racing technique. If that's true, was the previous method a hack job?
How is Groovy's system reqs compared to mainline?
Can you provide some examples of these lag free flat panels? I think even the best ones still add 1-3 frames. Could be wrong.
You still have the additional lag intruced by the emulator itself however many frames that is.
People who just want to play games aren't interested in swapping perfectly good TVs, computers, etc. If there is an available solution that gets them the results they want right then with what they have on hand, they're going to jump on it.
Again, just offering up real-world observation.
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: LensLarque]
#378897 - 10/08/18 08:20 PM
|
|
|
> The MAME info screen at game launch, or mame.info, shoud tell the hardware's default
> original lag like it does resolution and refresh.
> That would maybe stop people from doing silly tweaks with no idea about what lenght
> of delay they should seek for accuracy.
>
Actually it's more likely that MAME shouldn't even display resolution, since it seems to be a source of confusion for people.
Also in most cases there's a single, or double buffer on the sprites, that doesn't necessarily apply to tilemaps, or palette or anything else, just because the hardware lags the sprites by a frame doesn't mean it lags everything else (sometimes the software does this instead to keep everything in sync) Sometimes these buffers are automatic, hardware controlled, other times the copy is triggered by software.
You're asking for an arbitrary number that can be measured against any number of things, not something that can simply be derived from hardware specs.
The Cave CV1000 hardware for example has no inherent lag (it's a blitter, you could blit to the screen at any point and flip buffer at any point) but the way it's programmed (to avoid sprite glitches by rendering to an offscreen buffer etc.) contributes towards making the games laggy.
> Ideally there would be a button to press ingame (like F11 for speed) so the delay
> information would appear in a corner of the screen ingame, with the game's and the
> sync option if any used, for instance;
> [GAME: 2 frames, SYNC 3 frames]
>
> This could be then required to appear in a replay video for it to be trustable.
>
> Of course RA by its design could still get around this, unless there's means to
> prevent even that.
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: DiodeDude]
#378902 - 10/08/18 09:30 PM
|
|
|
> How is GroovyMame dealing with input lag?
Quoting a small portion of what you can read on the eiusdemmodi website (the guides here are a bit outdated but this still stands):
Quote:
The frame delay feature actually serves two purposes:
- Delaying the emulation of a frame in order to get the most up-to-date input state before going into the emulation itself
- Bypassing a frame queue that's built in the ATI video drivers when Direct 3-D 9 is used which adds a lag of 2-3 frames by itself (be aware that Direct 3-D 9 Ex already bypasses it, so there's no need for enabling frame delay with this version of the API for this purpose; just under plain Direct 3-D 9)
Basically reducing the lag that comes after the core emulation to one frame, then depending on the game and your PC's strenght you can adjust frame delay to conquer even more terrain over that last remaining frame.
It works on nVidia GPUs just as well afaik. AMD ones are compulsory only for using with crt_emudrivers.
> My understanding is they only just recently
> implemented the beam racing technique. If that's true, was the previous method a hack
> job?
It's just two different methods achieving the same level of lag reduction, but beam racing when it works is much less resource-hungry.
Problem is unlike frame_delay it doesn't work with every MAME driver.
> You still have the additional lag intruced by the emulator itself however many frames
> that is.
In short you have the core emulation (driver) which assuming is coded correctly by the MAME devs produces its own delay which is the same as the original game/hardware and we shouldn't defeat if we care about shit being accurate and people playing fair.
Then there's what comes after which is mostly frames used to synchronize the picture to the display, and this is what frame_delay AND beam racing work on, NOT the core emulation's natural delay.
Only ShupMame before by using hacks denaturing the proper core emulation, and RA with run-ahead when it's abused (set to more frames than it should), are touching what shouldn't be.
> How is Groovy's system reqs compared to mainline?
Same, no additional cost when you only set it to bypass the frame queue, it's when you use frame_delay to 'assault' the last remaining undesirable frame that it demands more juice.
With that use compared to run-ahead it is not much different in terms of muscle requirements.
Understand: it's not that I find run-ahead bad, it's pretty great! the problem is that it can be used to produce abusive lag reduction that defeats even the original game hardware's own natural lag, which is anti-accuracy, allows the user to overperform those playing on real hardware or normal conditions emulation, and this 'cheat' ability is basically what run-ahead is popular for as we could see from many press articles and even giving people the motivation to make and share a build like that ShmupArch which is stupid.
The excuse of that cheat ability 'benefiting people who own laggy displays' is as poor as the frequent complaint that emulation requires a strong PC anyway.
One wants to game in good conditions using emulators with cutting-edge features like lag reduction and shaders ? : he must buy a good PC and fast display and stop kidding. Often the same people have no issues playing PC games on a monster pc, latest PS4/Xbone games on a fancy 4K TV, or mobile games on a $800 smartphone. Yet they want the best performance for their cheap student laptop or RPI3. Well no.
> Can you provide some examples of these lag free flat panels? I think even the best
> ones still add 1-3 frames. Could be wrong.
Yup that's wrong. There's a number of reviews websites that have been around for many years that test lag among other aspects, for monitors and also TVs.
tftcentral, pcmonitors, Rtings, displaylag etc to name only a few. there's also blurbusters site and forums for more learning and info.
A lot of people though do not fully get what they read there, because they don't know much about how flat panel displays work and what the readings (which are not done exactly the same way depending on the site) mean.
Anyway there's been many low and lagless flat panels available on the market over the years, starting to draw the frame at way under one frame of delay, I've owned and tested many myself, telling you about model names would be pointless because the product series are renewed almost evry year and the availability varies depending on the zone and sometimes even the country. Go visit specialized websites, they also often provide detailed guides to help readers.
> People who just want to play games aren't interested in swapping perfectly good TVs,
> computers, etc. If there is an available solution that gets them the results they
> want right then with what they have on hand, they're going to jump on it.
> Again, just offering up real-world observation.
I know people just want to have fun, but what surprises me is how fiercely they will defend what they've found and gives them immediate satisfaction, against people who know better, just because hearing the possibility that the thing they love and the ideal situation they've built around it in their minds, might not be as cool as they thought, is too annoying or even insulting to some.
All I've learned over the too many years that I've been following and using all possible kinds of hardware and software stuff in the world of 'retro' gaming is that I'm retro too now...er I mean, that in our case here proper core emulation, running on proper hardware, with proper non-destructive settings and features whatever they are, is what to desire. Compromising with hacks and dodgy roundabouts that disrespect the essentials is only extremely rarely worth it, should be used with much precaution and only temporarily.
I'm not against options that bring closer or to exact accuracy, I'm not even against conveniences such as savestates and autofire, I'm against what betrays the code supposed to reproduce the real world, and against stealthy use of conveniences.
Conclusion; I like run-ahead, but it should be limited on a per-game basis to never allow to go down below the game's natural lag. And people should care about buying good displays, if we stop caring about the products performance, manufacturers will do too, and trust me it's real: several have made effort regarding things like input lag only after hearing customers complain for many years.
A TV with over 1 frame of lag even in game mode will never be one suited for fast gaming period.
Regarding lag reduction in mainline MAME; maybe it will happen some day, when they have found an acceptable solution and they have time to include, after all they never said that thay would never provide any, just that we can deal with that on our own in the meantime, with alternate builds or just buying a FreeSync or G-Sync setup.
protip: even some TVs feature FreeSync now, nVidia also make TV-sized G-Sync monitors, and with HDMI 2.1 variable refresh rate (VRR) will become another standard.
|
> MAME isn't about playing the games anyway.
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: Haze]
#378903 - 10/08/18 09:45 PM
|
|
|
> You're asking for an arbitrary number that can be measured against any number of
> things, not something that can simply be derived from hardware specs.
But among all the things that the hardware does internally there's a peak value that matters to the player isn't it?
Most times you're playing the action with a layer of sprites, shouldn't that value be what counts for peak/total lag of the hardware, assuming it all happens within a frame?
If so that's what should be referenced IMHO.
Anyway I think the more info the better, because the more you remove the more incorrect things people assume, and we clearly need to understand more, not less.
EDIT: okay maybe you're giving me a developer answer because you don't think like a user.
I'm talking about input lag in MAME, the one we can count in frames, each game hardware has a number of those, some react to the next frame, some need 1 more, 2 more, etc.
Then on top there's the frames used for syncing to display if we choose waitvsync or something.
That (initial) number of frames is the one I think should show somewhere. (and optionally the ones used for sync to display)
EDIT2: or are you telling me that the translation in a number of frames in emulation isn't fixed in a set number to a 'cycle' ? if so how come we can always count the same number of frames when we try a particular hardware for input lag?
|
> MAME isn't about playing the games anyway.
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: LensLarque]
#378905 - 10/08/18 10:34 PM
|
|
|
I'm telling you that you're asking for metadata that can't be derived from hardware directly (in a 100% logic based way) and that in most cases it's down entirely to the programming of the game.
It's information that is completely irrelevant to MAME or how MAME works. We emulate things, accurately where possible.
> > You're asking for an arbitrary number that can be measured against any number of
> > things, not something that can simply be derived from hardware specs.
>
> But among all the things that the hardware does internally there's a peak value that
> matters to the player isn't it?
>
> Most times you're playing the action with a layer of sprites, shouldn't that value be
> what counts for peak/total lag of the hardware, assuming it all happens within a
> frame?
>
> If so that's what should be referenced IMHO.
>
> Anyway I think the more info the better, because the more you remove the more
> incorrect things people assume, and we clearly need to understand more, not less.
>
> EDIT: okay maybe you're giving me a developer answer because you don't think like a
> user.
> I'm talking about input lag in MAME, the one we can count in frames, each game
> hardware has a number of those, some react to the next frame, some need 1 more, 2
> more, etc.
> Then on top there's the frames used for syncing to display if we choose waitvsync or
> something.
> That (initial) number of frames is the one I think should show somewhere. (and
> optionally the ones used for sync to display)
>
> EDIT2: or are you telling me that the translation in a number of frames in emulation
> isn't fixed in a set number to a 'cycle' ? if so how come we can always count the
> same number of frames when we try a particular hardware for input lag?
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: Haze]
#378906 - 10/08/18 10:49 PM
|
|
|
Then sorry to insist but what are those frames that we can count from each game hardware ?
In the eyes of users this is what we understand as the translation of the game hardware 'lag' in emulation environment.
If the emulation of the harware is correct then this number of frames (even if it would be more understandable in miliseconds) should be an indication of time lenght we can at least a bit rely on, shouldn't it?
No way it doesn't mean anything at all...
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: LensLarque]
#378913 - 10/09/18 06:31 AM
|
|
|
> Then sorry to insist but what are those frames that we can count from each game
> hardware ?
> In the eyes of users this is what we understand as the translation of the game
> hardware 'lag' in emulation environment.
> If the emulation of the harware is correct then this number of frames (even if it
> would be more understandable in miliseconds) should be an indication of time lenght
> we can at least a bit rely on, shouldn't it?
> No way it doesn't mean anything at all...
The majority of the time you're counting it from the game software, lag that was programmed into the games.
As I said, at the very most you have a small handful of sprite chips that actively triple buffer the sprite list without software intervention, but that's a tiny handful of games, and only one chip in the setup, it tells you nothing directly about how much input lag the game will have. At the very most this would give any game using such a chip a 2 frame delay from the video hardware, but that is extremely uncommon.
On the same hardware, in many cases, you could write a 'demo' that used screen timing and palette changes only to do something that changed the colours on screen with a 'next pixel' lag, since that part of the video memory is read every pixel by the hardware.
Most of the time you measure lag it's due to the game programming, which MAME knows nothing about. Sometimes that programming is how it transfers values between multiple CPUs, the sync points in the actual game, sometimes it's active buffers in the game code so that the game can 'look ahead' (ie cheat the player for difficulty) sometimes it's active buffers in the game code so that incomplete frames don't get sent to the hardware. MAME knows *nothing* of that. Sometimes the lag is from internal MCU programs etc. that we run, but aren't actually well coded (a number of Namco games suffer from this) but again that's *software* not something that MAME knows by hardware.
You want an over simplified value that isn't based on actual logic but instead 'how the game plays / how the game software was written' MAME presents things based on actual logic, MAME isn't about 'how the game plays' MAME runs the code, it doesn't care about how the game was programmed.
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: Haze]
#378914 - 10/09/18 07:51 AM
|
|
|
How the game play in MAME is what I'm talking about, this is what matters to everyone, and why to attend to the matter of lag things like frame_delay and run-ahead exist.
In practice when we play MAME this lag appears to us and we can at the very least count it in frames between the time we input (action) to when the reaction is seen on screen (reaction)
Additional frames used to sync to screen notwithstanding, as far as we've seen the 'initial' delay consistent, each emulated hadware produces a number of those frames from input to reaction.
And this is the one lenght that we understand corresponds (even if maybe not an accurate translation) to what we can have in the emulated game environment, and we qualify as the original game hardware's lag.
I think either you don't get where a user-player stands, or you're giving me the answer that concerns the developer point of view, which is probably the right one for someone who would like to understand all what it's about but is less interested in knowing about what it translates to in the real life practice, and yet is verifiable when playing games with MAME.
Maybe as a dev it goes against your way of thinking to speak of it in terms that would be relatable to the user/player for the matter that concerns him.
Don't get me wrong I'm not criticizing you there, and I believe I've got a portion of what you said, but if you remember my idea was to add some form of information about what indeed happens in MAME delay-wise and the user experiences while playing, because I think it would prevent a good number of misunderstandings (again at a use-player experience level) and therefore limit misuses in practice (driver hacks, abuse of lag reduction like run-ahead, stealthy 'cheating')
Now if discussing this from that perspective is something you refuse then nevermind what I asked, and please again don't take offense, remember you're not talking to an engineer or a developer here, just a user-player who loves MAME.
What I'm thinking of can probably be done outside of MAME without your involvement (even if of course I think it's much, much better when actual MAME devs are involved)
EDIT: last attempt from my side; were you actually simply trying to tell me "the lag in real life environment (pcb + crt) is not the same thing as the lag in MAME" ?
If so just try to understand that if you then also say that MAME emulates the game-hardware accurately, as users playing we are naturally driven to think that we can trust the lag frames we can count in MAME.
Edited by LensLarque (10/09/18 08:14 AM)
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: LensLarque]
#378918 - 10/09/18 08:44 AM
|
|
|
I'm starting to find your posts somewhat abrasive.
Yes, these things can be measured on hardware, but they're entirely to do with how the game is programmed in most cases, nothing to do with the actual hardware.
NeoGeo for example has 'next line' response for most things, including sprites (which is why you can do raster effects on sprites) but plenty of the games have measurable input lag due to how the games are programmed. MAME has no way of knowing that, or communicating that information back to you. Systems like the Genesis are 'next line' too. It's meaningless however, because the games are almost never programmed to take advantage of that, the game code buffers inputs and buffers sprite lists, that is where most of the 'lag' people are measuring 'with hardware' comes from.
In a 'best case' scenario MAME will be 1 frame more laggy than the original games due to having to compose the screen to a buffer for the video card to present. If you start turning on options that specifically add extra buffers then it will be more. If the game code (software) is out of sync with when your PC reads inputs / MAME gets inputs from your device, then there can be another, but again, that comes down to the software programming of the game, something MAME does not know about. PCs and original hardware don't work in the same way.
As I said before, you're asking for something which outside of running the game, and having a specific piece of software running, cannot be summed up in a simple number. This is not something MAME can know.
MAME does not think as a 'player' as it is not a player, it is a piece of software, it is not self-aware.
MAME will not be following projects like RetroArch down the ugly path of databases for per-game hacks of things that are completely irrelevant to emulating a system properly. That is the wrong direction.
Techniques like Beam Racing, which requires a lot more effort to actually do right, can take out the extra frame of lag from the PC side and match how the games would run on hardware (to the nearest line, not pixel, but nobody is measuring response times in pixels right now) Run-ahead is an ugly cheat. Unfortunately as people would rather cheat it seems there is less incentive to do it properly (as doing it properly actually will requiring rewriting every single driver to have 100% proper line rendering and buffering logic emulated at the exact times the hardware does it)
At this point I'm just repeating myself, and will not be responding further.
> How the game play in MAME is what I'm talking about, this is what matters to
> everyone, and why to attend to the matter of lag things like frame_delay and
> run-ahead exist.
> In practice when we play MAME this lag appears to us and we can at the very least
> count it in frames between the time we input (action) to when the reaction is seen on
> screen (reaction)
> Additional frames used to sync to screen notwithstanding, as far as we've seen the
> 'initial' delay consistent, each emulated hadware produces a number of those frames
> from input to reaction.
> And this is the one lenght that we understand corresponds (even if maybe not an
> accurate translation) to what we can have in the emulated game environment, and we
> qualify as the original game hardware's lag.
>
> I think either you don't get where a user-player stands, or you're giving me the
> answer that concerns the developer point of view, which is probably the right one for
> someone who would like to understand all what it's about but is less interested in
> knowing about what it translates to in the real life practice, and yet is verifiable
> when playing games with MAME.
> Maybe as a dev it goes against your way of thinking to speak of it in terms that
> would be relatable to the user/player for the matter that concerns him.
>
> Don't get me wrong I'm not criticizing you there, and I believe I've got a portion of
> what you said, but if you remember my idea was to add some form of information about
> what indeed happens in MAME delay-wise and the user experiences while playing,
> because I think it would prevent a good number of misunderstandings (again at a
> use-player experience level) and therefore limit misuses in practice (driver hacks,
> abuse of lag reduction like run-ahead, stealthy 'cheating')
>
> Now if discussing this from that perspective is something you refuse then nevermind
> what I asked, and please again don't take offense, remember you're not talking to an
> engineer or a developer here, just a user-player who loves MAME.
> What I'm thinking of can probably be done outside of MAME without your involvement
> (even if of course I think it's much, much better when actual MAME devs are involved)
>
>
> EDIT: last attempt from my side; were you actually simply trying to tell me "the lag
> in real life environment (pcb + crt) is not the same thing as the lag in MAME" ?
> If so just try to understand that if you then also say that MAME emulates the
> game-hardware accurately, as users playing we are naturally driven to think that we
> can trust the lag frames we can count in MAME.
|
|
|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
[Re: Haze]
#378919 - 10/09/18 09:29 AM
|
|
|
> I'm starting to find your posts somewhat abrasive.
I was afraid you would think that, but no, in fact I'm simply struggling to communicate with you because you're using quantity of information to explain, some I understand, some that don't make sense to me yet no matter how hard I try. Sorry.
> In a 'best case' scenario MAME will be 1 frame more laggy than the original games due
> to having to compose the screen to a buffer for the video card to present. If you
> start turning on options that specifically add extra buffers then it will be more. If
> the game code (software) is out of sync with when your PC reads inputs / MAME gets
> inputs from your device, then there can be another, but again, that comes down to the
> software programming of the game, something MAME does not know about. PCs and
> original hardware don't work in the same way.
Yes there you're talking about what I'm trying to understand/learn.
So, you're saying that (leaving the options to buffer to sync the the display aside) there's
- at least 1 frame to compose the picture
- and maybe another one or two depending on the circumstances from things like the game software itself, or the dealing with inputs.
And that explains why some games respond the next frame, some require two, or more.
If I finally got it and that - from what I understand now - defines the base driver lag in MAME before we make things like sync options or whatever that might add more frames intervene.
And if I'm still following you it can then be radically different, and potentially higher by a few frames, from what you can experience from the real life situation (pcb + crt)
Okay then, so that information tells about the lag on the MAME side and is indeed measurable in a number of frames, which is at minimum +1
Finally all that would mean that in order to apply a realistic lag reduction that would bring the experienced delay to a realistic-enough value close to the pcb's, it would have to be based on the original hardware's live average lag measurements, and not on how much frames MAME uses, nor from an arbitrarily chosen unique number of frames reduction down to 1 frame anyway.
So in fact there isn't a single build derivative that does the best thing or they're all too random(?)
Shmupmame hacks cluelessly break the correct behaviour, frame_delay and beam racing only get us close to MAME lag (which may or may not differ a lot from the real thing) minus sync buffers, and run-ahead is used to remove a number of frames but you would first need to know how much really is good or not to remove on a game-by-game basis, which is hardly any obvious at all with the information we have, globally speaking.
So, again if I got it well, this paints a rather chaotic picture of the whole lag reduction thing.
Maybe what I was asking about would be better in the form of a consultable detailed info of the MAME chain that is running while you're playing, and translated into that number of frames we can count.
Wouldn't change the situation, but that'd still clear a number of myths and help some simply better understand what's going on during play.
Anyway I'm going to stop there because i'll probably only further increase your irritation whatever I write. 
Thanks anyway, as I think I understand more on the topic now.
EDIT: okay i think I see where something went wrong in our communication; i've always thought "MAME emulates hardwares, not games", which is womething i've read a number of times in the past, so i've always thought it right to associate the two as the same thing in MAME, which is why I write 'game-hardware' for instance.
It took me a moment to realize my error, and I can say now if that if you took me literally about the 'hardware lag', if it's not the one that matter but rather the game's overall (software running on hardware) one, then of course this is the information that I value.
This is the problem when you're the layman like me, with a baggage of wrong knowledge and assumptions, while talking with developers asking them to explain complicated stuff: they're so educated that it's impossible for them to buffer their thinking and wording down to that typical low level of user talk, and both sides easily get irritated.
Yet i think this is necessary and valuable, it might be just me there, but int he end I'm convinced translating with the purpose of demythifying for the general is crucial (again because if you don't then RA & Co. will keep on winning the hearts of people, for great injustice.
Edited by LensLarque (10/09/18 10:34 AM)
|
|
|
|
Re: Beam Racing
[Re: Haze]
#378991 - 10/15/18 08:56 PM
|
|
|
> Techniques like Beam Racing, which requires a lot more effort to actually do right,
> can take out the extra frame of lag from the PC side and match how the games would
> run on hardware (to the nearest line, not pixel, but nobody is measuring response
> times in pixels right now) Run-ahead is an ugly cheat. Unfortunately as people would
> rather cheat it seems there is less incentive to do it properly (as doing it properly
> actually will requiring rewriting every single driver to have 100% proper line
> rendering and buffering logic emulated at the exact times the hardware does it)
Isn't that what ZX Spectrum emulation would require in order to achieve 100% accuracy? If that's the case, maybe its driver could be used for testing any Beam Racing implementations, whenever somebody wants to attempt a rewrite of it.
|
|
|
|
Re: Beam Racing
[Re: ICEknight]
#379002 - 10/16/18 06:59 AM
|
|
|
> > Techniques like Beam Racing, which requires a lot more effort to actually do right,
> > can take out the extra frame of lag from the PC side and match how the games would
> > run on hardware (to the nearest line, not pixel, but nobody is measuring response
> > times in pixels right now) Run-ahead is an ugly cheat. Unfortunately as people
> would
> > rather cheat it seems there is less incentive to do it properly (as doing it
> properly
> > actually will requiring rewriting every single driver to have 100% proper line
> > rendering and buffering logic emulated at the exact times the hardware does it)
>
>
> Isn't that what ZX Spectrum emulation would require in order to achieve 100%
> accuracy? If that's the case, maybe its driver could be used for testing any Beam
> Racing implementations, whenever somebody wants to attempt a rewrite of it.
Beam Racing is not related to ZX Spectrum emulation, no, it's a presentation technique that happens to require emulation that is already scanline accurate in order to implement.
For ZX Spectrum emulation you do need accurate screen timing, you actually need accurate *pixel* timing, as many effects change things during the horizontal scan, right before video data is pulled. Byuu found the same for that one SNES game which changes the palette during the horizontal scan at a very specific position in order to draw a shadow.
*without* scanline accurate rendering Beam Racing becomes difficult as the rendering / execution load across your screen is unbalanced, and once using techniques like beam racing you're effectively dealing not with 'frames per second' but 'scanlines per second' and your emulation must be able to deliver each single scanline (assuming 240 lines, 60 fps) within 1/14400th of a second as opposed each single frame within 1/60th of a second. If any one *scanline* doesn't render in time then the entire framerate drops.
The problem with a lot of systems in MAME and other emulators is that they're framesynced and assume that everything is drawn at one specific point in the frame which means the load is heavily unbalanced (effectively the last scanline takes 240x as long as every single other one) and in many cases real buffers that existed on hardware to prevent graphic corruption if spriteram etc. is updated midscreen aren't being emulated, and CPU execution times don't have to be as accurate either as long as they're relatively accurate within frame. Simply forcing 'scanline' updating to split the load evenly for an emulation that hasn't been properly developed will create a lot of glitches due to other bad assumptions in the emulation.
So yeah, Beam Racing demands accurate emulation to implement, but visually accurate emulation doesn't demand beam racing.
|
|
|
|
Index 
Threaded 
I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
Reply
[Re: 
