MAME shmups input delay list

[unsane]

Is there a standard difference between wolfmame .128 and mame .128? What i mean is, do all games on your list have for e.g. +1 frame delay in the same version of regular mame? Or are the differences all over the place, i.e. specific fixes for specific games in wolfmame?

[nimitz]

newer wolfmame has higher priority for for input, I heard the new mame versions are prone to "input locking" which is supposed not to happen in wolf

Also, newer WOLFmame version do have game (driver) specific fixes, good exapmples are : Raizing games and Seibu SP1 games

[Pulsewidth]

For the benefit of those finding this thread from search engines, I'll point out that Raine plays most of the laggy games with no input lag. I don't know whether this is inaccurate emulation or just MAME being buggy (eg. MAME used to run DoDonPachi laggy but doesn't in modern versions), but it's a lot more fun.

[Ed Oscuro]

lol I broke some promises in this thread

Anyway, if/when I ever get a Linux box going for MAME (as per Elvis' suggestion) it will be an interesting place to look for lag.

The author of the Ootake emulator made some notes about Windows Vista and 7 being worse than XP for game input delay, I've seen similar mentioned elsewhere. The late '00s - early '10s = lag generation.

I tried out Pistol Daimyo, aside from the test not working on the credit, and the hold mechanics for both vertical movement AND the shot, I gave up. Never liked that game anyway.

A quick test with Strikers 1945 in Mame+ GUI 1.4.9e / MAME version 0.136u2:

Shot button from start: ~1 frame delay (user error?)
(new instance of MAME) Left to right (and vice versa): ~4 frames delay
Shot during continuing left and right movement: ~4 frames delay

I retried the shot button during continuing right movement in the very next version of MAME+ GUI 1.4.9e / MAME version 0.136u3 (they don't increment the MAME Plus! version but the fast-forward button's function has changed to hold instead of toggle, and the mapping has changed, should be a MAMEdev change, eh I guess it's useful), same result as before.

Using the credit button during the attract sequence isn't as useful, since it takes a few frames for the next screen to fade in. I did notice it took about 4 frames for the current scene to disappear, though, which is consistent.

It's worth mentioning that psikyosh.c changed significantly in MAME 0.136b with the addition of more accurate (and computationally expensive) scaling, but that only affects Strikers II / III. Might be more interesting to do a test there.

[Pulsewidth]

The author of the Ootake emulator made some notes about Windows Vista and 7 being worse than XP for game input delay, I've seen similar mentioned elsewhere.

It sounds like Linux could have the exact same problem if you use "Compiz" (very popular Aero style hardware accelerated window manager). I use Linux but I don't use Compiz and I'm not interested in installing it to test it.

[Ed Oscuro]

I don't use Aero for Windows Vista, just the good ol'-fashioned Windows Classic style interface, which they fucked with enough as is (interchanging the Explore and Open buttons, for example, though I guess it's still consistent).

I ought to try this on my XP box soon.

So, quick lessons:
-Pistol Daimyo is a horrible choice unless perhaps you're crafty and choose left-right movement to test lag
-Either MAME or my laptop keyboard is very inconsistent with how it handles input (no surprise, it gives WASD priority)
-In any case, I found (re-discovered, probably) that I can't just tap the key and then Shift+P to the next frame; you need to hold it down through the Shift+P for it to register.

Forgot to mention I'm using Ctrl on this keyboard; that and the arrow keys have lower priority (due to ASUS increasing priority for the WASD keys, which are useless for me), but it didn't seem to be an issue.

I also tried out Guardian Force with the latest MAME; I counted eight frames (including the first frame, so seven) holding the Ctrl key which in Guardian Force turns the turret left, which is consistent with Nimitz' findings before. Would be interesting to see with a 60FPS camera how long it takes the real thing.

[orange]

Anyway, if/when I ever get a Linux box going for MAME (as per Elvis' suggestion) it will be an interesting place to look for lag.

i'm actually going to be doing this in the coming weeks, i will be sure to post how it turns out

[nimitz]

For the benefit of those finding this thread from search engines, I'll point out that Raine plays most of the laggy games with no input lag. I don't know whether this is inaccurate emulation or just MAME being buggy (eg. MAME used to run DoDonPachi laggy but doesn't in modern versions), but it's a lot more fun.

Thanks for pointing this out, this is indeed very interesting.

I will do some testing and post back again with the results with Raine.

edit : http://speeddemosarchive.com/forum/inde ... 295.0.html the 3rd program on the first post allows to test how well you can see input lag, the program uses vsync though.

[nimitz]

Ok, after some testing I got the Raine results...

Turns out about half the games are not in Raine at all (no drivers), on the other half that are in raine most drivers have pretty bad problems that make the games unplayable:

-The Taito F3 has virtually no input lag but some sprite layers are completely broken.
-The Cave hardware has all the slowdown removed (not a good thing) and has some problems with guwange
-The Raizing driver has speed problems with batrider and removes slowdown for all games (think garegga).
-The Cps-2 driver removes all slowdown and makes most games too fast as a result.

That being said, pretty much all working games respond AT LEAST one frame faster, often more. So if you can deal with huge accuracy issues it's not bad.

The only driver that seems decent and which is an actual improvement over mame is the first generation psikyo driver, I cannot say for sure but it feels like it removes one frame, so these games play at ~3 frames delay in raine, which makes them playable (good news), the only minor gripe was some backround layering problems that I've seen in Gunbird.

The Toaplan driver for outzone, truxton, hellfire zero wing also seems relatively accurate but after some testing it seems truxton is much faster than in mame...



I will update the main post with the info that raine has 3 frames on the 1st gen psikyo driver.

[Udderdude]

Thanks for this info nimitz, very informative.

[PsikyoFan]

It's worth mentioning that psikyosh.c changed significantly in MAME 0.136b with the addition of more accurate (and computationally expensive) scaling, but that only affects Strikers II / III. Might be more interesting to do a test there.

It won't make a jot of difference in this respect, unless your PC can't keep up. Actually daraku is the most significantly impacted, it does retarded things with the tilemaps (using them for things traditionally done with sprites and using all of the features of the tilemaps, and using sprites where bgs would normally be used). I can only think it was some sort of crude copy-protection since they'd gone and used the sprites for everything else and it wouldn't have been hard to knock-off some silicon that would emulate it.
For psikyosh, I intentionally buffer the sprites by one-frame (as a lot of hw in MAME does) since presumably that's how the hw behaves because it updates the background one frame in advance and then switches on the next frame (e.g. scrolling, tiles etc.). As a result, if I didn't do that the sprites would lead the backgrounds. When transitioning left->right you'd see them slide slightly against the background. Unless I've got something horribly wrong with IRQs etc I can't honestly believe that the hw reacts any quicker. One day I'll do some hw tests and try and prove this one way or the other.

No games in MAME buffer sprites by more than two frames that I know of, additional lag shown by these tests is all introduced by the games themselves. A lot of games keep the last 'n' inputs in a buffer and look across multiple prior frames before evaluating inputs. Where RAINE performs better, it almost certainly is missing video effects or has issues with synchronisation and should only ever lead MAME by a frame or so and is almost certainly incorrect compare to the real hw.

I need to check, but I'm pretty certain that MAME reads inputs once/frame and caches it. This is slightly different to pure arcade hw, where they are free to directly poll the state of switches. The OS, and the various protocols that live on top of it mean that we can't really do any better. I also believe that the majority of complaints are due to people using poor USB products, or USB keyboards. So dodgy emulation + dodgy hw/OS-introduced latency can appear better than more accurate emulation + dodgy hw/OS. For my cab I decided to go with a PS/2 J-PAC rather than USB. The other known source of heavy lag is LCD displays, especially when not ran in their native resolution they can lag by a few frames.

The only way people can really say whether MAME has more lag than the original hw IMHO is to do the following:
* With high-speed video capture (at least 2x refresh rate e.g. 120Hz) both the screen and some indication as to when an input has been triggered
** You could wire up some bulbs to show when the switch has closed
* Compare this against MAME running on the same display (a CRT obviously) with the most optimum configuration (PS/2 keyboard encoder, hw that is fast enough to never drop a frame, stable video drivers). This should be in-game and not test modes since often they often don't configure the video hw in the same way, or use both sprites and tilemaps
* Repeat the test a few times
* Review the video - particularly interest to me is the interaction between sprites and tilemaps during transitions of movement and between scenes

I think it's likely to show that MAME + PC hw is inferior to the real hw by 1-2 frames, but that with a horribly configured setup this could rise to 10 or more.

[PsikyoFan]

The only driver that seems decent and which is an actual improvement over mame is the first generation psikyo driver, I cannot say for sure but it feels like it removes one frame, so these games play at ~3 frames delay in raine, which makes them playable (good news), the only minor gripe was some backround layering problems that I've seen in Gunbird.

I was responsible for that too
I'm a bit dubious that it's correct, but MAME actually buffers the sprites by two frames in total to keep the backgrounds and sprites in sync.
It's quite possible that there's something wrong regarding IRQs and vblank that's creating an artificial delay in when the tilemaps get updated. There's still a couple of things to figure out with that driver, and I might get back to it eventually (it was Luca's to start with, but I added s1945 and tengai once the protection was defeated).

[Keade]

A lot of games keep the last 'n' inputs in a buffer and look across multiple prior frames before evaluating inputs.

Interesting. I understand that some games need to keep trace of inputs (fighting games is an obvious example), but why should this add more input delay ?

[PsikyoFan]

A lot of games keep the last 'n' inputs in a buffer and look across multiple prior frames before evaluating inputs.

Interesting. I understand that some games need to keep trace of inputs (fighting games is an obvious example), but why should this add more input delay ?

I don't know why they'd do that, haven't bothered to follow the game code to ensure it's never actually used (since these are coded in higher level languages than ASM you find things are referenced indiretly, data is copied from place to place as people copy by value rather than everyone reading from the addresses the inputs are mapped to). It may just be a hangover in the code from Daraku in the case of the later Psikyo ones. It might be interesting to actually demonstrate that the laggier games listed earlier intentionally do this or something similar.

Mushi Futari 1.5 on the XBox has an option which I read as 'input lag' and had options which I understood to mean that you could choose between a low-latency XBox, and original PCB frame lag - perhaps to compensate for modern LCDs and other inherent lag in modern consoles. Or I may have totally misunderstood what they were getting at.

[Udderdude]

A lot of games keep the last 'n' inputs in a buffer and look across multiple prior frames before evaluating inputs.

Interesting. I understand that some games need to keep trace of inputs (fighting games is an obvious example), but why should this add more input delay ?

That isn't exactly the best way to do it. I wrote code for an input buffer for a fighting game years ago, and it was more like recording what the input is on the current frame and then seeing how long it took before another input was done, for timing purposes.

You can see a similar effect in Street Fighter 4's training mode if you set it to show inputs. It does not show how long the time between each input took, though (That would be a nice feature for SSF4!)

[Keade]

Thanks for the explanations guys.

@Udderdude : I'm not certain I understood what you meant : what you suggest is equivalent to not duplicating inputs inside the buffer when the input doesn't change, right ?
If so, it sounds better indeed, especially if the game have to look back in the buffer very often.

[Pulsewidth]

Battle Garegga in Raine does have "sliding" sprites (looks more like shaking sprites because the horizontal scrolling is less than one pixel per frame). This is a worthwhile tradeoff for having responsive controls.

Exact same problem occurs in ESP Ra.De., and again I think it makes the game more fun.

I'm not sure if the sliding affects the collision detection. AFAICT it does not, because the sliding/shaking also affects the player sprite, but it's not noticeable because of the faster movement.

[PsikyoFan]

Battle Garegga in Raine does have "sliding" sprites (looks more like shaking sprites because the horizontal scrolling is less than one pixel per frame). This is a worthwhile tradeoff for having responsive controls.

But does the original hw do this (I'd genuinely like to frame-skip over a video capture of someone playing these games)? It wouldn't be as obvious on the original hw with the slower decay of the phospurs.
It may be that in doing so you're effectively cheating - giving yourself an over people playing on PCBs and could be viewed similarly to someone slowing the emulation down.

I can show anyone a couple of lines in MAME to remove the intentional buffering of sprites for most of the games mentioned.
I'm personally of the opinion that RAINE is basically irrelevant now. FBA has its place, they've taken a fresh look at the emulation of games in MAME that have been taken for granted for eternity and is faster in some cases.

[Pulsewidth]

It may be that in doing so you're effectively cheating - giving yourself an over people playing on PCBs and could be viewed similarly to someone slowing the emulation down.

I discussed this in the High Scores forum thread and Plasmo accepts playing in Raine as not cheating. I've also heard that the Saturn port has less lag, and I'd be very interested in exact measurements. Raine also fails to emulate slowdown, so it's increasing difficulty in some areas too.

ESP Ra.De. is an interesting case. I believe it's running on the same hardware as DoDonPachi, but the control latency is greater. DoDonPachi used to have higher latency in MAME 0.99 and earlier, but an IRQ related change fixed this (and at the same time broke save states). Details in this thread: http://shmups.system11.org/viewtopic.php?t=18702

I wonder if some emulation change could get ESP Ra.De. running with no lag and synchronized sprites.

[third_strike]

I have one question for you nimitz.
You say:

4 FRAMES (bad)
Mars Matrix (Takumi)

and

The list was made using WOLF 0.128, new WOLF versions (over .120 or so) have input delay fixes.

Then Mars Matrix have better input in wolfmame-0136 than wolfmame-0106.
Am I correct?
Sorry my English, I hope you understand me.
Cool!

[nimitz]

I can show anyone a couple of lines in MAME to remove the intentional buffering of sprites for most of the games mentioned.

Please do. I would be very interested to see the results for the Namco systems.


third_strike : The fixes are game specific I think, so only if the wolfmame dev (devs?) actually took time to "fix" the delay on that game/driver.

And while I have not tried with wolf 136, I remember that it was not fixed in wolf 126/128

[PsikyoFan]

I can show anyone a couple of lines in MAME to remove the intentional buffering of sprites for most of the games mentioned.

Please do. I would be very interested to see the results for the Namco systems.

Which Namco systems? Not System23 surely?

[nimitz]

I actually just managed to "fix" the drivers for both namco system 1 and psikyo.c to skip that "buffering.

That being said I used a pretty brute way (it works very well though), I'm curious what is the way you wanted to suggest to remove that buffering.


I would especially be curious to know how you would proceed to remove the buffer in this driver : http://mamedev.org/source/src/mame/vide ... an2.c.html

[PsikyoFan]

I actually just managed to "fix" the drivers for both namco system 1 and psikyo.c to skip that "buffering.

That being said I used a pretty brute way (it works very well though), I'm curious what is the way you wanted to suggest to remove that buffering.

For psikyo.c, simply replace references to state->spritebuf2 with machine->generic.spriteram.u32 in draw_sprites() and VIDEO_UPDATE( psikyo ) in src/mame/video/psikyo.c.

namcos1.c is really odd actually. This is completely untested, but I'd probably change the following routine to look like the following. This is a hack, presumably you'll see unprepared sprite lists and the like.

Code: Select all

WRITE8_HANDLER( namcos1_spriteram_w )
{
        /* 0000-07ff work ram */
        /* 0800-0fff sprite ram */
        if(offset < 0x800)
        {
           namcos1_spriteram[offset] = data;
         }
        else if (offset < 0x1000)
       {
            namcos1_spriteram[offset] = data;
    
           int index = (offset % 0x10);
           if(index >=4 && index <=9) { /* hw should copy from here when demanded */
              namcos1_spriteram[offset + 6] = data;
           }

            /* a write to this offset tells the sprite chip to buffer the sprite list - disabled */
            /*if (offset == 0x0ff2)
                copy_sprites = 1;*/
       }
        /* 1xxx playfield control ram */
        else
           namcos1_playfield_control[offset & 0x1f] = data;
  }

[nimitz]

Thanks a lot, very interesting. What I did with the namcos1 is a bit similar, I commented out the "copy_sprites" but I actually brought the VIDEO_EOF up to the beginning of the rendering process.

Any ideas for the toaplan2.c ?

[PsikyoFan]

Thanks a lot, very interesting. What I did with the namcos1 is a bit similar, I commented out the "copy_sprites" but I actually brought the VIDEO_EOF up to the beginning of the rendering process.

Any ideas for the toaplan2.c ?

It should be enough to patch the last line of toaplan2_vram_alloc() such that:
spriteram16_n[controller] = spriteram16_new[controller];

(note that batrider actually does this for one of the 'controllers' anyway)

Again, untested. It only seems to buffer by 0/1 frames though. I really am not sure this makes any difference to how the games play other than screwing up the sync

[nimitz]

Well, it works for Mahou that's for sure.

Now I just have to ask you for some more drivers (if you don't mind). Do you know how this could be done for the namcos2.c driver and also the cps1.c video driver.

I've look into the namcos2 driver a bit and really can't figure it out

[PsikyoFan]

Regarding http://www.mameworld.info/ubbthreads/sh ... ber=217246
Don't you dare try and submit any changes related to this, they're all removing hw features and totally non-legit.

[nimitz]

Yeah, I had figured out that this wasn't "legit" code.

Thanks a lot for you help btw.

edit : turns out I can't get namco2s to work. can you help me with this one?

[PsikyoFan]

edit : turns out I can't get namco2s to work. can you help me with this one?

namcos2? I don't see _any_ buffering mechanism in MAME code. The game writes to ram that namcos2_draw_sprites() works with directly. If there is, it must be internal to the game code.