CAVE-STG

Deep inhale: Cv1000 games in  mame can be set to play very close to pcb speeds/timings, ever since ~ 2014  :police:

There are two kinds of slowdown that occur in a cv1000 game:
1. CPU dependant
2. Blitter dependant

Factual example: in Mushihime-sama ultra, first Boss's first pattern is CPU dependant, while stage 3's pre-boss segment (before the 1up zone) is Blitter dependant. This two variables are basically all you need to test in getting all of Mushihime-sama dangerously cose to pcb in terms of slowdown, throughout 95% of the game.

There is one other [unemulated] factor: the microcode that flags subtle changes in Blitter/CPU in certain small instances, but the great news is that those moments, apart from menus (which on pcb may have Blitter entirely disabled) occur once of twice in the entire game.

This is a general rule for all Cv1000 games: A set CPU and a set Blitter, for the entire game except menus and a couple other instances that generally mean some fancy 'blink and you miss it' slowdown, like Espgaluda 2's 2nd phase 2nd bullet pattern (or is it first one!?), where it slows down for a second for no reason and is not consistently triggered even on pcb (depends on the character, type.of shot and proximity to boss).

The emulation is of course, not perfect (it has small split second stutters in certain parts of certain games, like begining of Espgaluda 2), but it is much more playable and close in terms of speeds than many think.

If you could show me some video of this alleged accurate slowdown, I'll change my mind. The best I can find is stuff like this (MFBL):

https://www.youtube.com/watch?v=uIQWqxSTYXk&t=

Which has a lot of slowdown. But very little of it is accurate. It's either too choppy, way too slow, or not in the original PCB. And then there is missing slowdown too. Some of this you can only really tell if you play the PCB yourself for a good amount of time. What is shown in that video is far from "very close" to the PCB.

https://youtu.be/hKlVZQVzgRo

Sorry for the atrocious gameplay

Quote from: el_rika on March 28, 2020, 06:57:44 PM
https://youtu.be/hKlVZQVzgRo

Sorry for the atrocious gameplay

Thanks. Looks perfectly fine for playing on a phone! But it has the same accuracy problems as the Futari BL video I posted. The X360 port is more accurate in the slowdown timings.

Achieving perfect accuracy this way is practically impossible let's not kid. But closer to it in some of the cv1k library titles definitely is.
Again I got results sometimes better than for instance the worst of the 360 ports, such goal is realistic using MAME, and again with a lag close to the PCB's w/ Groovy (a little over 2 frames)

But it is very sensitive and hard to achieve, as the settings granularity is considerble and just a 00.01 difference (stealthily only appearing in the .cfg files but I'd explain the handling later if anyone's interested) can change the slowdown behaviour by a lot, like the sweet spot's there somewhere and you musn't miss it bc nothing else works.

Ideally at least a handful of playtesters with considerable knowledge of the PCB's ingame slowdowns would be the only people researching the best working settings, players like you EOJ, but like most I doubt you'd ever be bothered since it is a long slow tedious job, likely to be rendered useless by future update to the MAME cv1k driver to make things even more demotivating.
People who know the slwodowns best typically own the PCB's, so naturally why in the world would they bother studying emulation for better-yet-not-perfect results? this is logically why any serious cv1k settings research never even really started and likely never will.
IIRC at some point the MAME community tried gathering donations to redo the Cave library dumps with the goal of writing more accurate drivers, with those slowdowns in mind, but they quickly realized they lacked awareness of the insane skyrocketing prices, so that never happened.

On the topic of build versions, I know el_rika uses RetroArch with old MAME cores, I've told him I am entirely against doing any research on cv1k settings that way, since the MAME updates across builds definitely would make the results inconsistent, the only right way is for every tester as much as possible to always use the latest version or very close.
GroovyMAME always being up-to-date against baseline, having efficient lag reduction (albeit resource-hungry), and on top of that saving the OC slider setting - it's the only modern build to do it - is the obvious ideal choice.
(and it is honestly not complicated to set up for cv1k b/c no special hardware setup nor drivers are needed, just a beefy-enough PC)

Anyway, the SDOJ dump isn't available so *shrug*  :bigsmile:

That sounds quite complicated! I think Kaneda mentioned he got MMP working with better slowdown in MAME than in the X360 port. I don't know exactly how he tweaked it (and that's part of the problem with this whole MAME thing, results vary greatly based on many factors!). I've read similar stories about the Ibara games, but all the Ikeda SH3 stuff and post-2007 stuff in general runs messy from what I've seen (and heard, from other players).

Messy and laggy yes if you just drop cv1k roms in a random MAME build and just click play. That's what happens for the majority who doesn't know about things like GroovyMAME and underclocking/tweaking.
'Better than the worse ports' is clearly doable thanks to the latter. It works.
Not so complicated but extremely tedious. The CPU% slider moves slowly because it goes through hundredths and decimals in the background, which you don't actually see in the UI, each stick single input left or right does .01 which can make a difference to get a slowdown to trigger in a certain place, or to get one particular slowdown more or less the right speed against the pcb.

Use of multiple savestates is necessary to do constant comparisons and adjustments in various places, but the job hasn't much value unless it's done by a number of game-specific experimented players, mainly pcb owners.
There's no point in trying to replicate the 360 ports slowdowns, and even if PCB-less researchers used various runs videos, there aren't that many actually recorded from PCB play, several are also too low video quality to even be useful.

And yeah there's still the damn blitter delay slider too, this is what has had me scratch my head the most. Though as I said honestly I'm not sure it still works correctly in recent builds, that's something I wanted to investigate some time ago and then I got suck-in my giant PS4 backlog, too many games there I want to clear before the daily-intensifying apocalypse gets me.

Sorry for the redundancies :bigsmile: but I wanted to clarify-detail some points for anyone who'd be oddly interested in the topic whatever time in the future. Personally I used to be quite motivated for this, still was a couple of years ago, but then realizing it's impossible to do alone without reasonable and rather disciplined experienced community help, I just gave up.  :P

Quote from: EOJ on March 28, 2020, 07:25:58 PM

Quote from: el_rika on March 28, 2020, 06:57:44 PM
https://youtu.be/hKlVZQVzgRo

Sorry for the atrocious gameplay

Thanks. Looks perfectly fine for playing on a phone! But it has the same accuracy problems as the Futari BL video I posted. The X360 port is more accurate in the slowdown timings.

You're welcome EOJ!

I tested it quite a lot against both pcb and 360 (which i own) gameplay. I personally think it's not that far. An exceptional player like yourself would probably see deeper though  :)
The BL video you posted is indeed messy and it can be tweaked to play much better, undeniably.

Speaking of pcb and 360, there are some noticeable differences in how slowdown is handled (i'm talking about the slowdown that exists in both versions, not about the missing or added slowdown in the 360 version).
For example,  in Futari 1.5, the slowdown in 360 is generally slower and longer, and the transition to normal speed is always more sudden, often lacking the transitional (slightly stuttery) slowdown from pcb. Everything is jumpier on 360, where in pcb is less jumpy but more stuttery (very noticeable mostly with normal shot Reco, after spider mid-boss level 4).

Quote from: EOJ on March 29, 2020, 03:57:32 AM
That sounds quite complicated! I think Kaneda mentioned he got MMP working with better slowdown in MAME than in the X360 port. I don't know exactly how he tweaked it (and that's part of the problem with this whole MAME thing, results vary greatly based on many factors!). I've read similar stories about the Ibara games, but all the Ikeda SH3 stuff and post-2007 stuff in general runs messy from what I've seen (and heard, from other players).

Actually, Ibara (BL), Pink Sweets and Muchi are the easiest in terms of tweaking, as they rely heavily on CPU, and less on Blitter. Ibara BL for example activates all major slowdown with 50% CPU alone, no blitter.

Quote from: xygax on March 29, 2020, 02:43:07 AM
Achieving perfect accuracy this way is practically impossible let's not kid.

But it is very sensitive and hard to achieve, as the settings granularity is considerble and just a 00.01 difference (stealthily only appearing in the .cfg files but I'd explain the handling later if anyone's interested) can change the slowdown behaviour by a lot, like the sweet spot's there somewhere and you musn't miss it bc nothing else works.

On the topic of build versions, I know el_rika uses RetroArch with old MAME cores, I've told him I am entirely against doing any research on cv1k settings that way, since the MAME updates across builds definitely would make the results inconsistent, the only right way is for every tester as much as possible to always use the latest version or very close.
GroovyMAME always being up-to-date against baseline, having efficient lag reduction (albeit resource-hungry), and on top of that saving the OC slider setting - it's the only modern build to do it - is the obvious ideal choice.
(and it is honestly not complicated to set up for cv1k b/c no special hardware setup nor drivers are needed, just a beefy-enough PC)

Anyway, the SDOJ dump isn't available so *shrug*  :bigsmile:

Perfect accuracy is impossible in my opinion as well atm.

I don't think there is something more sensitive beyond the actual Mhz values that you can check in Machine Information (or similar) tab. You set a certain CPU % with the slider, and then check the CPU Mhz for the actual speed.

Yeah, it's true that my test version is older (0.155), but in terms of core emulation, nothing has changed since then, as the 0.192 update to the driver deals with speed, nothing else (the slight stutter issues are still there, and the games behave identical, just that they are less CPU hungry). So by using an older version you miss nothing, but it's true that the tweak numbers may not work between versions.

Quote from: el_rika on March 29, 2020, 06:04:49 AM
I don't think there is something more sensitive beyond the actual Mhz values that you can check in Machine Information (or similar) tab. You set a certain CPU % with the slider, and then check the CPU Mhz for the actual speed.

That's wrong there definitely is a difference in precision, told you I could observe major differences with just 00.01 difference in not-so-rare occurences.
Your method using an old build and different environment; I don't see the point in even trying to work and compare data with other testers that would would be using a PC with recent MAME/Groovy and differently working options.
Your settings and results would require an additional dedicated column/chart separate from the others.
The way to do worthwile testing in any kind of software is not one that's so dispersed, otherwise it is a waste of time, there's tons of good reasons why mamedev reject any reports from older builds.

Quote from: el_rika on March 29, 2020, 06:04:49 AMYeah, it's true that my test version is older (0.155), but in terms of core emulation, nothing has changed since then, as the 0.192 update to the driver deals with speed, nothing else (the slight stutter issues are still there, and the games behave identical, just that they are less CPU hungry). So by using an older version you miss nothing, but it's true that the tweak numbers may not work between versions.

It changed the behaviour and graphics memory loadings of the games for me that's enough difference, considering several people testing they have to do it with the same base software.
Other non cv1k changes can also affect these games anyway, and there's been tons since 0.155, don't underestimate that.
You know I'm against your way of doing this, the obvious requirements to make such a big job worthwhile are;
- PC
- quite recent GroovyMAME or MAME build (Groovy features saving OC slider and lower lag even without using frame_delay so it' the obvious choice...)
- with input from players/testers who have experience sufficient from playing the PCBs

That's the only way, unless you want to force people using the same old build and environment as yours, or ignore the inevitable inconsistenciesthat will fatally pollute the results chart.

That's the last time I'll be writing on the topic because there is nothing more to add, it's been obvious for years that thorough, worthwhile effort for this cv1k stuff will never happen, because of how the shmups 'community' (or practically any internet community) is these days. Emulation discussion too has become meh because most users have lost interest, putting accessibility/personal convenience and artificial fanciness/gratification on top priority even if that means sacrificing more valuable paths that prioritize accuracy and progress (RetroArch-like logic in a nutshell, which I reject)
In a distant future a supposed complete reworking of how MAME works might bring much better accuracy on default, but I doubt it will actually ever happen, or in so long that nobody will care anymore.
Too bad FPGAs aren't powerful-enough.  :-\

Quote from: el_rika on March 29, 2020, 06:04:49 AM

Quote from: EOJ on March 29, 2020, 03:57:32 AM
That sounds quite complicated! I think Kaneda mentioned he got MMP working with better slowdown in MAME than in the X360 port. I don't know exactly how he tweaked it (and that's part of the problem with this whole MAME thing, results vary greatly based on many factors!). I've read similar stories about the Ibara games, but all the Ikeda SH3 stuff and post-2007 stuff in general runs messy from what I've seen (and heard, from other players).

Actually, Ibara (BL), Pink Sweets and Muchi are the easiest in terms of tweaking, as they rely heavily on CPU, and less on Blitter. Ibara BL for example activates all major slowdown with 50% CPU alone, no blitter.

Unfortunately, this is not the case. We tried to tweak Pink Sweets with blitter delay and it's always completely off. No matter what you do, some parts have either too much or too less slowdown.

I can't comment on the other games, but I'd be very surprised if you can actually tweak any of the games so that they are comparable to the PCB. It's a complete mess.

Quote from: Plasmo on March 29, 2020, 09:16:21 AM
Unfortunately, this is not the case. We tried to tweak Pink Sweets with blitter delay and it's always completely off. No matter what you do, some parts have either too much or too less slowdown.

I can't comment on the other games, but I'd be very surprised if you can actually tweak any of the games so that they are comparable to the PCB. It's a complete mess.

If that's the only thing you've tried then of course you couldn't have gotten anywhere.

Quote from: Plasmo on March 29, 2020, 09:16:21 AM

Quote from: el_rika on March 29, 2020, 06:04:49 AM

Quote from: EOJ on March 29, 2020, 03:57:32 AM
That sounds quite complicated! I think Kaneda mentioned he got MMP working with better slowdown in MAME than in the X360 port. I don't know exactly how he tweaked it (and that's part of the problem with this whole MAME thing, results vary greatly based on many factors!). I've read similar stories about the Ibara games, but all the Ikeda SH3 stuff and post-2007 stuff in general runs messy from what I've seen (and heard, from other players).

Actually, Ibara (BL), Pink Sweets and Muchi are the easiest in terms of tweaking, as they rely heavily on CPU, and less on Blitter. Ibara BL for example activates all major slowdown with 50% CPU alone, no blitter.

Unfortunately, this is not the case. We tried to tweak Pink Sweets with blitter delay and it's always completely off. No matter what you do, some parts have either too much or too less slowdown.

I can't comment on the other games, but I'd be very surprised if you can actually tweak any of the games so that they are comparable to the PCB. It's a complete mess.

Pink Sweets is my least played game out of the bunch but, from what i experienced though, it mainly has linear slowdown, like Ibara.
That being said, the way to approach the tweaking, is to find a clear spot where the slowdown is CPU dependant, set the CPU to the required value, and start the Blitter tweaking from there, preferrably in a few spots that are Blitter dependant. I'd be surprised if the game ever uses more than 50% CPU in any given situation.

Some extra notes: i am almost certain that in some games (ex. Futari; Normal Reco vs Abnormal Palm), for different characters slightly different Blitter values are used, so comparison should be made with the same exact characters.

Quote from: xygax on March 29, 2020, 06:56:58 AM

Quote from: el_rika on March 29, 2020, 06:04:49 AM
I don't think there is something more sensitive beyond the actual Mhz values that you can check in Machine Information (or similar) tab. You set a certain CPU % with the slider, and then check the CPU Mhz for the actual speed.

That's wrong there definitely is a difference in precision, told you I could observe major differences with just 00.01 difference in not-so-rare occurences.
Your method using an old build and different environment; I don't see the point in even trying to work and compare data.

I just checked latest mame build for windows, and there is no smaller increment in CPU clock than 0.1 Mhz, just like in my build.

As to why do i bother? Because i like playing these games, its relaxing and rewarding, and atm mobile is my only option, and of course, playing them as close to originals as it can be, is the way to go  :righton:

Ps: even if the values between builds don't hold up, if one build works, any other build should work just as good, just with slightly different numbers. Also the "always use the latest build 'cose the older one is obsolete" logic is a bit flawed seeing how there will always be a newer build and the, already time consuming to find, numbers will always slightly change... ??? Chose a build an stick to it  :bigsmile:

Quote from: el_rika on March 29, 2020, 09:58:17 AM
I just checked latest mame build for windows, and there is no smaller increment in CPU clock than 0.1 Mhz, just like in my build.

People don't read. For years I've been specifying how it works and just repeated here. But nope.

Again it can't be seen from the UI. The setting exists inside each game's corresponding .cfg file, there is a dedicated folder.
The CPU setting granularity is of 1000, but it exists there only during play if OC is used.
That's why the best solution is to use GroovyMAME which allows to check, edit and save that value, it is the most precise, convenient way since with it so we don't have to redo the OC every time we play.

Quote from: el_rika on March 29, 2020, 09:58:17 AMPs: even if the values between builds don't hold up, if one build works, any other build should work just as good, just with slightly different numbers. Also the "always use the latest build 'cose the older one is obsolete" logic is a bit flawed seeing how there will always be a newer build and the, already time consuming to find, numbers will always slightly change... ??? Chose a build an stick to it  :bigsmile:

No, just no. Any MAMEdev would laugh - bitterly - at this statement.
That no-f-given, self-centered culture that RetroArch introduced and promoted is a disaster, and among all the retrogaming communities the Shmups one is probably the most inept there is in regards to its understanding and relationship to emulation.
I bet MAMEdev as well as GroovyMAME's dev would agree considering the extra time and efforts they've dedicated to those its demogrphic's interests have mostly been trampled on or completely ignored, and players including the most prominent ones always privileged inferior obsolete builds and hacked solutions w/ dumb settings.

TL;DR the only right way to to this would be thoroughly, by the book with indeed the latest or very fresh build, because of course the settings and results will be best being similar that way and really for everyone's benefit, otherwise it will be a compiled mess of various versions performing and setting differently, made by isolates being like 'what-ever I do what I want, I know better without anyone telling me' that will considerably complicate the testing, sharing and data gathering, and therefore ruin it.

Told you some time ago it will never materialize, I know the so-called 'community' too well.

Quote from: xygax on March 29, 2020, 10:53:20 AM

Quote from: el_rika on March 29, 2020, 09:58:17 AM
I just checked latest mame build for windows, and there is no smaller increment in CPU clock than 0.1 Mhz, just like in my build.

People don't read. For years I've been specifying how it works and just repeated here. But nope.

Again it can't be seen from the UI. The setting exists inside each game's corresponding .cfg file, there is a dedicated folder.
The CPU setting granularity is of 1000, but it exists there only during play if OC is used.
That's why the best solution is to use GroovyMAME which allows to check, edit and save that value, it is the most precise, convenient way since with it so we don't have to redo the OC every time we play.

What you say is exactly what i say.

The Sh3 cpu is 102.40 Mhz and the CPU Slider has 1000 units (as seen in .cfg).
When the CPU is underclocked by 1 unit, it reflects into the CPU speed to a roughly 0.103 Mhz (sometimes is 0.102) value.  So the defaut 102.40 minus 1 unit, equals 102.297 and so on.

Quote from: el_rika on March 29, 2020, 09:58:17 AMPink Sweets is my least played game out of the bunch but, from what i experienced though, it mainly has linear slowdown, like Ibara.
That being said, the way to approach the tweaking, is to find a clear spot where the slowdown is CPU dependant, set the CPU to the required value, and start the Blitter tweaking from there, preferrably in a few spots that are Blitter dependant. I'd be surprised if the game ever uses more than 50% CPU in any given situation.

That's some brilliant information right there! Thanks a lot for sharing! I will see if this approach might bring us anywhere closer to the PCB slowdown.

This would be a serious breakthrough if Pink Sweets would run properly. I will report on this more in the future, stay tuned! :righton:

Quote from: el_rika on March 29, 2020, 01:46:52 PM
What you say is exactly what i say.

I tell people how to use an up-to-date build to do the adjustments to cv1k games, with a build that has non-destructive lag reduction as well (unlike R-A's run-ahead)

You tell them about the same using an outdated build with RA and different options settings on a phone. Why this anti-progress logic?

Using groovy for this job is the best solution for getting it done and have the broadest reach/accessibility with the most up-to-date consitent results and overall approaching accuracy. It's arguably even easier than the RA route even.

*sigh*

In the realm of emulation and hardwre any effort in the favor of shmuppers in recent years has been a waste, they're like pets, when you present them the highest grade food, they still go for the already rotting leftovers. Always.
I'm just disappointed to have wasted years trying to promote and do support for bleeding-edge solutions for people who after all always ignored that and instead persistently privileged outdated emulators, with lossy hacks, crappy settings, and setups, and the top attention-craving players and influencers out there, that have become the unofficial 'rulers' of a now farce morbid 'community' which only remaining right for existence is to acquiesce and cheer on them internet e-sports and social media overlords, who proudly promote that inferior crap everyday.
Emu devs really wasted their efforts, and I with a few others who tried everything to offer the best, wasted our time too.
So ashmed to now think that in the end, Calmity's efforts were ignored, and that MameHaze was right, at least about the community's worth.

Quote from: Plasmo on March 29, 2020, 06:06:27 PM

Quote from: el_rika on March 29, 2020, 09:58:17 AMPink Sweets is my least played game out of the bunch but, from what i experienced though, it mainly has linear slowdown, like Ibara.
That being said, the way to approach the tweaking, is to find a clear spot where the slowdown is CPU dependant, set the CPU to the required value, and start the Blitter tweaking from there, preferrably in a few spots that are Blitter dependant. I'd be surprised if the game ever uses more than 50% CPU in any given situation.

That's some brilliant information right there! Thanks a lot for sharing! I will see if this approach might bring us anywhere closer to the PCB slowdown.

This would be a serious breakthrough if Pink Sweets would run properly. I will report on this more in the future, stay tuned! :righton:

Wish i had studied Pink Sweets more, and lend a hand, but as i said, i have no clue how to properly play it yet  :'( These days i'm mostly testing Ibara BL, Futari 1.5 and Daifukkastu 1.5. I'll definitelly get into Pink Sweets as well at some point.
I'm 100% certain you can achieve excelent results in Pink Sweets  :righton:

@xygax
I appreciate all your inputs, and you are of course right in  using the best available software. Reality is what is it though, i'd use it if i could but still, as it is, i think all our discussions revealed valuable information, for anyone interested in this matter.
It's more and more clear that with the available tools, these games can be tweaked to play much better than initially thought.

That's what I've been saying and promoting and tried my best to contribute to, and provide support for, for years, what some emu devs and contributors did efforts for, all that way before you yourself got into the thing, and we were ignored, even lied about by all those idiots of the shmups 'community' (the amount of false crap ppl said about emulation and GroovyMAME is unbeliveable, up to that stupid lag test from Marks which is obviously wrong on Groovy because he failed to configure it, naturally since he deliberately ignored any offered support for it, for his hubris and self-promotion reasons)
We offered you all the best tools improving them over the years, builds/tools for working on tweaking cv1k and providing the best possible way of playing these games in emu has been doable thanks to that for years with the cutting edge stuff.
But now you come with an inferior solution, and people give you attention...
Yup.
Typical of the shumps community.
Hey, you should make a twitter account and blog or whatever, specifically for this, give it a name, you're certain to be welcome and thanked in the various discords and your way using outdated material to become the popular adopted solution in the 'community', and the actual better rational stuff will be buried even further down into limbo.
Isn't that what the world is about today? that's how things go, yes.

Sorry to hijack this topic once more.

@el_rika
So we did some testing and the results are absolutely stunning! This is a revelation! I have informed the other players as well and they are very impressed. :righton:

This is like Christmas, I cannot thank you enough!!

Who would've thought that sh3 slowdown can be emulated properly and it was there in front of our eyes the whole time?

Again, thank you!

What settings are you using for Pink Sweets?

What settings do you have in any of the SH3 games?
I'm fine with running Groovymame, but I don't really want to try to find the magical values for myself.

Some sort of thread/wiki/page whatever with blitter + cpu values for the sh3 games would be great.

@Plasmo,

Great news, i'm glad :D

Xygax, MetalliC (the original sh3 & Blitter coder) and a few other ethusiasts, have been preaching for years that CPU underclock is a "major" factor in properly achieveing those yummy slowdowns.

Personally, I'm always going for a bit more slowdown than original (+10%), as it obviously helps in survival (and it's damn cool :)), but that's just my prefference.

Don't know how the numbers work between older versions and newer (mame 0.192 saw a change in overall speed in x86), but i'll look into it when i get access to a laptop, and present my findings and how they relate to the values i use.

Yeah we've been promoting it for years (shmups forums, groovy forums etc), got help from devs, yet been ignored and annoyed by shmupper naysayers who didn't even try it themselves.

Some time go I've PM'd Muchi Muchi Spork here to tell him about the OC saving that Calmity implemented in GroovyMAME that finally allowed us to work on adjusting cv1k slowdowns without, and on a modern competent build.
He seemed to be one of the rare ppl aware of the potential of the method (but he was busy and maybe no longer into these things. Welp)



@Plasmo; you can try and act like this method is new to you, that you weren't aware, specifically ignore me and over-thank el_rika like a hero, maybe thinking you have me fuming? Poor Dudemo, all you manage is to show more of your ugly character. It was never about you nor the narrow self-important e-sports tabloid shmups internet churches that have monopolized all the open public traffic and ruined this genre's appeal for anyone not a shmupathlete starved for attention. What mattered was always the general, way beyond the narrow boundaries of the now only imaginary 'shmups community', p***ing-contest-focused shmuppers have long showed they're persistently inept at emulation anyway, thinking high scores entitle competence in very field. :whyioughtta:

And you still wonder why people are ignoring you?

Why does this video say Pearl came up with this idea when Plasmo got it from el rika and xygax in this thread and by his own admission told others (including Pearl)? Am I missing something?

https://www.youtube.com/watch?v=V_ew3VoBqX4

BTW the Groovymame slowdown in that video isn't close to the PCB, so they have a long way to go in tweaking this. The first step would be to compare it the the PCB, rather than the X360 port (which itself is only about 80% accurate to the PCB).

Quote from: EOJ on April 02, 2020, 06:07:47 PM
Why does this video say Pearl came up with this idea when Plasmo got it from el rika and xygax in this thread and by his own admission told others (including Pearl)? Am I missing something?

https://www.youtube.com/watch?v=V_ew3VoBqX4

BTW the Groovymame slowdown in that video isn't close to the PCB, so they have a long way to go in tweaking this. The first step would be to compare it the the PCB, rather than the X360 port (which itself is only about 80% accurate to the PCB).

hello.

idk why im mentioned as the founder; I never claimed that I found the method at all. however I was the one who jump started getting everyone to actually give it a go, to encourage people to work together to find correct settings. I started working right away on Mushi and Pink Sweets.

the settings used in that video are incorrect, i told mark this but the video was made and he was aiming for 360 speed anyways. ive been comparing mushi back and forth for a few days straight now, and only now I can really confidently say im reaching a point where I can say it's rather damn accurate.

specifically : 37.6% CPU, 56% blitter delay, are the settings i'm currently working on. very few sections are incorrect in my testing, and the only one that is actually noticable is an attack on the s3 boss (first phase, aimed 3way shots)

Thanks for the info! I will have to test this out. I have not used MAME in years but I'll download the latest version in the near future.

Quote from: Plasmo on April 02, 2020, 08:15:18 AM
And you still wonder why people are ignoring you?

And you still ignore why I hate you guys?

This very thread has enough examples of how hypocrite and opportunist several more or less prominent ppl in the community are. What EOJ linked is typical, and I'm not suprised knowing some.

By the way as far as I remember Muchi Muchi Spork was the first one telling the community about mixing CPU underclock with blitter delay, that was probably like 5 years ago if not older.
Later because the method was a pain to apply due to the non-permanent slider and hardly anyone was trying, I've asked Calamity if he could implement saving the OC slider, which he awesomely kindly successfully did sometime in 2018 iirc.
Around the same time he fixed savestates specifically for shmuppers needs, with other contributors demonstrated the efficiency and lossless nature of Groovy's lag reduction, making it basically the ideal build for everyone's cv1k needs: proper smooth video sync, proper delay, workable tools for tweaking the slowdowns, fixes for LCDs, and almost always up-to-date with baseline).

Archetypal of the shmups community though all that was ignored, dissed, even lied about (Mark's lag chart among other BS i've read), no interest nor help for researching and testing (I couldn't honestly test everything there was to by myself, and I found no one to help), all prolly because of fear of too much to read/learn or whatever, which is of course wrong since for exact 60Hz games like cv1k no specific hardware nor complicated settings are needed, only a not-too-wimpy PC and a couple minutes in the mame.ini, but catching even just that bit of information was always too much of a hassle apparently lol.
Now today because it was bound to happen, typical of the attention-starved type of social-media-driven kind of 'shmups community' you privilege and promote 'for the good of the genre', it was inevitable then that the day would come when more 'good' souls would have the nerve to attempt to use the ideas and achievements of others for their personal glory (yet for most ultimately almost guaranteed to opt for a subpar solution like and old MAME build with RetroArsch), which Mark will certainly later pre-configure in 'his build', advertise and cash-in the thanks and likes for, his speciality.

Anyway, whatever you guys do with that now I don't care, I see some linking old threads on the farm where several infos about Groovy are outadated and might need some refresh. But meh, I know where this is likely going, I've wasted so much time with that stupid community I know their recipies for disaster, I won't ever again lift another finger like I did way too many times over the years for f* nothing, when I was thinking 'shmuppers' would be cool about such topics but they weren't and acted like total ass instead, continue to.

Some need to get CAVID-19 and choke, these days lots of shmuppers don't deserve the best stuff.  :righton:

Okay, I downloaded the latest version of Groovymame and fiddled around with this. I managed to get the cheats enabled and found the slider menu. But I have a question: why is the CPU slider not available when I play DFK BL, but it is when I play, for example, DSMBL? DFK BL does not have proper slowdown with the CPU at 100%, no matter what Blitter I set.

I tested out various settings for DSMBL today. CPU set at 36-40%, blitter at 50-63%. I couldn't find any combination that had really accurate slowdown. None, for example, that properly emulated the slowdown on the Forest boss at Rank 3. So far it's a lot better than nothing, but still not better than the port. I'll continue testing various settings, hoping I'll hit the jackpot.

Groovymame with lag reduction ON still feels like it has about 4-5 frames of lag on my PC. This is quite noticeable when I play DFK BL, for example. It feels about the same as the lag in the SDOJ port. This is a big improvement over how MAME used to feel -- I mean, it felt like 6-8 frames before for me -- but it doesn't come close to the PCBs or the good X360 ports.

More testing:

Ibara Kuro: I see Plasmo said (on a shmups forum thread that is on the same topic as this one) he set the CPU to 50% and the blitter off. Unfortunately, doing so produces slowdown that is far from very accurate.
Mushi: my ROM has sprites/bullets randomly disappearing, but I used Pearl's settings (37.6% CPU, blitter at 56%) and many parts ran too slow and/or felt too janky. I'll have to find a clean ROM somewhere and test again.
Pink Sweets: Again, I used Plasmo & Pearl's settings (37.2% CPU, blitter OFF). I played HARDER mode. Pretty good, but much slowdown is missing and some slowdown is too slow.

I tried various settings with Muchi Muchi Pork but so far I can't find one that plays accurately. Most emulate the boss slowdown well, but then there are spots in the stages that are too slow or too fast.

BTW the thread title on shmups forum, "Slowdown accuracy for cv1k games on MAME is almost perfect (https://shmups.system11.org/viewtopic.php?f=1&t=66312)", made me chuckle after testing out these settings myself. If you change the "almost perfect" to "better than before", "pretty good", or "better than most people thought possible", it would be a more accurate assessment of the current situation.

Here is a good post about this topic from 3 years ago, with lots of settings listed per game:

https://shmups.system11.org/viewtopic.php?p=1276872#p1276872

Unfortunately, he doesn't seem to have a good understanding of the slowdown on the PCBs, so these numbers aren't of great help. Setting the blitter to 63% in DFK BL, for example, produces less accurate slowdown than the port (by quite a significant degree): I'd put it at about 60% accuracy.

Topic split, so we can continue this discussion here.

When examining the slowdown accuracy in an emulator, the following factors need to be considered:

1) location: where the slowdown occurs in the PCB. Some slowdown is purely locational.
2) causation: what triggers the slowdown to occur? A shot type, a rank level, a bullet threshold, etc. Some slowdown is non-locational and thus is purely causational. Some slowdown is both locational and causational.
3) transitional-in slowdown: speed of the slowdown as it begins at a location or causation and moves into the durational phase.
4) durational slowdown: speed and duration of slowdown after the transition in.
5) transitional-out slowdown: speed of the slowdown as it moves out from the durational phase back to normal game speed.

I don't think anyone else has laid these out together like this before, but anyone who wants to do this seriously has to fully consider each factor as they tweak the CPU and blitter settings. So far everything I've tested has been inaccurate in all five factors at least some of the time and at least one factor almost every time.

Quote from: EOJ on April 03, 2020, 07:08:24 PM
Mushi: my ROM has sprites/bullets randomly disappearing, but I used Pearl's settings (37.6% CPU, blitter at 56%) and many parts ran too slow and/or felt too janky. I'll have to find a clean ROM somewhere and test again.
Pink Sweets: Again, I used Plasmo & Pearl's settings (37.2% CPU, blitter OFF). I played HARDER mode. Pretty good, but much slowdown is missing and some slowdown is too slow.

Mushi is the single cv1k game that doesnt play nice when blitter is turned on during game boot. I have to disable blitter, boot the game, savestate at the copyright screen, close the game, boot the game again, turn on blitter and THEN load the save state.

what did you play for Mushi? ive only been able to notice maybe 2 or 3 sections with incorrect slowdown on Maniac with W-Power. I'm sure you know but mushi slowdown is really weird, a lot of it will feel slow but it has matched what I look at on pcb footage.

as for Pink Sweets, that's in it's early phases. I plan to play a lot of the game after calice cup and when that happens I'll be tweaking that game a lot more.

Thanks for the Mushi workaround. I will try that.

I played Maniac with W-power. I have scored over 300 mil on the PCB (no rapid fire), so I know the game well. I have also owned the PCB many times (even within the past year) and have spent countless hours playing it. I know the slowdown in it like the back of my hand. Watching videos isn't the same as the tangible feel and reaction of the game in your hands. Believe me, I have tried to rely on PCB footage before in measuring slowdown accuracy and it leads to some false conclusions (usually, an overestimation of slowdown accuracy in a port or emulated version).

Then I hope you're able to help us find an even closer setting for the game!

I will try my best.

I used Pearl's Mushi workaround and got it to run properly with the CPU and Blitter settings he specified. Unfortunately in my estimation the slowdown accuracy overall is no better than 60%, compared to the PCB.

The main problems I encountered were:

-Slowdown missing in ST1 and the ST1 boss.
-Slowdown missing in ST2 (especially on the plants in the second half!) and the ST2 boss. The midboss is good, though.
-Slowdown missing in the first part of ST3. However, the slowdown after that is surprisingly accurate throughout the stage! (This is the real highlight of the entire MAME experience, it is better than the port in this part.)
-Stage 4 is a mess. Slowdown is missing in many spots in the first half, but the midboss has slowdown in its last phase that is too slow, making this tricky part a lot easier. Worst of all is the last part of the stage (everything after the midboss), which has WAY too much slowdown that lasts way too long. It is horrific.
-Stage 5 slowdown is stuttery, either too fast or too slow, and just feels rather janky overall. On the PCB it is smooth as butter. On the plus side, the midboss has the proper slowdown.

In addition, all of the transition-in and transition-out speeds are off (usually too fast in emulation).

I will try tweaking things up and down in the Slider menu, but it is possible what we have is already "as good as it gets" in MAME. I will be pleasantly surprised if I can get it significantly better, but like I said, I'll try.

Quote from: EOJ on April 03, 2020, 10:05:39 PM
I used Pearl's Mushi workaround and got it to run properly with the CPU and Blitter settings he specified. Unfortunately in my estimation the slowdown accuracy overall is no better than 60%, compared to the PCB.

The main problems I encountered were:

-Slowdown missing in ST1 and the ST1 boss.
-Slowdown missing in ST2 (especially on the plants in the second half!) and the ST2 boss. The midboss is good, though.
-Slowdown missing in the first part of ST3. However, the slowdown after that is surprisingly accurate throughout the stage! (This is the real highlight of the entire MAME experience, it is better than the port in this part.)
-Stage 4 is a mess. Slowdown is missing in many spots in the first half, but the midboss has slowdown in its last phase that is too slow, making this tricky part a lot easier. Worst of all is the last part of the stage (everything after the midboss), which has WAY too much slowdown that lasts way too long. It is horrific.
-Stage 5 slowdown is stuttery, either too fast or too slow, and just feels rather janky overall. On the PCB it is smooth as butter. On the plus side, the midboss has the proper slowdown.

In addition, all of the transition-in and transition-out speeds are off (usually too fast in emulation).

I will try tweaking things up and down in the Slider menu, but it is possible what we have is already "as good as it gets" in MAME. I will be pleasantly surprised if I can get it significantly better, but like I said, I'll try.

Ultra or Maniac?

also, strange. Where is it supposed to slowdown on stage 1? and nothing ive checked has slowdown on those plants either..
i know its dumb to ask but are you sure you enabled blitter in machine configuration? i had to help someone with that earlier.

also, the stage 4 midboss does not have too much slowdown to my knowledge.

Quote from: Pearl on April 04, 2020, 12:21:19 AM
Ultra or Maniac?

also, strange. Where is it supposed to slowdown on stage 1? and nothing ive checked has slowdown on those plants either..
i know its dumb to ask but are you sure you enabled blitter in machine configuration? i had to help someone with that earlier.

also, the stage 4 midboss does not have too much slowdown to my knowledge.

Maniac.

(All on the PCB:) ST1 has some slowdown on the large beetle thing that comes out on the left side of the screen after the midboss, as well as other bits here and there (none I'd classify as "important"). Yes there is slowdown on the plants if you score on them properly (tap, tap, tapping away). MAME emulation is also missing slowdown on the sand beetle things in the second half. Yes I enabled blitter at the rate you specified.

RE: ST4 midboss. Last phase has slowdown on the PCB/port and MAME. It's very important because if you're serious about scoring you need to jack up your counter to at least 100k in the previous phases and if you die in the last phase your whole score is killed for the stage. Port is a bit too fast here, MAME is a bit too slow, (so far) PCB alone has it "just right".

For some perspective, the differences in slowdown in ST1 and ST2 are relatively minor. None of that missing slowdown strikes me as very important. But the differences in ST4 and ST5 are significant.

Great we got some discussion going here! :righton:

Quote from: EOJ on April 04, 2020, 02:17:23 AMBut the differences in ST4 and ST5 are significant.

Could you maybe link to the replay you've used to determine this, ideally with timestamps? I think transparency is the most important thing here. It would be even better if people who have the PCB could record some footage to put it directly side by side to Mame.

It's great that you know the game that well EOJ, but please let us noobs also understand what exactly you are referring to. Otherwise we will not be able to tweak it ourselves.

Quote from: EOJ on April 03, 2020, 06:14:38 PM

Groovymame with lag reduction ON still feels like it has about 4-5 frames of lag on my PC. This is quite noticeable when I play DFK BL, for example. It feels about the same as the lag in the SDOJ port. This is a big improvement over how MAME used to feel -- I mean, it felt like 6-8 frames before for me -- but it doesn't come close to the PCBs or the good X360 ports.

I have 2 frames of lag with Retroarch and mame core in android (though an extra ~ 5 from the touch screen latency), so i'd be surprised if Groovy alone had double that  :-\  Be sure to enable nobuffer patch in mame settings/cfg, it should cut an extra frame of lag.

Quote from: EOJ on April 03, 2020, 06:14:38 PM
Groovymame with lag reduction ON still feels like it has about 4-5 frames of lag on my PC. This is quite noticeable when I play DFK BL, for example. It feels about the same as the lag in the SDOJ port. This is a big improvement over how MAME used to feel -- I mean, it felt like 6-8 frames before for me -- but it doesn't come close to the PCBs or the good X360 ports.

4-5 frames, getting that with a 2 frames source like cv1k sounds typical of broken settings, meaning the lag reduction isn't working. Maybe 9 in 10 new users experience that as I've witnessed (typically they changed settings in the mame.ini they shouldn't have, or introduced another parameter that's breaking everything, like misconfigured multi-monitors, or they downloaded the wrong build, etc)
There is a quick configuration guide which has crucial info but the site is currently down so check later.
http://geedorah.com/eiusdemmodi/forum/viewtopic.php?id=433

When you use lag reduction (frame delay slider from the UI menu) you're supposed to see tearing appear, that means the feature is active, and as you increase the frame delay level you'll get where it affects performance negatively (frame/sound drops)
[often this is where users go and mess with sync settings and make a fatal mistake]
Set at a stable level before it, like if 7 is too much set 6 or even 5.
On my PC with cv1k games I can set 5 for global cv1k stability. 7~8 is better of course but it's really heavy on the CPU and GPU at times. and yes with Groovy the GPU matters a bit too, in particular with high-res displays like full-hd, wqhd, 4k, so I wouldn't trust much things like Intel iGPUs)
tip: keep an eye on F11 when you set frame delay, make sure the meter stays at 100%.

Then create a specific .ini file for a game, for instance pinkswts.ini
in it write:
vsync_offset              250
and drop it into the 'ini' folder.

That 250 value is just for illustration, you may need a much lower or higher one, play the game to see if it gets rid of the tearing.
typically this takes a few tries to get right.
Note higher values can mean it's too tight for your hardware and you should maybe drop frame delay 1 level then try a different offset value.
tip: the higher resolution your display, the greater values you'll need, think about your monitor's vertical resolution, you're moving the tearing line up and down it.

Alternatively you can use a single ini named cv1k.ini, and drop it into a 'source' subfolder in the 'ini' one.
but using a single offset value for all games don't always work perfect...

Anyway if you did that right you now have your vsynced and lag-reduced video working the way it should, tear-free butter-smooth scrolling and low lag close to that of the pcb (2~3 frames)
Levels of frame delay kinda represent setting chances of occurences of having no unwanted lag at all, it's not really a percentage but you could picture it like with 7 you have 70 chances of an input being lagless within the targeted frame time.
It's more subtle than that but Calamity would explain better.

For the CPU slider, remember there's ten steps in between each % , hence the slowness, and that's not visible from the UI (go to each game's individual .cfg file, open and witness your CPU setting on a 1000 scale to be absolutely sure of the slider position, eventually edit manually there if that's your thing)
As I've said before, even 0.1% can matter in places, some in-game behaviours will trigger or won't by a hair.
If nobody watches this, then 10 people who've set for instance 50% could have 10 different set values without knowing it.

I don't know why you're experiencing a game missing the CPU slider, I'd have to know everything about your setup, build, settings, roms, etc but I won't really go and ask that then provide the inevitable hours of support like I did tens of times on the farm and other places, paraphrasing the official guide(s) with additional explanations, because it's led to people most times failing, essentially because they were very uncooperative and a few other reasons, and I've worked my ass for nothing. I would maybe for you EOJ but there are people here I really don't like and I don't want to help them along.
You can ask anything in private though.


PS: about Calamity, few people who would really have benefited from his help actually went and asked at BYOAC (el_rika gave the link), and those who did often wouldn't bother producing a log file like Calamity demands so he can provide efficient help.
For anyone who's having trouble with Groovy that's the place to go and where to receive support, in fact this is where all the ppl serious about this current topic should go now, start a thread similar to this one and get aid from the most skilled people there along Calamity's.
That would be the smarted and most valuable move, much, much better than going for the dead-end made with old builds and retroarch trash.

However you know the situation right now, and he's in Spain (ouch), so it's possible there won't a be a response before long (plus he was already often absent from the forum even before that)

pps: oh and if you need fresh roms go to r.e.t.r.o.r.o.m.s , besides the 'dome' it is the only place carrying up-to-date rom sets, which is absolutely crucial these days the way modern MAME works, and therefore for Groovy too (wrong/old roms = some things might not work properly if at all)

Quick [crappy] run of Mushihime-sama ultra up to level 4 mid boss.

https://youtu.be/5BWclKbSbKk

(the small annoying stutters are from youtube rendering, not the video itself)

Though maybe a tad slower in some moments (ex: the level 4 mid boss seems to start the last pattern a bit slower than pcb..or not?), it is noticeably closer to pcb than the ps2 port.
  As a small observation, the ps2 port also lacks the on-the-fly blitter management that exists in the pcb hardware, that affects a few spots in the game (very few luckily). Just like mame, it uses a pre-set CPU and Blitter for the entire game. {probably the same case with Ibara}

Quote from: xygax on April 04, 2020, 04:36:23 PM


However you know the situation right now, and he's in Spain (ouch), so it's possible there won't a be a response before long (plus he was already often absent from the forum even before that)

Let's hope he and everyone will be ok in these pretty dark times. Stay inside as much as possible guys, play some Caves, and we and ours will be safe  :righton:

Quote from: Plasmo on April 04, 2020, 03:56:38 AM

Quote from: EOJ on April 04, 2020, 02:17:23 AMBut the differences in ST4 and ST5 are significant.

Could you maybe link to the replay you've used to determine this, ideally with timestamps? I think transparency is the most important thing here. It would be even better if people who have the PCB could record some footage to put it directly side by side to Mame.

It's great that you know the game that well EOJ, but please let us noobs also understand what exactly you are referring to. Otherwise we will not be able to tweak it ourselves.

I didn't use any replay.  However, the official superplay DVD should be sufficient to show the differences I'm talking about. I listed the parts of the stages that were particularly bad in a previous post. As you must know yourself, if you play an arcade game enough (recently) and you have a set route you know right away where it feels different in an emulation or port. And people who are intimately familiar with the way the PCBs play should be the ones judging each new setting proposed (ideally, two or more people per game). I am doing my part here, and I hope other PCB players will join in. In the meantime I hope people will keep posting cpu/blitter settings that they think are good, and I will keep testing them.

@xygax: thank you very much for your detailed reply. It is very helpful. I didn't know about the lag reduction stuff you wrote, but I did know how to properly tune the CPU settings in each game's .cfg file. I play on a Dell Inspirion 5475 All-in-one with the latest build of groovymame (groovymame64_0219.017p_win-7-8-10). It has a 3.1GHz AMD Ryzen 7 CPU and a 4GB Radeon RX560 GPU. I suspect the screen itself introduces at least a few frames of lag.

Later edit: much better numbers that result in way better accuracy are on the next page.

Futari 1.5 maniac Palm Abnormal quick test (CPU 37.9 Mhz, Blitter 54%) Reco needs a lower CPU speed for the smooth slowdown.

https://youtu.be/h-5qT1hOWRQ  (sorry for the potato quality, be sure to select 320p)

Youtube seems to be having an issue, here it's another upload that works better:

https://vimeo.com/406256643

Observations:
Just a bit overall slower (ex. Boss 1 lava speed is just like in BL, Boss 4 third pattern slows down ~ 1s earlier, though feels less jumpy than pcb, some stage bits of slowdown last 2s longer).
Some 2 - 3 Mhz more should get it as close as it can be, though a bit of stutter occurs at times (seen in pcb/360 recordings as well).

Deathsmiles quick test (cpu 52.5 Mhz, blitter 59%) Lvl 3 forest & cemetery:

https://vimeo.com/407969615

Observations: very good overall, not easy to tweak, as even on pcb, many slow parts don't always trigger the same way, due to very very small yet drastically affecting factors (player position, type of shot, quantity of moving objects).

[Only] Rosa needs a lower blitter (57%) and a higher CPU clock (+ 1.5 Mhz) due to the more complex shot/laser graphics that produces more slowdown. (Pcb is inconsistent in some instances with Rosa as well, sometimes it slows down drastically, sometimes not as much).

I will try the Deathsmiles settings this weekend, but the video does not look very close to the PCB (several sections have added slowdown, slowdown transitions in- and out- are too fast, etc. The usual problems!). It's misleading to claim "even on pcb, many slow parts don't always trigger the same way, due to very very small yet drastically affecting factors". In fact, the slowdown on the PCB always triggers the same way. That is to say, if you play the same pattern with the same character, the slowdown will be exactly the same every time. As on every SH3 PCB, slowdown is causational, locational, or a mix of the two.

My wording was a bit wrong maybe  :bigsmile: This game's timings seems more affected by the smallest of factors, almost impossible to observe, compared to other games.(ex. on pcb, Rosa and the Dragon boss, first pattern can be slightly slow, or very slow without obvious differences in gameplay [the amount of falling rocks you randomly destroy might be an important factor]. Another ex. forest Boss big apples pattern slows down earlier/more sudden, if both apples appear ~ the same time, or ~ 2 sec later if one appears first).

I've seen this spasmic slowdowns ins and outs on many pcb Deathsmiles gameplays (all sh3 games have them). I think it's overall a bit slower too, and also much closer than the port (my God that's bad).

Quote from: el_rika on April 16, 2020, 01:11:31 AM
also much closer than the port (my God that's bad).

The X360 port is one of the more accurate CAVE ports (certainly more accurate than any MAME emulation I've seen thus far). Perhaps you are thinking of the Steam port, which is horrible.

Was it maybe patched at some point? Because i have it on 360 and it's very off in many instances (forest boss slowdown is off, graveyard as well, level sections are either too fast or too slow).

https://youtu.be/Or2uHxS0o2s  (forest and graveyard bosses are very eloquent).

JP version is excellent (no need for a patch). US version was messed up on release but received a patch later on that fixed the slowdown. You should download the patch.

Also, the video you linked to is 360 mode. Arcade mode has more accurate slowdown.

I assumed as much, as it was really messy. Will do that sometime in the future when i get to my xbox. Thanks for the info  :righton:

Quick question: does Deathsmiles MBL slowdown more than vanilla (i'm talking similar conditions, say both level3)? Black Labels have a tendency to do that.

Could anyone link me a pcb (preferrably Windia) MBL playthrough (not lvl999)?

There are a lot of videos on Nico douga:

https://www.nicovideo.jp/search/%E3%83%87%E3%82%B9%E3%82%B9%E3%83%9E%E3%82%A4%E3%83%AB%E3%82%BAMBL?sort=h&order=d

I don't recall there being more slowdown in LV3 in MBL compared to vanilla. The shots/lasers are basically the same in each game. Bullet patterns are very similar too.

However, there are parts with LESS slowdown in MBL compared to the vanilla. Such as the Jitterbug boss fight. This is apparently due to the higher spec of the CV1000D ("SH3-b") PCB. DSMBL is the only BL to be on different hardware in comparison to the vanilla version.

Oh, thanks so much for answering. I didn't know that MBL used slightly different specs; this might explain the small speed differences.
I will check the link you provided for some down to earth pcb Windia vids!

I'be been testing for a couple of hours and it seems the overall slowdown is indeed similar, with some exceptions. Most importantly, Windia's full power laser (BIG option circle shots) definitelly slows down the game more than in vanilla (which has a smaller laser @full). Also some bosses have slowdown eliminated or modified, see forest Tree Boss, where big apples pattern slows down much less and only if you keep shooting the apples. Also last pattern doesn't have the vanilla slowdown anymore (nor the safespot :-[)
Lava dragon also has most of the 1st pattern slowdown removed.

I'm only talking level3 here, as 999 i way out of my league atm, but it's getting clearer ~ 2 Mhz higher and ~ 2% faster blitter is starting to look right for MBL compared to vanilla.

Thanks again

Will return with more findings  :righton:

So, Deathsmiles MBL is indeed a bit different in terms of slowdown especially when you activate 1000 Power mode. Windia's full laser slows down the game much more agressively than in vanilla. Capser's shot as well.

1.5 mhz more and 2% less blitter usually does the job. For Windia though, 54% blitter seems to be the sweet spot. Taking a little break from it for now.


Meantime here's an Espgaluda 2 quick test with Cpu at 49.76 mhz and blitter delay 63%. There are spots when the game slows down, depending on how you play and what shot you use, especially in later levels, but most of the slowdown occurs in awakening and ultra-awakening, mid bosses and bosses.

https://streamable.com/mhvaqf

(Any audio delay or slight stutters are due to streaming conversion)

Daifukkatsu 1.5, what a gorgeous game   ^-^

Different ships/modes produce more or less agressive slowdown, with B/C Strong ships' shot producing the most. Unlike Futari though, it seems on pcb Cave didn't use different CPU/Blitter values, to have similar timings with all ships/modes.

On pcb, mostly with green and blue, the game has certain parts where it exhibits that CPU dependant spasmic slowdown seen in Futari (and most others).

Too high CPU clock value, eliminates some of the subtle slowdown found on pcb, while too low produces too much in-out slowdowns (spastic). There are some spots affected exclusively by blitter (ex. 2nd Boss penultimate attack), so it's a matter of fine-tuning it.

Quick test with B Power:
https://streamable.com/nppkmt

Quick test with B Strong (a bit longer):
https://vimeo.com/422407474

Cpu 43.62 Mhz 
Blitter 59%

As always, the upload conversion produces a little stutter in a couple instances, so ignore it.

Could anyone (EOJ?) link me some pcb Akai Katana gameplays? Prefferably not superplays. This is another game where C ship slows down the game much more than A & B ships, so careful comparison is needed.
Youtube doesn't like this game so much, there aren't many pcb videos of it.

Thanks very much!

I don't notice any extra slowdown with Type C in Akai katana compared to the others. The slowdown in the game is based mainly on how much gold you have rotating around as well as how many enemies and bullets are on the screen. For PCB videos there is youtube and nicodouga and that's about it AFAIK. Not a whole lot out there.

Your DFK settings produce slowdown that is not very accurate to the PCB (too much slowdown, slowdown is too slow, etc. The usual problems).

Oh, thank you for the feedback and observations!

Watching a couple of Akai Katana vids led me to believe that there's a difference due to the shot spread, but as you say, it's most likely the accumulation of greens and/or golds. Need to watch more  :righton:

Type C can accumulate green energy orbs more rapidly and more often than the other ship types, which leads to more slowdown. So in that regard you could say Type C has more slowdown overall. There may be a minor effect with its shot as well, but honestly the game has so much slowdown even when you're not shooting, I don't notice anything extra that is induced merely by the act of shooting.

This should be the easiest game to get better slowdown emulation in MAME compared to the X360 port, because 50-60% of the slowdown is missing in the port. Even 60-70% accuracy in MAME would be a big improvement.

Good info there. It did seem to be the case at first glance .

I always tend to settle for a bit more slowdown in these games myself. Just love the dramatic near miss feeling it gives  ^-^

For emulation I think it is best to aim for accuracy, not 'a bit more slowdown than on the PCB', even though perfect accuracy is not possible in MAME. From what I have tested out thus far, no MAME emulation of any Ikeda SH3 game is more than 70% accurate (the ports are more accurate in basically every case). Yagawa stuff fares noticeably better (e.g. MMP and PS can be set to have more accurate slowdown in MAME than in the ports) except DFK BL, which is on par with the Ikeda stuff in terms of accuracy (probably because it is an Ikeda game in its core programming).

Aim for accuracy? I don't know if I should laugh or cry.

Again it is a waste of time researching this using an outdated build. For the Nth time some ingame behaviours changed a bit after the recompiler was introduced (0.192 mem loadings that can influence slowdowns in places). Also using a proper up-to-date build you wouldn't have to deal with crashes and workarounds.

In short whatever you guys find here is in part of no use to users of proper up-to-date builds, and of course no use for the future.

The people who pushed for doing the wrong, uneducated choice of going for outdated cv1k emu ruined the chance of this 'project' to be at least a little serious, as expected from the SRR (Shmuppers + Retroarch = Retardation) typical combo recipe for inacccurcy and promotion of anti-progress, and the ugly clickwhores a la Mark_MSX will surely further promote mediocrity since that's what they exist for/live off.

Aim for accurcy = start with using a proper up-to-date build period.

Retroarch culture is people who don't understand the serious problem of sticking with heavily outdated versions of software, it's a cancer of our times for the world of emulation and development as a whole, a disservice to video games.

Damned Brandolini's law is the essence of the internet.  :displeased:

U OK hun?

I use the "proper, up-to-date build".

Testing a bit of Akai Katana, another gorgeous game full of pretty effects.

I've been studying this for the past week (still don't fully understand all the elements of proper scoring - do i actually need to graze bullets with the captured orbs and gold?! or they mature on their own after a fixed time?) and i have a good idea on what it needs to properly run in mame.

As i assumed earlier and EOJ confirmed, type C slows down the game most, and it's a very noticeable difference in slowdown, with any of the ships, between an option full of matured orbs, small orbs and no orbs.

A guy on nico did pcb runs with all characters without ever going into Bubble mode (not an easy thing to do :oogle: ), which is very helpful for testing.
There are sections in this game where, especially with C and B, the game slows down so much that i think it's in single digits. Possibly the slowest slowdown in any Cave   cv1000 game.

B ship:
https://vimeo.com/426182216

Cpu 47.00 mhz
Blitter delay 68%

C ship needs a faster Cpu clock and lower blitter value (60%), while A ship needs a lower Cpu and considerably higher (i settled for 72%) blitter.

Muchi Muchi Pork!

Love everything about this game, except for the bosses, mostly because they lack a health bar or audio cue of some kind. Maybe they'll grow on me    ^-^

Cpu 53.55 Mhz, blitter delay 53%

https://streamable.com/vh6pcn - level 1

https://streamable.com/cfpdff - level 2 and 3 (half)

Maybe a little faster at times, though pretty good overall (level 4 boss slows down just a little bit more than on pcb). This game is soo delicious and sucking in those big golden porky heads is incredibly satisfying.


Daifukkatsu Black Label

This game is pure madness, bullets everywhere, the hud and your ship completely vanishes, hyper quickly becomes a double edge sword, the soundtrack is blood pumping...what can i say, a masterpiece   :righton:

Cpu 41.57 Mhz, blitter delay 57% (Strong/Power)

https://m.youtube.com/watch?v=S7kxrY5R5jw&t=172s - level 1 and half of 2 Green Strong

https://m.youtube.com/watch?v=xmXpWdfVEnQ&t=4s - level 1 and half of 2 Blue Power

https://m.youtube.com/watch?v=LpuUDgMpkw8&t=283s - level 2 and 3 Green Strong (got ultra lucky in a couple of spots).

!youtube/streamable always add a bit of annoying stuttering in some moments, so ignore it!  :'(

This game's timings are very very dependant on rank and shot type. As with all games heavy on special effects, blitter is the first to byte from lasers and explosions, while Cpu goes after the rest (bullets).
The game is fastest with A, a bit slower with B and (slightly slower) with C, like most Cave games with this forumla.
Level one and three bosses on Strong/Power with a full red rank, as well as a couple of dense bullet pattern moments (before mid boss level 3, begining of level 4) are important and reflect well the overall slowdown of the rest of the game.

If anyone knows a pcb Strong/Bomb no Ura no Hyper level 4 mid boss footage (preferrably B ship), it'd help a lot

Bomb style needs 1 Mhz more with B and C, otherwise some instances are a bit too slow (ex.level 1 boss 3rd pattern full red).

what an interesting thread, I currently run a 360 plus UVC for my cave ports but id love to one day just have a PC that does everything rather than having to mess about with so much equipment.

So, Futari Black Label.

No need to reiterate how amazing this one is.

There's a lot to be said about this game and how the emulation handles it, but i'll keep it short.

On pcb, contrary to the norm, sometimes Reco produces more slowdown, sometimes Palm does that (ex. as opposed to Daifukkatsu where the rule is that blue always slows down the game more, and red less ). So the logic is not clear cut, and this made analysing and tweaking much more time consuming.

Reco maniac:
Cpu 45.26 Mhz, Blitter Delay 54%
Palm maniac:
Cpu 46.08 Mhz, Blitter Delay 56%

Reco god:
44.54 Mhz, Blitter Delay 56%
Palm god:
44.33 Mhz, Blitter Delay 56%


Overall level 2 boss and certain Larsa patterns are great for the CPU values, while level 3 and 4 bosses and again Larsa, for blitter.
In-levels and mid bosses, line up very well with these boss values.
Also, the more agressive/point blank the game is played, the more slowdowns happen. Superplayers tend to always play like this, for those red aura gems  :shock:

Observations:
There are a couple of instances (boss 3 and 4) where, depending on how homing (mostly Reco's little bugs) connect to the boss body, an extra 1 or 2 seconds of slowdown occurs. I've seen it in pcb vids and it seems to also be dependable on how much of the boss's body is on screen, so it's somewhat random.

In maniac, 2nd level Boss, first salvo of last segment, is a bit slower with Palm laser, if it connects the center of the boss. Shot has no issues.
In maniac (to lesser extent God) level 3 boss first salvo is slower with Reco if laser hits frontal compared to pcb. Last pattern also depends on positioning, but it is slightly slower as well.

[In these bosses, it depends a lot on how soon/late you create that ~ 3 seconds continuous white flash, with laser/shot, on the boss's body. It seems superplayers actually use this to their advantage, creating a bit more or a bit less slowdown in those quick moments]

Larsa's first salvo in maniac is just a little slower with Reco's laser compared to pcb, though i've seen it go slower in some pcb vids while a bit faster in others.

Larsa in god is very good with both ships :wink:


Maniac:
https://vimeo.com/471737529/ (Reco maniac lvl1,2,3)

https://vimeo.com/471731416/ (Reco maniac lvl1)

https://vimeo.com/479581629 (Palm maniac lvl1,2)

https://vimeo.com/479582830 (Palm maniac  lvl3 boss)

https://vimeo.com/475076907/ (Palm maniac lvl4 boss)


God:
https://vimeo.com/476652165  (Reco god lvl1,2)

https://vimeo.com/477588588  (Reco god lvl2)

https://vimeo.com/user107095125 (Reco god lvl3 boss)

https://vimeo.com/476787078  (Reco god lvl4)

https://vimeo.com/476856294 (Reco god lvl4 mid boss to boss)

https://vimeo.com/479470121 (Palm god lvl4 boss to lvl5 mid boss)

- as always, there are some stutters from vimeo conversion.

Note: There is a behaviour on pcb that can not be replicated (without completely breaking everything else):
Palm (and to a lesser extent Reco's) laser effect seems to have a greater impact on slowdown in less busy scenes in certain levels. Easily observed in superplays at the begining of level 4, where Palm's laser visibly slows down the speed. Other similar moments don't seem to behave the same, with Palm not slowing down the game this dramatically.
This somewhat supports Trap15's old idea that different bleding methods need different blitter values. Thankfuly it happends only in a couple of small instances, the overall blitter and cpu values taking over quite quickly.

Cheers to all.

Revisiting Mushihimesama and Futari 1.5.

My initial analysis for both games was flawed, and the results not as good as they could have been, so i re-tested and compared to pcb runs, with better understanding of how the games behave and how mame handles the blitter delay.
There are surprisingly few pcb runs available for these games at high quality in maniac and ultra modes, so thanks to those that helped me find them :)

The new numbers are much better and i think, as accurate as emulation allows it atm and for the forseable future.

Mushihimesama Futari 1.5:

Reco Normal (maniac):

CPU 47.7 mhz, Blitter Delay 57%

https://youtu.be/D-Qd5cz_tCc lvl1and 2

https://youtu.be/qBU3W4jsHbI lvl3

https://vimeo.com/492447261 lvl2 and 3+boss

https://vimeo.com/492351257

https://vimeo.com/488979653 lvl5

https://vimeo.com/492842604 lvl4+boss,5 and Larsa (potato quality, but showcases how accurate Larsa is)


RecoNormal has a more stuttery normal shot slowdown compared to PalmNormal. The 360 port mitigates this a bit by adding longer slowdown sections in most instances.

Palm Normal (maniac):

Cpu 48.5 Mhz, Blitter Delay 57%

https://youtu.be/oloBwbrLPIo lvl1

https://youtu.be/ZpZmRlHV0Cc lvl3 boss

https://youtu.be/IY2eKyVMZ6I lvl1,2,3

https://youtu.be/kGD3sHywIdM from lvl4 boss to Larsa

https://youtu.be/MQKTuvXmBy4 lvl5

Normal Palm's shot slows down the game most. Does that on pcb as well. In mame it may be a bit slower in some instances, though definitelly in the 10% range. Tried to show that behaviour in a couple of spots on bosses.

Abnormal Palm (maniac):

Cpu 41.5 mhz, Blitter Delay 56%

>footage coming soon<

The normal shot on pcb slows down the game more than in mame, so the game is a bit faster overall in mame. Laser on the other hand slows down the game (lvl3 boss) a bit more than on pcb.
Overall the game is faster (less slowdown) than with Normal Reco and Palm.

Abnormal Reco, Original and Ultra, waay out of my league to properly test them.


Mushihimesama:

Cpu 41.77 Mhz, Blitter Delay 57% (Ultra mode)

I mostly use Wide Shot, as do 99% of the players.
My inital cpu clock speed was too low. This one is the sweet spot for the Cpu dependant patterns (boss1 first salvo, level 2 bullet cancelling sand-worms circular salvos) and overall speed. Level 3 is where the Blitter Delay is important, as there is a lot of in-out slowdown on pcb to be observed.

https://youtu.be/Vui28Eaes-M lvl1,2,3

https://youtu.be/elwYtjxbQlo lvl1,2,3,4,5(half)

https://youtu.be/uuTuL9inw50 lvl5

Maniac mode:
Cpu 48.0 mhz, Blitter Delay 57%

>footage in the future<

Edit: long overdue maniac footage:
https://youtu.be/4MpB3ig9uAk
https://youtu.be/fvQO2MFUDGU
https://youtu.be/r4PtTA-1yEU
(sorry for the slight vibration sound that pops up)

Plays very very close in maniac and probably original as well (never tested it).

Youtube always adds some kind of resample and small extra stuttering to these vids, so that's unfortunate.

So, further testing on a laptop (windows) with a recent mame version, revealed that the post 0.192 cv1000 driver needs 2.3 mhz less for the CPU, to match the speeds shown in this topic.
Only tested two games (Mushihimesama ultra and DfkBL), but it's definitelly around this % difference for all.


While a bit off topic, i'd like to share a couple of visual enhancements that are possible for the Cave shmups, thanks to the mind blowing edge detection implementation and recent improvements in the scalefx shader (Spooky of libretro gets the credit, my excuses if i'm mistaken). It's like a hardcore AA solution for 2D 240p  :righton:

It's a custom preset made by me, with added scanlines and a touch of cel shader (which in my opinion makes games with dirtier artwork, like Progear, Esprade look astonishing). They also look so much better in motion.

Progear

https://imageupload.io/g/rEyuLyOT1l
https://imageupload.io/g/n0rku22YNV
https://imageupload.io/g/hC7SgYpAVi
https://imageupload.io/g/m9hkgqFRlA
https://imageupload.io/g/tS47Xc4c3Y

Esprade

https://imageupload.io/g/eCzr54CDTe
https://imageupload.io/g/n3YWQMuKCB
https://imageupload.io/g/EzWALHoJsB

Espgaluda

https://imageupload.io/g/fdOg8jEidZ
https://imageupload.io/g/7SMbuoKuc5
https://imageupload.io/g/MuULBVbKna

Ketsui

https://imageupload.io/g/aElg87H63M
https://imageupload.io/g/zQqjs07FwH
https://imageupload.io/g/b3cMSmzaeL

Mushihimesama

https://imageupload.io/g/BxATWY3qm8
https://imageupload.io/g/n5BNeutmUz

Espgaluda 2

https://imageupload.io/g/yK1Qx3Im0q
https://imageupload.io/g/F6PyoDVR0F
https://imageupload.io/g/BepR0GsLcr
https://imageupload.io/g/O50RmwC7ly

Ibara Black Label

https://imageupload.io/g/dL03yBxVrv
https://imageupload.io/g/8rv0Po0ToV

Daifukkatsu 1.5

https://imageupload.io/g/6GCDSERomG
https://imageupload.io/g/gJM5PeNZ61

Hi

Does anyone have a list of the best available setting for these games ?

I know they wont be a 100% but it would be nice to set these up in mame with what people regard as the best settings in 2021

I really hope someday these games can be made perfect through emulation as the PCB's are out of the question now for most of us.

Thanks

The updated settings presented here in this very topic are the best. Scroll through the posts (start with theast page).

Ok no problem,  I only ask as I was looking for settings for DSMBL and come across some conflicting opinions.

I'll dig through this thread and make my own list in notepad so I can refer too.

It's a shame no one has done a specific core on retroarch just for SH3 but its obviously not that easy as I'm sure we would of seen one by now.

Thanks.

Dsmbl was one of the hardest games to analyse, as every character's shot/laser has quite different impact on overall game speed.

Here is the summary, to save you time:

Deathsmiles MBL:
53.35 / 54 (Windia)
53.04 / 56 (Follet)
52.53 / 58 (Casper)
52.53 / 58 (Sakura)
53.35 / 55 (Rosa)

Thanks very much  :)

Quote from: el_rika on November 01, 2021, 03:50:56 AM
Dsmbl was one of the hardest games to analyse, as every character's shot/laser has quite different impact on overall game speed.

Here is the summary, to save you time:

Deathsmiles MBL:
53.35 / 54 (Windia)
53.04 / 56 (Follet)
52.53 / 58 (Casper)
52.53 / 58 (Sakura)
53.35 / 55 (Rosa)

Hi

My copy of Mame has a slider for CPU overclock but only goes up and down in increment's of "1" is this the correct setting

https://ibb.co/Pr0rWRg (https://ibb.co/Pr0rWRg)

Thanks

If you wanna do this right use GroovyMAME 0.237, the very latest with all properly working saving sliders with decimals precision added, not whichever core on retroarch.
RA is of no help since the only versions it supports that have saving sliders are too old.
Also older versions of standalone MAME and Groovy have their lackings and quirks too that are annoyances if not liabilities for tweaking slowdowns in cv1000 games, so ppl shouldn't waste time with those, no RA, no old build period.
If they're worried about roms well the up-to-date sets are basically everywhere now every month, the years of struggling are over, I think a lot of users still haven't noticed.
So emulation of cv1000 has been the most up-to-date in recent MAME and Groovy follows its drivers development faithfully, that includes the small adjustments to performance and refresh rate MAMEdev have done over time, which some very thick-skulled ppl with a phone and old-ass RA cores still don't understand even after years of telling them that it DOES make a difference for this research, and that results done with old versions are useless to share.

- Get GroovyMAME 0.237 (whoever: complain only to yourself if you get an older version and experience issues, missing stuff etc)

- First in Groovy's mame.ini edit this way for a basic flat panel use (not crt):
cheat                     1
monitor                   lcd

- Then launch a game and in the ingame menu go turn blitter delay on then reset (F3)

After that you're free to adjust both CPU% and blitter sliders, it'll all be saved.
CPU slider uses % but you can see the Hz in the machine information menu if you want.

You're also free of using other sliders that do save too, frame_delay to minimize lag, and vsync_offset to eliminate tearing if you have some.
The higher frame_delay the more often your inputs are at pcb-level of delay, although reaching 8 is tough on both CPU and GPU, and 9 almost impossible on heavy games.
NB: abusing vsync_offset has a huge toll on performance so it's better to reduce your frame_delay level instead.

Use Portaudio to reduce sound latency, and HLSL if you want, they do work in combination with everything else of course, up to you to learn how to configure them.
HLSL is rather old but at least it's still there.
Personally tho I prefer a simple light filtering, I just use the following in mame.ini (Groovy's)
autofilter                0
autostretch               0
filter                    1
prescale                  2
It's a bit blocky but clean and colors are good.

But you CANNOT use BGFX or change anything else in the configuration that has to do with video backends or sync if you don't know exactly what you're doing.
This is not baseline MAME nor RetroArch nor FBN or whatvever, Groovy has got its specifics that most new users break by touching settings they shouldn't have, but hey Groovymame forums on BYOAC exist.
Anyway for playing tweaked cv1000 games you don't need to know more.
(Would you want to play more games like the 1st gen Cave games or older Toaplans with benefits of frame_delay, I recommend increasing from 2 to 3 the following:
sync_refresh_tolerance    3.0)

Groovy's as good as arcades emulation gets on a simple PC and normal monitor without breaking emulation accuracy.
Anyone who wants actually better get yourself a GSYNC setup or dive into the other possibilities with flat panels and CRTs that actually exist and work, using groovy or not.
Don't fall for the BS snake-oil RA and shmuparch are selling on lag and refreshes, well, I guess most ppl do, and it's too late for them to realize, plus retro arcades got old so it's preaching in a desert.  :P

It seems recent mame versions only work like this.
Small increments affect the performance a little, but you're still good.

Very important though: my numbers are used on older mame version. Newest mame versions need 2 mhz less for CPU values (blitter is the same).

Hi

OK,  thanks for the detailed responses,  I'm planning on making another more upto date GM PC in a couple of months running a I7 3770 & HD7570 , I'm currently on 0.220.

I also will be using this in my Astro & Aero so will be using a CRT.

I havnt got a clue how to update mame after i have it all set up and am always to scared to try just in case I mess all my hard work up.

Quote from: el_rika on November 06, 2021, 09:50:55 AM
It seems recent mame versions only work like this.
Small increments affect the performance a little, but you're still good.

Very important though: my numbers are used on older mame version. Newest mame versions need 2 mhz less for CPU values (blitter is the same).

You've been told for years and not just by me that using an old version like you do means people who use up-to-date builds will have different results than yours on cv1000 slowdown adjustments, you're just holding progress on cv1000 tweaking and disrupting the potential of coordinated research, since ppl can't work together in the same software conditions.
Performance of the cv1000 driver and refresh rate have changed more than once by MAMEdev's work on the driver, even if those were little changes in appearance, considering how very sensitive this blitter+CPU% business is, just stating a random 'just minus 2mhz' doesn't cut it, you're not taking this seriously refusing to use an up-to-date why should ppl trust you stating such an approximation ? RA is jank, forces ppl to use old software, and is therefore unreliable, you shouldn't encourage ppl to follow your example for something that requires actual progress and cooperation.

Quote from: trev1976 on November 06, 2021, 10:10:26 AM
Hi

OK,  thanks for the detailed responses,  I'm planning on making another more upto date GM PC in a couple of months running a I7 3770 & HD7570 , I'm currently on 0.220.

I also will be using this in my Astro & Aero so will be using a CRT.

I havnt got a clue how to update mame after i have it all set up and am always to scared to try just in case I mess all my hard work up.

You don't have to go the whole mamecab deal now to play the right stuff the right way.*

0.220 is old, you're better starting with a fresh install which is done in minutes if playing Cave cv1000 games and tweaking slowdowns and lag properly is what you want.
Also getting full sets of the very latest roms these days is easy as pie, I can't tell without breaking the rules but heh, just lurk around it's relatively fresh news.


[moar, big rant!]  :cool:

* To clarify; there's long been a big misunderstanding in the little world of arcades and emulation; GroovyMAME is definitely NOT limited to CRT usage, it's actually superior to every other build as a standalone MAME to use even on your average PC with a LCD, and it works with nVidia or intel iGPU too, of course.

It features non-destructive lag mitigation, saving sliders for Blitter delay and CPU%, also working in combination: Portaudio lag reduction and HLSL.
comes with mame.ini also as a convenience for those who don't like to use command line to produce one.

Actually it can do its own fashion of variable refresh even on some PC flat panel monitors that don't officially feature that, and without even installing CRT_Emudriver (I have two monitors that support that groovy exclusive feature, such monitors are rare but not so much when you know what to look for), though in this case it requires and AMD card. Well...in fact there's a way on nVidia cards too tho using fixed modes.
That's something no other build features, heck it can even do custom 4K modelines on the fly, so it's in reality the best both for CRT and LCD/flat panels.

GroovyMAME is an improved MAME as a whole, in no way just limited CRT use then. It pioneered pretty much every feature that improves the experience in arcades emulation since about 2012 when frame_delay was introduced, then it brough to other builds things like the default (but limited to only 1 frame) lag reduction baseline MAME features now, and previously integer scaling, Portaudio lag reduction, saving sliders, support for exact refresh modes outside 60 for displays that normally don't, all that on top of its initial goal of being a CRT-oriented build.

Groovy by itself can eliminate almost all the lag beside that game's natural/inherent's. In practice that means it can kill the 2~3 frames of lag other builds produce the moment you use any form of sync setting (whether vsync type or double/triplebuffer type), there then Groovy goes even further as it can as well compensate for input delay on the very last troublesome frame where all other builds tend to register inputs too late.
In total it kills 4~3 frames of lag when you put it against BGFX and d3d/ogl, litterally putting your total lag at the door of pcb-level of delay (compared to that the 'lag reduction' feature currently in MAME removes only 1 frame, it was ported from Groovy but is only a portion of the real deal and therefore nowhere as effective. I've seen lots of ppl on forums have misunderstood that dramatically)

Today Groovy is so well rounded and polished that you don't even have to edit tons of ini files and such, anyone can use it with just the few steps I've listed above, if anything RA or FBN are sensibly harder to set up than it.
I'm baffled that all the arcades communitites have basically ignored it all those years and instead embraced broken garbage like RA, shmupmame, shmuparch or whatever that's anything but the actually best of the best.
Dang there's even a lag tester that's been developed by Oomek specifically with a pluging to test MAME's lag and that proved Groovy is everything it claims: http://www.gameinputlagtester.com/ no one gave a damn.

There's such a thing a 'too good for people to believe', probably, even if they have it before their eyes they can't believe it's just there and it's free and easy to use.
But an influencer giving them a pre-configured RA with old-ass core and utterly accuracy-breaking settings ? a lag-reduction method that allows players to perform with less input delay than even the original game's hardware and its performance record still be validated ?...everyone's fine with that, total trust !  :righton:

Makes me think also of the FPGA scam which has helped some people make big money arguing solely on semantics, while in reality they were selling extremely overkill emulation setups just housing further developed and therefore with improved code accuracy against some old MAME drivers that haven't been touched in ages. Haze sait it himself, those FPGA builds don't offer superior per-se properties vs a pc and software emulator, they don't magically resolve things like missing timing delays (the reason we we are here btw), they've just had developer working harder and further than mamedevs did on those specific games. And FPGAs being weak there's no hop to emulate stuff like cv1000, it'll always be old games up to the mid-90's at best.
I've seen some people throw insane amounts of cash on this on the sole belief 'FPGA is hardware emulation therefore it is by nature superior', oh God, the BS ppl will accept if you give it to them like it's the cure.
I once believed ppl in this hobby were smarter than rich kids buying $3000 computers to play COD, but after over a decade spending time with them I've realized; wherever you go the reason why snake oil sells anyway, is probably the same.

Whatever criticism ppl migh have had against MAMEdev and their policies along the years can be argued about over ana over, whatever, it stands that they're still by far the only ones we can fully trust when it comes to judging of the rationality and quality, and GroovyMAME following their lead matches those requirements. When they say retroarch does BS and harms real valuable emulation and its development, well that's pretty damn true and we have prime examples like we've seen here.


TL;DR for your quality arcade emu fix trust MAME and legit builds like GroovyMAME, inform yourselves, don't trust RA's and derivates like shmuparch's snake-oil narratives.
Use up-to-date builds, they're here, they're not hard to use, the roms are around too, to play the best way possible you don't have to go for ages-old outdated builds and romsets that misinformed ppl recommend, the newer cutting edge stuff is better for so many rational reasons: use it !

And that's what you need for Cave CV1000 slowdown tweaking period.

[/rant, which im sure no one will give a damn about but heh, guess that was my last attempt wherever at bringing some light against the dominant obscurantism in that field. thats the nerdiest thing ill do this year and hopefully last]

1.The 2 mhz is not random, it's tested.
2.The blitter code is exactly the same since 10 years ago.
3. RA is not jank.
4. There is no "coordinated research" for cv1000 slowdown. I am the only person to ever take this seriously and actually test, compare, provide hard proof and numbers.
5. Nobody is forcing you to lurk this topic, when you can do your own research with the latest version of whatever you want (i already explained to you that by the time you finish your research, 20 new mame version would have been released, so you won't be up to date ever)
6. Calm down, deep breath

Coordinated research for cv1k timings would tbh not have much to do with the current blitter/cpu settings.

At best, tou can use those sliders to get something better than the mame default, but it will still always be an incorrect approximation due to it bot really representing the actual slowdowns of the pcb.

The cpu underclock helps being the slowdown closer to the real thing by just decreasing the clock speed, instead of using the actual sh3 wait states. These wait states are known, but the main issue is that caching makes it very hard to emulate the behavior, since only some ram acceses will actually trigger waits.

The blitter delay also just injects a fixed delay to some blitter instructions. This seems unlikely to map to the actual behavior.

Proper research + accurate emulation would require:
- Rewrite sh3 logic to use wait states for external access.
- Emulate simulated sh3 caching (very hard)
- Research blitter behavior under heavy load on a pcb. Could be done by a benchmarking prog rom written over jtag, but also loads of work.

Messing around with blitter is more of a rough tuning to get something better than "no slowdown whatsoever", but exact values per game will not be a thing. This is also why you end up with different percentqges per stage/ship when you are poking around with it.

Badically tl;dr:
- Current sliders are flawed, and no matter the setting will not be accurate
- They can still lead to better playability than default
- "Research" in exact percentages doesnt have much value. Just pick something vaguely correct
- Actual research into fixing this is a lot of work, which explsins why noone has done it

I wouldn't say it has no value. EVen though I own all the cv1000 pcbs (well except the impossibly rare ones like akai limited and mushi matsuri) I still like to have mame for practice.

I would never play the cv1000 stuff "seriously" in mame but I do appreciate having something to use that works ok enough for some save state practice, especially for bosses.

Yeah, as I wrote, the settings are useful to make something that behaves better than default. They definitely have value.
Trying to approximate down to 0.1% values is meaningless though. Just pick something vaguely "right". Exact values for actual slowdown doesnt exist, since they dont map to same slowdown behavior on hardware.

Even with the current state of the core emulation, what would help a bit for some extra % towards even better acccuracy in some cases (ex. Ab Palm in Futari 1.5 or Rosa in DS), would be sepparate blitter settings for different blending effects.
Both MetalliC and Trap15 fancied this idea back then, and after analysing these games a lot these past years, i'm convinced that it would make quite a difference in these particular cases.

Very doable, and obviously it's not about being pretty, it's about the end result.
It's gonna be pretty and fancy when all the wait states and other factors will be fully understood.

For wait states, I think they are pretty well understood, or well... at least not hard to understand.

On SH-3 there's two registers WCR1 and WCR2 which specifies the number of wait cycles for any external access. These writes are simple to get by just looking at the values the games write there on startup.
The issues is that RAM access (Area 3/CS3) is cached, which means that only cache misses will generate wait states. Emulation of cache behavior like this is very tricky, and would require a lot of research. Most likely, this is the #1 thing that needs to be resolved to get proper slowdown, and any messing around with current sliders will aproximate it poorly.

For blitter, the sliders will just set the time that the blitter will report busy after any write. Pretty sure this is just a way to inject _some_ amount of waits into the blitter, which might make sense, but without more knowledge about how it's actually supposed to behave, I don't think splitting up delay more will add much use.

It's definitely possible to make proper slowdown emulation, but it's just so much work that someone has to do, and there's not really any good shortcuts.