Emulating with original controllers connected by adapter is superior

input lag

>>4119253
wat

>>4119254
Is a meme.

File: IMG_0196.jpg (2MB, 4032x3024px) Image search: [Google]

2MB, 4032x3024px

>>4119253
my usb adapter is better

>>4119261
>Is real
Fixed for you

>>4119273
Nope, a meme. You can't differentiate the difference.
Emulators these days are actually faster than the original systems.

>>4119276

This. Emulators up to and including SNES are perfect now

>>4119276
t. doesn't own real hardware
>inb4 I used to have an n64!

>>4119253
This is just plain objectively false. Not only does it introduce input lag, but on top of that, it means you are forced to use an emulator which introduces more input lag, and then even FURTHER, it means you are likely playing on an LCD, which again, introduces more input lag. It's one thing to say "Playing with this converter on a PC is fine", it's another to say it's superior. CRT + console + flash cart (and the few games the SD2SNES doesn't support) + OEM controller is unbeatable period. I respect your proper conclusion that this works in most cases though for what that's worth.

>>4119287
t. doesn't know what he's talking about

>>4119276
Can you tell me why there are lag optimized drivers for Mame, if emulators having input lag is a myth?

File: 1483562845515.jpg (4KB, 249x147px) Image search: [Google]

4KB, 249x147px

>>4119292
What a faggot

>>4119292
Excellent counter argument

File: cringing.gif (591KB, 480x270px) Image search: [Google]

591KB, 480x270px

>>4119292
>people this retarded exist

>>4119306
>Can you tell me why people do X, if X is a myth?
Have you ever actually met any human beings?

>>4119292
You *do* know that it's literally physically impossible for that non to be incorrect, right..?

File: noice.png (49KB, 1030x941px) Image search: [Google]

49KB, 1030x941px

>>4119273
>>4119286
i play this on both hardware and emulator without any perceivable difference in timing. the game has some moves that take 1/60s timing

>>4119339
If this is actually true (it isn't), you would have experienced differently. Even the best emulator setup (Retroarch with hard G sync with an old video card to output S video to your CRT) introduces multiple frames of lag. You're either a troll or have simply gotten used to the lag that comes with the territory.

File: IMG_20170713_214638.jpg (941KB, 1920x1080px) Image search: [Google]

941KB, 1920x1080px

You don't need the old controllers, modern controllers can do everything they can and more. The only controller you can't emulate is the Wiimote and Nunchuk.

>>4119368
New controllers have shit tier Dpads.

File: IMG_20170713_214621.jpg (820KB, 1920x1080px) Image search: [Google]

820KB, 1920x1080px

>>4119369
The 8bitdo FC-30 says otherwise.

>>4119372
>FC-30
Christ, I really hope this is bait...

I've got an old PSone controller I use for emulating, but thinking about getting a PS4 controller. How's the D-pad?

File: IMG_20170713_214629.jpg (866KB, 1920x1080px) Image search: [Google]

866KB, 1920x1080px

>>4119373
My bad, I meant the FC30 Pro.
I have really shitty lighting in my room.

>>4119376
That really isn't much better...

>>4119381
If I'm emulating 2D games that utilize directional pads, can't I just remap them to my analog stick?

Oh, and has anyone heard of "slapping the blue out of your CRT"? I have to do it constantly.

>>4119385
Trust me, you've never played Fantasy Zone without Analog. What controllers do you reccomend for Retro?

>>4119267
link?

>>4119276
>You can't differentiate the difference
Correct (for most of us)
>Emulators these days are actually faster than the original systems.
Wrong.

I've been using my WiiU Pro controller with an adapter for most of my retro gaming. God tier D-Pad and everything is spaced together nicely. 200+ hour battery life is a plus. I've never used the second gen Saturn pad personally. Are they really that phenomenal? Is the Mayflash USB adapter pretty good?

>>4119276
>you can't tell the difference
depending on the situation I usually can actually you fucking NIGGER
>emulators these days are faster than the original systems
I'm not sure that means they have less lag

File: WAT.jpg (68KB, 541x556px) Image search: [Google]

68KB, 541x556px

>>4119401

>>4119409
Input delay is affected by more than FPS.

>>4119384
>just remap them to my analog stick?
That is well beyond garbage tier...

>>4119413
>changing the goal posts
wew lad

f_ntsc = 60 Hz
t_ntsc = 1/60 s = 0.01667 s = 16.67 ms

f_lcd = 60+ Hz (let's just say 60 Hz)
t_lcd = 1/60 s = 0.01667 s = 16.67 ms

(notice how they are the same?! crazy, i know! that means LCDs can't "introduce lag" unless you are using one from 20 years ago.)

t_ps2 = PS2 controller polling time = 10 ms

(that means new data is available from the USB driver every 10 ms! well under t_ntsc = 16.67 ms!)

>>4119409
(and this guy!)

>>4119425
This post might be the most oblivious one I have ever read. Refresh rate has literally NOTHING to do with input lag. This is actually impressive at how lacking in knowledge the post is.

>>4119429
>>4119429
explain where the magic bits and time disappear to, o knowledgeable one.

>>4119389
http://www.retrousb.com/product_info.php?products_id=29

>>4119429
I forgot to add the latency for my VH236H is 10 ms

>>4119434
Refreshing at 60fps has nothing to do with how long it takes an initial frame to reach the display. You can lag for 10 seconds even and then suddenly give a 60fps stream. You're heavily confusing latency and bandwidth.

>>4119476
see
>>4119448

File: cecc2761b0bd97c06d409b1e76938900a3181a66[1].png (3KB, 483x291px) Image search: [Google]

3KB, 483x291px

Well this thread is a mess but it is true that a modern computer with a gaming lcd monitor can achieve nearly as low a delay as a real SNES on a CRT.

*note the frames in pic related are 240fps so 4:1 60fps SNES frame

>>4119448
Okay so that combined with the lowest latency possible with an emulator (retroarch Gsync) is going to be more than a frame of lag.

Just read this autist's book:
https://byuu.org/articles/latency/

>>4119492
>even the best hardware can't reach console+CRT tier
I think we have our answer here.

>>4119494
isn't that the faggot who wants to suck lucario's toes?

>>4119492
Right, so as I said here
>>4119401

>>4119492
input lag on CRT with SNES is 1 frame. this graph is meaningless

>>4119498
I dunno, but that's not the point either way. He literally made the most accurate SNES emulator in existence from scratch. He knows his shit.

>>4119502
It probably depends on the system. I expect Stella can beat a real 2600 and the lag-reduced versions of MAME when running 80s games. We're getting there, gradually and it's a good thing but I'll still like playing on real consoles even when they can be replicated within an acceptable margin of error - which I consider to be equal to that present in different revisions of the original hardware.

>>4119509
>>4119509
VeriSNES is now more accurate. It passes the Nintendo hardware test rom.

>>4119505
The graph indicates it's actually somewhat less than one 60fps frame, on average of 25 samples. Again, the frames being referenced in the graph are 240fps.

>>4119519
That graph claims 3 frames were lost though..? Am I missing something here?

>>4119520
four frames at 240fps equals one frame at 60fps I'm sorry I don't know how to make that any clearer.

>>4119505
specifically

keeping in mind
>the analog NTSC signal input to the CRT is decoded and drawn within nanoseconds
>snes has digital hardware registers that track of horizontal and vertical position of the raster beam

>PPU displays current settings, CPU is computing next frame
>controller input during frame
>v-blank hits
>controllers are automatically latched and read by hardware shortly after v-blank
>game updates PPU to next frame settings while hardware is reading controllers
>game reads controllers
>v-blank ends
>PPU displays current video settings, CPU computes next frame with new controller input
>v-blank hits
>controllers read, PPU updated
>v-blank ends
>PPU displays first frame to respond to controller input

CRTs don't have latency, and neither does the SNES.

>>4119526
I would agree with you except that the SNES can't output at that refresh rate. Just cus the monitor does, doesn't mean the system does. I understand the concept of the monitor running above 60fps, I just dont' see how that actually impatcts anything.

>>4119253
In theory, maybe. There's a bunch of factors you still have to consider, like the monitor being used, the accuracy and settings of the emulator, and minimizing input lag.

>>4119534
The camera they used to record the output was running at 240fps. I should really just edit that image to display the SNES's delay as 0.9 frames and Retroarch's as 1.15 frames since this always seems to confuse people.

>>4119538
Ah, I get what you're saying now. Thanks for explaining.

>>4119267
I thought it was bad to wrap your controllers like that

>>4119253

>>4119276
>You can't differentiate the difference.
I can absolute assure you i can, adapters differ but compared to hardware they are always noticeably laggier. Go try the psp,ps1 or ps2 emulators and see how you get on.

>>4119538
it is confusing when you are claiming numbers to 0.1 frame precision when at best you have 0.25 precision (60 / 240 frames)

I assume by non-integer precision you also mean that they tried pushing buttons on the controller at different times during the frame and determining when at absolute latest you can push a button during a frame and have it register to be read on that v-blank. Otherwise integer precision makes no sense because you only get feedback from the monitor ... once per frame.

>>4120352
Yes, the fractional frame results are from an average of 25 different tests, it being essentially random at what point within the frame the input occurred. For all intents and purposes both setups offer one frame of delay but over the course of many tests it's demonstrable that the real hardware tends to be very slightly more responsive but at a nearly imperceptible level.

Also, the test was done with a Buffalo USB SNES control pad while I personally prefer to use a real controller with an adapter which may introduce additional lag although even the dedicated USB controller probably also adds some lag due to USB polling that a MAME person will tell you could be further reduced by using the direct input from the ps/2 port.

Also, different emulators with different settings may offer lower processing lag. The software itself on a modern computer is getting to the point of true performance though at least up through 4th gen consoles. 5th gen consoles (and even some games on 4th gen consoles) had real slowdown on actual hardware. I'm not sure if the goal will ultimately be to accurately replicate the real consoles' performance including slowdown or to make the emulators perform "correctly". Probably both chosen on a case by case basis by user preference and even objective performance. I know some NES emulators allow flicker to be eliminated but it actually changes the mechanics of some games. "Developer's intent" is ultimately impossible to determine, even through interviews with the developers who's perspectives may have changed over time.

This is making me want to go post in the HD remaster thread.

>>4119690
Wait . . . what? Is it?

File: FOE1YOOKF4EV2ZD0EO.MEDIUM[1].jpg (61KB, 543x366px) Image search: [Google]

61KB, 543x366px

>>4120404
It's a good way to get your wires twisted inside their sheathing. I usually wind cords like this.

>>4120396
>the fractional frame results are from an average of 25 different tests
i did not consider that. that's a good point.

>>4119267
>meme purple super famicom

File: 1472339563202.png (36KB, 256x224px) Image search: [Google]

36KB, 256x224px

>>4119253

>>4120414
Thanks for the tip bro!

>>4120476
Purple like royalty

>>4119492
I'm the one who produced that graph and the number of frames of input lag is NOT expressed as 240 FPS camera frames, but actual frames rendered by the console/PC. So:

3.6 frames for the SNES => 3.6 * 16.67 = 60 ms input lag on average

4.6 frames for the PC => 4.6 * 16.67 = 77 ms input lag on average

I should note that this test was done on a PAL console. A PAL console will have slower input response due to the longer frame period (20 ms vs 16.67 ms), but otherwise I have seen no information to suggest that input lag expressed as number of frames would differ between the two.

Anyway, while the SNES itself should be capable of next frame latency, what you'll get when playing actual games is another story. I've done my tests on Yoshi's Island and from what I've been able to tell, Yoshi's Island responds to input on the third frame after the console receives the input. The same appears to be true for Super Mario World, while other games, such as Super Metroid, respond on the second frame after receiving input.

Note: ~0.7 frames out of the 3.6/4.6 frames reported above are from scanning out the image to the display until reaching Yoshi in the bottom half of the screen. If you count average input lag as scanning to the middle of the screen, you can subtract ~0.2 frames from the figures above.

Before actually measuring the input lag of the SNES on a CRT, my hypothesis was that I would get 3.2 frames on average for my Yoshi's Island test case. The result was actually slightly worse, at 3.6 frames. My current hypothesis is that the extra delay comes from the controller itself, perhaps due to some internal processing/filtering (such as button debouncing).

I don't know why so many people seem to assume that the SNES has next frame latency. I've seen some truly comically clueless people on these boards expressing this belief as fact. I would suggest to those people to spend more time on producing some actual data and less on spreading misinformation.

>>4121089
I hooked a snes up via rf to an lcd and via s video to a crt at the same time. Turned it on and played off both screens. The lag on LCDs must exceed ~20ms. I could jump and mario on the crt was at like the peak of his jump as lcd mario was leaving ground.

>>4121089
I imagine the lag in Yoshis island is caused by the Super FX chip as it sits between the console and the rom.

>>4121140
>The lag on LCDs must exceed ~20ms.
Not all LCD displays are the same. Some shitty TVs have input lag of >100ms, while some monitors are <10ms.
https://displaylag.com/display-database/

>>4119276
>Nope, a meme. You can't differentiate the difference.
Is this the new "Human eyes can't see above 24 FPS"?

File: snes_pinout-1.png (12KB, 280x148px) Image search: [Google]

12KB, 280x148px

>>4121089
I appreciate doing an experiment, but your conclusions are wrong.

All SNES games have the same input lag. The controller is a shift register that gets latched by the hardware at the start of v-blank and serially read out. The data becomes available to the CPU shortly after the start of v-blank, and is read by the game's NMI handler, or shortly after the game has returned from NMI. There is no buffering in hardware besides the register the CPU reads.

The NES had a standard shift register as the only IC; no debouncing circuit (http://www.ti.com/lit/ds/symlink/cd4021b-q1.pdf). The SNES seems to have a custom IC, but I would wager it follows the same design as the NES.

The schematic of the SNES says the there is one frame lag. From the controller, to the hardware that reads it, to the time when the CPU has access to it, to the earliest a frame could be drawn in response to it. Games could buffer input, but there is no reason to save anything besides the last frame's input just for edge detection (yes half button presses are real).

>>4121146
The cart does not sit between the controllers and the console. Controllers are read automatically by hardware. The CPU program running in RAM (because ROM is being used by the SuperFX in all commercial configurations) runs the NMI routine and has access to controller input as fast as any other game.

>>4120414
How do you do this

>>4119261

You must think oxygen is a meme, too.

File: widowmaker.png (7KB, 480x640px) Image search: [Google]

7KB, 480x640px

>>4121450

>>4121439
I know that the hardware reads the input every frame. Whether the game reacts to that input on the next frame or not is up to the game. There's no way to draw the "wrong" conclusion from my test. I have soldered an LED to the B button of an original controller, connected the console to an old Panasonic CRT and recorded both at 240 FPS. Whether you believe there "should be" next frame latency is irrelevant, because that's not what happens in reality. You're of course free to explain/prove what's wrong with the test methodology, but if what you wrote is all you have, you're just another talker trying to validate your own preconceptions. How utterly tiresome.

>>4121513
>Whether the game reacts to that input on the next frame or not is up to the game
This is precisely what's wrong with the methodology. The input lag is from when you press the controller to when the CPU has that data available to it. What the game does after that can't be called input lag because it's up to the software to decide.

>>4121570
to be clear, the input lag you are trying to measure is a property of the hardware, not of specific software.

>>4121513
also, you have not posted your methodology in this thread, so I cannot poke holes in your experiment.

For instance, the LED leads connected to your controller could introduce parasitic inductance into the circuit that cause it to light up more slowly than you might think because the current flow that lights the LED must first work against the extra inductance.

Also, the description of how you compute the delay is unclear.

>>4121570
Ahh, so you just have a different definition of input lag. What people usually mean when referring to input lag is the amount of time it takes from applying input to getting a visible reaction. I thought it was obvious that that was what I wanted to test. It's already common knowledge that the SNES reads input from the controller every frame, so I don't understand why you thought that's what I wanted to measure.

Anyway, it's good that we cleared that up so we can put an end to this pointless discussion.

>>4119261
>>4119276
https://retropie.org.uk/forum/topic/2019/an-input-lag-investigation
83-157ms of lag (SNES) before factoring in LCD latency. Emulation is great, but don't be obtuse.

>>4121089
>3.6 frames
>-0.5 average from press till vblank
>-2.0 game does nothing
>-0.2 scanning to the middle of the screen
>=0.9
That's pretty close to next frame latency. Granted your data does indicate it's less than 1 frame average but it's a small sample size and has a large margin of error.

File: giphy.gif (592KB, 400x300px) Image search: [Google]

592KB, 400x300px

>>4119253