trap15 wrote:That's not how lag works. Lag is the time between when you input something and the time your action's results appear on screen. Emulation will almost invariably (as I said, there are hacks around it) add 1 frame to the base lag of the system being run on. Combining your system's lag (OS overhead and such) and monitor lag, and the game lag and the emulation lag is certainly noticeable to those who really need to notice (superplayers and some others), since you'll almost always get at least 2 extra frames from all that overhead on a normal modern PC running a normal OS. This is usually subconsciously noticeable to those sensitive to timing. Generally one can adapt without much problem, but when you start getting really high amounts of lag, it becomes very consciously noticeable.
You really need to try GroovyMame+CRT_Emudrivers on a proper CRT, I swear you wouldn't be able to tell the difference. I have the pcb's of R-Type, Shinobi and Daimakaimura and I can 1-life all of them ( http://www.youtube.com/user/exmosquito ) I can perform the same on Groovymame EXACTLY the same with no noticeable input lagg. If I walked out of the room and you swapped the pcb for Groovymame I couldn't tell. In contrast, playing generic Mame on my laptop with a USB pad the lagg is noticeably HUGE in comparison. Groovymame+CRT_Emudriver on an arcade CRT is a totally different beast from the Mame that I was used to before.
Your run on Ghouls & Ghosts was epic, that game probably took a few years off my life with how infuriating it sometimes was. When you died at the final boss I felt your pain, damn those freaking lasers!
Heh thanks man Yeah that was a pretty decent run. I never should have lost that life, though. I was so annoyed, I can usually do him easily. I should have been positioned slightly off centre so that the laser misses me but unfortunately I was to central and I got hit ;/ I didn't take a hit on my 2nd try!
trap15 wrote:That's not how lag works. Lag is the time between when you input something and the time your action's results appear on screen. Emulation will almost invariably (as I said, there are hacks around it) add 1 frame to the base lag of the system being run on. Combining your system's lag (OS overhead and such) and monitor lag, and the game lag and the emulation lag is certainly noticeable to those who really need to notice (superplayers and some others), since you'll almost always get at least 2 extra frames from all that overhead on a normal modern PC running a normal OS. This is usually subconsciously noticeable to those sensitive to timing. Generally one can adapt without much problem, but when you start getting really high amounts of lag, it becomes very consciously noticeable.
You really need to try GroovyMame+CRT_Emudrivers on a proper CRT, I swear you wouldn't be able to tell the difference. I have the pcb's of R-Type, Shinobi and Daimakaimura and I can 1-life all of them ( http://www.youtube.com/user/exmosquito ) I can perform the same on Groovymame EXACTLY the same with no noticeable input lagg. If I walked out of the room and you swapped the pcb for Groovymame I couldn't tell. In contrast, playing generic Mame on my laptop with a USB pad the lagg is noticeably HUGE in comparison. Groovymame+CRT_Emudriver on an arcade CRT is a totally different beast from the Mame that I was used to before.
Do you use an i-PAC? if so a PS/2 version or USB...or is there no difference for lag?
I use a Jpac. I ordered a USB version but when it arrived it was a PS2 version with a PS2 -> USB converter. I don't think they do the dedicated USB ones anymore. Works great.
Calamity, the co-creator of GroovyMame has done testing on the input lag of GroovyMame and would appear to produce 1 frame of lag!!!. taken from BYOAC forums....
First of all, by watching the videos done by papasi, I notice he is counting one frame less than I count (I'm referring to his videos). He says that SSFII Turbo, when played on the supergun, lags 4 frames natively, then I count them on his video and I get 5 frames. I'm guessing it must be due to the counting method: I start to count when the red led turns off, that frame is #1, then 2, 3, 4, and on #5 the character starts moving. Please correct me if you think I'm wrong.
The number of frames on my test videos has been counted following this rule, using Media Player Classic, CTRL+Right to advance frame by frame.
One difference is that I'm recording at 120 fps while papasi recorded his videos at 60 fps. So to get the number of frames on my videos you need to divide by too. I take 5 values and get the average.
The other difference is that the led in papasi's system is directly wired to the button, so in theory it's lag-less, but in my tests I'm using the keyboard leds, mapping the button to the caps-lock key in MAME (as suggested by DaRayu in MAME World). The problem with my setup is that, according to the old-school knowledge, it's the bios the one that turns these leds on/off, so the keypress signal must travel from the keyboard to the computer, be processed by the bios, then travel back to the keyboard where the led is finally lit. Obviously, this involves time, and judging by the slow motion video I took it takes at least 1 full frame of extra lag (5 frames at 240 fps). This means the led turns on/off one frame late, so you need to add 1 frame to the results from my videos.
So, due to this, my setup is suboptimal for this kind of tests. I really need to figure out how to wire a led to the buttons without short-circuiting my jpac, then I'll be able to get more accurate results.
The system that I used:
Pentium 4 3.0 GHz
Windows XP-64
ATI HD 4350
Catalyst 9.3 (CRT Emudriver)
The huge lag of d3d_vsync (4 frames) confirms DaRayu results and what we've been discussing here about the flip queue. This will need to be tested in W7 too, with newer versions of the drivers. So the only reasonable way of using d3d is by enabling the -frame_delay option: it removes 3 frames of lag, although, ironically, not because of the reason it was conceived for.
So, if these tests are right, we would have 1 frame of lag (as compared to the real hardware) for the properly working vsync cases (d3d_framedelay, ddraw_vsync, ddraw_framedelay). The frame_delay option doesn't seem to be making any fundamental difference here, although probably more accurate tests will be required to confirm this.
I believe the non-vsynced modes just show less lag because the changes are shown immediately without waiting for a full frame to be displayed. This is a little difficult to judge because the videos are not vsynced with the screen, so you get tearing either way."
Fudoh wrote:what's the purpose of the -frame_delay option ?
Does anybody remember the neogaf discussions about using triple buffering INSTEAD of v-sync for the same results be with heavily reduced lag ?
Per Calamity:
"- New option -frame_delay. Delays the start of the emulation of each frame by an amount of time defined in tenths of the frame period length (0-9), in order to give a chance to the emulator to have the most possible updated input for that frame, as an attempt to minimize input lag. A value of 0 corresponds to standard behaviour. This option is experimental, and is known to produce tearing in LCD screens."
Yeah that was a pretty decent run. I never should have lost that life, though. I was so annoyed, I can usually do him easily. I should have been positioned slightly off centre so that the laser misses me but unfortunately I was to central and I got hit ;/ I didn't take a hit on my 2nd try! 
