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 Try the site in https mode 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 135928 times)

0 Members and 1 Guest are viewing this topic.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #200 on: December 19, 2017, 02:56:57 pm »
Do you have any tips on installing the sweetlow driver?  I can't get it to do anything on either my win7 noSP or my win7 SP1 machines.

Make sure you use Test Mode. First you need to install the driver and SweetLow.CER (double click on it). After installing the cert, run 1kHz.cmd, right click on HIDUSBF.INF and choose install. You may or may not need to reboot.

Then launch setup.exe, select your mouse, select "Filter on device", "Install service" and choose the desired poll rate. Click "Restart". Now use mouserate.exe to see if the change took. If the mouse won't seem to go any higher than 125 Hz, try setting 62 Hz or 31 Hz. If the update rate is at 62 or 31 Hz, the driver is working as intended, and the mouse might be limited to a 125 Hz update rate.

Then do the same for your controller.
« Last Edit: December 19, 2017, 02:58:47 pm by intealls »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #201 on: December 19, 2017, 03:18:54 pm »
Thanks Dacasks and intealls for these new tests. Really exciting results!

No worries whatsoever. Thank you for the incredibly awesome CRT Emudriver v2, which will keep our lovely CRTs in use for years to come. :) And GM on state-of-the-art hardware as well! The entire project is just awesome.

I manually measured the response of 87 button presses from the recording. About 84% gave next-frame response. The best case was about 2.5 ms before vblank, but there were responses up to about 3 ms that didn't give next-frame response, so I need to look into it some more. Everything over about 3.4 ms gave next-frame response.

Code: [Select]
2110 1 6.5 RIGOL_D3D9EX_1000HZ_POLL
2324 1 5.2
2544 1 8
2762 1 4.5
2974 1 13
3187 0 1
3400 1 3.7
3618 0 1
3830 1 4
4046 1 9.2
4264 1 6
4482 1 3.7
4683 1 5.2
4896 1 8
5109 1 12
5326 1 15.5
5537 1 9
5757 1 14
5971 1 12
6181 1 5.5
6393 1 14
6607 1 7.2
6828 1 13.2
7037 1 13.7
7254 0 1.2
7473 1 12
7702 1 13
7904 1 11.5
8136 0 0.8
8358 1 15
8570 1 2.8
8781 1 13
8986 1 15
9206 1 4.2
9416 1 4
9646 0 2.8
9862 1 4
10087 1 8
10307 1 13.5
10525 1 11.2
10750 1 11
10975 1 15.5
11193 1 15.8
11409 1 5.2
11630 1 6.2
11844 0 1.5
12050 0 1.2
12260 1 15.5
12464 0 2.4
12679 1 9
12898 1 6.2
13121 1 3.4
13342 0 3.2
13560 0 1.6
13770 1 15.2
13998 1 5.2
14210 1 11.2
14412 0 2.8
14616 1 11.2
14835 1 7.2
15047 1 16.76
15264 1 16.76
15489 0 1.2
15705 1 3.5
15919 1 3.7
16144 1 7.5
16363 1 15
16582 1 10.5
16810 1 15.8
17025 1 14.5
17248 1 16
17458 0 1.4
17678 1 10
17886 1 15
18105 1 8
18318 1 7.2
18524 1 5
18733 1 4.8
18959 1 8.5
19168 1 11.5
19375 0 0.8
19593 1 16.76
19805 1 3.4
20028 1 15.5
20248 1 2.5
20477 1 3.9
20694 1 7.7
0.839080459770115
« Last Edit: December 19, 2017, 03:21:42 pm by intealls »

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 561
  • Last login:March 17, 2024, 06:03:11 pm
  • I want to play Defender like at the arcade.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #202 on: December 19, 2017, 09:21:33 pm »

Make sure you use Test Mode. First you need to install the driver and SweetLow.CER (double click on it). After installing the cert, run 1kHz.cmd, right click on HIDUSBF.INF and choose install. You may or may not need to reboot.

Then launch setup.exe, select your mouse, select "Filter on device", "Install service" and choose the desired poll rate. Click "Restart". Now use mouserate.exe to see if the change took. If the mouse won't seem to go any higher than 125 Hz, try setting 62 Hz or 31 Hz. If the update rate is at 62 or 31 Hz, the driver is working as intended, and the mouse might be limited to a 125 Hz update rate.

Then do the same for your controller.

Thanks for that. I got it working on the mouse now (at 62hz) it won't go above 125hz.

I use an arduino encoder, so when I get a chance I'll test it by programming some 500hz keypresses.


On forums jimmer speaks for himself as a Defender fan, not as proprietor of www.jbgaming.co.uk  << Is that advertising or disclosure ? or both ?

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 #203 on: December 20, 2017, 08:25:53 am »
Hi intealls,

Thanks for sharing your research and results  :)

I used a scope to see when vblank occured and when the button was pressed. Next frame responses could be observed down to about 2.5 ms before vblank!

Your testing setup is intriguing  :). Could you possibly explain a bit more in detail how your testing setup works, it's different from the LED wired to joystick + 240fps camera setup right?  If so, how does it account for possible video frame render queues or total USB stack latency?

Just did a test run with 1000 Hz USB polling (with the driver somewhere in this thread, http://www.overclock.net/t/1597441/digitally-signed-sweetlow-1000hz-mouse-driver ). Tried fixing the controller to 31 Hz to make sure the driver worked as intended, which made next frame response impossible.

I guess it's good to mention that the sweetlow "driver" is a hack that "tampers" with the USB Endpoint protocol in Windows. Depending on your hardware there may be benefits, there may be disadvantages...

Windows and USB Endpoint structure

It's a myth that Windows handles all USB devices at a polling interval of 8ms.

I'll elaborate a bit on this as we're all freaks right  :D

Windows has a very clear protocol on how it handles USB devices. The speed of the device together with the bInterval value that is set in hardware of the endpoint device configures the polling interval in Windows. Refer to USB_ENDPOINT_DESCRIPTOR structure

As can be seen from the three tables on the page, the minimum polling period for low speed USB devices is 8ms. Full speed devices may configure 1ms as minimum polling interval and high-speed devices configure it in "microframes", the minimum being 1/8th of 1ms.

Basicly any quality modern gaming endpoint device is configured to be a full-speed device and uses either 1ms or 4ms polling interval. In most cases it makes no sense using the sweetlow hack on these devices.
 
If you're interested in the interface speed of your Hori stick, you could download the tool USBView from Microsoft and look up the mentioned values for your joystick. Since you seem to experience a benefit from using the hack, my guess is that it's a low speed device.

To put this into perspective the I-PAC 2 is a full speed device that has a bInterval value that configures it at 4ms polling period. The new XBox One controllers when used on a PC also operate at 4ms polling period. The 2600-daptor runs at 1ms polling interval.

The potential disadvantage with the sweetlow hack is that there is no secure way to determine whether or not the (low-speed) USB joystick hardware really supports the higher polling rate. With a mouse you can use mousetester, but there is no such thing for testing joysticks. When you're applying the sweetlow hack with a device where the hardware does not really support such high polling interval, it may result in erratic behaviour and degrade the performance overall.
« Last Edit: December 20, 2017, 08:35:36 am by Dr.Venom »

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2006
  • Last login:February 08, 2023, 08:30:27 pm
  • Gotta have blue hair.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #204 on: December 20, 2017, 10:15:56 am »
Has any lag testing been done like this with the PS/2 interface?

I have an older JPAC interface that connects through the PS/2 keyboard port.  I'm curious if it has better/same/worse results than the USB IPAC interface.
Hantarex Polo 15KHz
Sapphire Radeon HD 7750 2GB (GCN)
GroovyMAME 0.197.017h_d3d9ex
CRT Emudriver & CRT Tools 2.0 beta 13 (Crimson 16.2.1 for GCN cards)
Windows 7 Home Premium 64-bit
Intel Core i7-4790K @ 4.8GHz
ASUS Z87M-PLUS Motherboard

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #205 on: December 20, 2017, 12:10:37 pm »
Hi Dr.Venom, long time no hear!

Your testing setup is intriguing  :). Could you possibly explain a bit more in detail how your testing setup works, it's different from the LED wired to joystick + 240fps camera setup right?  If so, how does it account for possible video frame render queues or total USB stack latency?

I've improved the setup since the last post, I can now actuate the button deterministically at a predetermined time from vblank.

It's quite simple - an MCU (Teensy) is monitoring vblank (from the UMSA), and pulls the button low on the RAP for 125 ms, x ms after vblank. x is configurable to any delay. Runtime operation is monitored by the oscilloscope.

Here's a timing diagram.

Code: [Select]
_____   ____________________   ___   ____
     |_|                    |_|   ...
       ^ vblank
       |-----------------|
                         ^ x
_________________________             ___
                         |________...|
                         ^ button actuation by MCU

I can post some pictures and a better rundown later on.

Other than that, the testing procedure is the same as previous endeavours (240 fps camera + LED). So next-frame response still need to be determined manually by looking at the video. It's quite easy with this setup though, since the button actuation interval is deterministic, a fixed number of video frames can be present between actuations. This makes it possible to quickly fast-forward between actuations.

USB stack latency should be included in the measured delay, since it's a system test. Determining what the USB stack latency is though, that's another story. :)

I guess it's good to mention that the sweetlow "driver" is a hack that "tampers" with the USB Endpoint protocol in Windows. Depending on your hardware there may be benefits, there may be disadvantages...

Windows and USB Endpoint structure

It's a myth that Windows handles all USB devices at a polling interval of 8ms.

...

Thanks for the USB rundown and USBView tip! Really helpful.

Here's the descriptor from the Hori stick, the MSDN descriptor page, in conjunction with the information from USBView seems to suggest that the device in fact uses a standard 8 ms polling rate (bInterval = 0x0A and Full Speed).

Code: [Select]
Is Port User Connectable:         yes
Is Port Debug Capable:            no
Companion Port Number:            0
Companion Hub Symbolic Link Name:
Protocols Supported:
 USB 1.1:                         yes
 USB 2.0:                         yes
 USB 3.0:                         no

Device Power State:               PowerDeviceD0

       ---===>Device Information<===---
English product name: "REAL ARCADE Pro.V3"

ConnectionStatus:                 
Current Config Value:              0x01  -> Device Bus Speed: Full (is not SuperSpeed or higher capable)
Device Address:                    0x13
Open Pipes:                           2

          ===>Device Descriptor<===
bLength:                           0x12
bDescriptorType:                   0x01
bcdUSB:                          0x0200
bDeviceClass:                      0x00  -> This is an Interface Class Defined Device
bDeviceSubClass:                   0x00
bDeviceProtocol:                   0x00
bMaxPacketSize0:                   0x40 = (64) Bytes
idVendor:                        0x0F0D = HORI CO., LTD.
idProduct:                       0x0022
bcdDevice:                       0x1000
iManufacturer:                     0x01
     English (United States)  "HORI CO.,LTD."
iProduct:                          0x02
     English (United States)  "REAL ARCADE Pro.V3"
iSerialNumber:                     0x00
bNumConfigurations:                0x01

          ---===>Open Pipes<===---

          ===>Endpoint Descriptor<===
bLength:                           0x07
bDescriptorType:                   0x05
bEndpointAddress:                  0x02  -> Direction: OUT - EndpointID: 2
bmAttributes:                      0x03  -> Interrupt Transfer Type
wMaxPacketSize:                  0x0040 = 0x40 bytes
bInterval:                         0x0A

          ===>Endpoint Descriptor<===
bLength:                           0x07
bDescriptorType:                   0x05
bEndpointAddress:                  0x81  -> Direction: IN - EndpointID: 1
bmAttributes:                      0x03  -> Interrupt Transfer Type
wMaxPacketSize:                  0x0040 = 0x40 bytes
bInterval:                         0x0A

       ---===>Full Configuration Descriptor<===---

          ===>Configuration Descriptor<===
bLength:                           0x09
bDescriptorType:                   0x02
wTotalLength:                    0x0029  -> Validated
bNumInterfaces:                    0x01
bConfigurationValue:               0x01
iConfiguration:                    0x00
bmAttributes:                      0x80  -> Bus Powered
MaxPower:                          0xFA = 500 mA

          ===>Interface Descriptor<===
bLength:                           0x09
bDescriptorType:                   0x04
bInterfaceNumber:                  0x00
bAlternateSetting:                 0x00
bNumEndpoints:                     0x02
bInterfaceClass:                   0x03  -> HID Interface Class
bInterfaceSubClass:                0x00
bInterfaceProtocol:                0x00
iInterface:                        0x00

          ===>HID Descriptor<===
bLength:                           0x09
bDescriptorType:                   0x21
bcdHID:                          0x0111
bCountryCode:                      0x00
bNumDescriptors:                   0x01
bDescriptorType:                   0x22 (Report Descriptor)
wDescriptorLength:               0x0089

          ===>Endpoint Descriptor<===
bLength:                           0x07
bDescriptorType:                   0x05
bEndpointAddress:                  0x02  -> Direction: OUT - EndpointID: 2
bmAttributes:                      0x03  -> Interrupt Transfer Type
wMaxPacketSize:                  0x0040 = 0x40 bytes
bInterval:                         0x0A

          ===>Endpoint Descriptor<===
bLength:                           0x07
bDescriptorType:                   0x05
bEndpointAddress:                  0x81  -> Direction: IN - EndpointID: 1
bmAttributes:                      0x03  -> Interrupt Transfer Type
wMaxPacketSize:                  0x0040 = 0x40 bytes
bInterval:                         0x0A

The potential disadvantage with the sweetlow hack is that there is no secure way to determine whether or not the (low-speed) USB joystick hardware really supports the higher polling rate. With a mouse you can use mousetester, but there is no such thing for testing joysticks. When you're applying the sweetlow hack with a device where the hardware does not really support such high polling interval, it may result in erratic behaviour and degrade the performance overall.

I wasn't aware of the fact that modern devices actually set a faster polling rate. Maybe the proper thing to do would be to find an encoder that operates at 1 kHz, and not use the SweetLow hack!

I found this page of someone using Joy2Key to test the polling rate, but haven't tested it.

Edit: Tested this, and it doesn't work.

I'll elaborate a bit on this as we're all freaks right  :D

This is irrefutably the case! Albeit in a good way.
« Last Edit: December 20, 2017, 01:32:12 pm by intealls »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #206 on: December 20, 2017, 03:07:22 pm »
OK, so I did a few runs.

I set the button actuation to about 3.6 ms from vblank (window is about 1.9 ms), and set the polling rate to Default, 500 Hz and 1000 Hz using the SweetLow driver and logged the result. The timing can be seen in the attached image. I started counting from about frame 250 and onwards.

1000 Hz: 51 pass, 6 fail, 89% next frame response.
 500 Hz: 21 pass, 36 fail, 37% next frame response.
Default: 57 fail, 0% next frame response.

So even though it's still unknown if the Hori in actuality handles 1000 Hz polling in a graceful manner, it performs a lot better with 1000 Hz polling set. With multiple button presses and the like, who knows. Maybe it'll choke.

I uploaded the videos to here: mega.nz.

I use VLC to convert the videos to avi (MJPEG) and then VirtualDub with ffdshow to view them, which allows very fast scrubbing.
« Last Edit: December 20, 2017, 03:09:33 pm by intealls »

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 #207 on: December 20, 2017, 03:53:28 pm »
Hi Dr.Venom, long time no hear!

Yes it's been a while, good to see you around also :)

I've improved the setup since the last post, I can now actuate the button deterministically at a predetermined time from vblank.

It's quite simple - an MCU (Teensy) is monitoring vblank (from the UMSA), and pulls the button low on the RAP for 125 ms, x ms after vblank. x is configurable to any delay. Runtime operation is monitored by the oscilloscope.

Other than that, the testing procedure is the same as previous endeavours (240 fps camera + LED). So next-frame response still need to be determined manually by looking at the video. It's quite easy with this setup though, since the button actuation interval is deterministic, a fixed number of video frames can be present between actuations. This makes it possible to quickly fast-forward between actuations.

Ah now I understand, thanks for explaining. Great setup.

OK, so I did a few runs.

I set the button actuation to about 3.6 ms from vblank (window is about 1.9 ms), and set the polling rate to Default, 500 Hz and 1000 Hz using the SweetLow driver and logged the result. The timing can be seen in the attached image. I started counting from about frame 250 and onwards.

1000 Hz: 51 pass, 6 fail, 89% next frame response.
 500 Hz: 21 pass, 36 fail, 37% next frame response.
Default: All fail, 0% next frame response.

So even though it's still unknown if the Hori in actuality handles 1000 Hz polling in a graceful manner, it performs a lot better with 1000 Hz polling set. With multiple button presses and the like, who knows. Maybe it'll choke.

I uploaded the videos to here: mega.nz.

I use VLC to convert the videos to avi (MJPEG) and then VirtualDub with ffdshow to view them, which allows very fast scrubbing.

That's a pretty awesome finding. Thanks for sharing, I'll take a look at the videos later!

The below got a bit longer than I anticipated but since it may have some relevance to the topic on hand..

Some time ago I did some more elaborate testing on the latency of WinUAE versus real Amiga (which I still own). With the help of the WinUAE author a small application for the Amiga side was made which allows to set the rasterline where the Amiga polls for input and then shows a color on screen after vsync when a button is pressed (Very tiny Amiga DOS program that takes rasterline number as input :P). I.e. you can have the Amiga side poll early or late in the frame and see how it affects the latency measurements on the Windows host.

One of the takeaways was that WinUAE when compared like for like with the real hardware shows a lag of 1.2 frames when the Amiga side acquires input early in the frame and about 1.8 frames when it acquires input late in the frame. WinUAE's D3D9Ex implementation as far as I know is quite similar to that of GM, the main difference being that WinUAE doesn't have a framedelay feature like GM.

I guess the above may have similar implications for GM, especially when there is "some" inherent lag on the host (USB stack?) this can become a factor.* (Framedelay cannot fully compensate, especially when game polls late in the frame). So depending on which rasterline an Arcade game reads its input, it will be easier or more difficult to match the response with emulation. It may also imply that if we find next frame response for one game, that it doesn't have to be the same for all games.

*If I remember correctly some tests done by Calamity way back suggested something like half a frame of inherent host lag (next frame response was only seen when LED active and rasterbeam had not yet crossed 1/3rd of the screen.. but correct me if I'm wrong..)

In case you're interested, a (very long) thread spawned from it on the EAB board: Input latency measurements (and D3D11), see here: http://eab.abime.net/showthread.php?t=88777.

The WinUAE testing brought up an interesting other point, which has to do with a Microsoft comment that mentioned that in most situations there is 1 frame of inherent video latency in Windows applications (this may be interesting to Calamity especially). With Windows 8.1 a new feature is introduced called "waitable swap chains" that has the potential to implement next frame response to input, see this post out of the earlier mentioned thread specifically: http://eab.abime.net/showpost.php?p=1188236&postcount=19

Quote
How does waiting on the back buffer reduce latency?

With the flip model swap chain, back buffer "flips" are queued whenever your game calls IDXGISwapChain::Present. When the rendering loop calls Present(), the system blocks the thread until it is done presenting a prior frame, making room to queue up the new frame, before it actually presents. This causes extra latency between the time the game draws a frame and the time the system allows it to display that frame. In many cases, the system will reach a stable equilibrium where the game is always waiting almost a full extra frame between the time it renders and the time it presents each frame. It's better to wait until the system is ready to accept a new frame, then render the frame based on current data and queue the frame immediately.

It's part of the reason why the thread derailed into in a DGXI/D3D11 thread  :), which Toni is currently implementing into WinUAE. Time will tell, once the low latency vsync stuff is implemented, whether it will result in shaving off another frame of latency compared to its (WinUAE's) D3D9Ex implementation.

Here's the descriptor from the Hori stick, the MSDN descriptor page, in conjunction with the information from USBView seems to suggest that the device in fact uses a standard 8 ms polling rate (bInterval = 0x0A and Full Speed).

Right, that's a configuration seen on many "normal" (non gaming) USB2 input devices.

I wasn't aware of the fact that modern devices actually set a faster polling rate. Maybe the proper thing to do would be to find an encoder that operates at 1 kHz, and not use the SweetLow hack!

Sure that seems like the best solution. Not easy to find though as there is some nuance to modern devices setting a faster polling rate. It seems to be the modern (expensive) gaming gear that are almost without exception full speed devices with 1 ms polling (or configurable as 1, 2, 4 or 8ms via a hardware switch, like e.g. my Corsair K70 gaming keyboard). But opposite to that is the category of modern "cheap" gear, like most of the gamepads and joystick / gamepad adapters from China, which sadly are mostly low speed 8ms, or worse...

I'll elaborate a bit on this as we're all freaks right  :D

This is irrefutably the case! Albeit in a good way.

Definitely. It's great to have people apply a little science to these topics which have been so obscure for many years.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #208 on: December 21, 2017, 05:32:23 am »
Quote
*If I remember correctly some tests done by Calamity way back suggested something like half a frame of inherent host lag (next frame response was only seen when LED active and rasterbeam had not yet crossed 1/3rd of the screen.. but correct me if I'm wrong..)

Yes, but my tests were done on an old Core2Duo running XP 64. We suggested back then that the faster the CPU, the smaller the host system lag would be, as later tests on more powerful hardware are confirming. Intealls' results (3.6 ms from vblank) show next frame response with the beam having crossed 4/5 of the screen. Eventually, as hardware gets faster, host system lag should be close to zero.

The breakthrough was to prove that next frame response is possible in emulation, conceptually and empirically, something that was denied at the time and is still questioned today.


Quote
(Framedelay cannot fully compensate, especially when game polls late in the frame). So depending on which rasterline an Arcade game reads its input, it will be easier or more difficult to match the response with emulation.

While I understand and find your results with Amiga logical*, I think this statement is not true for (Groovy)MAME. In general, it doesn't matter on which rasterline an arcade game reads its input, because emulation time will be compressed to a fraction of the frame time, instead of spreading across the full duration of the frame time. So, provided you have the most recent input polled right before emulating the frame, and the closest possible to vblank with a high frame delay value (ideally we should do the whole emulation during the vblank interval) the emulated arcade game is guaranteed to have the most recent input regardless of the scanline it polls input.

* In my understanding, your Amiga experiment involves two things:

1.- The Amiga emulator polls host input at any point that the emulated software polls input. MAME doesn't work that way, all input is polled and buffered prior to emulating next frame.

2.- The time spent by the Amiga emulator to emulate a frame is not negligible (at least it's long enough that the polling point makes a difference). With GroovyMAME and high frame delay we're assuming the emulation time is negligible.


However, there are two scenarios I can think of where the GroovyMAME model won't be able to match real hardware, by design:

1.- If a game can poll input at any point in a frame and make action happen right in that frame (e.g. make the character move on the lower half of the screen). Although we have no knowledge of any game doing this, it's certainly possible that real hardware did that and GroovyMAME definitely can't.

2.- Respond to button presses shorter than a frame period. Oomek made some tests that show this is not possible with current implementation. A button press must cross a frame boundary to get MAME aknowledge it. This might be the reason why combos in fight games are more difficult to achieve than on real hardware. An adhoc workaround for this might be possible but testing its effectiveness requires a very specific setup.


Quote
It's better to wait until the system is ready to accept a new frame, then render the frame based on current data and queue the frame immediately.

Certainly, those waitable swap chains are Microsoft's implementation of frame delay. In my understanding, there's a big catch, however:



You see: Button press happens during frame #1, but action happens on frame #3. No next frame response.

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 of pasting it.

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

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #209 on: December 21, 2017, 07:30:49 am »
Yes, but my tests were done on an old Core2Duo running XP 64. We suggested back then that the faster the CPU, the smaller the host system lag would be, as later tests on more powerful hardware are confirming. Intealls' results (3.6 ms from vblank) show next frame response with the beam having crossed 4/5 of the screen. Eventually, as hardware gets faster, host system lag should be close to zero.

I should mention that I'm running the tests on an i5 4690k clocked at 4.5 GHz on Windows 7 x64.  ;D

So this setup definitely has more grunt than the C2D.

The biggest uncertainty with my setup is the controller, I don't know if it works properly at 1 kHz. I have a mouse that is polled natively at 1 kHz, I'll try this as input source this evening.

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 #210 on: December 21, 2017, 07:33:22 am »
Yes, but my tests were done on an old Core2Duo running XP 64. We suggested back then that the faster the CPU, the smaller the host system lag would be, as later tests on more powerful hardware are confirming. Intealls' results (3.6 ms from vblank) show next frame response with the beam having crossed 4/5 of the screen. Eventually, as hardware gets faster, host system lag should be close to zero.

Good to know. So basicly (for good / new hardware) we're already close to the 1ms Input Stack, as shown in the Microsoft picture below.

While I understand and find your results with Amiga logical*, I think this statement is not true for (Groovy)MAME. In general, it doesn't matter on which rasterline an arcade game reads its input, because emulation time will be compressed to a fraction of the frame time, instead of spreading across the full duration of the frame time.

I see your point of negligible frame emulation time for most of the older games and systems in MAME.  But MAME also includes games and systems that do have noticable frame emulation time. E.g. CAVE games, Chihiro based stuff, console based systems like Playstation, Saturn, computer systems like C64, Amiga, etc. Some of them have have considerable frame emulation time in (Groovy)MAME. For those cases frame delay has to be lowered from the ideal of 9 (in some cases a lot), up to the point where it starts to matter where in the frame the game or system acquires input, right?

Maybe it would be nice to test the Amiga driver in GroovyMAME and see how it stacks up to WinUAE and real hardware?

@Intealls would you be up for it? I could supply you with an Amiga diskimage / adf that boots into Amiga shell with the button test program. Then we would have a like for like comparison between GM and real hardware.

However, there are two scenarios I can think of where the GroovyMAME model won't be able to match real hardware, by design:

1.- If a game can poll input at any point in a frame and make action happen right in that frame (e.g. make the character move on the lower half of the screen). Although we have no knowledge of any game doing this, it's certainly possible that real hardware did that and GroovyMAME definitely can't.

I think the Atari 2600 used to do this a lot, it was called "racing the beam", so I wouldn't be surprised if more games from that era used similar tricks.

2.- Respond to button presses shorter than a frame period. Oomek made some tests that show this is not possible with current implementation. A button press must cross a frame boundary to get MAME aknowledge it. This might be the reason why combos in fight games are more difficult to achieve than on real hardware. An adhoc workaround for this might be possible but testing its effectiveness requires a very specific setup.

Good point. In WinUAE it's possible with the debugger to see the exact rasterline at which a program /game acquires input. If something similar would be possible with the MAME debugger you could prove whether or not there are games that read input more than once in a frame..


Certainly, those waitable swap chains are Microsoft's implementation of frame delay. In my understanding, there's a big catch, however:

You see: Button press happens during frame #1, but action happens on frame #3. No next frame response.

You're including the touch digitizer...  :). It doesn't play a role in our case (the original example incorporates a tablet with touchscreen), leaving next frame response.



Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #211 on: December 21, 2017, 07:47:19 am »
You're including the touch digitizer...  :). It doesn't play a role in our case (the original example incorporates a tablet with touchscreen), leaving next frame response.

I was being merciful :)

Button (digitizer, whatever) is pressed while frame #0 is being scanned on the screen, but action happens on frame #3.  So even if we remove the touch digitizer from scene, we're still a frame late.

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 of 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 #212 on: December 21, 2017, 07:56:12 am »
You're including the touch digitizer...  :). It doesn't play a role in our case (the original example incorporates a tablet with touchscreen), leaving next frame response.

I was being merciful :)

Button (digitizer, whatever) is pressed while frame #0 is being scanned on the screen, but action happens on frame #3.  So even if we remove the touch digitizer from scene, we're still a frame late.

I'll be merciful too :)  The touch digitizer is an endpoint, its like Intealls Hori stick taking 25ms to process input. As Intealls tests has shown the Hori stick registers within 1 ms, so you may leave the latency of the touch digitizer out of the equation :)

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #213 on: December 21, 2017, 08:07:45 am »
Hopefully this clarifies my point:

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 of pasting it.

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

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #214 on: December 21, 2017, 11:12:39 am »
Quote
Some of them have have considerable frame emulation time in (Groovy)MAME. For those cases frame delay has to be lowered from the ideal of 9 (in some cases a lot), up to the point where it starts to matter where in the frame the game or system acquires input, right?

Sure, there are systems where frame emulation time is not negligible, and because of this they don't fit in the frame delay model (although you may find a benefit enabling it even with low values just to bypass the frame queue, but that's not frame delay's purpose). However, even for those cases the point in the frame where input is polled doesn't matter as MAME always polls input at the same point: right before emulation of the frame. The emulated system does not poll input directly through MAME, it just accesses a pre-buffered data.

Quote
I think the Atari 2600 used to do this a lot, it was called "racing the beam", so I wouldn't be surprised if more games from that era used similar tricks.

That's pretty interesting, I hadn't heard of that.

Quote
Good point. In WinUAE it's possible with the debugger to see the exact rasterline at which a program /game acquires input. If something similar would be possible with the MAME debugger you could prove whether or not there are games that read input more than once in a frame..

Yeah that would be interesting. I believe there's no reliable information about this on the web, regarding different hardware systems and how and when they poll input, whether it's game dependent, etc.
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 of pasting it.

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

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #215 on: December 21, 2017, 02:12:42 pm »
Some more measurements.

The same setup as before (3.6 ms before vblank = 1.9 ms window).

Razer/Microsoft HABU gaming mouse (Raw input?, native 1 kHz polling):

Pass/tot: 5/55, 9% next-frame response.

HORI Real Arcade Pro VX-SA (Xinput, X360 variant of the one I tested previously):

Pass/tot: 40/58, 69% next-frame response.

So the best device so far is the RAP V3-SA (DirectInput).

Edit:

Tried hammering a lot of buttons on the RAP V3, and measured next frame response on the one synced to vblank.

Pass/tot: 54/66, 82% next-frame response, down from 89%.

So it should perform well under use as well.
« Last Edit: December 21, 2017, 08:07:24 pm by intealls »

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 561
  • Last login:March 17, 2024, 06:03:11 pm
  • I want to play Defender like at the arcade.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #216 on: December 21, 2017, 06:34:20 pm »
If you're interested in the interface speed of your Hori stick, you could download the tool USBView from Microsoft and look up the mentioned values for your joystick. Since you seem to experience a benefit from using the hack, my guess is that it's a low speed device.

Thanks for that DrVenom. My encoder is FULL speed, and has 4 pipes(!?).  Would I be right that the final line is telling me that the HID device is being polled at 1ms ?

Code: [Select]
[Port5]  :  USB Composite Device


Device Power State:               PowerDeviceD0

       ---===>Device Information<===---
English product name: "Arduino Leonardo"

ConnectionStatus:                 
Current Config Value:              0x01  -> Device Bus Speed: Full
Device Address:                    0x03
Open Pipes:                           4

          ===>Device Descriptor<===
bLength:                           0x12
bDescriptorType:                   0x01
bcdUSB:                          0x0200
bDeviceClass:                      0xEF  -> This is a Multi-interface Function Code Device
bDeviceSubClass:                   0x02  -> This is the Common Class Sub Class
bDeviceProtocol:                   0x01  -> This is the Interface Association Descriptor protocol
bMaxPacketSize0:                   0x40 = (64) Bytes
idVendor:                        0x2341 = Arduino, LLC
idProduct:                       0x8036
bcdDevice:                       0x0100
iManufacturer:                     0x01
     English (United States)  "Arduino LLC"
iProduct:                          0x02
     English (United States)  "Arduino Leonardo"
iSerialNumber:                     0x03
     English (United States)  "HIDPC"
bNumConfigurations:                0x01

          ---===>Open Pipes<===---

          ===>Endpoint Descriptor<===
bLength:                           0x07
bDescriptorType:                   0x05
bEndpointAddress:                  0x81  -> Direction: IN - EndpointID: 1
bmAttributes:                      0x03  -> Interrupt Transfer Type
wMaxPacketSize:                  0x0010 = 0x10 bytes
bInterval:                         0x40

          ===>Endpoint Descriptor<===
bLength:                           0x07
bDescriptorType:                   0x05
bEndpointAddress:                  0x02  -> Direction: OUT - EndpointID: 2
bmAttributes:                      0x02  -> Bulk Transfer Type
wMaxPacketSize:                  0x0040 = 0x40 bytes
bInterval:                         0x00

          ===>Endpoint Descriptor<===
bLength:                           0x07
bDescriptorType:                   0x05
bEndpointAddress:                  0x83  -> Direction: IN - EndpointID: 3
bmAttributes:                      0x02  -> Bulk Transfer Type
wMaxPacketSize:                  0x0040 = 0x40 bytes
bInterval:                         0x00

          ===>Endpoint Descriptor<===
bLength:                           0x07
bDescriptorType:                   0x05
bEndpointAddress:                  0x84  -> Direction: IN - EndpointID: 4
bmAttributes:                      0x03  -> Interrupt Transfer Type
wMaxPacketSize:                  0x0040 = 0x40 bytes
bInterval:                         0x01

       ---===>Full Configuration Descriptor<===---

          ===>Configuration Descriptor<===
bLength:                           0x09
bDescriptorType:                   0x02
wTotalLength:                    0x0064  -> Validated
bNumInterfaces:                    0x03
bConfigurationValue:               0x01
iConfiguration:                    0x00
bmAttributes:                      0xA0  -> Bus Powered
  -> Remote Wakeup
MaxPower:                          0xFA = 500 mA

          ===>IAD Descriptor<===
bLength:                           0x08
bDescriptorType:                   0x0B
bFirstInterface:                   0x00
bInterfaceCount:                   0x02
bFunctionClass:                    0x02  -> This is Communications (CDC Control) USB Device Interface Class
bFunctionSubClass:                 0x02
bFunctionProtocol:                 0x01
iFunction:                         0x00

          ===>Interface Descriptor<===
bLength:                           0x09
bDescriptorType:                   0x04
bInterfaceNumber:                  0x00
bAlternateSetting:                 0x00
bNumEndpoints:                     0x01
bInterfaceClass:                   0x02  -> This is Communications (CDC Control) USB Device Interface Class
bInterfaceSubClass:                0x02
bInterfaceProtocol:                0x00
iInterface:                        0x00
  -> This is a Communications (CDC Control) USB Device Interface Class

          ===>Descriptor Hex Dump<===
bLength:                           0x05
bDescriptorType:                   0x24
05 24 00 10 01
  -> This is a Communications (CDC Control) USB Device Interface Class

          ===>Descriptor Hex Dump<===
bLength:                           0x05
bDescriptorType:                   0x24
05 24 01 01 01
  -> This is a Communications (CDC Control) USB Device Interface Class

          ===>Descriptor Hex Dump<===
bLength:                           0x04
bDescriptorType:                   0x24
04 24 02 06
  -> This is a Communications (CDC Control) USB Device Interface Class

          ===>Descriptor Hex Dump<===
bLength:                           0x05
bDescriptorType:                   0x24
05 24 06 00 01

          ===>Endpoint Descriptor<===
bLength:                           0x07
bDescriptorType:                   0x05
bEndpointAddress:                  0x81  -> Direction: IN - EndpointID: 1
bmAttributes:                      0x03  -> Interrupt Transfer Type
wMaxPacketSize:                  0x0010 = 0x10 bytes
bInterval:                         0x40

          ===>Interface Descriptor<===
bLength:                           0x09
bDescriptorType:                   0x04
bInterfaceNumber:                  0x01
bAlternateSetting:                 0x00
bNumEndpoints:                     0x02
bInterfaceClass:                   0x0A  -> This is a CDC Data USB Device Interface Class
bInterfaceSubClass:                0x00
bInterfaceProtocol:                0x00
iInterface:                        0x00

          ===>Endpoint Descriptor<===
bLength:                           0x07
bDescriptorType:                   0x05
bEndpointAddress:                  0x02  -> Direction: OUT - EndpointID: 2
bmAttributes:                      0x02  -> Bulk Transfer Type
wMaxPacketSize:                  0x0040 = 0x40 bytes
bInterval:                         0x00

          ===>Endpoint Descriptor<===
bLength:                           0x07
bDescriptorType:                   0x05
bEndpointAddress:                  0x83  -> Direction: IN - EndpointID: 3
bmAttributes:                      0x02  -> Bulk Transfer Type
wMaxPacketSize:                  0x0040 = 0x40 bytes
bInterval:                         0x00

          ===>Interface Descriptor<===
bLength:                           0x09
bDescriptorType:                   0x04
bInterfaceNumber:                  0x02
bAlternateSetting:                 0x00
bNumEndpoints:                     0x01
bInterfaceClass:                   0x03  -> HID Interface Class
bInterfaceSubClass:                0x00
bInterfaceProtocol:                0x00
iInterface:                        0x00

          ===>HID Descriptor<===
bLength:                           0x09
bDescriptorType:                   0x21
bcdHID:                          0x0101
bCountryCode:                      0x00
bNumDescriptors:                   0x01
bDescriptorType:                   0x22 (Report Descriptor)
wDescriptorLength:               0x002F

          ===>Endpoint Descriptor<===
bLength:                           0x07
bDescriptorType:                   0x05
bEndpointAddress:                  0x84  -> Direction: IN - EndpointID: 4
bmAttributes:                      0x03  -> Interrupt Transfer Type
wMaxPacketSize:                  0x0040 = 0x40 bytes
bInterval:                         0x01




On forums jimmer speaks for himself as a Defender fan, not as proprietor of www.jbgaming.co.uk  << Is that advertising or disclosure ? or both ?

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 #217 on: December 22, 2017, 08:27:46 am »
Thanks for that DrVenom. My encoder is FULL speed, and has 4 pipes(!?).  Would I be right that the final line is telling me that the HID device is being polled at 1ms ?

Hi jimmer, that's correct!


Some more measurements.

Razer/Microsoft HABU gaming mouse (Raw input?, native 1 kHz polling):

Pass/tot: 5/55, 9% next-frame response.

Interesting. The deviation seems quite large when compared with the Hori stick at 1ms. Just to be sure: there's only one endpoint / open pipe on the mouse? Does it make a difference if you apply the sweetlow hack on the mouse?

Your testing setup, with the ability to force button actuation at specific points in the frame,  gave me the following thought: What if we could prove not only 1 frame response, but also sub 1 frame response? I think it may be possible, I'm curious as to your opinion on it.


Proving emulator input latency can achieve (far) below 1 frame response

Testing setup:

  • use MAME Amiga driver
  • start the Amiga "button test" program (that I referred to previously) with a rasterline value of 300 (very near the end of the Amiga frame). On button press it will do two things:  A) color visible screen red immediately within the same frame (on real Amiga) and B) turn screen yellow immediately after the first following vsync. 
  • use frame delay 9 and actuate button just in front of host vblank. If all goes well this could prove responses in the sub-frame range of roughly 1/4th of a frame!*

*On real Amiga the lowest possible visible response would be when a button actuation occurs right in front of vsync: immediately after the blanking the first yellow scanlines would be visible. If blanking is in the order of 25 lines and total screen is 313 lines, this would be in the order of ~0,1 frame visible response! Give or take a bit because of granularity of 240fps recording speed..


Things that may influence results:

1. Input stack on testing setup near zero.  Confirmed for Intealls setup by previous testing.
2. No secret buffers in the MAME Amiga driver. Confirmed. I did some tests in the past with the frame stepping method while keeping button pressed and MAME shows response in the next frame when using the button test program. We would need to reaffirm this with most recent Amiga driver in MAME.
3. There is no other delay in the host PC system. Unconfirmed. For example the almost 1 frame of delay Microsoft is hinting at with the "equilibrium" state when doing present calls**. Which is the whole point of the waitable swap chains, to do away with that last bit of lag.

** As quoted previously, Microsoft says: "In many cases, the system will reach a stable equilibrium where the game is always waiting almost a full extra frame between the time it renders and the time it presents each frame."

It may have become obvious from my previous postings, but my biggest concern is with point 3, the almost 1 frame of delay Microsoft is hinting at. The good thing is that above test could provide us with the much needed evidence whether this is really an issue for our case or not.

How cool would it be of we could prove emulator response in the subframe region?!?  I'm sure if say below 0,5 frame of response could be shown, there would be no bigger Christmas gift for Calamity this year!  :)

@Intealls, what's your opinion, would this be a valid test (setup)?

« Last Edit: December 22, 2017, 08:31:45 am by Dr.Venom »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #218 on: December 22, 2017, 09:42:07 am »
Hi Dr., is that Amiga test program available somewhere? I'd like to test it if I have a chance. GroovyMAME (by design) won't be able to paint in red the bottom of the screen, however it should be able to paint yellow right after vblank like the actual Amiga.

Anyway, I need to point out that your #3 is indeed confirmed (2013). I can't elaborate on it now, but if you look at Intealls' results, they're already showing it, in other words: next frame response implies both subframe response and no hidden additional delay in the host PC. This is true because with frame delay we're sort of bypassing Microsoft's "present" stack. And if my understanding of waitable swap chains is correct (not 100% sure), what Microsoft is trying to fix is being 2 frames behind us, but their implementation is still 1 frame behind (see my picture above).

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 of pasting it.

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

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 561
  • Last login:March 17, 2024, 06:03:11 pm
  • I want to play Defender like at the arcade.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #219 on: December 22, 2017, 10:46:45 am »
Maybe one of you guys could explain the details of how the Defender system processes and displays things.  Because I'm wondering whether framedelay 9 is more responsive than the real system.

My guess has always been something simple like:
 
Poll the inputs.
cpu spend 16ms? doing calcs and moving pixels around the screen memory
Video system reads the screen memory, and then spends the next 16ms writing it to the monitor.

On forums jimmer speaks for himself as a Defender fan, not as proprietor of www.jbgaming.co.uk  << Is that advertising or disclosure ? or both ?

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 #220 on: December 22, 2017, 01:21:31 pm »
Hi Dr., is that Amiga test program available somewhere? I'd like to test it if I have a chance. GroovyMAME (by design) won't be able to paint in red the bottom of the screen, however it should be able to paint yellow right after vblank like the actual Amiga.

Hi Calamity,

I've created a bootable disk with the button program on it, see attachment. It boots straight to Amiga DOS. The command is "button <scanline>". Scanline value between 0 and 312 for PAL Amiga. Blanking ends around rasterline 26.

Green line appears where "wait" line is set. When mouse button is pressed, red color appears below green line, then comes vblank wait and then color gets changed to yellow. Then it waits for final vblank and resets back to normal state. (=get flickering colors if button is kept pressed). Program can be quit by pressing joystick button.   

Quote
Anyway, I need to point out that your #3 is indeed confirmed (2013). I can't elaborate on it now, but if you look at Intealls' results, they're already showing it, in other words: next frame response implies both subframe response and no hidden additional delay in the host PC. This is true because with frame delay we're sort of bypassing Microsoft's "present" stack. And if my understanding of waitable swap chains is correct (not 100% sure), what Microsoft is trying to fix is being 2 frames behind us, but their implementation is still 1 frame behind (see my picture above).

Let's see how the proof stacks up to the statement of "no hidden additional delay in the host PC".

I honestly look forward to scrubbing through a video capture of mentioned testcase and see input response happening in the subframe range of 1/4th of a frame.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #221 on: December 22, 2017, 02:08:02 pm »
Quote
Let's see how the proof stacks up to the statement of "no hidden additional delay in the host PC".

Seriously Dr., I have to insist on the fact that the proof is already in this thread: http://forum.arcadecontrols.com/index.php/topic,133194.msg1377633.html#msg1377633

Lots of others have replicated it since then. Do you or anyone else really doubt that the results above or the ones achieved by Dacasks, Intealls, etc. already prove what you're meaning to prove? I'm asking this sincerely because I have the feeling that these tests and their implications are not being understood properly and we might need to elaborate a proper write-up explaining it better. Sorry if I look assertive on this but otherwise readers of this thread might get the wrong impression that next frame response is under debate.

That said I'm willing to perform the test on the Amiga driver, but some remarks first:

- Mouse devices are not treated in the same way as joysticks or keyboards in GroovyMAME. There's an specific fix in GroovyMAME to force keyboards and joysticks to be polled on demand (remind the "always_poll" patch) instead of at a given timeout. I tried implementing the same for all input devices but that broke mouse and spinners. So to achieve the lower latency possible you'd need modify your test program to use a keyboard button instead of the mouse. Is this change possible? *

- As I said previously, the red colour below the green line won't happen in GM. Is that condition required to get yellow color in next frame? I have the feeling that you'll use that result to deny subframe response. But we're not talking about the same thing here. What you want to achieve is "current frame response" which I already said is not possible and probably won't ever be in GM. Next frame response already implies what you call "subframe response": in my example above it's 2/3 of 16.67 ms (subframe). In Intealls' tests it's much lower. Do you see my point?

* This is the probable explanation to why Intealls' mouse test results weren't good.

« Last Edit: December 22, 2017, 02:09:49 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 of pasting it.

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

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #222 on: December 22, 2017, 03:20:43 pm »
Please, no bickering. :)

Probably most (all?) mice, fight sticks or keyboards run a small firmware.

If the firmware only updates its state at 30 Hz, it doesn't matter if the device is polled at 1 kHz.

I think this is the problem is with the Habu mouse. I don't think the buttons are updated directly at 1 kHz (a typical debounce period could be up to 5 ms for instance, and a state update might occur after, and not before debounce).

I have an additional Teensy configured as a HID keyboard, which I have control over and it is polled at 1 kHz. I'm triggering this in the same way the others (Habu, RAPs). I'm compiling the results and will hopefully post them tomorrow, they highlight the fact that the encoder is very important for optimum frame delay performance. I haven't seen any type of USB stack latency in these measurements, granted there is no USB traffic other than the button on/off going on.  ;D

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #223 on: December 22, 2017, 05:04:42 pm »
Quote
Probably most (all?) mice, fight sticks or keyboards run a small firmware.

If the firmware only updates its state at 30 Hz, it doesn't matter if the device is polled at 1 kHz.

Yeah, that makes sense, but I was talking about a change in baseline that made next frame response impossible several versions ago, which is partially reverted now in GroovyMAME, but only for keyboards and joysticks:

Code: [Select]
void windows_osd_interface::poll_input(running_machine &machine) const
{
m_keyboard_input->poll(machine);
m_mouse_input->poll_if_necessary(machine);
m_lightgun_input->poll_if_necessary(machine);
m_joystick_input->poll(machine);
}

That "if necessary" was the culprit.
« Last Edit: December 22, 2017, 05:06:39 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 of pasting it.

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

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #224 on: December 22, 2017, 05:22:31 pm »
Yeah, that makes sense, but I was talking about a change in baseline that made next frame response impossible several versions ago, which is partially reverted now in GroovyMAME, but only for keyboards and joysticks:

Code: [Select]
void windows_osd_interface::poll_input(running_machine &machine) const
{
m_keyboard_input->poll(machine);
m_mouse_input->poll_if_necessary(machine);
m_lightgun_input->poll_if_necessary(machine);
m_joystick_input->poll(machine);
}

That "if necessary" was the culprit.

Ah, ok. Missed that, certainly makes sense.

It might not be the firmware that's the issue with the Habu then - however I still think it's a very real issue.

The nice thing about the Teensy is that it can be reconfigured easily to be a mouse, joystick or whatever. So it's possible to test several code paths/devices with one hardware.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #225 on: December 23, 2017, 01:39:25 pm »
It turns out vblank was the wrong reference point for deadline calculation, SwitchRes setup a resolution of 384x240 for sf2, the actual game resolution is 384x224. I think this means that internally MAME uses a resolution of 384x240, and the frame is needed 8 scanlines before it's drawn on the screen.

This would also mean that the hard deadline for when the frame is needed is past vblank.

See the attached image.

Taking this into consideration, I setup three test cases.

All of them used the Teensy polled at 1 kHz.

Code: [Select]
2.180 ms before deadline (0.5 ms poll window)

25 pass, 25 fail = 50%.

2.430 ms before deadline (0.75 ms poll window)

39 pass, 12 fail = 76.4%.

2.680 ms before deadline (1.0 ms poll window)

50 pass. = 100 %

So the measurements certainly match up. They also imply that there is no USB lag, or other "host lags" present. Again, this is on a fast computer with virtually no USB traffic.

The videos have been uploaded to here: mega.

With the previous measurements corrected, they look like this:

Code: [Select]
4.8 ms before deadline (3.1 ms poll window)

HORI RAP V3-SA, SweetLow 1000 Hz: 89% (82% with heavy mashing).
HORI RAP VX-SA, SweetLow 1000 Hz: 69%.
Razer/MS HABU, SweetLow 1000 Hz:  9%.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #226 on: December 23, 2017, 04:53:25 pm »
I'm watching the TEENSY_2.680MS_F_DL.MOV file, it's just amazing...


From your graphic:

15.6147 kHz x 2.680 ms = 41.85 lines (42)

blanking = 1 + 3 + 16 = 20 lines
borders = 8 + 8 = 16 lines (224p active in 240p mode)

42 - 20 - 16 = 6 lines from bottom

224 - 6 = 218 (beam position at 97% of the screen height, 100% input events get in next frame)

 :o

EDIT: Ok, I now see you seem to be placing the frame deadline at the end of v back porch so I shouldn't be substracting the upper 8-line border.

42 - 20 - 8 = 14 lines from bottom

224 - 14 = 210 (94%, still amazing)
« Last Edit: December 23, 2017, 05:59:50 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 of pasting it.

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

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #227 on: December 23, 2017, 05:55:03 pm »
15.6147 kHz x 2.680 ms = 41.85 lines (42)

blanking = 1 + 3 + 16 = 20 lines
borders = 8 + 8 = 16 lines (224p active in 240p mode)

42 - 20 - 16 = 6 lines from bottom

224 - 6 = 218 (beam position at 97% of the screen height, 100% input events get in next frame)

 :o

Yes, this seems to be the case!

It lines up perfectly. 1/10 frametime for emulation and 1 ms for input polling.

I would say frame delay does exactly what it's supposed to.

What we need now is 8 kHz USB 3 polling and a finer frame delay granularity.  ;D

EDIT: Ok, I now see you seem to be placing the frame deadline at the end of v back porch so I shouldn't be substracting the upper 8-line border.

42 - 20 - 8 = 14 lines from bottom

224 - 14 = 210 (94%, still amazing)


Correct, I monitored Red as well to easily see where input occured.

And this is for 100% next-frame response.

I think we need a firmware that handles all of the input handling within a guaranteed 1ms timeslot, while we wait for several-kHz USB 3. :)
« Last Edit: December 23, 2017, 06:12:39 pm by intealls »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #228 on: December 23, 2017, 06:26:17 pm »
I think we need a firmware that handles all of the input handling within a guaranteed 1ms timeslot, while we wait for several-kHz USB 3. :)

Yeah. In the meantime a finer frame delay granularity might help. I bet your machine can do better than 1.68 ms for emulation.

Great stuff!


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 of pasting it.

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

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #229 on: December 23, 2017, 06:54:49 pm »
I bet your machine can do better than 1.68 ms for emulation.

CPS1 seems to be a very fast driver since it runs so well at fd9, NeoGeo needs fd8. The Sega Genesis driver also needs fd8.

Haze's cv1k optimizations are amazing though - Pink Sweets runs at fd8. But it seems to vary quite a bit depending on the game. Some cv1k games need fd5.

Psyvariar (PSX based) needs fd1.

So even though it's quite fast - it's not nearly enough. :)

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 561
  • Last login:March 17, 2024, 06:03:11 pm
  • I want to play Defender like at the arcade.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #230 on: December 24, 2017, 07:07:27 am »
Yeah. In the meantime a finer frame delay granularity might help. I bet your machine can do better than 1.68 ms for emulation.
Great stuff!

At some point you have to say 'who is going to notice a difference of 0.8ms ?'

To answer my Defender question, the inputs are polled every 8ms and the screen drawing is split into 2 halves (drawing one, moving pixels on the other).  This gives an average of 12ms from input to screen draw (8ms to 16ms). 

As the Defender ship is usually about 3/4 down the screen, a groovymame FD9 set-up will achieve about 15ms (12.5 + 2.7). On my LCD set-up I will have to add some more ms for the lag between the vga signal and the pixel lighting up, maybe 5ms?
On forums jimmer speaks for himself as a Defender fan, not as proprietor of www.jbgaming.co.uk  << Is that advertising or disclosure ? or both ?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #231 on: December 24, 2017, 09:41:35 am »
I've created a bootable disk with the button program on it, see attachment. It boots straight to Amiga DOS. The command is "button <scanline>". Scanline value between 0 and 312 for PAL Amiga. Blanking ends around rasterline 26.

Hi Dr.Venom,

I'm planning to test your Amiga program in the next days, I'm testing it right now on my laptop, using this command:

mame64 a1200 -flop button_test.adf

What Amiga model is this supposed to be tested on? Amiga 1200?

BTW MAME complains about Amiga driver not working, even if the program actually loads fine and seems to run as expected.
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 of pasting it.

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

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #232 on: December 24, 2017, 10:04:20 am »
Quote
To answer my Defender question, the inputs are polled every 8ms and the screen drawing is split into 2 halves (drawing one, moving pixels on the other).  This gives an average of 12ms from input to screen draw (8ms to 16ms).

Just out of curiosity, where or how did you get this information about Defender?

Quote
As the Defender ship is usually about 3/4 down the screen, a groovymame FD9 set-up will achieve about 15ms (12.5 + 2.7). On my LCD set-up I will have to add some more ms for the lag between the vga signal and the pixel lighting up, maybe 5ms?

The issue here is GroovyMAME can't replicate the way Defender works, considering your description above. MAME buffers whole frames, it can't poll input twice per frame.
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 of pasting it.

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

1500points

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 550
  • Last login:November 20, 2018, 01:44:12 pm
    • How to succeed at Robotron
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #233 on: December 24, 2017, 02:54:25 pm »

Just out of curiosity, where or how did you get this information about Defender?


Jarvis himself explained it on FB recently.  :)


Sent from my iPhone using Tapatalk

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 561
  • Last login:March 17, 2024, 06:03:11 pm
  • I want to play Defender like at the arcade.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #234 on: December 25, 2017, 06:21:53 am »
Quote
As the Defender ship is usually about 3/4 down the screen, a groovymame FD9 set-up will achieve about 15ms (12.5 + 2.7). On my LCD set-up I will have to add some more ms for the lag between the vga signal and the pixel lighting up, maybe 5ms?

The issue here is GroovyMAME can't replicate the way Defender works, considering your description above. MAME buffers whole frames, it can't poll input twice per frame.

Indeed, I wasn't complaining in fact I was quite happy when I plugged the numbers in to find such a small difference. We have a Defender meetup in February and if I get my act together I'll be doing some testing to see what players can discern. I'll try different framedelays, and do groovymame vs jrok. I'm not a crt user though so it'll all be lcd based.

I've got an idea that there must be a way to use the highspeed of the displayport connection to squirt the whole frame AND get the lcd lit up in less than 16ms. In other words LCDs could be faster than crts for a change.





On forums jimmer speaks for himself as a Defender fan, not as proprietor of www.jbgaming.co.uk  << Is that advertising or disclosure ? or both ?

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 #235 on: December 25, 2017, 11:14:00 am »
== my earlier post got deleted because of the adf's I attached. So here it is again, without the adf's ==

mame64 a1200 -flop button_test.adf

What Amiga model is this supposed to be tested on? Amiga 1200?

I would advise A500/A600 as it should be less demanding to emulate.

I used the a600 driver as on the a500 driver the keyboard doesn't seem to get recognized.

A1200 is the successor generation with faster CPU (14Mhz 68020) and more advanced video chipset. 

BTW MAME complains about Amiga driver not working, even if the program actually loads fine and seems to run as expected.

Yeah I know. A lot of things work quite OK though. I've attached some stuff for you to try out and get a feel.

Q-Bic.adf (a500/a600) -- Q-Bert clone
Hybris.adf  (a500/a600) -- Shooter, playable apart from some minor gfx and audio bugs. Use space on keyboard for superbomb and make a 360 cycle on joystick to change state of active weapon to enhanced state.
Slamtilt (a1200) -- pinball game with large 50fps scrolling playfield. It's keyboard controlled: on menu where you can pick the table just press space (gfx bug doesn't show table selection highlight) and it will load first table (Mean Machines).  When it asks for 2nd disk just load it through file manager. Game is started with F1, Enter launches ball and Alt for flippers.

Note that in Amiga land joystick port 1 has the mouse attached and port 2 has the joystick and is player 1 (so MAME "player 2" configures Amiga "player 1").  Re button_test, I just remapped button 1 on port 1 and 2  for the button_test to be used with joystick button and have program exit with mouse button.

As with more drivers (MSX to name one) the MAME dev again choose to hardcode a doubled vertical resolution for PAL progressive resolutions. It's a bit annoying given that the goal is to document real hardware. Just wish they would look more to the PSX driver to see how to handle the capability for both progressive and interlace resolutions more gracefully. Whereas LCD users probably won't notice it becomes an visible issue on CRT because GM will pick an interlaced mode based on this.

Would there be a way to accomodate for this in GM, could we just put in a "0.5" value for intscaley? (how will it handle 567/2?)

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 #236 on: December 25, 2017, 12:26:29 pm »
So the measurements certainly match up. They also imply that there is no USB lag, or other "host lags" present. Again, this is on a fast computer with virtually no USB traffic.

Awesome results, thanks for sharing :)  Super cool to see the evidence that it's at least possible to create a USB chain with no lags!

What if on the real arcade hardware the service menu program loop doesn't take a lot of cpu time and runs straight after vsync. Would this imply that GM with your setup (acquiring input late in the frame with no host lag) may actually prove to be lower latency than the real hardware? (Given that the real hardware uses a framebuffer and doesn't do any "racing the beam" of course!  :))

I think we need a firmware that handles all of the input handling within a guaranteed 1ms timeslot, while we wait for several-kHz USB 3. :)

Maybe the sweetlow hack for 2 - 4 - 8 khz (it's linked to from the thread you posted earlier) is already "exploiting" the possibility for USB3 microframe latency on low and full speed USB devices? http://www.overclock.net/t/1589644/usb-mouse-hard-overclocking-2000-hz

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 #237 on: December 26, 2017, 03:51:00 am »
I have an additional Teensy configured as a HID keyboard, which I have control over and it is polled at 1 kHz.

I'm sure this is already on your radar, but would the performance difference between the Teensy (keyboard) and the RAP (joystick) be fully explained by the difference in RawInput versus DirectInput API? Theoretically rawinput has the suggestion to be the faster of the two, although we never had conclusive evidence (I think).

Would be nice to see how the Teensy performs when configured as joystick instead of a keyboard (i.e. use directinput instead of rawinput).

. I haven't seen any type of USB stack latency in these measurements, granted there is no USB traffic other than the button on/off going on;D

I once had the APEX M800 keyboard and while you would think of it as one single device polled at 1ms, it actually enabled 3 active endpoints (two keyboards and one mouse "device", I guess for the macro keys and the like..) all polled at 1ms.  Then you have a real mouse attached at 1ms, then an I-PAC 2 2015 version (with the joypad firmware enabled) which configures three devices (a keyboard, a mouse and a joypad) all at 4ms, and suddenly what is supposed to be a relatively simple setup, you end up with 7 attached USB devices, four of which at 1ms and three at 4ms!!  In subjective testing I could notice the difference when unplugging the APEX M800, mouse and disabling two devices on the I-PAC2, such that I ended up with only the joystick active. It made a noticable difference (subjectively) to me in fluidity of the joystick movement in fast shooters.

So you're touching on a very real issue I think.  Would be really great if you can find the time to do the Teensy test, while also having 3 or 4 other 1ms devices attached to your system.
 

Recapnation

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 332
  • Last login:December 01, 2023, 07:39:55 pm
    • Eiusdemmodi
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #238 on: December 26, 2017, 08:29:11 am »

As with more drivers (MSX to name one) the MAME dev again choose to hardcode a doubled vertical resolution for PAL progressive resolutions. It's a bit annoying given that the goal is to document real hardware. Just wish they would look more to the PSX driver to see how to handle the capability for both progressive and interlace resolutions more gracefully. Whereas LCD users probably won't notice it becomes an visible issue on CRT because GM will pick an interlaced mode based on this.

Would there be a way to accomodate for this in GM, could we just put in a "0.5" value for intscaley? (how will it handle 567/2?)

It was this discussed somewhere here a few months ago. Check G.2 here: http://geedorah.com/eiusdemmodi/forum/viewtopic.php?pid=987#p987


Lovely findings, by the way, even if hard to follow. Thank you all.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #239 on: December 26, 2017, 10:13:27 am »
I'm sure this is already on your radar, but would the performance difference between the Teensy (keyboard) and the RAP (joystick) be fully explained by the difference in RawInput versus DirectInput API? Theoretically rawinput has the suggestion to be the faster of the two, although we never had conclusive evidence (I think).

Would be nice to see how the Teensy performs when configured as joystick instead of a keyboard (i.e. use directinput instead of rawinput).

I already tried this. :)

I used this firmware, but wasn't able to get 1 ms next-frame response. I sniffed the USB traffic with a Saleae Logic and realized it was very late in sending the updated button state, it also sent a complete state update at every USB host poll. I did a very preliminary modification (stripped out almost everything and increased the poll rate) and was able to get the same 1 ms next-frame response with it configured as a joystick. I'm currently planning to do a replacement 1 ms controller for the HORI RAP that will work on the PS3 as well, using this firmware as base.

So you're touching on a very real issue I think.  Would be really great if you can find the time to do the Teensy test, while also having 3 or 4 other 1ms devices attached to your system.

I should also mention that the Teensy is connected to a USB 3 port. This might also affect performance.