Screen Refresh slider: Groovy cake and eat it w/out custom modes/Emudriver ?

[schmerzkaufen]

So that actually works ? 

I've always been playing Groovy on a 'normal' PC (W7, i5k 4+GHz, mid-range AMD's), because that's supposed to be the kind of hardware required to experience Groovy's features.
(edit: note even though I use a LCD monitor it's still one that specifically fully supports custom modes w/ Emudrivers so not too far from a classic CRT setup)

And for a long time I was also convinced my old everyday laptop (W8.1, 1.9GHz, nVidia 820m Optimus) was too weak, and its crappy intel+nvidia fake GPU tandem as unfit as it goes, not being able to produce custom modes/refreshes nor use frame_delay 1.

But today I've found about two things (using Groovy 0.214):

1. even just frame_delay 1 was unstable and unusable, for any game, but not because of a CPU/GPU performance issue; instead quite high vsync_offset values were required for all games (+/- 500~600) over a 900p display) which I would never have suspected because usually when the tearing line to eliminate is located as low as the middle of the screen or lower the recommended action is to decrease frame_delay before attempting again to find a working offset.
Normally this is a good recommendation because with tearing so low down the screen the vsync_offset fight is typically lost, but not in this case where extreme vsync_offset actually solved stability and made frame_delay useable even if only at minimal levels on this pc.

2. if you can't use custom modes whether dynamic with an amd and emudriver, or static with a discrete nvidia, also because your display won't take anything besides 60Hz anyway, there's still a way to conserve the smooth scrollings and correct refresh speed;
I've set sync_refresh_tolerance to 7 so all games down to 53Hz are covered by syncrefresh, and then for every game while playing I have adjusted the Screen Refresh Rate slider to a value closest to 60Hz (slider granularity is bad but I guess that can be set elsewhere like in the cfg's)
While doing this with frame_delay on, the game will go full speed unthrottled, but just moving the frame_delay slider once will set the game back on sync rails to the proper speed, like set fr delay to 2 then back to 1, done.
Check the speed% with F11 so it's at 100% but you'll realize the obvious with your eyes and ears anyway.

note; Screen Refresh Rate slider appears only if you have set 'cheat' to 1 in the mame.ini

So that's it, I got;
- frame_delay working/stable on a PC I though for years was too weak to handle even level 1
- with proper smooth scrollings and refresh speed, on a PC and display (nb: the laptop's integrated) without custom modes nor Emudrivers support

HLSL and Portaudio work fine with that by the way.

So besides the lacking granularity of the slider and that you have to tickle frame_delay every time you play a game, it's still an incredible discovery for me, considerably improving the experience on a computer I thought was hopeless for Groovy, and I wish I had known about that long ago.
I mean I've always read and repeated to people that frame_delay is heavy as hell on flat panels and demand a poweful pc, and that its smooth sync and proper refresh abilities were limited to autosync's syncrefresh/triplebuffer sped-up or choppy choice if your gpu & display lacked custom modes support...

So have I busted a myth here and found a new awesome way to configure Groovy and fully benefit from its features on many more PC's than we thought possible ? (and with incredibly much less hassle)
...
Or is there a huge issue/drawback I'm not seeing ? 
From my testing today this works amazingly well, with some modifications that would make a great alternative to the 'full course groovy on a large hardware set with a side of emudrivers and vintage tweaking'

[schmerzkaufen]

*tumbleweeds*

Not much interest I would I have guessed, probably because TL;DR or people don't get what this is about, but it is fantastic anyway. 

Just played on other random external displays and it works too if need to say.

Of course it's only been possible since the implementation of the frame_delay slider with ingame on/off switching, so since 0.205 IIRC, and made easier since the implementation of saving sliders settings.

Only issue I've met so far with that method is that apparently a -I hope- small number games will refuse to work, like I've found only one so far -dodonpachi- which freezes when you touch the refresh slider (the other cave games on same hardware are fine tho so this is odd)

If Groovy could be modified to work specifically for that method, if technically doable and improve-able, it would probably deserve its own fork.
I mean that's kind of a Grail here because most users could benefit from full Groovy features on any PC without being bound by strict hardware/driver requirements.

[cools]

Does Frame delay 1 have much impact on latency, or are you just using it as a trick for the refresh rate?

[schmerzkaufen]

Does Frame delay 1 have much impact on latency, or are you just using it as a trick for the refresh rate?

Well if you have followed the recent input lag test thread with oomek's fantastic findings, then yes, just frame_delay 1 brings the delay to just 1 frame (0 is 2 frames)

But most importantly it means that it works at whatever level 1~9 your PC performance and game software will allow, so you get under 1 frame of lag just as any normal use of frame_delay in your usual Groovy config.
And that on any game without sacrificing the refresh and smoothness.
No required custom modes compatibility nor specific drivers on either the GPU or display side.

It's basically 'have your cake and eat it' Groovy. The normal way is to constraining for average users, lets be honest most of them give up when we get to the part where custom modes and the required hardware compatibility are compulsory if they really want to fully benefit from Groovy's features, not experience just a fraction/glimpse of it.

If we had an alternate build modified to work with that different method I've come across, it would be much more 'universal' and undoubtedly more popular.

[Calamity]

Your will to experiment is something to praise, I like that.

I have adjusted the Screen Refresh Rate slider to a value closest to 60Hz

Regarding this, for years some users have built their own modded MAME to force all games to run at 60 Hz. For me, this means a head-on collision with GM's original purpose (even if GM, to some extent, allows you to deviate from rectitude with syncrefresh tolerance).

But I'm not a puritan. And I believe that even in perversion, there are degrees. Smooth scrolling at incorrect speed is less bad than correct speed with tearing or choppy scrolling.

I do appreciate your proselytism among LCD users. Anyway, we're getting closer to a point where VRR monitors will be ubiquitous, and looking backwards we'll be surprised of all the eccentricities we've been forced to do in the way in order to put up with fixed-refresh LCD's limitations.

[schmerzkaufen]

The refresh might not be but the game speeds I get doing this are not incorrect, they're normal to me, not accelerated, what I witness is basically the same I get using Groovy the normal way with custom modes on a compatible monitor.

edit: I used sync-refresh-tolerance at 7 only because starting from an already syncrefreshed situation is easier than bringing autosync into the process.
but I guarantee you that the games run at the correct speed.

And the other builds I've seen using that method don't have Groovy's frame_delay nor equally smooth scrollings, not the saving CPU sliders, they're not Groovy.

I don't see what harm an alternate co-existing version of Groovy aimed at average users would do, it would only be goodness for many people.

Groovy has basically been ignored by the majority because it's too complicated in that it requires to be set up for specific hardware to really deliver,
but for the average player who would love to enjoy Groovy's goodness at a level accessible to him, that what's going on in the background is not technically running the "correct way by dev geniuses and engineer power user standards" doesn't make a bit of difference if the result he's experiencing is the same.

Do we really have to ignore this for the sake of purity so Groovy remains forever on its ivory tower reserved to skilled users, looking down on peasants even those who fail honestly trying ?
If you think yes, then that's mamedev-like isolationism, and with that there was no point in any of us having patronized the rest of the emu scene telling them they're doing things wrong.

In any case even if not following dev tech religion by the book, for players such an alternative build would still be better than RetroArch or ShmupArch, ShmupMame or whatever alternatives they find for low lag MAMEing because they don't have better.
This is obviously THE best alternative that could have been but never was, for people who don't/cAn't build/invest in a dedicated PC and monitor nor in the cab-building adventure because all of that is beyond their skills and/or means.

And I don't agree at all that VRR has become nearly enough mainstream, still mostly only costly GPU+display combinations allow it, and out there the huge majority of people definitely still don't own such hardware, lots of people precisely have just a very average laptop.
EDIT: fyi 'there is VRR now' is the same thing mamedev were saying like also nearly 10 years ago to justify that there was no need for them to attend lag and refresh issues.
they were gravely mistaken.

An alt build of Groovy like that, kind of a ''democratized Groovy for the non-elite masses with lame PCs and displays'', would sure have lots of users for yet another decade.

I've spent I don't know how many hours trying to help people use Groovy, maybe about 85% of that effort in vain and I'm being optimistic, so I know users, not the usuals here who are too few and too skilled, I'm talking about the average Joe players and what the hurdles are for them, I know what I'm talking about.

I can't create this build myself since this is way beyond my ability of course, but if neither you nor anyone can help then I'll just spread around the 'how-to' apply that method with the regular build.

I do appreciate your proselytism among LCD users.

In case you re not aware even if I don't speak people ask me all the time, often in private some because they're turned off by the dead/slow atmosphere of the forums or they're intimidated by the kind of either too laconic or too complex answers they're given.

I'm afraid no one here can realize realize how much good a build working specifically with that alternative method would bring, and would have since whatever time it's become possible.
Maybe years have been wasted, two fashions of Groovy could have coexisted all along.

[schmerzkaufen]

And for the Nth time I'm convinced this yet another case where I'm misunderstood / not trusted, and the validity of what I write is doubted by default.
This happened to me way too many times on this forum.

So to make sure I'm understood, I'll shout. 

WITH THAT METHOD THE GAME'S SPEEDS ARE CORRECT, NOT ACCELERATED, THE SYNC/SCROLLINGS SMOOTH, AND FRAME_DELAY WORKING

EVERYTHING WORKS RIGHT

YET NO CUSTOM MODES-COMPATIBLE GPU & MONITOR, NOR DYNAMIC w/ EMUDRIVERS OR STATIC METHODS ARE USED

As it is, it works with a trick to apply when you start a game, found one game not working with it, but overall the result is practically indistiguishable from the regular Groovy experience on a proper setup. Editing the refresh slider's value in the .cfg's might be necessary for more precision (I'm looking into that).

Don't believe it ? try it yourself... you'll have to be pretty convincing to explain I'm wrong and not seeing what I'm seeing, because if this is an illusion it's a pretty damn realistic one, it's like I'm playing on my main PC which has W7/AMD/Emudrivers.

I'll gladly accept that there is a fatal flaw I'm missing if you show it to me, but besides one reluctant game so far, I'm not seeing that fatal flaw. It just works. ¯\_(ツ)_/¯

[Calamity]

Hey schmerzkaufen,

Please don't feel misunderstood nor untrusted. Frankly, I was assuming you were aware that your method involves speed modification.

Do a simple test, launch loht, with and without your method, and use a stopwatch to time how long the intro screen lasts (the one with the clouds behind the letters).

In case I wasn't clear, I wasn't trashing your method: it's a way to apply frame delay where it's usually not possible. However, that's not enough to ensure sound synchronization.

I haven't tried it, but I think a more robust way to do this would be using the -speed option, with a factor of monitor_refresh / game_refresh.

[schmerzkaufen]

I think you're mistaken, I insist the speed of all the games I've tried is right, I kinda have experience with proper normal set Groovy, you know.

Not perfect as the slider's granularity isn't right as I already said but it can probably be fine-adjusted manually by editing cfg value, in any case the deviation is never even 1%, it's like when using the static method with several fixed modes like 54, 44, 56 etc.

This is not like when you use only syncrefresh/autosync with tolerance and the game's refresh is locked to 60 and therefore sped-up (F11 showing 104%, 106%, 110 etc).
Do you really believe I would mistake the two cases ?

Here it's definitely not the same, when I set the refresh slider to 60 and then give frame_delay nudge, the game's speed goes back to normal (F11 shows 100%) but smooth syncrefresh and frame_delay are maintained.

You definitely have to try. EDIT: didn't you even have a similar laptop ? it shouldn't be hard to reproduce, here I did it with 0.215 again, works fine.

I haven't tried it, but I think a more robust way to do this would be using the -speed option, with a factor of monitor_refresh / game_refresh.

I don't use command line, never got used to it never will no matter what it's too alien and unpractical for me especially for testing and tweaking, and I suspect you actually shouldn't do it this way in this particular case.

[Calamity]

F11 shows 100% because you're modifying the original machine speed. Please do the stopwatch test.

[Calamity]

You definitely have to try. EDIT: didn't you even have a similar laptop ? it shouldn't be hard to reproduce, here I did it with 0.215 again, works fine.

I have tried it today, on my laptop, you have my word.

I only tried loht, and I noticed audio issues immediately. Scrolling was smooth, indeed, but speed was accelerated, it's hard to notice because audio pitch, issues aside, is correct. Correct audio pitch creates the illusion of correct speed, but it's not.

I mean if this worked just like you say, it'd be the discovery of the decade and I would be proud to admit it, I swear.

[schmerzkaufen]

So instead of a stopwatch I've simply launched games simultaneously with the two computers side-by-side, and indeed the video speeds are not exactly the same and it's indeed sound producing the illusion.

But here's the thing; it's such a good illusion that I got fooled. Unless you use a stopwatch or put them side-by-side it's extremely hard to differenciate.
It's kinda like playing a good console port.

Sound sync issues: I've barely noticed them, you really have to try games very off-60Hz for that to be an obvious noticeable thing, yet still not big problem, and I even had Portaudio on.
I've been playing Xexex, R-Type, Tonma, Raiden DX, Raphero, for a few hours and the tradeoff is more than acceptable.
For games closer to 60Hz even less problematic, practically indistinguishable.

Speedup done in that fashion is more acceptable than the other way, from my experience using that Refresh slider is more benefit than problems, you get smoothness with the illusion of correct speed and access to frame_delay for low lag gameplay, it is such a relief compared to how narrow and limiting Groovy is without it.

For someone who doesn't have access to custom rates, only a fixed 60Hz setup, this is good, better sacrifice accuracy for a working illusion and more features.
Only issue is for useability because of the necessary little 'tickling' frame_delay for re-syncing trick, and at least one game I found so far (ddp) that doesn't work (how many more and why: no idea)

Okay this might not be worth a fork in your eyes but maybe an occasional alt build fixing those little issues if possible, like 'Anti-GroovyMAME' or 'GroovyMAME-for-60Hz-Peasants-Edition' for instance ? ^^

Or is it in fact what RetroArch already does ? (it does something different with the sound though it seems)
Even if that is so, I dislike RA's use of frontend, old versions of MAME, lack of access to certain ini controls, lack of MAME up-to-date-ness that works with with lag reduction and saving 'cheat' sliders, and run-ahead is a bad method for lag reduction anyway.

What RA does with MAME, or rather fails to do, an alternate Groovy would do much better, don't you think ?

In any case I'm certain now after about a year interacting with people that Groovy for LCDs, as it is now, is reserved to reasonably 'power users' niche with fitting hardware, the personal and equipment requirements are not much different than for CRT.
It was pointless of us advertising its 'superiority' when in the end only about 1/10 users showing interest are actually able to use it.
And it is not to be recommended to anyone out there who isn't motivated nor able to understand what it's about and deal with the requirements.
If Groovy had a co-existing RA-like alt build that works for a decent experience anyone could enjoy on any PC without being an above-the-masses MAME-er with specific hardware, then I would recommend that one alternative warmly to the 9/10 users who obviously can't deal with the 'real Groovy' requirements.

This way there would be two Groovy's, one for the skilled/equipped, one for the plebs... and, in fact, I wouldn't be surprised the latter would actually work as a pusher/motivator to the real Groovy.

So anyway for now I'm laying down my weapons, as over the year I've filled pages of support for people who were in large majority just overwhelmed by the complexity or disappointed they couldn't do it with their PC.
As much as I dislike RA for various reasons, strategy-wise I'm seeing things differently now, they aren't necessarily wrong if they can get the 9/10 to an accessible experience even if the results are not technically kosher.

Groovy already achieved technical perfection (well, the closest possible with what's available), so I don't see it progressing much technically nor in popularity in the future, you may one day successfully implement the auto-frame_delay and vsync_offset sliders, and port that system to other backends, which will be awesome, but in my eyes even with that it's gone stagnant, because the no-peasant-skills-and-pc requirements are still there to prevent broad accessibility.

And again I definitely don't see VRR become mainstream-enough anytime soon to make up for that, frame_slice/beam-racing is also a pipe-dream, so as things are RA will enjoy easily another decade being the most popular emu solution still with no competition.

[Recapnation]

I always thought of GM's LCD support as a side bonus; Calamity dislikes flat panels even more than I do.

Your proposal is essentially nullifying GM's point, which, in the end, is telling your peasants (and even the devs, or the whole industry, for that matter) the games deserve a better treatment. R-Type at 60 Hz is not R-Type.

[Substring]

Screens that can run rtype at original 55Hz will one day or another be just in museums. Expecting decent rendering only on high end monitors is reducing even more the possible users. It should be a user decision to prefer smoothness over precision, as long as it's clearly stated that the game won't run in its original state, and some differences can be noticed.

I remember a guy at retroarch saying that proper upscaling of most consoles can only happen on 4k monitors. Ok, but meanwhile, what should we do ? That's the same situation.

It wouldn't be wise to only stick to CRT simply because only these screens can render like in old days. I don't think GM's rendering quality deserves such niche end users. Of course GM's root essence is CRT rendering, but why "forbid" any other user to enjoy its smoothness on a flat panel ? Someone here is trying to give a a new impulse to GM's features, someone who knows much more than most users on GM, let's be a little more open minded

[schmerzkaufen]

I always thought of GM's LCD support as a side bonus; Calamity dislikes flat panels even more than I do.

Your proposal is essentially nullifying GM's point, which, in the end, is telling your peasants (and even the devs, or the whole industry, for that matter) the games deserve a better treatment. R-Type at 60 Hz is not R-Type.

You're exaggerating the reach/impact and purpose of my proposal and adding some unnecessary negativity to it, my idea is an alternative build with a different focus, precisely a bonus build. Nothing was said about touching or betraying the real Groovy, that bonus build wouldn't even need to have the same name, nor even be regular-released, I said it.

Also tons of arcade games console ports don't run at the original frame-rate, I've owned R-Types on PS1, it was definitely R-Type and doing the originals justice, many ports do even if they're not perfect carbon-copies, don't be ridiculous.
The purpose of that alterntive build would be something like that, and from what I've experienced it seems doable.

And thinking CRT only would be snubbery with guarantee to remain stuck on an ever-shrinking tunnel vision as CRTs slowly but steadily go extinct.
There's no way considering flat panels is 'only a bonus' in GroovyMAME, that would be stupid, flat panels are the present, reality, and the future.

Calamity worked awesome progress for flat panels and it's great, hard to believe he hates LCDs. But as fantastic as this fresh flat panels support is, it's at the same level of accessibility the 9/10 can't deal with.
They can't and it's not their fault, they're just not real geeks/nerds, just like me most people aren't, so Groovy's level of accessibility is just too much for the majority, I've witnessed it vividly all this year long.
They could all buy VRR equipment but unfortunately they don't it's still mostly owned and accessible to a minority that's focused on PC gaming, not retrogaming, I'm sure of it at least another decade is needed before we can say VRR's gone full mainstream and a majority of households has it.

But right now just open your eyes; only a handful of geeks are able to use Groovy as intended, what was the point then in our narratives to patronize RA or ShmupMame users telling them their stuff is wrong while swinging under their nose something better they can't really comprehend and touch ? even if absolutely not intended I've realized that was kind of condescending and a bit douchey, also counter-productive; Groovy has been badmouthed for being elitist or its performance BS just because people couldn't figure it out.

Or, well... seriously tell me guys, do you actually want GroovyMAME to remain only a tiny niche fundamentalist church build for a mole-people elite ?

Really this community is only 1 developer on whom practically everything weighs, with just a handful of more or less regular power users and occasional contributors to help, plus rare intimidated noobs taking a peek, overall the activity of a deserted church with passing monks exchanging only information that's necessary then going back to absence/silence.
There are limits to conservatism, immobilism, and mutism, seriously, it is necessary to confront the real world and no, it's not evil.

No way a side-dish like that alt build I'm thinking of would hurt Groovy, nor anything nor anyone, it'd only be good news, activity, and making some happy users.


PS: anyway, it does work even with the normal Groovy build, the little issues just get in the way of practical use and therefore hardly has chances of being adopted/popular in this state. hence the idea of an alt/bonus modified build specifically more convenient for using that method. welp.

[Calamity]

schmerzkaufen,

I can't beat your verbosity in this language that's so alien and unexpresive to me.

It's kinda like playing a good console port.

Exactly. That's what it is.

Changing the screen refresh slider is totally different from adjusting the speed with -syncrefresh.

Syncrefresh adjusts the "real world" speed but the emulated machine is totally unaware of this change: it's internal state is not modified.

On the other hand, by changing the screen refresh slider, you are in fact creating a new, alternative machine, one that never existed. This new machine preserves some parts that run at the original speed (cpu?, audio, input?,...) mixed with other parts that run a new, unexpected speed (graphics).

In many cases, you'll end up with a viable derivated machine, that outputs sound at the correct pitch, even if slightly accelerated by the effect of the overclocked graphics hardware. I believe this is the case when system timing is based on vblank.

But unfortunately, some other cases will produce a broken system, like with donpachi. In these systems, different hardware parts are so tangled-up that modifying the graphics speed will simply break the system.

Then, it's reasonable to think that some systems will appearently be unaffected by this change, while still might have issues that are not immediately obvious.

[schmerzkaufen]

So you're saying there's no way to modify Groovy to run in "60hz console mode' with syncrefresh and frame_delay, better than it currently does with my little trick-method ?

That's a bit hard to swallow since the number of games that run well when forced to 60hz with syncrefresh and refresh slider so far seems to be a large majority, not just 'some', there are little inconsistencies but with such configuration it's not perfect accuracy that matters anyway, it's smooth scrollings and lag reduction.

RA does something that, even if it's not the same as your syncrefresh, seems to rather successfully normalize things, so all games do work anyway no matter the system even if they're forced to 60.
What type of sync and audio trick do they use ?

Something that would bear similar results isn't possible with Groovy then ?

[Calamity]

Forcing all games to run at 60 Hz can be done with GM since the beginning, without breaking emulation, by means of syncrefresh, with the obvious trade off of altered audio pitch.

Syncrefresh "contains" old CabMAME's soundsync feature idea, though refactored. I wrote about it here.

I haven't revisited RA since long, but when I looked into it, they were doing essentialy the same thing. They called it dynamic rate control and claimed it was their invention.

In order to preserve audio pitch, you'd need to implement real time audio time stretching. This would be the "correct" way to do it. RA might have implemented this, I don't know.

RA can't certainly do the equivalent of adjusting the refresh slider since it runs MAME's "core" more or less like a sandbox so there's no way it could access those features. That's my understanding of it.

In short, if you want a bullet-proof force-everything-to-60-Hz recipee for LCD users, it'd be something like this in mame.ini:

Code: [Select]

monitor lcd
autosync 0
syncrefresh 1
triplebuffer 0
frame_delay 1
vsync_offset *

* depends on your system

I usually disagree with forcing frame_delay 1 in mame.ini but in this case it'll allow you to avoid the step where you need to enter the menu to fix the unthrottling issue. Then, for each game, set frame_delay as high as your system allows.

This, obviously, will change sound's pitch. No solution for this unless someone implemented audio time stretching (highly unlikely).


The other non-destructive solution that was suggested was implementing frame interpolation. This would be pretty interesting as an experiment, but I'm afraid it wouldn't be possible without a latency penalty, that would invalidate the approach in practice.


The "destructive" alternative of building a version with all screen refresh rates set to 60 Hz, at the cost of breaking a random amount of systems, is certainly one that someone might consider to build. It won't be as easy as it was a few years ago, when the screen device had a simple parameter called refresh, that you could modify. Now most systems have implemented the more correct "screen raw params" where the refresh rate is not a magic number but rather it's calculated from something similar to a "modeline". So it wouldn't be as "simple" as changing a refresh figure in a few hundred systems but you'd need to provide valid fake screen timings. It can be done, anyway.

If all you want is an option to force the refresh rate to exact 60 Hz regardless of what the driver specifies, I guess it can be done too, by just overridding the intenal screen refresh once the machine has started. Or one might add more granularity to the slider, if that's all what you want.

[schmerzkaufen]

Thanks Calamity, configuring mame.ini like you suggest works, I even get more liberty with frame_delay like that (can get slightly higher for some reason)

Then for the sound pitch I use the Screen Refresh slider which is indeed not very convenient, almost never falling on 60.

For instance esprade; the slider brings it to either 59.55 or 60.55

If I want esprade @ 60 I need to edit esprade.cfg and set

Code: [Select]

<slider desc="Screen Refresh Rate" value="2449" />Welp, just a bit annoying but manageable.

For games that refuse to have their refresh manipulated then I don't use that method period, no problem there aren't that many.

Overall this makes my Groovy experience on that crappy weak 60Hz-fixed laptop, much more enjoyable than before when I had only syncrefresh or triplebuffer to choose from and I couldn't get frame_delay to work at all.
This is good because I don't always have my main/real PC around and am often stuck for days with that laptop. 

The only bizarre thing is that now Portaudio crashes the emulator on start.


Well, no need for an alt build if we have that I guess. ^^ Then of course if in the future someone manages to implement the non-destructive techniques you mentioned, why not a '60hz Groovy Special Ed.'

[Substring]

Ever heard of libresample ?

[Paradroid]

But right now just open your eyes; only a handful of geeks are able to use Groovy as intended

Have you taken at look at The CRT Collective on Facebook? I'm constantly surprised by how many of those 11K members successfully get their heads around GroovyMAME. Certainly plenty of people I've never seen around these parts.

Not sure of Calamity's ambitions... world domination or a decent sized group of extremely satisfied CRT enthusiasts. Certainly the former goal has been reached.

[schmerzkaufen]

Doesn't change that it's still a niche, and a niche that can only shrink with the dying of CRTs. Even if CRT's the primary purpose of Groovy it ended up covering flat panels better than any other build.
I'm sure most of the regulars here haven't paid much attention to the many related changes Calamity's made in that area, but it's real, Groovy's the best for flat panels.

Still, even though thanks to that Groovy supports by far the greatest variety of displays and situations, there was - oddly - that single particular use case that we haven't really discussed not written about: configuration for fixed 60Hz environment...
...
...which happens to be what most people around the world deal with, and emulate on. I mean this is most emulator's and RetroArch's #1 configuration target, and we're talking about millions of users.

It is perfectly laudable that Groovy differenciates in being the most if not only one competent in actually adapting to hardware to play games in practically perfect reproduced original conditions, but it would be too bad that it's completely and intentionally closing itself to the lesser-to-non-accurate use that most people don't have any choice about.

I mean I've seen it, it's impossible to convert the crushing majority of average users to accurate emulation, they don't have the skills and hardware.
However they do appreciate lag reduction, smooth scrollings, they enjoy having at least that if accuracy is out of reach for them or their PC.

Anyway, Calamity originally stated the most basic configuration setting is "monitor     lcd" in the mame.ini, but as we know the only liberty you're given with that - if you want to benefit from frame_delay and smooth scrollings - is to increase sync_refresh_tolerance, which makes more games covered, but all accelerated both in video and sound.

Even if as Calamity demonstrated using the Screen Refresh Rate slider only creates an illusion of correct speed by bringing back the audio pitch to normal, what that brings is still a much more pleasing compromise situation, even if some games have audio issues or will reject the Refresh slider change.

So turned out that it was in fact a matter of knowing how to configure the mame.ini, which I didn't know and thereore though it wasn't possible and that '60Hz Groovy' might require an alt/diff. Glad I was wrong.

It works, like we're playing console ports then...

- Save for DoDonpachi and probably some other games that I haven't met yet, can't help it
- The Refresh slider granularity is way to low, manually editing the .cfg files instead allows to fine-tune to almost exact 60Hz but curiously they seem to wipe out the edit at some point
- Portaudio crashes the emulator right from the start, strange
- (placeholder in case)

If one day some better solutions to those little issues are found then of course they'll be welcome, but please Calamity no need to think about it too hard, playing at 60Hz is just meant for people who want to enjoy at least in part Groovy's goodness even if their skills and PC or display won't allow them to, it is a bonus configuration, not in any way betraying the main purpose and greatness of Groovy.

Thanks again for the help. /

[wp34]

But right now just open your eyes; only a handful of geeks are able to use Groovy as intended

Have you taken at look at The CRT Collective on Facebook? I'm constantly surprised by how many of those 11K members successfully get their heads around GroovyMAME. Certainly plenty of people I've never seen around these parts.

Not sure of Calamity's ambitions... world domination or a decent sized group of extremely satisfied CRT enthusiasts. Certainly the former goal has been reached.

The CRT Collective is a fun little Facebook group if you love CRT's.  I get a kick out of the photos people post when they find a CRT in the wild.  Thanks for the heads up.   

[schmerzkaufen]

So this is weird, since the Refresh slider doesn't seem to save in the .cfg's, I've tried to use 'speed' from specific .ini's, but that doesn't work as well.

 

EDIT; I can set the cfg's to 'read only' but thats no convenient at all.

EDIT2: nevermind the 'refresh slider not saving', rather it seems that if you attempt to use the 'speed' command from specific ini files, not only it doesn't work (refresh speed unchanged), but it also clashes directly with any existing Refresh slider entry in cfg, I even got some crashes dunno exactly how.

So it works okay with editing the cfg's, the only thing to make that less awkward would be maximum granularity for the Refresh slider (really maximum otherwise it wouldn't be precise enough) so there would be no need to edit manually anymore.

Or a way to make 'speed' effective from specific ini's, and without conflict...

EDIT3; some examples of Screen Refresh Rate slider values to manually edit in the .cfg's
it is simpler to tell by hardware and mention the games that eventually don't work, since they're kinda few

<slider desc="Screen Refresh Rate" value="0000" />

(cave) 2449 - except; donpachi, dodnpachi, dangun feveron
(toaplan1) 2387
(pgm) 830
(toaplan2) 363
(xexex) 5747
(m72) 4982
(cps2) 363
(raiden2) 4592

[cools]

Does Frame delay 1 have much impact on latency, or are you just using it as a trick for the refresh rate?

Well if you have followed the recent input lag test thread with oomek's fantastic findings, then yes, just frame_delay 1 brings the delay to just 1 frame (0 is 2 frames)

I hadn't spotted that, but I've just been back and forth in the thread for 15 minutes finding it - a patch that made it in 212 meaning that frame_delay 1 kills an additional frame of lag?

So this is weird, since the Refresh slider doesn't seem to save in the .cfg's, I've tried to use 'speed' from specific .ini's, but that doesn't work as well.

It's a cheat isn't it? Sadly they don't save at all.

I too admire your will to experiment, having done a ridiculous amount of MAME setting bashing over the years and kinda wish I still had the time to pursue it as a hobby. I'm sure somewhere there are posts by me describing getting baseline MAME running in the same fashion by adjusting the speed

In short, if you want a bullet-proof force-everything-to-60-Hz recipee for LCD users, it'd be something like this in mame.ini:

Code: [Select]

monitor lcd
autosync 0
syncrefresh 1
triplebuffer 0
frame_delay 1
vsync_offset *

* depends on your system

I usually disagree with forcing frame_delay 1 in mame.ini but in this case it'll allow you to avoid the step where you need to enter the menu to fix the unthrottling issue. Then, for each game, set frame_delay as high as your system allows.

This, obviously, will change sound's pitch. No solution for this unless someone implemented audio time stretching (highly unlikely).

Can the unthrottling issue be fixed? If so, could "monitor lcd" become a shortcut for i-know-this-is-wrong-but-the-game-cant-run-correctly-on-an-lcd-so-just-make-it-as-nice-as-possible ?

[schmerzkaufen]

I hadn't spotted that, but I've just been back and forth in the thread for 15 minutes finding it - a patch that made it in 212 meaning that frame_delay 1 kills an additional frame of lag?

Originally we thought that d3d9ex without frame_delay was leaving only 1 frame of delay, but in fact it was 2, as revealed by oomek's test.

So just like with plain d3d9 in the past, switching frame_delay on (simply 1), brings the delay down to 1 frame. Which works even on rather low end computers and is therefore nice (well, you have to deal with vsync_offset as a tradeoff but that's manageable)

It's a cheat isn't it? Sadly they don't save at all.

Dunno since when you haven't updated your Groovy, but now they do ! You know Calamity is a wizard, right ?
Introduced in 0.205 IIRC.
(yeah even the CPU% to tweak those cv1k games among others)

Just now I had a slider not saving issue because I was trying two things at the same time, creating a conflict, I think.
Otherwise they do save, no problem.

Can the unthrottling issue be fixed? If so, could "monitor lcd" become a shortcut for i-know-this-is-wrong-but-the-game-cant-run-correctly-on-an-lcd-so-just-make-it-as-nice-as-possible ?

It is 'fixed'.
There was nothing to fix actually, just certain settings required, read some Calamity's post above.

EDIT: oh guess you meant, 'keep the default config yet fix the unthrottling'. I'm gonna bet not, bc I think Calamity made a pretty crucial change so that frame_delay could be switched on directly from the UI, and 'fixing' would remove that ability.

[cools]

Dunno since when you haven't updated your Groovy, but now they do ! You know Calamity is a wizard, right ?
Introduced in 0.205 IIRC.
(yeah even the CPU% to tweak those cv1k games among others)

Just now I had a slider not saving issue because I was trying two things at the same time, creating a conflict, I think.
Otherwise they do save, no problem.

Ah, I was under the impression it was just the "non cheat" sliders that saved. Nice.

I hadn't spotted that, but I've just been back and forth in the thread for 15 minutes finding it - a patch that made it in 212 meaning that frame_delay 1 kills an additional frame of lag?

Originally we thought that d3d9ex without frame_delay was leaving only 1 frame of delay, but in fact it was 2, as revealed by oomek's test.

  I've had frame_delay set to 1 for so long (originally to do the queue bypass) that when something about that changed and it started introducing tearing I swear I noticed the response speed difference, but put it down to the game not running vsynced!

Does vsync_offset vary with CPU load?

[schmerzkaufen]

Does vsync_offset vary with CPU load?

I guess you can say it does since it's different with every game to begin.

But on a same game if you use post-processing (png effects, filters, hlsl, etc, maybe even overlays and portaudio too) CPU load increases and you have to adjust vsync_offset again.

The day Calamity manages to 'automatize' vsync_offset, or even just add a working slider for it... that day will be like the second coming of Groovy (well at least for flat panels users because they're the most concerned)

[Calamity]

MAMEdev has accepted this commit of mine:

https://github.com/mamedev/mame/pull/5901

It should be in for MAME 0.216. With this new option -lowlatency, baseline MAME becomes as "lagless" as GroovyMAME, when used on VRR monitors. This is without any further configuration, out of the box, just enabling -lowlatency.

GroovyMAME will still be an option for non-VRR monitors, but with Freesync monitors already available at 100$, there's little excuse not to upgrade and play MAME on an LCD with zero compromises, zero configuration,

[MrMikeZH]

Congrats!! 😮😃😃😃

[donluca]

Finally!

Congrats man, I'm really happy seeing this baseline MAME.

Just one thing: AFAIK Macs doesn't support Freesync/G-Sync/Adaptive Sync at all, yet you said that there's a user who reported success in using baseline mame with a VRR monitor.

Is the guy on this board?

[schmerzkaufen]

Congratulatios on making it to baseline MAME, but I'd need some translation please:

- does that mean it works the same w/ all backends: no latency if you use VRR

- does that mean what you were talking about; automatize frame_delay and vsync_offset, or at least add a vsync_offset slider, for non-VRR environment, is abandonned ?

PS: wrong thread to post that news really, it's unrelated.

PS2: yeah I won't get any answers as usual.

[Calamity]

It works the same with all backends, check the link in my post.

This means nothing about me abandoning other developments. I just posted it here since it will provide a much simpler route for users that want an out of the box low latency experience without messing with advanced options.

GM already has this mod since years ago. I wanted to determine why GM still had less lag than baseline even on vrr monitors. Now they should be on par.

A slider for vsync offset won't work very well since the simple act of drawing the ui menu already varies the offset (similar to fd).

Anyway, those features are intended to be done once we have a raster implementation common to all renderers.

There's no guarantee auto frame delay will work as expected. It's just an idea that might turn out not practical.

[schmerzkaufen]

It works the same with all backends, check the link in my post.

I did but there' s alot of information and language in it I don't fully understand. other devs often do that like 'oh everyone understands this stuff of course so lets link to github'. Sorry but no.
It's hard for someone at my level to process that what we were seeing in oomek's lag tests like the undefeated additional frames of lag in BGFX, are suddenly gone and everything in vsync-less situation now works the same and returns the same figures. that seemed completely impossible not long ago, and for someone who can't understand the technique it is like 'wow, what , really. really-really?' you know that's normal reaction from a non-tech person.

A slider for vsync offset won't work very well since the simple act of drawing the ui menu already varies the offset (similar to fd).

Anyway, those features are intended to be done once we have a raster implementation common to all renderers.

There's no guarantee auto frame delay will work as expected. It's just an idea that might turn out not practical.

I can't make what you mean out of this, sorry I don't know what "raster implementation common to all renderers" means, and overall what you say here just confuses me, I don't understand if you're saying it is highly likely to become a thing, or if you're saying it's pending to something I don't understand that's of unknown likeliness and of undertermined time.

Can't you please just tell me "yes it will likely be a thing working in GM in the near or not-too-distant future" or "no I don't know if I can make this work it could be a long undetermined time and it is also possible it won't happen at all either"

Or is this what you already meant?

I'm forced to ask because I'm not sure, you formulate this in too vague fashion for me, this is also because you greatly overstimate my technical knowledge/understanding of all this stuff.
I have end user experience, not 'power user' or 'contributor-to-development' tier experience. I know of a couple of things related to GroovyMAME configuration which I've learned with great difficulty because those were already above my level, and I have interacted here and with other end-users interested in the same niche use everywhere, but I don't have like 4% of the overall technical/dev/software knowledge and understanding you guys have.
So without updates and explanations I can relate to from time-to-time, as I said for someone at my level it's like being permanently in the dark and naturally part misunderstanding the status, part expecting things I shouldn't because they're not what is actually happening 'in your lab' now or in the future.

[Calamity]

You need to adapt your expectations to the pace of this project. There are more than 10 years of incremental development here in GM, from which you say you've barely been aware of the last 2. There have been big leaps forward and stagnation periods along the years.

For me, having a feature planned for a couple of years in the future means "not-too-distant future". So, if that's good to you as an answer, then yes, that's my plan. I hate vaporware, that's why I don't advertise features I'm not sure that will be possible.

Doozer and I have already been working in the underlaying raster implementation during the first part of this year. When will we resume the work? Real life will tell, I wish it was soon.

Real life is full of unextendible deadlines my friend, and I do this for fun. One not only needs the time but the mood to focus on this stuff. I have my own limitations. I'm not rich. I'm not a coder. I just learn what it's necessary for the the things I want to make.

[schmerzkaufen]

For me, having a feature planned for a couple of years in the future means "not-too-distant future". So, if that's good to you as an answer, then yes, that's my plan.

THANK YOU!
Allelujah! first core project dev info I can read in at least a year. 

But besides that your post shows you quite misjudge my complaint and what I'm asking about, I was never here asking you to speed up or or set deadlines (your conception of dev pacing is he same as mine btw; when the dev & company can), no I'm asking you to sometimes give people like me updates about the direction you're taking the project to, with basic explanations so we can understand what you're working on, just don't stay silent most of the time and only communicate with people who are at your level, that's not providing relatable information for petty end users like me.

Really even if it's not moving because that's life, we need to know where it's going, or planning to go. Nothing more, yet even just information is very useful, vital sometimes, even for petty end users.

And please I hope you can leave the 'dev victim of impatient user demanding stuff' paranoid kind of narrative to mamedev, because that's not what's happening here and you should very well know it, I behaved and waited a whole year before snapping for simply requesting more information, I was never demanding progress sooner.
If you think that's impatience then it's you who are abusing the definition because it is damn not.

The problem is not the project's pace or quality, the problem is you're way too undercommunicative about the project, and often deliberately avoid answering even natural question topics, and that causes problems (again like the story of the non-working ArcadeOSD), as well as undermines the overall perception of the project by other users also at my level.

If I'm going to write new guides in a specific fashion for people like me to be more at ease with Groovy (which in return should be in parts beneficial to you too) it is only natural that I'll have some questions for the general but for you directly too (several already asked about over time but ignored, I'll need at least minimal assistance and advice for filling holes otherwise that won't work, my articles will be incomplete/useless...)

[Paradroid]

The problem is not the project's pace or quality, the problem is you're way too undercommunicative about the project, and often deliberately avoid answering even natural question topics, and that causes problems (again like the story of the non-working ArcadeOSD), as well as undermines the overall perception of the project by other users also at my level.

Enough is never enough for you, is it?

The poor guy is straight-up telling you that he is maxed-out IRL and yet you're still reaming him for being uncommunicative.

You really should get with the gang and buy some CRTs... it'll teach you to appreciate imperfection.

[schmerzkaufen]

Enough is never enough for you, is it?

The poor guy is straight-up telling you that he is maxed-out IRL and yet you're still reaming him for being uncommunicative.

You really should get with the gang and buy some CRTs... it'll teach you to appreciate imperfection.

You know what disappoints me the most about this community ?

It's that you all make a point of not reading and understanding my point either for no f*cks given and prejudice-fueled judgement, or purposedly distort it to make me pass for bad guy. Every f*ing time.

I only asked Calamity to, like a couple times a year maybe, to inform of the direction development is taking, in a fashion that laymen can also get, because I can't get esoteric dev talk like they do with doozer or other once in a while.
Like, a paragraph of text, will that ruin his life?
Dev projects that don't share even minimal information and explanation for end users to read once every few months are naturally perceived as inactive/dead.
If a dev considers normal to stay this silent, even not saying 'projects slowed down bc I/we have no time but rest assured its not dead', well that's f*ed up.

And also to not flat out blank me when I have a question here and there. One can at least respond 'I don't know' or 'I have no time to reply' can't he ? or does that cost one year of life every time ?
Just blanking someone and repeatedly so is flat out impolite, I did not get mad for nothing.

He probably just doesn't get me and thinks I'm a leech, lots of devs end up thinking that of users who get too close, he just doesn't want to admit it but that's what this cold shoulder behaviour shown me all this year. What pissed me off is that this started relatively soon after I did a somewhat generous donation as thanks for all his help and for project support, I did it in complete honesty never with ulterior motive, I'm not a dirty person like that, but I still never imagined he would change his attitude towards me like that for no f* reason.

I happen to be one of the rare people around who can't stand when people can' tbe honest and direct, if I annoy someone I respect that he says so or even 'f* off', rather than playing the silent treatment game for a long period like that, leaving you to try to communicate and wait uselessly.

Also @Para, I have CRTs I believe I stated so many times already, I just have a much more vivid interest in flat panels and progress in emulation overall, and Groovy is the only serious project around, very close to completion, something I've waited for like 20 years, it's just unique, but so hidden in the shadows and with a so sclerosed community it's unbearable.
And I hate gang/group mentality, said it already this place gives 'old conservative men bubble stuck in time accumulating dust' vibe thats really not my cup of tea. I like change, progress, nuance and new ideas. Life.

I will make everyone happy and just f*ck off from here anyway, the farce's lasted long enough I think, it's Christmas early for ya'll old grumps.
The guides I'll write will be limited to what I know and since I can't count on Calamity's input once in a while then they'll likely be lacking a bit. *shrug*

[Mike A]

He doesn't owe you anything.
People like you are why developers take their projects offline.

I will make everyone happy and just f*ck off from here anyway, the farce's lasted long enough I think, it's Christmas early for ya'll old grumps.

Wow! Santa is real! Sitting on his lap at the mall actually paid off.

[Calamity]

I don't know what you're talking about mate. I didn't change my attitude to you or anybody, and thinking that it could have something to do with the cash you sent me is sick. If I left any post unanswered it's probably that I entered a period of several months with a lot of work when probably I'm not on the keyboard but standing on a workplace with an air hammer operator by my side, then get home at night and have two kids to care about. I can't even type a post like this one without being interrupted by the phone twice. Then when after that period of time I can sit again to check the forum then it may be two months later and the posts are lost.