MAME shmups input delay list

[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.

[nimitz]

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.

That's exactly what I feared, thanks for the confirmation

DO you know if it's the same for the neogeo driver?

[Ex-Cyber]

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.

That's exactly what I feared, thanks for the confirmation

DO you know if it's the same for the neogeo driver?

Looks that way to me. There's a comment in there saying "double check the Y coordinate, in case somebody modified the sprite coordinate since we buffered it", but it looks like this is referring to a scanline delay (Neo Geo sprite system is based on dual linebuffers) rather than a frame delay.

[PsikyoFan]

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.

That's exactly what I feared, thanks for the confirmation

DO you know if it's the same for the neogeo driver?

Looks that way to me. There's a comment in there saying "double check the Y coordinate, in case somebody modified the sprite coordinate since we buffered it", but it looks like this is referring to a scanline delay (Neo Geo sprite system is based on dual linebuffers) rather than a frame delay.

See http://shmups.system11.org/viewtopic.ph ... 77#p564077.