SH3/CV1000 emulation in MAME: CPU and blitter settings for emulating slowdown

[el_rika]

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

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.

[EOJ]

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.

[el_rika]

https://youtu.be/hKlVZQVzgRo

Sorry for the atrocious gameplay

[EOJ]

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.

[xygax]

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* 

[EOJ]

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).

[xygax]

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 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. 

[el_rika]

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).

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.

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* 

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.

[xygax]

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.

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.

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. 

[Plasmo]

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.

[xygax]

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.

[el_rika]

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.

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 

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 

[xygax]

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.

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 

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.

[el_rika]

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.

[Plasmo]

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.

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!

[xygax]

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.

[el_rika]

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.

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!

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 

@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.

[xygax]

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.

[Plasmo]

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.

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!

[EOJ]

What settings are you using for Pink Sweets?

[buffi]

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.

[el_rika]

@Plasmo,

Great news, i'm glad

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.

[xygax]

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.

[Plasmo]

And you still wonder why people are ignoring you?

[EOJ]

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).

[Pearl]

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)

[EOJ]

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.

[xygax]

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. 

[EOJ]

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.

[EOJ]

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.