Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up --- Bug Reports --- Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: Input Lag - MAME iteration comparisons vs. the real thing?  (Read 104336 times)

0 Members and 1 Guest are viewing this topic.

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #120 on: June 22, 2014, 06:58:54 pm »
I used a dumb trick that seems to have worked.  I just started up everything on a 1440x900@60Hz lcd monitor and then switched to the CRT.  Screenshots of the CRT's OSD and Retroarch's GUI are attached to offer some assurance that this new video is running at 60Hz.  This keyboard encoder result in KMS seems to differ very little from the previous 60hz video I shot with Joysticks compared to the 75Hz one.  Calamity, I'll defer to your conclusions. 

https://anonfiles.com/file/3f6e3966c915fd4733f832acaae5595e

« Last Edit: June 22, 2014, 07:01:45 pm by vicosku »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7198
  • Last login:December 06, 2021, 02:40:00 pm
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #121 on: June 23, 2014, 08:21:33 am »
Hi vicosku, thanks again for your video, I know how much work it involves setting up everything in order to record these things properly.

So this is my counting for your new video (RA_KMS_I-PAC60hz.MOV):

19 samples at 120 fps: 8 9 9 10 10 8 9 9 9 9 10 9 9 8 9 10 8 8 9 -> 4.47 frames (RetroArch in KMS mode)

Indeed, it looks quite similar your previous results with KMS & joystick (4.47 vs 4.75). This may have two readings:
1.- When using the libretro API under Linux in KMS mode, joysticks and keyboards behave just the same in terms of lag.
2.- Any hypothetical advantage of the keyboard encoder is masked by the (suboptimal) input management of this API.


Just for reference, here is my own counting for your video from june the 12th (Frame_Delay_9_I-PACRAW.MOV):

21 samples at 120 fps: 4 3 4 2 4 3 4 4 3 3 4 4 4 4 4 3 4 4 3 3 4 -> 1.78 frames (GroovyMAME, Windows XP 64, frame_delay 9)
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #122 on: June 23, 2014, 10:57:31 am »
Calamity, thanks for reviewing the videos and confirming the frame counts.  I'm glad to perform the tests if they can be of help.  I'm no programmer, so it's nice to finally be able to contribute to the community in some way. 

I don't know the full implications of the KMS results, so I won't comment or speculate.  I just hope they'll be of use to you and other parties.  If I can perform any other tests that would be helpful, please let me know.

rCadeGaming

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1255
  • Last login:February 22, 2020, 01:48:00 pm
  • Just call me Rob!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #123 on: November 16, 2014, 11:49:22 pm »
Hi everyone, haven't been on in quite a while.  Recently I was able to make time to work on the hobby again and catch up on things.  First, I just wanted to say that the ATOM-15 drivers, and especially the new website, look AWESOME.  Calamity, you're the man!

Anyhow, I'm getting ready to make the switch from XP to 7, and I wanted to benchmark the two to make sure I won't be losing anything in terms of lag.  To start with, I need to optimize my current setup in XP and get a baseline, but I've found something strange along the way. 

Calamity, the good news is that I was able to replicate your test with Terra Cresta.  Following the same counting method, I was also able to get 3-4 frames of video at 120 FPS until the ship moves.

Video here:


BUT, that was done with the GroovyUME 150 beta 01 from about a year ago.  I think it's either the one you PM'd me or the release directly following that.  I'm unable to duplicate these results with the current GroovyMAME 155 (latest version downloaded from Google Code page 11/15/2014).  I keep getting 5-6 frames of video at 120 FPS, meaning a full extra frame of lag at 60Hz.  This is all on the same hardware, the only difference being the MAME release.

Video here:


Are there any known problems with increased lag in the current release?

One thing I can think of is that I'm still using the Switchres 015c release from the same time period as that GroovyUME 150 beta 01 (sorry, I've lost track of which one).  I'm guessing it's unlikely, but could the older CRT_Emu/Switchres conflict with GM 155, causing the extra frame of lag?  Could the problem go away when I upgrade to the newest releases and switch to Windows 7?

Could it have anything to do with audio latency?  I haven't gotten into adjusting that yet.

I'll attach my mame.ini for 155 and the resulting log from Terra Cresta.  Can you see anything that might be causing the problem, or anything that could use improvement in general?

Setup:
XP64
Core i3-2130 Sandy Bridge Dual-Core 3.5GHz CPU
Asus P8Z68-M Pro Motherboard
8GB (2x4GB) DDR3 SDRAM @ 1333MHz
Kade Encoder in USB Keyboard Mode
ASUS HD4350 -> TC1600 VGA to Component Transcoder -> Sony KV-27FS120 TV
« Last Edit: November 17, 2014, 07:41:43 am by rCadeGaming »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7198
  • Last login:December 06, 2021, 02:40:00 pm
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #124 on: November 17, 2014, 04:03:25 am »
God you ruined my breakfast...  :D

Ok, fortunately (or not) the problem (or not) is related to the terracre.c driver itself. It looks like starting from version 0.155 some sort of sprite buffer has been added to this driver. You can check this by using the shift + P method (pause the game, and keep one cursor pressed while you step frame by frame using pressing shift + P). Starting with 0.155, the spaceship takes one more frame to react. So this driver is no longer the ideal "lagless" driver to use for reference, I'm afraid. Your lag tests are consistent with this.

I've attached the 0.154 vs 0.155 diff.

More info: http://mametesters.org/view.php?id=5700
« Last Edit: November 17, 2014, 06:40:15 am by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

rCadeGaming

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1255
  • Last login:February 22, 2020, 01:48:00 pm
  • Just call me Rob!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #125 on: November 17, 2014, 07:39:04 am »
God you ruined my breakfast...  :D

Haha, sorry, didn't mean to alarm you.  Thanks for the quick response.

In any case, I'm very relieved to hear this.  At least I can be sure there's nothing wrong with my setup.  I'll compare lag results with Windows 7 soon.

Looking at my .ini, is there anything that could be improved for an optimal setup, aside from the audio latency value?  I've gone through everything else and set it up as best I could, but just wanted to be sure.

On another note, while testing I found that forcing direct draw by running with "-video ddraw" caused the game to run at 67%.  Any idea why this is happening?  It's not critical, as direct3d seems to be the way to go, but I just wanted a working direct draw option available for testing.  Log attached.  This was run with the same mame.ini posted above.

Thanks again.   :cheers:

adder

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 640
  • Last login:February 04, 2021, 10:51:51 am
  • Location: Easy St.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #126 on: November 17, 2014, 07:54:09 am »
Quote from: Calamity
Ok, fortunately (or not) the problem (or not) is related to the terracre.c driver itself. It looks like starting from version 0.155 some sort of sprite buffer has been added to this driver.
expect here is the change :) http://mametesters.org/view.php?id=5700
« Last Edit: November 17, 2014, 10:29:36 am by jadder »

adder

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 640
  • Last login:February 04, 2021, 10:51:51 am
  • Location: Easy St.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #127 on: November 17, 2014, 10:59:32 am »
guys, if needed i found a couple of games which can be used for lagless testing if necessary (ie. no built in lag regarding the shift+p method):

gunsmoke
vertical: 224x256(v) 60.000000hz

thunderx
horizontal: 288x224(h) 60.000000hz

if u require me to find others/different types of games/anything else, let me know
« Last Edit: November 17, 2014, 11:02:35 am by jadder »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7198
  • Last login:December 06, 2021, 02:40:00 pm
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #128 on: November 17, 2014, 11:06:49 am »
Thanks jadder!

thunderx looks like a good choice (you start playing quite fast).
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

cools

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 642
  • Last login:October 13, 2020, 09:31:43 am
  • Arcade Otaku Sysadmin
    • Arcade Otaku
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #129 on: November 17, 2014, 04:37:28 pm »
Space Invaders responds on the next frame. It's the only thing worth loading it for ;)

rCadeGaming

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1255
  • Last login:February 22, 2020, 01:48:00 pm
  • Just call me Rob!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #130 on: November 18, 2014, 07:24:30 am »
Thunder Cross works well.  The only problem is it's a pretty fun game, so it's distracting.   :lol  I started some testing using that, and I'll post up some results when I can compare with Windows 7.

Does anyone need any testing done in XP?  I'd be happy to help, just let me know now, because if my Windows 7 setup works out I'll decommissioning XP soon.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7198
  • Last login:December 06, 2021, 02:40:00 pm
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #131 on: November 18, 2014, 07:35:32 am »
Hi rCadeGaming,

Your .ini file looked fine, so your tests results must be "legit". Thanks for doing these tests.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

adder

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 640
  • Last login:February 04, 2021, 10:51:51 am
  • Location: Easy St.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #132 on: November 18, 2014, 08:21:36 am »
thanks Rob i might have some xp tests at some point
any timescale on when u will no longer be doing xp tests? (eg. few days, weeks.. months?)
cheers!

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7198
  • Last login:December 06, 2021, 02:40:00 pm
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #133 on: November 19, 2014, 03:47:55 am »
On another note, while testing I found that forcing direct draw by running with "-video ddraw" caused the game to run at 67%.

You may need to lower the -frame_delay value when using ddraw. This is because ddraw keeps the CPU busy for a longer period than d3d.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

rCadeGaming

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1255
  • Last login:February 22, 2020, 01:48:00 pm
  • Just call me Rob!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #134 on: November 24, 2014, 11:40:28 pm »
I finished some testing with a build that Calamity sent me to verify improvements to frame_delay, and the results look good.

First let me note my experience with XP64.  I was able to get some decent results at one point, but then found that I couldn't achieve this consistently.  The amount of lag seemed to vary randomly after each time I rebooted the PC.  I didn't troubleshoot this extensively.  It may have been fixable, but I didn't want to spend much more time on XP because my goal was to confirm the viability of 7 for myself and, if so, make the change to 7 permanently.  Your results may vary with XP.  The data points I used for XP represented the best I could gather from one continuous run in GM.

In any case, these tests were all performed in GM 155 with the game "Thunder Cross" at frame_delay 7.  The number of frames refers to frames of gameplay at 60Hz.  I collected 40 data points for each test to find an average.  I had about 75 data points for the first test in Windows 7, but found that the average of all the points was within 1% of the average of only the first 40 points, so I decided 40 would be enough as the standard for my tests.  A spreadsheet with the full results is attached, but I'll summarize here:

-GM 155-
XP64 - average: 2.200 frames, average with outliers removed: 2.044 frames.
7x64 - average: 2.025 frames

-GM 155_test-
7x64 - average: 1.913

The average with outliers removed for XP was determined by omitting occasional data points of 3 or 3.5 frames (6 or 7 of 120 fps video).  Notice that there is no such value for Windows 7.  This is because the delay NEVER exceeded 2.5 frames in Windows 7.  Windows 7 was much more stable all around.  I got the exact same behavior after restarting GM and the PC a bunch of times.  Again, your results with XP may vary, but I can at least vouch for quality in Windows 7.

Also notice that lag in the test version is even lower, "statistically."  I don't really know how important these averages actually are.  Given the low amounts of lag that Calamity is achieving (:applaud:), the amount of time that comes down to chance (at what point in the frame the button is pressed, the delay until the LED is captured by the camera, the timing offset between the camera and the CRT) becomes relatively high.  I think the most important thing that can be said about these results is that there is usually a visible on-screen response to the physical button input within 1.5-2 frames, 2.5 at most (in Windows 7), and that the new test build is at least as good if not better.

Setup:
ASUS HD4350 -> TC1600 -> KV-27FS120
Kade Encoder - USB Keyboard Mode

XP64
Core i3-2130 Sandy Bridge Dual-Core 3.5GHz
Asus P8Z68-M Pro
2x4GB DDR3 SDRAM @ 1333MHz

7x64
Core i3-4370 Haswell Dual-Core 3.8GHz
Asus Z97-M Plus
2x4GB DDR3 SDRAM @ 1600 MHz

*** rename attachment to .xlsx, I had to change the file extension to allow attachment ***
« Last Edit: November 25, 2014, 07:59:40 pm by rCadeGaming »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7198
  • Last login:December 06, 2021, 02:40:00 pm
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #135 on: November 27, 2014, 11:18:40 am »
Hi rCadeGaming,

Thanks a lot for your detailed tests. I'm happy to see these results being reproduced by other users. Thanks to your results I've decided to make that change into the "official" patch, now SwitchRes 0.015d. Hopefully this should also help with previous issues regarding analog controls.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

rCadeGaming

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1255
  • Last login:February 22, 2020, 01:48:00 pm
  • Just call me Rob!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #136 on: November 28, 2014, 09:06:47 am »
Awesome, I'm updating to 156 now!  Glad that I could help.  Let me know if you need anything else tested  :cheers:

rCadeGaming

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1255
  • Last login:February 22, 2020, 01:48:00 pm
  • Just call me Rob!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #137 on: January 11, 2015, 09:55:41 pm »
Did a little more lag testing today.  Whereas before all of my tests were run in native res, I did another test in a super resolution.  I got the result I was hoping for, which was that there isn't really any detectable lag penalty for using super resolutions.  This being the case, I don't see any reason not to use them.  I'm really loving super resolutions.

Next, I tried to squeeze a little bit more speed out of my computer by disabling a bunch of services that weren't necessary (mostly networking stuff).  Afterward, I was able to run Thunder Cross at an unthrottled average of ~3200%, meaning frame_delay 9 was rock-solid.  My previous tests had all used frame_delay 7 to play it safe for comparison across OS's.  Another lag test showed noticeable improvement.  See the results below.  I also attached an updated spreadsheet with the full results.

GM 155
7x64
native res
frame_delay 7
average: 2.025 frames

GM 155_test
7x64
native res
frame_delay 7
average: 1.913 frames

GM 155_test
7x64
super res
frame_delay 7
average: 2.025 frames

GM 155_test
7x64
super res
frame_delay 9
average: 1.763 frames


It's also worth mentioning that during 3 of the 40 samples taken at frame_delay 9, on-screen response was visible at only the second camera video frame (120fps) after the button press has started, which had never happened at frame_delay 7.  This is really getting down close to next gameplay frame response.

...and yes I know I need to upgrade to 157.  I don't get enough time for this stuff  :P

*** rename attachment to .xlsx, I had to change the file extension to allow attachment ***

koopah

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 3
  • Last login:June 25, 2018, 04:51:35 pm
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #138 on: February 10, 2015, 02:50:52 am »
Hello,

I just joined this forum because i wanted to share with you how i achieved to setup a vsynced direct3d without additional input lag in mame 0.158.
As you mentioned earlier, the problem with mame is that Direct3D + waitvsync (which is probably the mode that lcd owners want to use the most) is causing noticeable input lag.

Since i dont have access to a 60 fps camera i did this test : i made a script to run mame either with (direct3d + waitvsync) or (directdraw + waitvsync, which is supposed to produce less lag) at random. Then i play the game for 10 sec and try to guess which mode was choosen based on the input lag i can feel. After that i compare my choice to the real mode printed in console output to see if my guess was correct.

I found out that almost 90% of the time my guess was correct which mean that the input lag is a real thing and is definitely a thing a player can feel. (I am talking about the additionnal 2-3 frames that Direct3D + vsync adds)

But the good news is : i think i found a workaround to fix the problem and achieve perfect vsync in direct3d without the additionnal direct3d lag.

In mame source code, vsync in Direct3d works with the "D3DPRESENT_INTERVAL_ONE" option. The problem with this option is that it creates a "render queue" which adds latency and creates lag. I found a fix by using the "Direct3d 9Ex" library (which is compatible with Direct3d so there is just a little source code modification) and using the method : "SetMaximumFrameLatency(1)", documented here : https://msdn.microsoft.com/en-us/library/windows/desktop/bb174347%28v=vs.85%29.aspx.

With this fix, Direct3D + vsync works like a charm (perfectly vsynced to my 60hz lcd) and no noticeable input lag (i am not able to feel any additional lag, using my previous test).  :)

If you are interested in testing this fix, let me know. I can share a patch file so you can recompile mame yourself or send you my binary build which is only for windows 64 bits (btw this fix wont work for older windows version than Vista because of Direct3D 9Ex).

Additional notes : my setup is Intel G3420 CPU with integrated Intel HD GPU on windows 8.1 64 bits. The fix works perfectly on my system but i don't know if it will work on every graphics card (buggy drivers implementation for example).

Cheers

bulbousbeard

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 522
  • Last login:August 25, 2015, 11:58:25 pm
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #139 on: February 14, 2015, 09:32:55 am »
Isn't that the same as just setting max prerendered frames in Nvidia's drivers to 1?


Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7198
  • Last login:December 06, 2021, 02:40:00 pm
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #140 on: February 14, 2015, 04:00:44 pm »
If you are interested in testing this fix, let me know. I can share a patch file so you can recompile mame yourself or send you my binary build which is only for windows 64 bits (btw this fix wont work for older windows version than Vista because of Direct3D 9Ex).

Hi koopah, and thanks for sharing this. It'd be great if you posted your patch.

Yes, as you say the problem with D3D is that by default it creates a render queue. The length of this queue can be controlled either programatically using the API method you mentioned or forced to certain value with the specific tools provided by the manufacturer, like the one posted by bulbousbeard.

However, in Windows XP we don't have that API, so for D3D we've been using a manual call to GetRasterStatus followed by Present with the D3DPRESENT_INTERVAL_IMMEDIATE flag. This bypasses the frame queue, however it creates static tearing when there's significant scaling involved.

The alternative was DirectDraw, which can bypass the queue without adding tearing. Unfortunately DirectDraw is extremely slow on Windows 8, to the point of being totally unusable (I wouldn't be surprised if it was actually emulated by software or something).

So probably at some point we'll need to add this feature and apply it for Windows 7 and 8 where it's available, and finally have a "lag-less" D3D implementation without using hacks or resourcing to the deprecated DirectDraw (we also use DirectDraw currently for interlaced modes, we'll need to solve this though).
« Last Edit: February 14, 2015, 04:02:18 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

koopah

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 3
  • Last login:June 25, 2018, 04:51:35 pm
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #141 on: February 15, 2015, 07:42:20 am »
Quote
Isn't that the same as just setting max prerendered frames in Nvidia's drivers to 1?
Maybe it can solve the issue, i can't test it because my GPU is an Intel one (no Nvidia drivers). But if it works that's great :)

Quote
It'd be great if you posted your patch.
I only modified 2 files in the source code :
/src/osd/windows/d3d9intf.c http://pastebin.com/U40riSEK
/src/osd/windows/drawd3d.c http://pastebin.com/UxGxwemU
Simply replace the old contents with the new linked source code.

Let me know if it works for you (also please remember you need Direct3D 9Ex library which is only available on Windows Vista or newer).

koopah

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 3
  • Last login:June 25, 2018, 04:51:35 pm
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #142 on: February 17, 2015, 12:27:29 pm »
I just reread your message,

Quote
Unfortunately DirectDraw is extremely slow on Windows 8, to the point of being totally unusable

Before running Mame with my "fixed" Direct3D patch, i used to run it using DirectDraw (my os is Windows 8.1 64 bits).
It was pretty fast. Running a game with "-nothrottle" option was even faster with DirectDraw than Direct3D (something like 1000% speed with DirectDraw and 700% speed with Direct3D on some random old games).

Are you sure that you are using DirectDraw and not GDI or software rendering? I'm really surprised that you found DirectDraw slow.


Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:March 04, 2021, 09:45:30 am
  • Z80 ERROR
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #143 on: March 13, 2015, 01:59:30 pm »

Input lag test under Linux with UME 0.159 and thunder cross rom (frame_delay = 0). I have 3-4 frames at 120 fps.

Game is 59.9 Hz, if I am not bad at math, I have 2 frames delays. I have used the ship movement to the next pixel row.

[Sorry for the extremely bad picture quality, I did not manage to get uncompress video out of my phone]

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:March 04, 2021, 09:45:30 am
  • Z80 ERROR
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #144 on: March 13, 2015, 02:26:09 pm »
Video with better resolution.
« Last Edit: March 16, 2015, 08:14:53 am by Doozer »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7198
  • Last login:December 06, 2021, 02:40:00 pm
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #145 on: March 17, 2015, 05:19:42 am »
Hi Doozer, thanks for your test.

Input lag test under Linux with UME 0.159 and thunder cross rom (frame_delay = 0). I have 3-4 frames at 120 fps.

Yeah this seems to confirm our other Linux tests. Whatever I tried, even writing directly to the primary buffer without flipping, I could never go down from a count of 5-6 at 120 Hz (around 3 real frames) although usually it was 7-8. Notice that for simplicity we include the first frame were the led lights up even if the real input lag would obviously exclude that frame (this means that getting a count of 2 at 120 Hz (1 real frame) means no lag).

If you compare these results to the most recent ones above by rCadeGaming in Windows 7 you see that, on average, input takes 2 frames more to be received in Linux than in Windows. This happened even when we tested with low latency kernels.

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:March 04, 2021, 09:45:30 am
  • Z80 ERROR
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #146 on: March 17, 2015, 06:55:18 am »
Yeah this seems to confirm our other Linux tests. Whatever I tried, even writing directly to the primary buffer without flipping, I could never go down from a count of 5-6 at 120 Hz (around 3 real frames) although usually it was 7-8. Notice that for simplicity we include the first frame were the led lights up even if the real input lag would obviously exclude that frame (this means that getting a count of 2 at 120 Hz (1 real frame) means no lag).

If you compare these results to the most recent ones above by rCadeGaming in Windows 7 you see that, on average, input takes 2 frames more to be received in Linux than in Windows. This happened even when we tested with low latency kernels.

I will do the test on the kernel event level to see how the it reacts to inputs.

Is the lag observed identical under Windows with groovyume compiled using SDL library?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7198
  • Last login:December 06, 2021, 02:40:00 pm
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #147 on: March 17, 2015, 07:01:22 am »
Is the lag observed identical under Windows with groovyume compiled using SDL library?

GroovyMAME SDL builds don't work at all because the SDL side of the patch is not adapted to Windows yet.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #148 on: July 16, 2015, 10:58:04 am »
I just want to bump this thread and add some of the latest information on the topic that has been discussed in other threads.  I figure there are some people subscribed to this thread that haven't seen some of the others.

1.There appears to be no significant input lag discrepancy between Raw and Direct Input in GroovyMAME.  Note that this is only based upon my own testing with multiple devices so far.  One PCB using direct input was found to be slower than others.  Previous laggy direct input results were probably due to PCBs that are not lagless with this API, rather than the API itself.  Evidence of significant differences in response time for different PCBs can be found here.  However, that testing has only been performed on consoles. While interesting, I suppose it is of limited use in this thread.

2. In the aforementioned thread, the CPS1 test screen, accessed by pressing F2 in a game like sf2 and then navigating to it, was chosen as a convenient way to test input lag.  Lately, this screen has been used to show that it is possible to get next-frame response in Groovymame more than 50% of the time at high frame_delay values.  Specific details can be found in the spreadsheets linked throughout the thread.

3. New Frame_Delay value information.
There's something critical I've found out: the frame_delay value is off by 1 unit of what's supposed to be. So if you use -frame_delay 8, it's effect is -frame_delay 9. If you use -frame_delay 9, it actually "wraps" to the next frame, so -fd 9 must not be used!

4. Multiple latency reduction and stability topics have been discussed (Such as the one above) and are being tested in the GM ASIO PRE-ALPHA thread.  Koopah's D3D9ex work has been tested as well.  I encourage you to review it if you are interested in the topic.
« Last Edit: July 16, 2015, 02:40:04 pm by vicosku »

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #149 on: July 18, 2015, 07:34:02 am »
Thanks vicosku for recapping!

I just want to bump this thread and add some of the latest information on the topic that has been discussed in other threads.  I figure there are some people subscribed to this thread that haven't seen some of the others.

1.There appears to be no significant input lag discrepancy between Raw and Direct Input in GroovyMAME.  Note that this is only based upon my own testing with multiple devices so far.  One PCB using direct input was found to be slower than others.  Previous laggy direct input results were probably due to PCBs that are not lagless with this API, rather than the API itself.  Evidence of significant differences in response time for different PCBs can be found here.  However, that testing has only been performed on consoles. While interesting, I suppose it is of limited use in this thread.

2. In the aforementioned thread, the CPS1 test screen, accessed by pressing F2 in a game like sf2 and then navigating to it, was chosen as a convenient way to test input lag.  Lately, this screen has been used to show that it is possible to get next-frame response in Groovymame more than 50% of the time at high frame_delay values.  Specific details can be found in the spreadsheets linked throughout the thread.

3. New Frame_Delay value information.
There's something critical I've found out: the frame_delay value is off by 1 unit of what's supposed to be. So if you use -frame_delay 8, it's effect is -frame_delay 9. If you use -frame_delay 9, it actually "wraps" to the next frame, so -fd 9 must not be used!

4. Multiple latency reduction and stability topics have been discussed (Such as the one above) and are being tested in the GM ASIO PRE-ALPHA thread.  Koopah's D3D9ex work has been tested as well.  I encourage you to review it if you are interested in the topic.

Given 4, it may be useful to revisit some of the input latency tests at a later stage (when gmasio is considered mature), to see whether the conclusions regarding 1 and 2 still hold.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7198
  • Last login:December 06, 2021, 02:40:00 pm
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #150 on: July 18, 2015, 07:48:40 am »
Many thanks for doing this, Vicosku.

Adding an interesting latency test done by Hunter K. (RetroArch's dev).


Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #151 on: July 18, 2015, 09:05:34 am »
Adding an interesting latency test done by Hunter K. (RetroArch's dev).

Interesting indeed.

The main takeaway for me is that we could possibly improve our own testing methods by also using the protoresistor method, instead of our current (camera) one.

The conclusions regarding aero and filters are obvious and commonly known. I don't know why he thinks GM is better under Linux than under Win64, it's actually the other way round if I understood right.

It's good to see GM come out well in the relative test though.  Would love to see him repeat the tests with a CRT.

deadsoulz

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 103
  • Last login:July 20, 2016, 03:03:26 pm
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #152 on: July 18, 2016, 11:12:05 am »
Koopah Anyway I could get a copy of your Build with this modification.  I am running mame on a LCD TV and seeing significant input lag.

I just reread your message,

Quote
Unfortunately DirectDraw is extremely slow on Windows 8, to the point of being totally unusable

Before running Mame with my "fixed" Direct3D patch, i used to run it using DirectDraw (my os is Windows 8.1 64 bits).
It was pretty fast. Running a game with "-nothrottle" option was even faster with DirectDraw than Direct3D (something like 1000% speed with DirectDraw and 700% speed with Direct3D on some random old games).

Are you sure that you are using DirectDraw and not GDI or software rendering? I'm really surprised that you found DirectDraw slow.

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #153 on: July 19, 2016, 11:54:36 am »
Hi Deadsoulz.  The current version of GroovyMAME has progressed well beyond this thread.  It's been a while, but I'm almost certain Koopah's work and further improvements are included in GroovyMAME 0.171. 
« Last Edit: July 19, 2016, 11:57:48 am by vicosku »

deadsoulz

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 103
  • Last login:July 20, 2016, 03:03:26 pm
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #154 on: July 20, 2016, 02:57:06 pm »
Hi Deadsoulz.  The current version of GroovyMAME has progressed well beyond this thread.  It's been a while, but I'm almost certain Koopah's work and further improvements are included in GroovyMAME 0.171.

Thanks, I know it is in Groovymame, but I am running a LCD TV and Groovymame always just white screens for me on this setup with NVIDIA graphics card.   I was hoping maybe someone had incorporated Koopahs changes into standard mame or mameuifx.


oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 263
  • Last login:August 22, 2021, 12:40:21 pm
  • Mame forever.
    • https://github.com/oomek
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #155 on: December 04, 2016, 08:14:22 pm »
Allow me to dig out that old thread and update it with my recent lag measurements of GroovyMame 0.179 d3d9ex with always poll patch.
I used an Arduino board with 1ms polling rate and my 1200 fps camera.
My readings have precision of 0.8333 ms

Game I used: thunderx - service screen
renderer: d3d9ex
frame_delay: 9
Youtube link:



The results, especially the minimum frame delay is more than impressive.
 

Paradroid

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 684
  • Last login:November 30, 2021, 02:55:19 am
    • SCART Hunter
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #156 on: December 05, 2016, 04:13:41 am »
Excellent report! Thanks for taking the time and sharing here.

Out of interest, what kind of CPU are you running to get such low latency?
My MAME/SCART/CRT blog: SCART Hunter

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 263
  • Last login:August 22, 2021, 12:40:21 pm
  • Mame forever.
    • https://github.com/oomek
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #157 on: December 05, 2016, 05:35:25 am »
Excellent report! Thanks for taking the time and sharing here.

Out of interest, what kind of CPU are you running to get such low latency?

You will be surprised. It's an AMD A4 5000 1.5GHz (4 cores)

adder

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 640
  • Last login:February 04, 2021, 10:51:51 am
  • Location: Easy St.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #158 on: December 05, 2016, 07:07:08 am »
hi oomek thanks for your tests
coukd you post/attach your mame.ini file please

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 263
  • Last login:August 22, 2021, 12:40:21 pm
  • Mame forever.
    • https://github.com/oomek
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #159 on: December 05, 2016, 07:28:58 am »
hi oomek thanks for your tests
coukd you post/attach your mame.ini file please

Code: [Select]
#
# CORE CONFIGURATION OPTIONS
#
readconfig                1
writeconfig               0

#
# CORE SEARCH PATH OPTIONS
#
rompath                   D:\mame\roms
hashpath                  hash
samplepath                samples
artpath                   artwork
ctrlrpath                 ctrlr
inipath                   .;ini;ini/presets
fontpath                  .
cheatpath                 cheat
crosshairpath             crosshair
pluginspath               plugins
languagepath              language
swpath                    software

#
# CORE OUTPUT DIRECTORY OPTIONS
#
cfg_directory             cfg
nvram_directory           nvram
input_directory           inp
state_directory           sta
snapshot_directory        D:\mame\snap
diff_directory            diff
comment_directory         comments

#
# CORE STATE/PLAYBACK OPTIONS
#
state                     
autosave                  0
playback                 
record                   
record_timecode           0
exit_after_playback       0
mngwrite                 
aviwrite                 
wavwrite                 
snapname                  %g/%i
snapsize                  auto
snapview                  internal
snapbilinear              1
statename                 %g
burnin                    0

#
# CORE PERFORMANCE OPTIONS
#
autoframeskip             0
frameskip                 0
seconds_to_run            0
throttle                  0
syncrefresh               1
autosync                  0
sleep                     1
speed                     1.0
refreshspeed              1

#
# CORE RENDER OPTIONS
#
keepaspect                1
unevenstretch             1
unevenstretchx            0
unevenstretchy            0
autostretchxy             0
intoverscan               0
intscalex                 0
intscaley                 0

#
# CORE ROTATION OPTIONS
#
rotate                    1
ror                       0
rol                       0
autoror                   0
autorol                   0
flipx                     0
flipy                     0

#
# CORE ARTWORK OPTIONS
#
artwork_crop              1
use_backdrops             0
use_overlays              0
use_bezels                0
use_cpanels               0
use_marquees              0

#
# CORE SCREEN OPTIONS
#
brightness                1.0
contrast                  1.0
gamma                     1.0
pause_brightness          0.65
# effect                    scanline85.png
effect                    none

#
# CORE VECTOR OPTIONS
#
beam_width_min            1.0
beam_width_max            1.0
beam_intensity_weight     0
flicker                   0

#
# CORE SOUND OPTIONS
#
samplerate                48000
samples                   1
volume                    0

#
# CORE INPUT OPTIONS
#
coin_lockout              1
ctrlr                     
mouse                     0
joystick                  1
lightgun                  0
multikeyboard             0
multimouse                0
steadykey                 0
ui_active                 0
offscreen_reload          0
joystick_map              auto
joystick_deadzone         0.3
joystick_saturation       0.85
natural                   0
joystick_contradictory    0
coin_impulse              0

#
# CORE INPUT AUTOMATIC ENABLE OPTIONS
#
paddle_device             keyboard
adstick_device            keyboard
pedal_device              keyboard
dial_device               keyboard
trackball_device          keyboard
lightgun_device           keyboard
positional_device         keyboard
mouse_device              mouse

#
# CORE DEBUGGING OPTIONS
#
verbose                   0
log                       0
oslog                     0
debug                     0
update_in_pause           0
debugscript               

#
# CORE COMM OPTIONS
#
comm_localhost            0.0.0.0
comm_localport            15112
comm_remotehost           127.0.0.1
comm_remoteport           15112

#
# CORE MISC OPTIONS
#
drc                       1
drc_use_c                 0
drc_log_uml               0
drc_log_native            0
bios                     
cheat                     0
skip_gameinfo             1
uifont                    default
ui                        cabinet
ramsize                   
confirm_quit              0
ui_mouse                  1
autoboot_command         
autoboot_delay            0
autoboot_script           
console                   0
plugins                   1
plugin                   
noplugin                 
language                  English

#
# CORE SWITCHRES OPTIONS
#
modeline_generation       0
monitor                   custom
orientation               horizontal
connector                 auto
interlace                 1
doublescan                1
super_width               2560
changeres                 1
powerstrip                0
lock_system_modes         1
lock_unsupported_modes    1
refresh_dont_care         0
dotclock_min              0
sync_refresh_tolerance    2.0
frame_delay               9
vsync_offset              0
black_frame_insertion     0
modeline                  auto
ps_timing                 auto
lcd_range                 auto
crt_range0                63100.00-64100.00,50.00-65.00,0.759,1.241,2.000,0.016,0.047,0.503,0,1,768,1024,0,0
crt_range1                auto
crt_range2                auto
crt_range3                auto
crt_range4                auto
crt_range5                auto
crt_range6                auto
crt_range7                auto
crt_range8                auto
crt_range9                auto

#
# OSD KEYBOARD MAPPING OPTIONS
#
uimodekey                 SCRLOCK

#
# OSD FONT OPTIONS
#
uifontprovider            auto

#
# OSD OUTPUT OPTIONS
#
output                    auto

#
# OSD INPUT OPTIONS
#
keyboardprovider          auto
mouseprovider             auto
lightgunprovider          auto
joystickprovider          auto

#
# OSD DEBUGGING OPTIONS
#
debugger                  auto
debugger_font             auto
debugger_font_size        0
watchdog                  0

#
# OSD PERFORMANCE OPTIONS
#
numprocessors             auto
bench                     0

#
# OSD VIDEO OPTIONS
#
video                     d3d
numscreens                1
window                    0
maximize                  1
waitvsync                 0
monitorprovider           auto

#
# OSD PER-WINDOW VIDEO OPTIONS
#
screen                    auto
aspect                    auto
resolution                auto
view                      auto
screen0                   \\.\DISPLAY1
aspect0                   4:3
resolution0               1280x1024@0
view0                     auto
screen1                   auto
aspect1                   auto
resolution1               auto
view1                     auto
screen2                   auto
aspect2                   auto
resolution2               auto
view2                     auto
screen3                   auto
aspect3                   auto
resolution3               auto
view3                     auto

#
# OSD FULL SCREEN OPTIONS
#
switchres                 1

#
# OSD ACCELERATED VIDEO OPTIONS
#
filter                    1
prescale                  1

#
# OpenGL-SPECIFIC OPTIONS
#
gl_forcepow2texture       0
gl_notexturerect          0
gl_vbo                    1
gl_pbo                    1
gl_glsl                   0
gl_glsl_filter            1
glsl_shader_mame0         none
glsl_shader_mame1         none
glsl_shader_mame2         none
glsl_shader_mame3         none
glsl_shader_mame4         none
glsl_shader_mame5         none
glsl_shader_mame6         none
glsl_shader_mame7         none
glsl_shader_mame8         none
glsl_shader_mame9         none
glsl_shader_screen0       none
glsl_shader_screen1       none
glsl_shader_screen2       none
glsl_shader_screen3       none
glsl_shader_screen4       none
glsl_shader_screen5       none
glsl_shader_screen6       none
glsl_shader_screen7       none
glsl_shader_screen8       none
glsl_shader_screen9       none

#
# OSD SOUND OPTIONS
#
sound                     auto
audio_latency             1.0

#
# BGFX POST-PROCESSING OPTIONS
#
bgfx_path                 bgfx
bgfx_backend              auto
bgfx_debug                0
bgfx_screen_chains        default
bgfx_shadow_mask          slot-mask.png
bgfx_avi_name             auto

#
# WINDOWS PERFORMANCE OPTIONS
#
priority                  0
profile                   0

#
# WINDOWS VIDEO OPTIONS
#
menu                      0

#
# DIRECT3D POST-PROCESSING OPTIONS
#
hlslpath                  hlsl
hlsl_enable               0
hlsl_oversampling         0
hlsl_write                auto
hlsl_snap_width           2048
hlsl_snap_height          1536
shadow_mask_tile_mode     0
shadow_mask_alpha         0.0
shadow_mask_texture       shadow-mask.png
shadow_mask_x_count       6
shadow_mask_y_count       4
shadow_mask_usize         0.1875
shadow_mask_vsize         0.25
shadow_mask_uoffset       0.0
shadow_mask_voffset       0.0
distortion                0.0
cubic_distortion          0.0
distort_corner            0.0
round_corner              0.0
smooth_border             0.0
reflection                0.0
vignetting                0.0
scanline_alpha            0.0
scanline_size             1.0
scanline_height           1.0
scanline_variation        1.0
scanline_bright_scale     1.0
scanline_bright_offset    0.0
scanline_jitter           0.0
hum_bar_alpha             0.0
defocus                   0.0,0.0
converge_x                0.0,0.0,0.0
converge_y                0.0,0.0,0.0
radial_converge_x         0.0,0.0,0.0
radial_converge_y         0.0,0.0,0.0
red_ratio                 1.0,0.0,0.0
grn_ratio                 0.0,1.0,0.0
blu_ratio                 0.0,0.0,1.0
saturation                1.0
offset                    0.0,0.0,0.0
scale                     1.0,1.0,1.0
power                     1.0,1.0,1.0
floor                     0.0,0.0,0.0
phosphor_life             0.0,0.0,0.0

#
# NTSC POST-PROCESSING OPTIONS
#
yiq_enable                0
yiq_jitter                0.0
yiq_cc                    3.57954545
yiq_a                     0.5
yiq_b                     0.5
yiq_o                     0.0
yiq_p                     1.0
yiq_n                     1.0
yiq_y                     6.0
yiq_i                     1.2
yiq_q                     0.6
yiq_scan_time             52.6
yiq_phase_count           2

#
# VECTOR POST-PROCESSING OPTIONS
#
vector_beam_smooth        0.0
vector_length_scale       0.5
vector_length_ratio       0.5

#
# BLOOM POST-PROCESSING OPTIONS
#
bloom_blend_mode          0
bloom_scale               0.0
bloom_overdrive           1.0,1.0,1.0
bloom_lvl0_weight         1.0
bloom_lvl1_weight         0.64
bloom_lvl2_weight         0.32
bloom_lvl3_weight         0.16
bloom_lvl4_weight         0.08
bloom_lvl5_weight         0.06
bloom_lvl6_weight         0.04
bloom_lvl7_weight         0.02
bloom_lvl8_weight         0.01

#
# FULL SCREEN OPTIONS
#
triplebuffer              0
full_screen_brightness    1.0
full_screen_contrast      1.0
full_screen_gamma         1.0

#
# INPUT DEVICE OPTIONS
#
global_inputs             0
dual_lightgun             0