after investigation and clarification by PsikyoFan it turns out that mame emulates a frame/sprite buffer for most arcade hardware. What I found out is that this buffer can “safely” be removed on most hardware with very little consequences.
Removing this buffer is certainly altering the original behaviour, but it's doing so in a way that doesn't actually appear to negatively affect the gameplay emulation as it's just a video buffer, so saying that this is "messing up the game internally" is a stretch.
Obviously emulation should always strive to be as accurate as possible, and Shmupmame's alterations should not be part of the default MAME build. However, they work. If MAME were to include a toggle option to use these performance enhancements in cases where there is a measurable performance improvement without a cost to the gameplay or emulation quality, that would be ideal, but how easy that is to implement on current builds is another issue altogether.
BareKnuckleRoo wrote:One thing I am genuinely curious about: if Groovymame implemented Shmupmame's latency hacks, would it be possible to get it down to ~1 frame of lag (as in arcade accurate for games that have 1 frame of delay for input normally)?
Those hacks are not required. Take thunderx for instance. This game responds on next frame. GM does so.
If Shmupmame's hacks where added in GroovyMAME, it would respond faster than real hardware. E.g. Donpachi would respond on next frame instead of on second frame as the original, etc.
I assume in the scenario where both emulators have sync on but on the GM side you don't use frame_dealy (just have it running on d3d9ex) the advantage of GM would be of only about 1 frame?
Like
GM d3d9ex sync on = 3.20 (2.20 + 1.00)
Shmupmame sync on = 3.95
is that right?
EDIT: that makes baseline MAME ridiculously high btw.
I haven't tested it so this should be confirmed, but I'd say it would work like this:
With D3D9x you have:
Game latency = 2
Frame queue = 1
Total 2+1 = 3
With D3D9x + frame delay 8 you have:
Game latency = 2
Frame queue = 1
Frame delay = 0.8
Total 2+1-0.8 = 2.2
@Roo: with what shmupmame does it depends on the games but in many there's obviously sprites desynced with the rest of the game, i don't know if it affects the hitboxes though where it matters, anyway if there's a better way to achieve further lag reduction without doing this then why not?
just as if there's a current way to reduce the lag without screen tearing then why ignore it? you won't argue again of that 0.15 frame difference won't you? that's fucking nothing.
you know I criticize mame for a lot of things but i don't see why i would go against their will do do things cleanly instead of fucking up the work they've done, it's not like they don't accept lag reduction, they just want it to be done right
now again if you guys want to play with tearing and desynced sprites, as well as outdated drivers (a lot of things have been worked on emulation proper since shmupmame came out, accuracy is not just about the desynced sprites, there's also the audio lag reduction with portaudio and integer scaling, those things matter too even if you dgaf) then by all means keep using Shmupmame forever, nobody will stop you!
@Calamity: okay I see, thanks again for everything.
If you watch one of the Shmupmame's vsync off videos I posted, I accidentaly dropped a bomb right at the beginning. You can see those explosions totally corrupted by tearing, it's so distracting and ugly that the only logical explanation that comes to my mind for someone willing to play that way is that he must be a person that really hates videogames. Because obviously that is not the case of you guys, then how is that possible? Well, I guess one can get used to anything. It's like trying to sell shoes to someone that's happy walking barefoot.
I listen to the ingame audio almost always, so portaudio/WASAPI setups contribute to a nice difference to my general mame experience.
Some of my Third Strike hit confirms are easier to land with timely hit/block sounds playing alongside the action.
Calamity wrote:If Shmupmame's hacks where added in GroovyMAME, it would respond faster than real hardware. E.g. Donpachi would respond on next frame instead of on second frame as the original, etc.
This might be a dumb observation, but here we go...
We are taking for granted that people here will always be using LCD monitors which means that even those who use the most performant screens are always going to get 1 or more frames of delay due to how LCD panels behave compared to CRT screens.
Is it somewhat "correct" to make game react faster than their PCBs since people are going to get delay anyways due to the use of a LCD screen, thus bringing the delay on par with that of the PCB?
donluca wrote:Is it somewhat "correct" to make game react faster than their PCBs since people are going to get delay anyways due to the use of a LCD screen, thus bringing the delay on par with that of the PCB?
Yeah, and there are some console ports (M2's recent ports, for example) that do exactly that. You can reduce the game's innate input delay to lower than the original PCB, but since your monitor or controller probably has some small additional amount of delay, it probably balances out?
a lot of lcd's have close to no additional lag, mine for instance begins the frame with only 3ms of delay, that' very common with monitors today
most TVs lag more but a select few are very close to that performance.
but in the situation where for instance the monitor has a full frame of additional delay, then shaving off a frame on the emu side will benefit the player
now does that introduce other issues? idk...that's a good question
Calamity wrote:You can see those explosions totally corrupted by tearing, it's so distracting and ugly
You know you're invulnerable when you bomb, right? It won't keep you from dodging anything.
Xyga wrote:you won't argue again of that 0.15 frame difference won't you? that's fucking nothing.
It's certainly more important than something as totally irrelevant as a bit of screen tearing. =)
then by all means keep using Shmupmame forever, nobody will stop you!
I really appreciate your permission, a great weight has been forever lifted from my shoulders. Phew!
Xyga wrote:with what shmupmame does it depends on the games but in many there's obviously sprites desynced with the rest of the game
Since I haven't noticed anything like this at all in anything I've played in Shmupmame I am genuinely curious to see evidence of this. Which games specifically in Shmupmame of the ones in the 52 drivers that have lag reductions have sprites that are "desynched with the rest of the game"? Details on what sprites/where in the game it's visible would be appreciated, as well as severity (is it a minor, non-gameplay impacting visual glitch, does it render the section unplayable, etc).
Calamity wrote:
Is it somewhat "correct" to make game react faster than their PCBs since people are going to get delay anyways due to the use of a LCD screen, thus bringing the delay on par with that of the PCB?
Yeah but the "correct" way of doing that is with the run ahead method that's been implemented in RA, not the way Shmupmame does.
And still, that method doesn't magically fix things. If my monitor has 2 frames of latency, I'm never going to manage to go below that. I can align in-game latency for games that have it with monitor's latency, up to 2 frames, so both latencies don't add up. But for games with latency lower than the monitor's it won't work.
BareKnuckleRoo wrote:It's certainly more important than something as totally irrelevant as a bit of screen tearing. =)
that's like 2.5 milliseconds, are you fucking serious? buahahahah
BareKnuckleRoo wrote:Since I haven't noticed anything like this at all in anything I've played in Shmupmame I am genuinely curious to see evidence of this.
you need glasses then, and compare with another mame build
donluca wrote:Is it somewhat "correct" to make game react faster than their PCBs since people are going to get delay anyways due to the use of a LCD screen, thus bringing the delay on par with that of the PCB?
Yeah, and there are some console ports (M2's recent ports, for example) that do exactly that. You can reduce the game's innate input delay to lower than the original PCB, but since your monitor or controller probably has some small additional amount of delay, it probably balances out?
This is the idea. ShmupMAME was created in a time where people were not using things like FreeSync/G-Sync, and... many people are still not using things like FreeSync/G-Sync. Demanding people buy a new monitor so that they don't have to use a fork of a free program is... more than a bit much.
Never mind that there's hardware like Strikers 1945 which is absolutely disgusting and basically requires ShmupMAME to be playable. I'm pretty sure the ports don't behave like that naturally, so if that's part of the hardware... eww. Just... eww. I've sometimes said arcade games aren't perfect and need ports to complete them, and that is definitely something you'd "complete" with a port.
Freesync/gsync are not just for lag, you also get the correct speed and no tearing at the same time, for flat panels it's the ideal thing if you have money and are too lazy to look for a CRT. But most people acquire such setups for PC gaming.
Of course in parts of the world CRTs are now quite difficult to find especially in good condition, or they're treated as collectors items like the prized sony pvm/bvm series.
In those cases a low end freesync setup will be more affordable, for someone who's really into this then why not?
And yeah good ports are better, I'd vote for good ports of everything and fuck emulators and whatever displays. Case closed.
@BareKnuckleRoo;
I took some time to reload shmupmame and just as I remembered there's many games with desynced sprites, of course I didn't go through the whole list but anyone can do that game by game if he desires, for me what i've seen is enough.
Mostly what happens is that sprites that are supposed to be standing on the background are no longer sticking to it, enemies, explosion impacts, items, buildings/structures etc, detach and shake when you move the ship sideways as the screen follows.
In games where there's no sideways movement of the scrolling and the it only goes straight forward it's not an issue, unfortunately shmups that move sideways following the player aren't just a couple.
Just a quick appreciation of how some of these games are affected;
19xx (bad)
air gallet (light)
doj (awful)
galuda (awful)
ketsui (awful)
batsugun (light)
garegga (mild)
dimahoo (light)
dodonpachi (bad)
donpachi (bad)
esprade (bad)
fire shark jp 1p (light)
gun frontier (awful)
ray force/gunlock (bad, hesiting with awful)
hotdog storm (mild)
raiden (awful)
ryu jin (light)
varth (awful)
I wanted to play more like the seibu RF games but ran out of patience. Anyone can have fun expanding that list. Also some games are either missing like Raiden II/DX or I don't have the right roms and it being an old build I don't want to chase around solutions for that.
Such display is enough for me, the PGM games in particular are completely fucked up, in some levels parts of all kinds of nature moving all over the place, because even some buildings 'n shit are made of sprites.
It's really broken and I can't imagine having tearing on top of that, and I know many applly the full bilinear filter without even raising the prescale, like they imagine it'll hide that mess, but you know all that shit together made me think of a new name for ShmupMAME: MAME Cronenberg Edition (bringing body horror to retrogaming!)
Again there really is only one thing in Shmupmame that's superior to GM: it's easy and nice to use, convenient, those old style GUIs for instance were always the shit, what a mistkake mamedev have made eradicating those.
But that's all it's got for it, I'd recommend even RetroArch a hundered times over that broken relic, and for those who want something with the same purpose but much more serious and efficient, there's GroovyMAME of course.
Sure for now it requires a brain and some effort/perseverance, so (whoever you are) either pull your fingers out of your ass and learn it - it's only a matter of getting a handful of things right - or be patient and wish groovy devs will make something for your in not too long.
----
PS: message to Calamity if you come back around here: I've realized that modeline generation is on by default in the switchres block of the mame.ini
maybe that's what causes problems for some
how the hell anyone who knows how those games are supposed to look doesn't notice
in parts there's so much shit shaking on the screen compared to normal behaviour it's actually quite distracting for any player
because people get used to shit doesn't mean shit is good
I only noticed the game overall shaking like jelly when I got a new monitor
but I don't pay attention to it and stopped noticing it after a day so who cares
I didn't know emulators could go into cardiac arrest. I've used shmupmame on raiden/rayforce and never experienced any of these issues, so more evidence is needed. Thanks!
