shmups.system11.org

Does the Nebulas Ray PCB feel slightly laggy to anyone else?

In a sea of Cave worshipers, how many people do you think have played NebulasRay on MAME, let alone played it enough to buy the PCB?

Both of them are probably on this forum.

^ good answer.

I've always heard NR has significant input lag in MAME, but I've no idea if the PCB is considered similarly. It can happen. Battle Garegga's PCB has a bit of lag (4f, if I recall) and Guardian Force's STV cart has a lot, with MAME reflecting both.

I didn't realize it was a widespread problem on original hardware but it makes sense. Are there many shmups with 0 frames of lag on PCB?

I wouldn't say noticeable input lag is widespread on hardware. Over the past 15 years, those examples have always sounded more like exceptions to me. Kino hypothesised via trap's research that Guardian Force was coded on Saturn, then ported to STV, with something going awry... either way, the Saturn version handles fine. Having never played the STV cart, I'd previously assumed MAME's awful lag was strictly down to emulation.

My point is more that playing a game on its native hardware (any hardware) isn't a bulletproof guarantee against noticeable input lag. "Noticeable" being the operative word... there's always some input latency, but ideally it should be either unnoticeable, or minor enough to adjust to (my experience with Garegga's PCB). Whatever happened to Metal Slug XX's PS4 version, that's one I can't enjoy. Has a heaviness to its handling that eats away at reaction windows, my usual perception of borderline-unacceptable input lag. Conversely, ACA Neo Geo (PS4)'s Slugs respond sharply enough that I could easily replace my MVS carts with them, if I felt like it.

It's too bad that people can't either just be helpful, or just stay out of it if they have nothing to contribute. I can't answer the question of Nebulas Ray PCB myself. I played stage 1 on mame for reference just now. I can't swear to it, but you might be describing a sensation from the ship's slow speed, the strange graphical effect of the background, and the fact that stage 1 has a lot of forced scrolling camera movement that makes it seem like you're 'fighting' the scrolling of the game. I don't know if this keeps up in later stages, but it's definitely something I noticed as I popped in a credit.

This was also tried with the low-latency setting available on the latest MAME builds (at least 216 and up). Switching that in the config file from 0 to 1 shaves off a frame, so it would feasibly be a little closer to PCB (though factor in my bog-standard LCD display and Windows 10, probably adding more delay than a PCB + CRT...).



There's no such thing as 0 lag, because there is at the least the act of pressing the button and sending that signal to the arcade board. The lowest that PCBs can achieve, to my knowledge, is 2f of lag. But this isn't constant across games (BIL mentions Garegga, which runs natively with 4 frames). What you can notice or respond to is up to debate; as BIL mentions unless the game is really egregious you can 'plan' around it, and your brain will make adjustments subconsciously.

There is a red line though, imo. 7 or 8 frames is about my upper limit (generously so), but anything beyond that you'll definitely feel like the control is not as responsive as you want.

I used to have the PCB and can attest that it definitely felt a bit floaty. It doesn’t help that the background behaves weirdly and might even contribute to the feeling of float to the controls.

I could be wrong, but I seem to recall that GF on the Saturn also had latency issues...I definitely recall it feeling "off" when I last played it some time ago, though I've never played the STV version to compare.

I'd like to know where the people saying the Saturn version is the original got that from. That'd make sense for something like Radiant Silvergun, with all the non-arcadey content it has and how close the release dates are (and still, both versions were developed in parallel), but for Guardian Force?

It is usually said however that you can never achieve 1 frame of input lag on PCBs whereas that figure is possible with certain home systems. But don't ask me why.

I've always noticed a mild degree of heft in Guardian Force's movement, but I'm willing to give it the benefit of the doubt and put it down to the tank concept. MAME's another story entirely, it's outright delayed there.



Paraphrasing trap15, the STV version processes inputs like a Saturn game, despite the two systems handling inputs differently. Pasting directly, to reflect trap's emphases:



Strictly from layman's perspective, I'd assume the Saturn was its original development platform, and someone failed to optimise it for STV. Bigger devs have screwed up their code (like SFC Mario Collection's inverse SMB1+2 brick physics, or Metal Slug 2's bad FPS lock).

Yeah, and here's the thing: for a community that loves to whine about supposed cheaters, there sure are double standards about what does and does not qualify as cheating. The fact you can abuse emulation to have less input lag than the PCB seems to be the goal for most players, which is absurd to me. How is that not cheating? Shouldn't emulation attempt to replicate input lag as experienced on the PCB instead of all this runahead nonsense?

Interesting, thanks.

I've only played a bit on MAME in the past ( when I was thinking about 1cc'ing before shelving it), but I've had a similar experience to what Ing stated ( especially the scrolling + ship speed, which makes some sections more annoying than they should be imo).



I think most players have expressed that they'd prefer to have a 1:1 frame lag to PCB through emulation ( while a few other people wanted to experiment and see how using runahead in a program like ShmupArch w/ potentially less input latency can improve game performance, & is still a WIP).

I'm not even sure if there's any existing video examples of "cheating" in this manner ( such as a ShmupArch vs PCB comparsion for a Cave 2-ALL but if there is, then feel free to link it)

Some Namco games like Nebulasray have a main CPU and an additional microcontroller that handles things like inputs and sounds. So inputs must first go through the MCU, and then be forwarded to the main CPU which runs the game. This could add some lag both on real hardware and on emulation.

Furthermore, depending on how tight MAME is synchronizing these two CPUs, there could be additional lag (for instance, if the synchronization isn't tight enough, when you press a button, MAME runs enough "cycles" of the main CPU to poll the input from the MCU before running the MCU code that reads the actual inputs = one additional frame of lag)

Just to set the record straight, Garegga's lag is mostly a software problem, setting aside the 2f implied by its sprite framebuffer. Batsugun uses the same sprite framebuffer and does not suffer for it.

Which ones of Namco's "systems" do use an MCU like that? System I and II are free of it, I presume?

FWIW a lot of Taito games have a similar architecture without negative consequences like that.

Namco were one of the earliest adopters of such tech.

Even their 8-bit games used multiple MCU setups for different tasks, often passing data through more than one of them.

Basically everything after the initial 'Pac-Man' hardware type employs some kind of additional MCUs rather than the main CPU having direct access to the input lines.

By the time you to Namco System 1 / 2 it's convoluted, with the IO MCU family changing entirely about half way through the System 2 life (with the same setups being used for the 3D games that were rooted in the same tech)

I can't speak specifically for Namco, but many such setups accept digital and analog data and will only send the digital inputs along with the analog ones after reading 3 frames worth of analog data to smooth out inputs / filter out erroneous looking data etc.

Some Taito games also read inputs through MCUs (the C-Chip based ones for example) as do platforms like the Hyper NeoGeo 64, and of course any recent JVS based ones, or anything based on PC architecture (even old stuff) as you never got 'direct connections' there. As mentioned ST-V, Naomi etc. all go through MCUs.

The games were programmed with this in mind and adjusted for difficulty accordingly (which is why a lot of 'newer' games are less 'twitchy' as there is an understanding that the player can't react as quickly due to the input latency)

Some interesting bits there, thanks. So in your opinion, Mame's current emulation of systems like those is likely to add extra input lag (not there originally) against emulation of non-I/O MCU systems?




But their home counterparts (Saturn, DC) are free of them, right?

No, Saturn and DC have them as well.

There's no reason for an MCU to add lag except in poor implementations. I kind of doubt that the Namco System 1/2 MCUs are so poorly implemented that they add multiple frames.

My recollection of Nebulas Ray is that the first stage's background scrolling makes it feel laggy and weird, but after that it feels fine. It's just an unfortunate optical illusion.

My opinion is that MAME's emulation of these things is going to properly represent any extra lag present on original hardware caused by the hardware design requiring it to pass data between CPUs and from any processing those CPUs do of the data. The interleave levels of execution between in MAME are sufficiently high enough that emulation of these shouldn't be adding anything more than they add in hardware.

Having played Galaga 88 on original hardware with a CRT, it was one game where I could notice the lag even then.

The Saturn and DC still have IO controllers. IO controllers became pretty much the norm as they can filter out bad data etc. which became increasingly necessary as controllers gained more and more complex inputs (and of course as they started to become wireless and hotpluggable too - nobody wants the main CPU being occupied trying to maintain connections to devices via complex protocols, they just want to know the status so 'command based' systems whereby the main CPU can request an input packet without having to worry about hardware level connection details were much preferable)

Thx for the explanation! Hopefully those raster issues still affecting Nebulas Ray/NB1 games can be properly understood soon.