Low lag, non-tearing Defender on LCD is all I want.

[jimmer]

This is my 2nd go around with groovymame and I want to start from scratch and make sure I'm doing things right.

What I'm after is seeing if groovymame can reduce lag on just 1 game. The game is Defender which is 60.1Hz and 294x238. I'm running it on Dell core2duo with winXP32, no graphics card (but I do have one if needed) and a 8ms LCD 1280x1024.

Now I've tried mame0169 and I don't have any particular problem with noticeable lag, but there is always the nagging thought that it could be more responsive, and I thought groovymame could give me that.  I don't have access to a real machine for a benchmark, and I'm trying to avoid buying a JROK.

I'm using  0169_groovymame_015l_fix.diff

I run it like this:    groovy.exe -nofilter -keepaspect -waitvsync defender

Like that it runs the same as MAME and I can't tell any difference in performance, should there be some?
If I dethrottle MAME F10  it stays at 100%.  ( because of vsync ?)

All good so far.
now if I try:  groovy.exe -nofilter -keepaspect -waitvsync -frame_delay 1 defender
I get tearing, and if I dethrottle it runs at 400%.

Is that what you'd expect?
does frame_delay turn off vsync ?

What settings should I be trying to get low lag, non-tearing Defender?

thanks in advance

edit: PS. I'm not using any ini files, so everything else is default.

[intealls]

You could attempt to do the steps outlined here (without HLSL): http://geedorah.com/eiusdemmodi/forum/viewtopic.php?id=293

However, I'm not sure it will work on your PC. I've successfully gotten tear-free frame_delay on an i5-2500k and i7-6700k using vsync_offset with integrated graphics on Windows 7/10. I doubt it will work well on a Core 2 Duo on XP.

[jimmer]

Thanks,

I did those steps with genesis, vsync_offset 100 moved the tear off the screen.

So then I tried
groovy.exe defender -v -monitor lcd -refresh_dont_care -frame_delay 1 -vsync_offset 100
and it played fine, no tearing.

Then I tried frame_delay 3,5,7,9  . It wasn't until I got to 9 that I could tell any difference (and it all went badly wrong at 9).

I was expecting delay of 2,3 or 4 to be my maximum. So what's going on? What should happen when I set framedelay too high?

[intealls]

Thanks,

I did those steps with genesis, vsync_offset 100 moved the tear off the screen.

So then I tried
groovy.exe defender -v -monitor lcd -refresh_dont_care -frame_delay 1 -vsync_offset 100
and it played fine, no tearing.

Nice, did you use the integrated card?

Then I tried frame_delay 3,5,7,9  . It wasn't until I got to 9 that I could tell any difference (and it all went badly wrong at 9).

I was expecting delay of 2,3 or 4 to be my maximum. So what's going on? What should happen when I set framedelay too high?

If you set frame_delay too high, it will go badly wrong, just as you experienced. If you set it slightly below the 'too high' limit, it won't go as badly wrong, and it's possible the game will stutter occasionally, but generally work quite well.

If you run the game with -bench 180, what average speed do you get?

[jimmer]

This has all been with the onboard graphics chip (I'll run speccy next time to find out what the chip is).

groovy.exe defender -bench 180

gives a cmd window which says:
'video chipset not compatible'
'switchres: could not find a video mode'
and then closes.

[intealls]

This has all been with the onboard graphics chip (I'll run speccy next time to find out what the chip is).

groovy.exe defender -bench 180

gives a cmd window which says:
'video chipset not compatible'
'switchres: could not find a video mode'
and then closes.

Ok, try '-video none -sound none -v -bench 180'.

Edit:

I know what's going on now. Defender doesn't require a very fast CPU to run fast. On my laptop C2D P8600 W7x64 it runs at about 2700%, which would enable you to max out the frame delay setting (8 ). However, you can't max the frame delay setting, since you're also using vsync_offset. You had to use a value of 100, which means you're using approximately one frame_delay unit to get rid of the tearing (100/~1024 = ~1/10 frame time, remember frame_delay is in tenths of a frame).

So try fd 7, if you experience stutters or audio glitches try lowering it to 6.

[jimmer]

groovy.exe defender -video none -sound none -v -bench 180
gives a long log of info on switchres etc in the cmd window and finishes with 'optional device 'palettte' not found' and then closes.
I can't see any speed in there.

When I unthrottle MAME or groovymame Defender runs at 400%, if that's the speed you are after.  That's why I thought framedelay 3 or4 would be my max (actually it could push 6 couldn't it).

But no way frame_delay 8.  That why I don't get frame_delay 8 not showing any difference to 1,2,3.  I'll go and have another play see if I can spot anything subtle. 


PS the video chipset is Intel Q965/Q963 I noticed in the info.

[intealls]

groovy.exe defender -video none -sound none -v -bench 180
gives a long log of info on switchres etc in the cmd window and finishes with 'optional device 'palettte' not found' and then closes.
I can't see any speed in there.

It's a bit difficult to spot, but *should* be there. But I'm pretty sure it runs fast. It's of course better to dethrottle like you did, but sometimes this isn't representative of the performance that can be achieved (to be clear: the Average speed report is not representative either).

Code: [Select]

...
Optional device 'palette' not found
  (missing dependencies; rescheduling)
Starting Speaker ':mono'
Starting Defender (Red label) ':'
Optional device 'palette' not found
Average speed: 6583.09% (179 seconds)


PS the video chipset is Intel Q965/Q963 I noticed in the info.

Very nice, thanks for testing and reporting. Nice to know that it works with this GPU as well!

Edit:

Updated the code snippet with an actual example from my 6700k (mame64 -video none -sound none -bench 180 -v defender).

[jimmer]

I was running the command from a batch file so the window was disappearing after the test!

1036% 

So, wow, frame_delay 8 is actually working.

The result of my play test on frame_delay 8 was not conclusive. I didn't feel for sure that it was sharper, but I did equal best score. (then again, I've been feeling like I'm improving all week and just waiting for a game to come together).  After I get used to FD 8  for a day or 2 I'll go back to FD 1 and see if I can tell the difference in that direction, which is more likely.

So, thanks very much for your help.

I would like to know what the various commands are doing but that'll wait until another day.  But, what is the -v ? is that waitvsync ?


Now I just have to work out how to run it from .ini files, and I want to try it stretched horizontally to 4:3 because I've been using that lately and quite like it (even though I always used to run it integer x4)

[intealls]

Nice, no problem.

The -v option enables verbose logging. I was unsure whether or not the average speed was reported without it.

[jimmer]

YAY !!!!  Got my best score today. Clocked it (1M) on difficulty 15/15 

So.... am I cheating?
Does my system have less input lag than the real machine, or are there other factors (other than frame delay) that even things up?

Note: this question is premised on an assumption that Defender polls the inputs near the start of the processing cycle.

[intealls]

YAY !!!!  Got my best score today. Clocked it (1M) on difficulty 15/15 

So.... am I cheating?
Does my system have less input lag than the real machine, or are there other factors (other than frame delay) that even things up?

Note: this question is premised on an assumption that Defender polls the inputs near the start of the processing cycle.

Wow, impressive!

Regarding the question, I'll refer you to this excellent post by Calamity.

[jimmer]

What I'm not clear on is what happens next? after groovymame has written to the screen buffer at just the right time.

I'm using VGA connection to my LCD. So does the video chip take the screen buffer, and transmit the video signal? and how long does the transmit take? (I assume it take the full frame 16.7ms because it's synchronous for use with CRT)   But does  the LCD process the signal as it arrives line by line, or does it read the whole frame into memory first?

you can see where I'm going with this, I'm trying to work out if there is a CRT advantage and how big it might be.

[schmerzkaufen]

Sorry to intrude; well with an lcd there's the signal passing and potential processing + the full frame time for drawing a picture top-to-bottom (@60Hz at least) + average pixel response time element to consider.
They're not all equal as some have close to zero signal processing latency, and very fast pixel response times. Those 120Hz and up models further reduce the delay of course.

Classic CRT's will always be faster, but the fastest flat panels really don't add much...so 'it depends' (on the model's performance).

Different but related questions: talking about the real hardware's lag when there is some (people say the Raizing shooters pcb's have a bit of delay for instance) and how the MAME drivers supposedly buffer some layers internally: how far apart are the two ? (actual pcb vs MAME driver)

I don't know much about how MAME works but I believe it was something like input + drivers + video, and regarding delay GM & RA benefits would come from how they handle the video part.
But the drivers keep their own 'lag', don't they ? Dunno... anyway if a MAME driver happened to be faster than the original hardware, and you're playing on a properly set GM and CRT, then maybe yeah we could say it's cheating. 

[intealls]

What I'm not clear on is what happens next? after groovymame has written to the screen buffer at just the right time.

I'm using VGA connection to my LCD. So does the video chip take the screen buffer, and transmit the video signal? and how long does the transmit take? (I assume it take the full frame 16.7ms because it's synchronous for use with CRT)   But does  the LCD process the signal as it arrives line by line, or does it read the whole frame into memory first?

you can see where I'm going with this, I'm trying to work out if there is a CRT advantage and how big it might be.

What the LCD does with the data it gets will vary between brands and models, but will most likely lead to added latency, check out this site for some comparisons: http://www.displaylag.com/display-database

Calamity pointed out the two major points of input lag in his post (aside from the frame queue): LCD processing and input. Since we're consistently getting next-frame response with high frame delay values, we can assume the input lag to be negligible most of the time (this will vary depending on keyboard/gamepad/OS/API).

On XP a keyboard (or stick emulating a keyboard) should probably be used.

But the drivers keep their own 'lag', don't they ? Dunno... anyway if a MAME driver happened to be faster than the original hardware, and you're playing on a properly set GM and CRT, then maybe yeah we could say it's cheating. 

The drivers try to accurately emulate the actual hardware. If there's lag in the hardware there should be lag in the emulation. Defender has been around for a long time so it's presumably very accurate.

For instance, ShmupMAME does various hacks to reduce input latency, this is not done in GM since it leads to inaccurate emulation.

[jimmer]

I'm not having much luck finding data on my old dell monitors. And display lag seems to have dropped 4:3 displays from it's database, last year I bought a new NEC panel and I'm sure it was on their database.

So I'm back to setting up a CRT benchmark system (JROK or groovymame), or a lag test arrangement (high speed camera or oscilloscope) if I want to know for sure where my system is at.

hmmm, now I'm thinking about DisplayPort. It gives the possibility of squirting the information into the monitor faster. In theory the overall speed could be faster than a CRT I think??? because the bottom of the CRT screen is drawn 16ms after the start of the the frame, but the LCD could maybe receive the info and turn all the pixels on faster than that?

[intealls]

I'm not having much luck finding data on my old dell monitors. And display lag seems to have dropped 4:3 displays from it's database, last year I bought a new NEC panel and I'm sure it was on their database.

No, but you get to know the ballpark, which is probably somewhere between 9 and 40 ms.

So I'm back to setting up a CRT benchmark system (JROK or groovymame), or a lag test arrangement (high speed camera or oscilloscope) if I want to know for sure where my system is at.

If you have an old CRT computer monitor laying around, the easiest way to measure LCD lag is to mirror the displays, display a stopwatch (with a millisecond counter, for instance this one) and take a picture.

But for a complete system test the most practical is probably a high speed camera. I use the PS3 eye, which is really cheap on eBay and records at 125 fps.

Edit:

hmmm, now I'm thinking about DisplayPort. It gives the possibility of squirting the information into the monitor faster. In theory the overall speed could be faster than a CRT I think??? because the bottom of the CRT screen is drawn 16ms after the start of the the frame, but the LCD could maybe receive the info and turn all the pixels on faster than that?

It appears (probably most) LCDs update the screen in the exact same manner as CRTs, check out this video:

Edit again:

But yeah, as long as the pixels are scanned out really fast they can be output faster than on a CRT (if there's no LCD processing delay). Let's say you use a display mode according to the one below (assuming 60 Hz).

Code: [Select]

<- begin active video ->
.                      .
.      480 lines       .
.                      .
<-  end active video  ->
<-   begin blanking   ->
.                      .
.   as many lines as   .
.       possible       .
.                      .
<-    end blanking    ->

This can output the complete image faster.

It's of course also possible to use a 120/144 Hz display, which will lead to a similar result, but this can be done on CRTs as well (without processing delay).

Edit again:

Come to think of it, the first method could probably be applied on CRTs as well. CRT computer monitors have size and position controls which could be used to achieve a similar result, probably not as flexibly though.

[donluca]

On XP a keyboard (or stick emulating a keyboard) should probably be used.

Sorry for the OT, but I'm curious if there's any way to do this with a USB stick on XP.

I've made the sticks myself and used a normal USB encoder (it's called "zero delay encoder" or something, just look on eBay) which so far has proved to work great, but, of course, I'm always looking to get the better deal

Is there a software or driver which I can use under XP to make my USB stick emulate a keyboard?
Or do I have to get something like a J-Pac or keyboard encoder to achieve this?

[intealls]

On XP a keyboard (or stick emulating a keyboard) should probably be used.

Sorry for the OT, but I'm curious if there's any way to do this with a USB stick on XP.

I've made the sticks myself and used a normal USB encoder (it's called "zero delay encoder" or something, just look on eBay) which so far has proved to work great, but, of course, I'm always looking to get the better deal

Is there a software or driver which I can use under XP to make my USB stick emulate a keyboard?
Or do I have to get something like a J-Pac or keyboard encoder to achieve this?

On XP, vicosku's testing shows that using the DirectInput API (gamepads) will lead to added latency. See his post here.

Using a keyboard will use the Raw Input API, which on XP appears to be faster.

On Windows 7, it doesn't appear to matter (see his later posts).

[jimmer]

If you have an old CRT computer monitor laying around, the easiest way to measure LCD lag is to mirror the displays, display a stopwatch (with a millisecond counter, for instance this one) and take a picture.

Am I right thinking that will show only whole frame differences? ie 0ms or 17ms or 33ms lag 

[intealls]

If you have an old CRT computer monitor laying around, the easiest way to measure LCD lag is to mirror the displays, display a stopwatch (with a millisecond counter, for instance this one) and take a picture.

Am I right thinking that will show only whole frame differences? ie 0ms or 17ms or 33ms lag

The picture itself will show that, yes, but you can probably average your measurements to a representative number. Also, another thing to consider is that most digital cameras use a rolling shutter, so they scan the image just like a CRT. As such, the two timers should be aligned horizontally in the picture.

Also, it might be possible to see where the raster line is updated as well. But if you want a simple solution, get one of these.