Can I add some delay into groovymame ?

[jimmer]

I'm happy with my groovymame set up.

But is there a way to add in a specific amount of input lag? So I can feel what eg 2 frames more lag is like.

[adder]

interesting idea 

... in the meantime, if you want to feel what 4 frames of lag is like, start a game of galaga'88 and move your spaceship left and right ...

[jimmer]

interesting idea 

... in the meantime, if you want to feel what 4 frames of lag is like, start a game of galaga'88 and move your spaceship left and right ...

Feels OK to me in groovymame0171. Has it been broken recently then?

[adder]

hey, sorry for the delay i dont seem to come by this way as often as i used to  (it used to be daily) 

as far as i remember, galaga'88 has 4 frames of lag buit into the game as default (even with the arcade pcb).  or if im wrong, dont know if anyone else can confirm?

im way behind on my groovymame version i use, my version is a couple of years old now  (im still using XP 64bit),  if i were to upgrade i would really be looking to move forward and start over with windows 7.   but anyway im ok as i am at the moment, not in a rush or urgency to upgrade

anyway, so i havnt tried galaga'88 lately, and not with a version of mame or groovymame from the last couple of years

[Dacasks]

Didn't know about that on galaga.

Just tried on Shmupmame out for curiosity and much of the lag is gone.

I guess breaking the game makes up for it sometimes

would be good a "GroovyShmupmame" for these cases. Or at least if shmupmame used the native resolutions correctly...

[Calamity]

I'm happy with my groovymame set up.

But is there a way to add in a specific amount of input lag? So I can feel what eg 2 frames more lag is like.

If you're not using frame_delay, then quite probably you're already experiencing 3 frames of lag.

[jimmer]

I'm happy with my groovymame set up.

But is there a way to add in a specific amount of input lag? So I can feel what eg 2 frames more lag is like.

If you're not using frame_delay, then quite probably you're already experiencing 3 frames of lag.

I am using frame_delay (=8). 

I'm a bit confused by your comment, are you suggesting that I will have 2 frames of delay even with say frame delay 9 ?

I thought frame_delay was the final part of the puzzle to get response as good as (or better) than the arcade pcb 

[Calamity]

Please read my comment again: "If you are not...

[jimmer]

Please read my comment again: "If you are not...

I read it OK. What confused me is frame_delay makes a maximum of 0.9 of a frame difference. So you appeared to be characterising groovymame as causing 2 frames of lag?  Whereas it's been my understanding that groovymame with frame_delay 9 is effectively zero lag.

The reason I made this thread is because I've tested back to back with original hardware and I couldn't feel a difference between that and my groovymame set-up. But I don't know how sensitive I am, ie whether or not I would feel 1 frame or 2 frames of lag because I've never had a system with a known amount of lag.

[intealls]

This tool is very useful when testing input lag:

http://junkerhq.net/xrgb/index.php/240p_test_suite

Runs in MAME with the genesis driver for instance.

[jimmer]

This tool is very useful when testing input lag:

http://junkerhq.net/xrgb/index.php/240p_test_suite

Runs in MAME with the genesis driver for instance.

Any tests in particular?

I need to get my head around that manual lag test.

I've used this to set up groovymame with my LCD screen in the past. I needed offset of 100 lines (1280x1024) does that tell us anything about the display lag?

[intealls]

I need to get my head around that manual lag test.

Once you do that, you'll definitely see the difference between a high frame_delay value and 3 frames of lag.

I've used this to set up groovymame with my LCD screen in the past. I needed offset of 100 lines (1280x1024) does that tell us anything about the display lag?

Unfortunately no. The LCD latency needs to be deduced with one of these for instance: http://www.leobodnar.com/shop/?main_page=product_info&products_id=212 .

[jimmer]

hmm I don't want to spend £75.     Maybe this can be my first arduino + hardware project.


I'm still not getting that manual lag test. Or your comment. How will I see the difference between high delay and 3 frames of lag?  Am I missing something here, is there a way to dial in 3 frames of lag into groovymame? (maybe using triplebuffer?)


edit:

From reading the other thread about lag I think (but not sure) that some of my misunderstanding is down to terminology  eg an average of 34ms from  button press to action on screen action is described as 2 frames of lag ie it is an absolute measurement.  I've been thinking relative to the arcade pcb.

So yeah, my system probably does lag about 2 frames (versus  the arcade pcb lag of 1.5 frames).  Maybe we should call it response time?

[Calamity]

Things are simple. Forget by now about the built-in pcb latency most games have (2 frames).

When you enable vsync on your emulator, AMD/Nvidia drivers create an infamous frame queue of several frames. This is true even without triplebuffer, which obviously makes things even worse (caution: GM's triplebuffer doesn't add latency).

Now, take stock MAME, or GM, they're mostly the same. And run it fullscreen with -waitvsync, and WITHOUT -frame_delay. You'll be experiencing 2-3 frames of lag due to frame queue (buffering), in addition to the pcb latency. GM might be slightly better (1 frame) due to the way the inputs are polled but no big deal: the bulk of the latency is in the driver's hidden frame queue.

Then, run GM adding -frame_delay 5. As a side effect of current -frame_delay implementation, the frame queue is bypassed, and you end up with 0-1 frame latencies. Notice the purpose of -frame_delay is NOT bypassing the frame queue, it is a (desired) side effect. Probably I'll split -frame_delay in two options, one to just bypass the frame queue and another one to actually do frame delay, so to avoid uneducated use of the frame_delay feature.

[jimmer]

Ah great. I got it now (almost).

I'm not sure now if I have about 2 frames of lag, or about 4 frames of lag.  I'm using groovymame0171 on winXP 32bit with onboard graphics (Intel Q43 chipset).   Which I think means I don't have Direct3D9ex , which is what allows the frame queue bypassing?

What's new in SwitchRes v0.015j

- Direct3D9ex support [koopah, intealls] (new option: -video d3d9ex): now GroovyMAME supports Direct3D9ex, which is present in all versions of Windows starting with Vista. This allows the application to take control of the frame latency and force it to the minimum allowed by the driver, avoiding the dreaded frame queues. This is specially useful in the situations where frame_delay can't be used reliably without tearing (LCDs, high resolutions). Besides, Direct3D9ex seems to perform better for certain hardware (Nvidia, Intel), so it may be preferred to plain Direct3D9 in general.

- Frame delay (improved) [intealls, Calamity]: now frame_delay polls the video driver for absolute scanline values, totally bypassing the default vertical synchronization functions. Some of the advantages are:

• Improved stability of the vertical synchronization mechanism, that finally makes it possible to extend GroovyMAME's audio/video synchronization to the frame delay use case.
• Awareness of the raster position and notification of missed retraces.
• Allows for anticipating the vertical retrace accurately (see vsync_offset, below).

- Vsync offset [intealls] (new option: -vsync_offset): forces render to happen a certain number of lines before the vertical blank (e.g. -vsync_offset 200). At high resolutions (LCD, etc.), the time it takes the GPU to scale a frame starts being longer than the blanking period itself. This is specially true when HLSL is used. This appears as static tearing when frame_delay is used. To compensate this issue, vsync_offset forces the render code to be called a number of lines ahead of time. Ideally, using a proper value realigns the render completion with the end of the blanking period, cleanly removing all tearing, even on LCDs with frame_delay and HLSL enabled. In practice, you need a fairly fast card in order to fully remove tearing. The higher the tearing line appears on the screen initially, the faster your card is, and the more chances of completely hiding tearing through -vsync_offset. Notice that you'll need to lower your frame_delay value proportionally to the amount of lines you set in -vsync_offset.

[jimmer]

Let me ask in a more general way.  Can you get sub 1 frame lag using groovymame on winXP ?

And if it's not possible on winXP should you mention that prominently in the documentation?   eg in the software reqts section here: http://forum.arcadecontrols.com/index.php/topic,151459.0.html  there is nothing to suggest one OS group is superior.

[Calamity]

Let me ask in a more general way.  Can you get sub 1 frame lag using groovymame on winXP ?

Of course. If you check my posts in the input latency thread, you'll see all my tests were done on XP.

7 is a better OS however and anyone with proper hardware (hd 5000+) shoud be using it already.

[jimmer]

so..my understanding now is that direct3d9ex is needed to take control of the vsync frame queues (which I would need a graphics card for).

You wrote a few posts back that AMD/nvidia drivers create the infamous frame queue. Does my Intel Q43 onboard graphics also create the problem frame queues?

If it does, I should be able to get the a 2.5(?) frame difference by tuirning frame_delay on and off.  I will test tomorrow.