Shmup Related Questions That Don't Deserve a Thread

[Creamy Goodness]

What is the best method for emulating CV1000 games? I am currently running Batocera on a Beelink SER5 and Futari, SDOJ, etc seem to run fine. But considering everytime I play I need to change settings to reduce lag and make slowdown more accurate it is kind of a pain. I do not think there is a way to keep those settings per game and I'm not sure if I am really even getting an accurate experience.

Was thinking of going the Xenia route especially since the games are built for HD. But not sure how well these games emulate on this or if my computer can even handle it. For reference I dual boot so Xenia would run on Windows 11.

[Bassa-Bassa]

What is the best method for emulating CV1000 games? I am currently running Batocera on a Beelink SER5 and Futari, SDOJ, etc seem to run fine. But considering everytime I play I need to change settings to reduce lag and make slowdown more accurate it is kind of a pain. I do not think there is a way to keep those settings per game and I'm not sure if I am really even getting an accurate experience.

There is with Groovymame, it saves CPU settings for a long time now. More importantly, it's also the best way to actually minimize lag (see frame delay), though you need a powerful computer for CV1000. Blitter settings still depend on manual adjustments (and therefore, on expert users sharing their findings) as far as I know, though a bit a go the driver received an update improving this.

[samspot]

Mame saves cpu settings when you save a state. Useful for skipping rom checks too!

[Lander]

Interesting, how does Groovymame's frame_delay parameter work? Searching around, I see claims that the correct value varies game-to-game, or even stage-to-stage, which makes it sound similar to runahead or preemption.

What is the best method for emulating CV1000 games? I am currently running Batocera on a Beelink SER5 and Futari, SDOJ, etc seem to run fine. But considering everytime I play I need to change settings to reduce lag and make slowdown more accurate it is kind of a pain. I do not think there is a way to keep those settings per game and I'm not sure if I am really even getting an accurate experience.

Personally, I use Retroarch (nee Libretro) with the FinalBurn Neo core for my CV1000 needs; FBN has proper support for preemptive frames and runahead, which are useful for clawing back some lag if your system can handle the extra overhead.
Retroarch is stupidly configurable, so you can dial in all manner of persistent per-game / per-core / per-category options once you get over the initial sweet lord so many settings shock.

Shmuparch also exists - a distribution of RA ostensibly aimed at preconfiguring various shmups for performance - but I wouldn't recommend it. It's just a zip of the latest release plus some configuration files, so you end up sacrificing an up-to-date core for the sake of preset options. Better to grab an up-to-date release and harvest the configs you need piecemeal, or just learn how to operate the program and DIY

Though Batocera looks like one of those meta-platform things like Lutris that unifies a bunch of programs under one roof, so for all I know it could already be using Libretro. Still, if it's lacking for configurability, RA is a strong replacement candidate.

Was thinking of going the Xenia route especially since the games are built for HD. But not sure how well these games emulate on this or if my computer can even handle it. For reference I dual boot so Xenia would run on Windows 11.

I'd consider Xenia a last resort unless you're seeking out console-specific features; good as the ports may be, nesting emulation within emulation is not going to do anything good for latency, and Xenia is already a heavy beast.

[Bassa-Bassa]

Groovymame doesn't corrupt the emulation by forcing the inputs faster than the emulated hardware processes natively (runahead) or by taking away the sprite buffering (shmupmame), it just minimizes to negligible figures the lag added by v-sync. In practice, frame delay isn't a per-game setting - ideally you'd set it globally at max but, as it eats so much CPU and GPU power, particularizations are required.

[Lander]

Ah, that feature - inserting an artificial wait between presenting a frame and starting to compute the next one, to shrink the gap between finishing a CPU step (ergo, input poll) and drawing its result to the screen.
Assuming timings are faithful (i.e. not skewed by idle loop detection hacks etc,) it might vary per emulated CPU, since the time taken for the host hardware to step the virtual hardware - and thus, the T-minus-sync available to shave off - will vary by clock rate.
MAME might account for variation and apply an extra offset based on known cycles per tick, though I expect that'd be nontrivial to do without runtime microbenchmarking.

And I'd call 'corrupted' fairly severe terminology for runahead artifacting, unless it's being erroneously attempted on an emulation that isn't deterministic.
In practical terms, it's just an adaptive frameskip with a different intent and more exotic implementation details - machine state is consistent with native and delay-based systems, but the emulator is free to fast-forward through N frames of it for the sake of fitting the latest within the sync deadline.

[Bassa-Bassa]

Ah, that feature - inserting an artificial wait between presenting a frame and starting to compute the next one, to shrink the gap between finishing a CPU step (ergo, input poll) and drawing its result to the screen.

Right, though apparently the actual benefit comes from avoiding a frame queue ATI cards otherwise use with Windows' Direct3D, which implies an additional 3-frames lag or so. That's why enabling frame delay (therefore, using Groovymame), even if your computer only allows for the minimum setting, is always advisable for non-VRR users.

Assuming timings are faithful (i.e. not skewed by idle loop detection hacks etc,) it might vary per emulated CPU, since the time taken for the host hardware to step the virtual hardware - and thus, the T-minus-sync available to shave off - will vary by clock rate.
MAME might account for variation and apply an extra offset based on known cycles per tick, though I expect that'd be nontrivial to do without runtime microbenchmarking.

I think the major drawback regarding accuracy (as in discussed by the author) was actually that Mame devs hardly know for most cases when the emulated hardware polls the input within the frame and it's therefore rarely a properly emulated feature, so you could end up with Groovymame being 1/2 frame faster than the original hardware for that odd instance the latter polls it at the screen's end.

And I'd call 'corrupted' fairly severe terminology for runahead artifacting, unless it's being erroneously attempted on an emulation that isn't deterministic.

That's the issue, in my opinion. I'm fine in practice with artifacts in order to achieve better accuracy, but a game can change input lag even depending on the stage you're playing. There's no way you can set today a global runahead setting for a game and be totally sure you're using it only to compensate Window's added latency as proper measurements for every game just don't exist for now. So basically I can only welcome it when it comes from M2.