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.

[Technicolor]

Every arcade DonPachi game has internal autofire on the C button.

Giving this a test now that I've gotten back around to it. the C button is supposed to be P1 button 3, right? Because, uh...it doesn't work. At all. It doesn't do anything when assigned and pressed, even after testing multiple keys.

I didn't have this issue at all on my previous device...but it's also hitting me just now that I was using the world version of DDP before, and I downloaded the japan version this time. Would that make a difference somehow? I'll give that a test later, but otherwise I'm lost here.

[Lethe]

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.

I don't think OS latency is worth complaining about anyway. Maybe I'm lucky (I understand it's going to vary by setup), but on my Win10 PC the total time from input to VRR LCD in the middle of the screen is under half a frame. Basically every other imaginable factor is more significant, even the LCD blur at 240hz is more disruptive than the "real" delay. I think much of the problem on PC is developers not understanding how to minimize rendering lag on modern pipelines, which can be partially blamed on there being so little attention given to the subject to begin with with modern game design priorities being as they are. Remember M2 complaining about forced input lag on Windows when indie games were getting practically instantaneous response times?

[BareKnuckleRoo]

Giving this a test now that I've gotten back around to it. the C button is supposed to be P1 button 3, right? Because, uh...it doesn't work.

This is likely to be because you haven't enabled it in the test menu. For whatever reason, the first 4 or 5 games CAVE made have C button autofire options but they're off by default for some reason (unlike Rayforce which has it on by default but allows you to disable it for who knows why). If you're using MAME, hold F2 for about 8 seconds to enter the test menu, and from there C button enable is easy enough to find.

This affects Donpachi, Dodonpachi, Dangun Feveron, Progear, and maybe Guwange? edit: Also, Donpachi's is weird and special in that it allows you to fire MUCH FASTER than tapping the A button does, so you benefit a lot from using C button autofire rather than using an external setup with A button autofire.

Later games like DaiOuJou, Mushihimesama, and Espgaluda all have it enabled by default.

Esp.Ra.De does not have autofire. If you enable the option in the settings, it causes autofire to be enabled on the subweapon which causes it to behave strangely instead of waiting for a fullcharge and automatically firing again as long as you hold it. If you want a true autofire button for the primary shot, you have to use an external rapid fire setup.

[Arino]

If I set up Mame this way, will I get an evenly scaled, pixel perfect image? In this case it's Neo Geo/Metal Slug.

https://ibb.co/wBD0syv

Any way to save these settings? Apparently I can save all kinds of settings but not this one.

[BareKnuckleRoo]

What is it you're trying to do? Define what you mean by pixel perfect in this case, are you looking for them to be perfectly square pixels?

Non-Integer Scaling I believe allows it to stretch to fill up to the top and bottom of the screen, so it'll look the way it would if you were playing it on a CRT screen. The key setting is Maintain Aspect Ratio; the game will look very odd if you play a game intended for 4:3 aspect ratio at 16:9 or something. As long as that's set to On the game'll look fine.

There's many systems that were designed in such a way that when played on a television or CRT screen, the pixels were not perfectly square, and the pixels actually look like wider and rectangular instead of square due to the system's native resolution not being 4:3. CPS-2 arcade games are like this, and I believe the NES is as well. If you want your pixels to be evenly square on some systems like NES you actually have to make it so it's played on a perfectly square monitor rather than a 4:3 aspect monitor like normal televisions were at the time.

If MAME isn't saving your display settings you can try checking to make sure none of your config files are set to read-only or something weird like that. Or maybe it always defaults to fill the screen and set Non-Integer Scaling to On.

[Arino]

What is it you're trying to do? Define what you mean by pixel perfect in this case, are you looking for them to be perfectly square pixels?

Non-Integer Scaling I believe allows it to stretch to fill up to the top and bottom of the screen, so it'll look the way it would if you were playing it on a CRT screen. The key setting is Maintain Aspect Ratio; the game will look very odd if you play a game intended for 4:3 aspect ratio at 16:9 or something. As long as that's set to On the game'll look fine.

There's many systems that were designed in such a way that when played on a television or CRT screen, the pixels were not perfectly square, and the pixels actually look like wider and rectangular instead of square due to the system's native resolution not being 4:3. CPS-2 arcade games are like this, and I believe the NES is as well. If you want your pixels to be evenly square on some systems like NES you actually have to make it so it's played on a perfectly square monitor rather than a 4:3 aspect monitor like normal televisions were at the time.

If MAME isn't saving your display settings you can try checking to make sure none of your config files are set to read-only or something weird like that. Or maybe it always defaults to fill the screen and set Non-Integer Scaling to On.

Hi BKR, thank you for your help! I am aware of what you're saying, that some games do not have a native resolution that matches an aspect ratio of 4:3, but they were still made with the fact in mind that they would be stretched to fill the whole screen (a CRT screen that has an aspect ratio of 4:3 - and on CRT that's no problem because CRTs do not have a fixed resolution the way flat screens have it). Therefore, as you said, some games like Street Fighter II look more like widescreen in their native resolution, when they are not stretched to fill a 4:3 CRT screen. However, there are also a lot of games that still look natural, even when they are not stretched to 4:3, because their internal resolution is still close to 4:3, so I would prefer having them displayed like that whenever I don't play on CRT.
The screen I am using in this case is not CRT and has a resolution of 1920x1080. The game in this case has a resolution of 320x224. (320x224) times four = 1280x896. 1280x896 would still fit into 1920x1080. I assume it would look best to have the game displayed in this resolution. Like highest integral multiple within the limits of the resolution of the screen being used, if that's the correct way of saying it?

[Rastan78]

That's exactly how M2 will usually handle it. Largest integer scale that will fit on the screen. x4 or whatever. So game might not be perfectly 4:3 but a lot of the times pixel art did not account for the slight stretching anyway. And with 1080p there will be a small boarder on top and bottom.

For something like PGM or NES that is pretty far off 4:3 when native they might do something like x4 vertical and x5 horizontal to keep the pixels clean and get the feel closer depending on the resolution.

[BareKnuckleRoo]

Therefore, as you said, some games like Street Fighter II look more like widescreen in their native resolution, when they are not stretched to fill a 4:3 CRT screen.

I'm afraid I do not agree with this statement. It was intended to be played on a 4:3 CRT screen, therefore its native or rather intended resolution is a multiple of a 4:3 aspect ratio. It just has rectangular, widened pixels rather than square pixels. The claim that they look "like widescreen" only is true if you're displaying it at an unintended aspect ratio, rather than the aspect ratio they were intended for.

I do also like NES games with square pixels personally though on a more square screen, rather than stretched to 4:3 TV aspect ratio, even though I grew up with playing them on TV.

The screen I am using in this case is not CRT and has a resolution of 1920x1080. The game in this case has a resolution of 320x224. (320x224) times four = 1280x896. 1280x896 would still fit into 1920x1080. I assume it would look best to have the game displayed in this resolution. Like highest integral multiple within the limits of the resolution of the screen being used, if that's the correct way of saying it?

With a 1920 x 1080 monitor, the extra stretching happening for a game with such a low native resolution is barely noticeable. The monitor's running at such a high resolution that it won't really make a huge difference whether or not it's stretched to the top and bottom edges of the screen or not. Do whatever you prefer. As long as you're not stretching vertical shmups horizontally to fill the screen widescreen I think nobody will complain, hahah.

[Arino]

Therefore, as you said, some games like Street Fighter II look more like widescreen in their native resolution, when they are not stretched to fill a 4:3 CRT screen.

I'm afraid I do not agree with this statement. It was intended to be played on a 4:3 CRT screen, therefore its native or rather intended resolution is a multiple of a 4:3 aspect ratio. It just has rectangular, widened pixels rather than square pixels. The claim that they look "like widescreen" only is true if you're displaying it at an unintended aspect ratio, rather than the aspect ratio they were intended for.

It doesn't really matter what I said there. I was just referring to how I remember it so it might be far off. Or completely off. Anyway, are there really games that were developed using pixels that are not squares? I remember hearing something like that. Again, this might cause zero issues on CRT and its original hardware, but would be a nightmare when using a non CRT screen, I imagine.

I haven't played my NES in a while but if there is one system that is in fact far from 4:3, more like widescreen, it is the Master System! Right?

[Bassa-Bassa]

Anyway, are there really games that were developed using pixels that are not squares?

Pixels on a CRT were never a square, likely it'd help if you start thinking about them like that. Strictly speaking, most games didn't use pixels that were equally tall as they were wide, as 224 pixels was a more common vertical resolution than 240. Then again, this didn't really matter much(*) when designing game graphics as a CRT has all kinds of nuances that made this aspect quite irrelevant - you were supposed to modify the screen geometry for every game's demands.

(*)On those games which use an super wide pixel aspect ratio such as Espgaluda or Progear it did matter actually, and the artists had indeed to take it into account, but they were not the norm.

[Arino]

Anyway, are there really games that were developed using pixels that are not squares?

Pixels on a CRT were never a square, likely it'd help if you start thinking about them like that. Strictly speaking, most games didn't use pixels that were equally tall as they were wide, as 224 pixels was a more common vertical resolution than 240. Then again, this didn't really matter much(*) when designing game graphics as a CRT has all kinds of nuances that made this aspect quite irrelevant - you were supposed to modify the screen geometry for every game's demands.

(*)On those games which use an super wide pixel aspect ratio such as Espgaluda or Progear it did matter actually, and the artists had indeed to take it into account, but they were not the norm.

I didn't know it was very common. That means there is no such thing as pixel perfect on modern screens?

[Bassa-Bassa]

There isn't, but not because the aspect ratio is lost in the process (which, many times, isn't - just pick any CV-1000 game), but because a pixel, when scaled, isn't perfect anymore. Upscaling low resolution graphics goes against the nature itself of pixel art (despite every other indie dev not getting it today), that's why there're so many methods to emulate a CRT display. I'd strongly advise to look into that.

[Arino]

There isn't, but not because the aspect ratio is lost in the process (which, many times, isn't - just pick any CV-1000 game), but because a pixel, when scaled, isn't perfect anymore. Upscaling low resolution graphics goes against the nature itself of pixel art (despite every other indie dev not getting it today), that's why there're so many methods to emulate a CRT display. I'd strongly advise to look into that.

Well upscaling just means that each pixel is bigger, if I am using the terminology correctly, so idk why that would change anything as long as the scaling is even (not sure if this is how you would say what I'm trying to say).
For instance, what I mean is: If you turn 320x240 into 640x480, why would that be bad in any way?

[Bassa-Bassa]

Because the resulting picture has nothing to do with the original:

https://x.com/CRTpixels/status/1599513805717135360

You're not upscaling analogically, but digitally.

[Arino]

Because the resulting picture has nothing to do with the original:

https://x.com/CRTpixels/status/1599513805717135360

You're not upscaling analogically, but digitally.

This post is not even about what we've been discussing? They are showing how an image looks on a flat/modern screen vs CRT!

[Bassa-Bassa]

That post illustrates that digital scaling transforms pixel art. You only can show it comparatively with photography and use a CRT for a big enough picture. Anyway, assuming you're not on your phone or some shit and can see these pictures with no scaling or filtering involved, check this on a modern screen:




and then compare it with this:




Whatever you think of this result, you just can't say there's any fidelity involved in the process, which was where your question resided.

[Lander]

If you define 'pixel perfect' in terms of 'looks like it would on a CRT' then you're in for an uphill battle, given that reproducing a CRT accurately with an imperceptibly-small margin of error requires resolutions and HDR ranges that we simply don't have yet, on top of the non-square-pixels problem.

But if you define it as 'looks like it does in the game's video RAM', then achieving pixel perfection is as easy as turning on Integer Scale (a.k.a. the "don't mangle the picture" setting), setting your emulator's video mode to unscaled (or equivalent), and making sure everything is running at native resolution to stop any extra OS / Driver / GPU / Monitor scaling passes from mucking things up.

For Metal Slug, that should correspond to MAME running in fullscreen at native resolution, with the Pixel Aspect screen mode, and Integer Scale on. You might get black bars on all sides if your monitor isn't a clean multiple of the game's internal resolution, and systems with non-square pixels will have a slightly-wrong aspect ratio, but that's the tradeoff.

MAME's a bit barebones for video options; they're generally workable, but there are some cases where the built-in screen presets end up with bad scaling no matter what - like Cho Ren Sha, where in-game resolution changes break the whole thing. RA is much nicer on that front - more tweakable dials than you can shake a stick at, and a nice GPU mipmap scaler for correcting aspect without introducing crawl or blurring the whole picture.

If machine-correctness doesn't satisfy and you want to rabbithole into reproducing the original art, try the CRT-Royale shader with Retroarch. Unlike most (naive, overlay-based) scanline implementations, it actually simulates the physics of phosphor decay on the GPU, which reintroduces the "no fixed resolution" property (a.k.a. aspect correction for free), localized phosphor bloom, etc, before sampling it back down to a discrete modern-display-friendly grid.
It's fairly caveat-heavy - good results depend heavily on low-res games, high-res monitors, and finely-tuned settings - but can produce gorgeous results under the right conditions; restores artistic tricks that a direct rendering simply can't reproduce, like shaping the beam with brightness in 2D pixel art, or defocusing it with bright depth fog in 3D games to blur and obscure distant objects.

[Bassa-Bassa]

If you define 'pixel perfect' in terms of 'looks like it would on a CRT' then you're in for an uphill battle, given that reproducing a CRT accurately with an imperceptibly-small margin of error requires resolutions and HDR ranges that we simply don't have yet, on top of the non-square-pixels problem.

But if you define it as 'looks like it does in the game's video RAM', then achieving pixel perfection is as easy as turning on Integer Scale (a.k.a. the "don't mangle the picture" setting), setting your emulator's video mode to unscaled (or equivalent), and making sure everything is running at native resolution to stop any extra OS / Driver / GPU / Monitor scaling passes from mucking things up.

I know you're giving him the answer he was looking for, but that's misleading and with it he isn't getting the whole idea behind this issue. It doesn't matter if on a CRT or on a flat screen (see my previous post), scaling a picture digitally breaks "pixel perfection" no matter how integer it is - you're making the computer fill in the gaps instead of being your own brain the one doing it.

[BareKnuckleRoo]

Because the resulting picture has nothing to do with the original:

https://x.com/CRTpixels/status/1599513805717135360

You're not upscaling analogically, but digitally.

This post is not even about what we've been discussing?

It is, and it serves to highlight how complex what you're asking for is. It's part of why I asked you to define what you meant by "pixel perfect" because games in an era of CRT screens weren't really meant to be seen on LCD screens or displayed on monitors running at the exact same aspect ratio as the game.

Upscaling low resolution graphics goes against the nature itself of pixel art (despite every other indie dev not getting it today), that's why there're so many methods to emulate a CRT display. I'd strongly advise to look into that.

I actually kind of like the look of playing a low res game on a high res monitor. Integer scaling is obviously ideal here but I find it doesn't result in much displeasing distortion to scale non-integer as long as the monitor's 1920 x 1080 at least and you maintain aspect ratio. I think good pixel art shines even without needing CRT filtering, and both of the Gyruss examples there look aesthetically pleasing to me, though that may be because I was fortunate to play on a fairly large CRT as a kid and they made the individual pixels pretty well defined.

Being fortunate enough to own a few CRTs, I also find CRT filters on PC games don't do them justice and I prefer to get the CRT look on the real thing, and the look of crisp pixels when playing on an LCD screen.

[Lander]

I know you're giving him the answer he was looking for, but that's misleading and with it he isn't getting the whole idea behind this issue. It doesn't matter if on a CRT or on a flat screen (see my previous post), scaling a picture digitally breaks "pixel perfection" no matter how integer it is - you're making the computer fill in the gaps instead of being your own brain the one doing it.

I think that's starting to get into semantics, at least as far as integer scaling goes. If two 2D grids of color describe identical images, but one is - in technical terms - twice the resolution of the other and actually composed from same-colored 2x2 cells, what difference does it make in practice?

Granted, the doubled one will be twice as big if presented side-by-side on the same display, but that's just a matter of viewing distance versus screen size if we're leaving fine-grained stuff like subpixel structure and panel properties out of it.

I'm all for drawing a distinction if the image data undergoes quantifiable change - like being smoothed or resampled - but if it's just N times bigger or smaller with no perceivable change in detail, then the frame of reference for any mental gap-filling will also be unchanged.

[Bassa-Bassa]

I think that's starting to get into semantics, at least as far as integer scaling goes. If two 2D grids of color describe identical images, but one is - in technical terms - twice the resolution of the other and actually composed from same-colored 2x2 cells, what difference does it make in practice?

Night and day, but you must not think about this in computing terms.

To be honest, I was afraid of not being understood by everybody, so likely it's my fault there as what I'm saying goes against any modern (and not so modern) mindset, and I knew it. When you digitally scale x2 a picture even without any resampling process you're indeed making a change in detail - you're using the computer to fill in the gaps between pixels with clones of them, so you're preventing you mind of picturing (imagining) properly any given detail a group of pixels are representing. In other words, the gaps were part of the detail itself (even if you usually don't perceive them as gaps, or actually, because of that) and filling them with /whatever/ is adulterating the intended picture.

Doubling or multiplying pixels is in actuality an artifact like any other - it's just the easiest one a computer can do. Of course, it's also a necessary thing as we're on a digital medium and well, it just seems to be the less arbitrary. It's still arbitrary, nonetheless. Leaving the gaps empty would be a more natural thing to do when upscaling digitally, but then again it wouldn't work in non-granular processes and it'd de-naturalize other aspects, so few people paid any attention to it. Until shaders, I want to believe. With all the issues they're still facing I'm hoping they become common use for your everyday digital upscaling when our screens get better, and not just for videogames.