/vr/ - Retro Games

-a-a-a-a-ag.

>>8306489
that's not even important. RetroArch itself has run ahead feature that allows you not only to remove all emulator input lag, but even game's own internal lag. emulator input lag has been solved. the people who say it's still an issue are either clueless, coping hard that emulator players won, or like audiophiles who claim they can hear the difference between $10 and $200 AUX cable.

>>8306553
this

>>8306489
>emufags have high cope

Though I'm very satisfied with emulation, I must say that only systems up to 4th gen (and some exceptions) are really spot-on. Newer systems, though many of them good, still need adjustments, some small and passable, others big and noticeable.

>>8306553
>run ahead feature that allows you not only to remove all emulator input lag
Does that actually have anything to do with the emulator itself adding input lag? The explanations I've read say that it only works to remove unused frames that the original hardware had, but doesn't have anything to do with an emulator itself adding input lag which is a separate issue.

>>8306553
Runahead is only one tool. There are others. Just configuring your emus computer properly and making sure your GPU doesn't do unnecessary shit with the program will solve most input lag, pic related for instance, but that's too much to ask for computer illiterate console warriors who throw a fit if it's not as easy as "push the big button called POWER"

I have a CRT next to my computer. By comparing with the same NES game back to back, at first the input lag was a bit noticeable. After configuring everything properly there was barely any difference.

can we see it compared to the actual SNES hardware

>>8306489
HE

>>8306553
While I don’t emulate anything and I don’t like emulation at all this post is 100% correct.

>>8307085
The same is strong with this fag

>>8306553
>>8306587
>>8306738
>>8306740
>>8306970
Emulation (even without runahead) is lower input lag than hardware on a CRT in every case I've tested so far up to and including sixth gen. People don't realize that even something like a NES hooked up to a CRT TV has like 30-60ms of input lag

>>8306740
PSX, N64, and Saturn all have extremely great, accurate, low input latency emulation with support for run-ahead.

>>8306523
FPBP

>>8307238
>He believes CRTs have 4 frames of lag
Why are zooms like this

>>8307339
Have you actually tested it yourself? You do realize that NES controllers only poll at 60Hz? You do realize that CRTs still have to draw the frame which takes about 7-8ms for the middle of the screen? You do realize that NES games have 1-2 and sometimes more frames of input lag inherently?

Also, 30-60ms (depending on game and variance) is not four frames of lag retard lol.

>>8307339
consoles do

>>8306489
Just curious if the controller is being used wired or wireless?

>>8307421
why do you ask

>>8307238
>PSX, N64, and Saturn all have extremely great, accurate, low input latency emulation with support for run-ahead.

Yes. Those are getting there, but they need a decent PC if you don't want to rely on inaccurate options. And, if you want run-ahead, make it double - the load will get heavy. If we are to include 6th gen, there's more trouble as well, though Dreamcast and Gamecube are pretty decent. Anyway, what I want to say is: beyond 4th gen, emulation gets less "trivial".

>>8307474
Stop being a poorfag trying to emulate on a toaster or your phone.

>>8306553
>emulators have TOO LITTLE input lag now

>>8307463
I was wondering if there was a noticeable difference in latency when using wired or wireless.

Do some of you really can notice some millisecond lag in emulated games?

>>8306553
This also works great for android devices so you can adjust any lag that bluetooth may have.

>>8307402

> Have you actually tested it yourself?
yes, homebrew is a thing.

> You do realize that NES controllers only poll at 60Hz?
false, you can read the controller registers nearly anytime, including during HBLANK, VBLANK and whatnot.
source: https://wiki.nesdev.org/w/index.php?title=Controller_reading_code

fancy example: SMB3 has to read the controller twice in a row (as quickly as possible) to fetch a single valid input due to a hardware glitch (both reads must match, if not its ignored), -> https://forums.nesdev.org/viewtopic.php?p=151720#p151720


> You do realize that CRTs still have to draw the frame which takes about 7-8ms for the middle of the screen?
you are kinda correct on this, but the "older than sliced bread" method to draw things on screen involves doing raster effects on HBLANK and whatnot. you actually have enough cpu time to do some scraps of game logic and read the controller during those. you actually can read the controller register status on the horizontal line exactly BEFORE what the controller input will alter. (just to be pedantic about latency?)

> You do realize that NES games have 1-2 and sometimes more frames of input lag inherently?
only if the developer (for some really weird reason) decided to make a buffer that stores commands in a delayed/detached manner from the game logic

the nes ppu (and a lot of old hardware) runs what we call "realtime code", things that you dont have the option to postpone at all. (cant happen before or after the fact, timing is critical)

the image has to be recreated everytime it is shown on screen, there is no frame buffer to fully store the previous presented frame.

but you have "developer intended delays" on modern 3d hardware that operates with command batches and whatnot. (1-3 frames, 0 is very inefficient for performance)

>>8307535
Never! Give me your money, buypig!

>>8307715
Show your slow-motion button-to-pixel tests of an NES hooked up to a CRT as dozens of people have tested it and found 30-60ms to be the results.

I'm not reading any of that shit because you're just flat-out wrong. The tested results prove that you are wrong so what you are saying is just complete drivel.

To me the eye opener was when I tested run ahead with games that had input lag natively in original hardware. Can't remember on top of my head the exact numbers, but Final Fight 2 had like 5 frames and Mortal Kombat 2 (SNES) had like 11. The difference in response was insane.

>>8307238
What N64 emulator has run-ahead? Couldn't make it to work with the mupen core in retroarch. If I can remove Snowboard Kid's native input lag I'm set for life.

>>8307761
MK2 on SNES is reasonably responsive. You're thinking of MK1 on SNES.

Guess what just works perfectly?
My SNES on a CRT

I love how I don't have to load autistic cores and mount the damn game files and set the refresh rate to the screen every single time. I also love that I don't have to rely on anonymous help from image boards whenever something obscure goes wrong. Fuck Retroarch.

>>8307769
Most likely, yeah. All I remember is that it had more input lag than the max run ahead option, so I couldn't remove it all. Still, it was way snappier.

>>8307715
https://www.youtube.com/watch?v=1MCfVV0mvPw 50ms
https://www.youtube.com/watch?v=_qys9sdzJKI 37ms
https://www.reddit.com/r/classicmods/comments/amskfj/input_lag_test_original_snes_classic_and/ 50ms
https://www.youtube.com/watch?v=G8ZggJjzQ1Y 58ms (SNES)
https://www.youtube.com/watch?v=EvZkty_FQHA 41ms (SNES)

All done on original hardware on a CRT. Mind you these are almost all done on games with low intrinsic input lag. Games like Mickey Mouse, Ghosts N Goblins, Castlevania, TMNT, and many more that have higher intrinsic input lag (in some cases way higher) for all actions in-game.

Ok now please, post your tests bending the laws of physics to your will

yes, input lag is no longer an issue with the right setup

>>8306553
>game's own internal lag
that's not lag

>>8307838
Functionally it is exactly the same. There is no difference between lag from something like buffered frames of V-Sync and delay to all actions in a game. To be honest, I doubt the vast majority of it is even intentional from the devs. I'm talking about when the character does literally nothing whatsoever for a set amount of frames, not talking about delay in terms of startup animations

>>8307238
>all that poorfag zoomer cope
kek

>>8307402
>all that copesplaning
yikes

>>8307751
>dozens of stupid people who can't into science have done things wrong
Only dozens?

>>8307817
>a game is a console
>post your tests bending the laws of physics to your will
Proving there were way more than just dozens of dumb kids who can't into science.

>>8307556
I like your pic's big boobs, FYI. Sauce, please?

>>8308478
cope

>>8307421
seconding

>>8308478
>>a game is a console
>>post your tests bending the laws of physics to your will
>Proving there were way more than just dozens of dumb kids who can't into science.
Wow, you sure deboonked his physical evidence there, genius.

>>8308543
>n-n-no u

>>8308575
I sure did debunk (His) physical evidence there, kiddo. You're just too stupid to understand. The poorfag cope has clouded your so called mind.

>>8306489
how do we have 2 threads, specifically, complaining about the first jump of DKC? Could you at least kill a Kremling before you start crying? Throw a barrel. Why trap DK inches away from his missing hoard? How can you enjoy a video game without allowing the ape you've created to live a little? Fuck off!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

>>8308904
why are you quoting yourself

>>8308904
You literally don't even understand what input lag is or why it's relevant lol

The video in OP is button-to-pixel full chain input lag. That button-to-pixel full chain input lag is lower than original hardware even without run-ahead, and with run-ahead it just smokes it

>>8306553
>the people who say it's still an issue are either clueless
No, they're actual gamers. Take a look at ST. Any player worth a shit would accept your emulation over what they grew up on and are use to.
>coping hard that emulator players won
HAHAHAHA. Talk about delusional.

>>8306489
it's often not the emulation but the controller itself

>>8308936
Now this is cope

>>8308945
>Emulation is better
How do you play Wariorware twisted on your PC? Does your keyboard have a rumble pack and your monitor gyro?

>>8308959
doesn't the DS4 allow you to do that?

>>8308968
DS4 can do a lot of things but one thing it cannot is outshine the originals.

>>8308976
original what anon

>>8309006
Using a ds4 analog stick to copy rotary sticks is not the same experience.

>>8309012
what does a rotary analog stick have anything to do with gyro controls

>>8306553
>removes lag
So it makes it a fake experience to the original. Good to know.

>>8309012
>Playing with rotary sticks and not the 8 way modded arcade release
Pleb

>>8309025
>Modded arcade release
Not sure what you're talking about but excuse me for playing an arcade game at my local corner store as a kid.

>>8308976
>>8309012
>responding with something completely unrelated to what you're replying to
Nice autism, anon

>>8309041
We're not discussing emulation being a piss poor substitute? Of course you could set a roller coaster up to your PC if you wanted to but when you speak on PC emulation generally the idea is regular PC set ups with keyboard, mouse and a regular monitor.

>>8309046
>more schizo nonsense
Okay

>>8309052
>more schizo nonsense
Hey I'm not the one claiming the originals are WORSE than PC emulation.

>>8309058
what are you fucking talking about dude
regardless of you nonsense argument that has nothing to do with anything, you can literally use any type of control scheme you want with an arcade stick

>>8309060
>What are you talking about
>that emulator players won
Replying to this. Theres so many examples of emulation not being able to stack up.

>>8309065
>pic not related and still nothing to do with fucking anything

>>8309065
Take your meds

>>8309065
Anon was taking about WW Twisted, and stated that the DS4 has both rumble and gyro. You respond to this by completely avoiding the point and going off on a tangent about utter nonsense

>>8306553
How does Retroarch avoid input lag?

>>8309082
It's programmed with built-in time travel code

>>8309080
The thing is you've never played the original nor has anyone else in this thread yet you feel the need to claim emulation is superior. It's utterly ridiculous. You have no clue. You could reply with a post of your GBA with wariorware, it wasn't a rare game so it's easy enough to do.

>>8309089
he's still going on his tangent

>input lag
I don't care. Thats some pussy nigger shit caring about that. Just play your games you God damn didgeridoo players.

>>8309106
How are you going to tell us which is best when you only ever tried one? Ignore this as it crushes your entire argument.

>>8309115
the fuck are you talking about, I literally just said you can emulate gyro and rumble with a DS4
in response to you saying how can you play wario ware twisted

>>8307605
>>8307421
wireless is faster.
no, really, it's true.

>>8309127
>not soulfully dangling a cord between your legs
Faggot

>>8309121
>I literally just said you can emulate gyro and rumble with a DS4
Of course you can find alternatives, everyone knows this. My original point was it doesn't compare to the original.

>>8309127
>light is faster than electricity
thanks for stating the obvious
the problem is more the polling rate than the speed of the signal though

>>8309134
>How do you play Wariorware twisted on your PC? Does your keyboard have a rumble pack and your monitor gyro?
>doesn't the DS4 allow you to do that?

>>8309127
You are a faggot lol

>>8309135
meant for >>8309132

>>8308913
This user is underage

>>8308917
I understand exactly what it is, my little zoom zoom. All you do is parrot poorfag zoomer talking points and pretend you can into science. Thank god for tidepods.

>>8306489
If that's on an LCD screen virtually all of that lag is the display itself.

input lag is audiophile tier nonesense, unless you use something that actually respondes a second later it doesn't matter in the slightest

>>8309201
Based

ITT:SEETHING ZOOMIES B.T.F.O!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
SSSSSNNNNNNNNNNNNNEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDSNEEDSNEEDSNEED
Trannyniggerjannieeessss sneeedddd

input lag is only an issue if its above ~130ms and/or if its variable variable input lag is unsalvageable
outside of that, its generally something you can just get used to by playing for a couple minutes. and at this point, can almost entirely be mitigated by just setting your emu up properly

that said, the last time i experienced unplayable input lag in emulation was me trying to get superfx-chip games to run in ZSNES like 10yrs ago, so idk how its even part of the discussion anymore
if youre playing /vr/ like actual pre-2k games, unplayable input lag hasnt been part of the discussion for years now

>>8306740
depends heavily on the system youre emulating, what software youre running, how that software is set up, and what hardware youre using to run it all is
for ex: i was emulating PS, with upscaled gfx, like 20yrs ago with bleem
saturn emulation is STILL spotty tho

>>8309019
2010: "oh no no I can't play it. i can feel it has exactly 20ms input lag. i can't play FF6 like this, it ruins the whole experience"
2021: "hold on, where's the input lag?? i can feel it runs 5ms ahead. i can't play it like this. there should be a DELAY like on REAL hardware. how can you enjoy the game when you press a button and the character acts immediately? that's not what the devs intended, the game was made deliberately to account for delay of SNES controller and your CRT TV. so i see emulation still sucks, can't even play Earthbound"

>>8309127
On console yeah. 1000Hz wired is faster than wireless though

>>8309169
So you just confirm that you don't know then..

I guess you are thinking about system processing latency and you're still not understanding even the fundamentals of input lag. Say you have a very simple game has an enemy that can throw a punch and you should deflect the instant you see the enemy throw the punch. Now let's say you're playing on a mediocre HDTV measured at having 50ms of display lag. It doesn't matter that the system and game has processed your deflect 50ms before the deflect shows up on your TV screen, because the punch also showed up 50ms after it was processed for you to be able react to it. It's six of one and a half dozen of the other.

It's like you completely fail to understand that a visual and reactive human being is playing this game, thus why input lag is important, because it directly affects how we interface with the game. This is a button-to-pixel input lag test measures exactly that, the entire chain from pressing the button to the action on screen. When compared to original hardware on a CRT, properly setup emulation will always have lower input lag, even on an LCD monitor or HDTV.

>>8309041
they dont make them how they used to

>>8309171
Absolute retard tier response. Please educate yourself because coming in here to spew absolutely pants-on-head retarded drivel.

>>8309465
>it's like you think lag is what lag actually is and not some contrived definition make up by coping poorfags
It's not like that, it's exactly that. Making your wall of text cope higher isn't going to convince me otherwise. It's just going to make me laugh harder. You're like a flat earther trying to convert a rocket scientist. So stupid it's not even annoying, just pathetically funny.

>>8309580
input lag is different from processing latency, the latter of which no one is discussion at all here. You're just retarded and refuse to admit you're wrong, it's ok.

>>8309608
I take it you learned that in a youtube last week and now think you know something no one else does. You realize every time you project your inadequacies it just shows how ignorant an insecure you are, right? Not everyone is as young and dumb as you.

>>8309148
You still don't seem to understand a DS4 doesn't spin your entire monitor around.

>>8306489
nice motion blur.

>>8309736
You thought original hardware had lower input lag than it actually does and got blown the fuck out. It's ok. You acted all cocky, got put in your place with a half dozen actual tests, and are now just spewing buzzwords like a retard.

>>8310612
The CRT image is blurrier, has more bloom, and has a trail almost twice as long as the others lol. Also not shown: the constant low refresh-rate flicker that can gives you eye strain and a headache.

You only see the motion blur because it's filmed at 240fps. It's imperceptible to me in motion outside of extremely fast scenes and specifically looking for it.

Of course an OLED will solve all of that, and just completely blows a CRT out of the water.

>>8309065
Pic not related? All three Boktai games are easily playable on emulator.

>>8310648
>Of course an OLED will solve all of that, and just completely blows a CRT out of the water.
One day OLED will actually be viable, I've been hearing this for 12 years and it still hasn't come true. Also I had one of the earliest AMOLED products, the Cowon S9 and I still don't give a shit about OLED. CRT is superior.

>>8310745
Modern OLEDs are already great, I just don't want to downgrade to a lower refresh rate.

>>8308959
This is basically one of the few cases where emulating on a phone is more than appropriate, if not ideal

>>8309276
>that's not what the devs intended,
This is the only thing that matters.

Also I swear all of you faggots on both side of the argument spend more time bitching about shit that barely makes a difference instead of just playing games.

>>8310781
The devs don't even have any idea how much input lag is in their game. The only thing you could argue is not intended is run-ahead as you could say that the devs "intentionally" included that input lag, which is pretty damn unlikely considering basically every NES, SNES, Genesis, etc. game has at least one frame of input lag built into the game (which you can test in frame advance)

>>8310789
>game programmed to process inputs then process the result to be displayed on the next video frame has input lag
I hate you faggots like you wouldn't believe.

>>8310642
>lose argument
>y-y-you used buzzwords
Which of those buzzwords made you lose kiddo?

There are IBM researchers RIGHT NOW playing on an NES emulator written for quantum computers that has inverted input lag. That is the game responds to your button press before you've made it.

>>8311394
already in retroarch. imagine being a a little pussy and following the guides instead of trying cranking up run ahead to 6.

>>8311010
>game programmed to process inputs then process the result to be displayed on the next video frame has input lag
Ok, the game runs at 2fps, now what. Ok, a display can draw the entire frame in 4ms, now what.Maybe you understand why it's fucking stupid to measure input lag in frames?

No native console on any CRT is getting next frame response time. Only a PC can do that.

>>8311692
>No native console on any CRT is getting next frame response time. Only a PC can do that.
Not the anon you're copesplaining to but those claims are total bullshit. It's possible for a console to have next frame to even same frame response. On a 2600 you generally read the stick input during the vertical blank and spend the rest of the time drawing the screen based on that. So yeah, one of the most basic consoles ever made can do what you think is impossible for anything but a PC. I'm afraid you've been lied to kiddo.

>>8306489
Source on the video? Also out of curiosity, what controller is being used?

>>8309082
Run-ahead and Automatic Frame Delay.

Run-ahead pre-processes the game by trying to predict input. If the prediction is correct, input lag can go lower than original hardware. To simplify greatly, imagine yourself pressing right on the controller. The emulator predicts that 18 milliseconds later you will still be pressing right and processes the next frame accordingly; then it compares what you actually press to the prediction, and if the two match, bam, the emulator seems to have almost-zero input lag. If the prediction is false, then run-ahead data is discarded. This requires much more processing power because there are several instances of the game running at all times, swapping savestates on the fly, but it's nothing for modern hardware.

Automatic Frame Delay waits until the last possible moment to do process the next frame, picking up more input from the controller (if there is any) while it waits, thus also having less input lag than original hardware. Games run in discreet ticks between which nothing happens in the game world, so the later you process the frame, the more input you're able to collect before you process it.

>>8312106
The source is the video I just recorded and edited.

The controller is literally in the video.

>>8312104
Yes, I've never seen it tested button-to-pixel, but that is where the term racing the beam comes from, so I imagine it's possible, but I would still like to see actual testing.

However, NES and everything onwards is never next-frame response though, and that's been confirmed many times over through many tests from various people. Consoles will never see next-frame response ever, it's just the sad truth. Even something like Melee with an autistic community who bitches about placebo input lag caused the earth's magnetic field has over 50ms input lag button-to-pixel on a CRT. Most people unironically have the false assumption that CRT = the screen responds the instant you press the button and that only "bad" displays or controllers would actually be above 0ms input lag.

>>8312143
Run ahead doesn’t predict input, your understanding of how it works is completely wrong.

>>8307238
Outside of cases where the game code is fucked up. NES, SNES, Master system, GENESIS and all similar consoles should have a total maximum input lag of 2 frames (33ms). These machines do not have a frame buffer, so unless the game code is written in a fucked up way there is just nowhere for lag to exist.

>>8312636
You'd think after realizing your broad general claims were wrong you'd stop making them. but no suck luck. Any system that allows you to change data the video processor is going to use for the current frame can do same frame response. That includes the NES. That's just the happy truth. The sad truth is that sad fucks don't want to accept that. So, as frequently happens when people want to believe false, scientifically disprovable things, they try to redefine words. Lag no longer means lag. It means "button-to-pixel" response. And straw men believe straw things. Armed with this cope, dozens of dumb children use their mommys iphones to take videos of mario jumping and PROVE that consoles have massive lag. Unfortunately none of them can understand how side splittingly hilarious this is to anyone who has a little common sense. You don't even have to understand the science to understand this. You just have to not be a dumb angry poorfag who's trying to prove the grapes are sour.

>>8313386
Button-to-pixel is what actually matters to the player. Again, because it is a visual game and they are reacting to everything on screen, that is how they interact with the game.

For an extreme example, imagine a game is processing everything in real-time and running internally at 60fps, however it's only outputting at 10fps. While the game may process your input extremely fast, it doesn't matter because a human is playing the game who had to react to something in the first place to produce that input. So when your game has 50ms of button-to-pixel input lag, the player is 50ms delayed in his reaction because the game he is reacting to was 50ms delayed in its visual output.

It's like you still fundamentally don't understand what input lag is lmao. Either that or you realized you were wrong, got btfo, and now are just spewing buzzwords and drivel trying to damage control.

NES games do not have next frame response on native hardware with CRT. Saying "b-but the game reacted, it just didn't show it until 50ms later!!" is just hard cope. You've seen the input lag tests comparing the native hardware on CRT in the same method as the emulator is tested in OP. You knew that's what this thread was about. You knew what input lag was. You were just wrong, get over it dumbfuck

>>8312892
Many of the games have input lag intrinsic to the game, and sometimes this can also vary wildly.

Look at something like Mortal Kombat or Star Fox on SNES

>>8314152
Button-to-pixel only matters to coping poorfags trying to justify emulation. It has nothing to do with the limitations or performance of the system. It's a variable, dependent on arbitrary decisions made by game developers. No one, in the entire history of gaming, ever conflated this with actual lag until one angry little emufag realized he could spin it as cope.
Your problem is that I understand exactly what lag is and you don't have a clue. You're only parroting cope you've been told. I absolutely did know this thread was about cope. That's why I came here with my stark fist of reality.
Riddle me this. If I make a NES game that polls the controller during screen draw and if a button is pressed updates the PPU what will you see? You'll see same frame updates. Tricks like split screen scrolling wouldn't work if this were impossible.
Now riddle me this. If I make an NES that doesn't act on any button press doesn't this make the button-to-pixel lag of your emulator infinite? According to your own rules it does. Look how quickly your cope falls apart when subjected to the slightest bit of common sense.

>>8310703
>easily playable
Yeah with cheats, robbing you of the original experience.

>>8309065
Grasping at straws

>>8314734
You know what else robbed you of the original experience?
Living in England

>>8314712
>Button-to-pixel only matters to coping poorfags trying to justify emulation.
Button-to-pixel has been a thing for many years to quantify the actual real-world application of input lag from the beginning to the end of the chain. It is relevant in everything from retro consoles to modern competitive titles to emulation. The chain is much, much more complicated than you oversimplify it to be, with minor changes or development decisions/constraints that could (usually unintentionally or unknowingly) result in significant amounts of input lag. Retards like you are why people think that the "default" input lag is literally zero ms and that the instant you press any button, it shows up on the next frame of the game, and that any deviation from this must be the result of a shitty display (or "not using a CRT"). Some games have as low as <10ms of input lag while others can have 200ms+ even in the most ideal scenario, so it's important to have some consistent way to measure this in a way that is relevant to the actual player, and to try to understand what controllable factors can increase or decrease this input lag.

>It's a variable, dependent on arbitrary decisions made by game developers.
Lol, you are one stupid motherfucker if you think a developer knows the exact delay of an entire complex chain from input to output. The developers oftentimes have no idea how much input lag is even in their games, and it's rarely intentional. Mind you, this is not how long the frames of animation are, or an animation delay, it's literally how long your player character just sits there doing absolutely nothing whatsoever before the pixels finally begin to move in some way to respond to the input. It can also vary wildly in some games for the exact same action when repeated, even in fighting games.

>>8314712
It's actually quite insane how little information you can find about this. I am testing dozens and dozens of console games and consistently every single game has waaay more input lag, usually about 2-6x or more, on console than on PC. But you cannot find these measurements basically anywhere. The few games people actually test are a select few fighting games or esports titles and basically nothing else. Or the few tests that are done or not done with optimal conditions that are optimal or reproducible.

The input lag varies across systems, across versions, across ports, across emulation, etc. There are soooo many factors.
>the same game on console will have anywhere from 2-6x as much input lag as the same game on PC (almost universally, never found a game where this wasn't the case).
>different video or game settings can change input lag substantially, even unexpected settings, e.g. the "official" Steam Config in Catherine nearly doubles the input lag over making a manual Steam config with buttons mapped to keys. Putting borderless instead of full-screen in certain games (such as Souls games) can reduce input lag by 40-50ms. Using a different video driver can affect input lag. Increasing frame-rate of the engine can affect input lag, but this varies significantly by game, with some seeing little benefit while other games require very high fps for low input lag
>using RTSS to limit the framerate and smooth the frame timing can in some cases either significantly reduce or significantly increase the input lag
>GPU utilization affects input lag substantially, especially at 98-100%
>graphical settings/effects can influence input lag, usually not significant but is in some games
>different versions/consoles/ports/engines have different input lag
>exact same emulation setup on a PC will have way less (in some cases like 100ms+) input lag than a retropie or some chinese handheld.
>different emulators/cores have different input lag even with the same setup

>>8314712
You are vastly oversimplifying with your rudimentary understanding of the tech. While I don't understand every aspect of the tech, what I CAN DO is not completely ignore reality like a fucking retard and act like the real-world results that actually reflect reality and affect how the players plays the game is irrelevant, and that my technobabble understanding of on-paper theoreticals is what really matters. LMAO. You're just a fucking idiot man; when you see real world results that conflict what you think to be true, you find WHY that is the case, you don't just dismiss them and try to warp reality to fit your pea-brain understanding of the tech.

>Riddle me this. If I make a NES game that polls the controller during screen draw and if a button is pressed updates the PPU what will you see? You'll see same frame updates. Tricks like split screen scrolling wouldn't work if this were impossible.
Except this is not true you absolute moron. Show me a SINGLE, just one, NES game that actually updates on the very next frame after an action in real-time. In accurate emulators you can use frame-advance to determine how much intrinsic input lag the game itself has from receiving an input to outputting an action, and it varies game-by-game. In real world tests, no NES game will EVER have next frame response, and certainly not consistently.

>>8314712
>Look how quickly your cope falls apart when subjected to the slightest bit of common sense.
It's funny you mention common sense when you see real-world tests of original hardware with original controllers on CRT TVs having anywhere from 30-60ms of input lag but yet you STILL cope with your bullshit technobabble about something you clearly don't understand at all, because, again, let me reiterate because you're a fucking retard: THESE GAMES ARE NOT EVER GETTING NEXT FRAME RESPONSE. EVEN IN GAMES WITH LOW INTRINSIC INPUT LAG, THEY ARE STILL HAVING MORE THAN THE ON-PAPER INPUT LAG WHEN ACTUALLY TESTED IN REAL-TIME. What part of this do you not understand? You claim next frame response, when there is literally NOT next frame response. You can literally SEE the fucking frames being drawn and SEE that it is not responding on the next frame.

Accept you are wrong, and then break down the tech and try to understand the process better to understand why you are wrong. To me, personally, it doesn't really matter as I'm not a console engineer or a game dev so it really doesn't make a difference to me. I care about what affects me as an end-user playing the game, which is why button-to-pixel is being measured. And on that measure, emulation is always better than original hardware, or can be just on par, or ""authentic"" if you want it that way too. Although there are so many variables that can affect input lag that it's a bit ridiculous to act like there is an ""authentic"" level of input lag or that input lag adds something to the experience. If devs wanted to give weight to something, they should have produced more frames of animation instead of being lazy incompetent bastards. And clearly judging by the difference from literally any game in history console vs. PC, it's obviously not their ""artistic vision"" to have more input lag (or maybe they just choose to "spite" PC by reducing the input lag lmao)

>>8314712
Just like how RGB modding or the Retrotink allows us to enjoy the game as originally intended without artifacting, noise, or inaccuracies, emulation allows us to enjoy games as originally intended without the extra input lag.

>>8314859
>no NES game will EVER have next frame response
What about Duck Hunt?

Not My Problem.

>>8307715
IIRC that hardware glitch is caused by DPCM samples corrupting joypad input reads.

>>8307715
>only if the developer (for some really weird reason) decided to make a buffer that stores commands in a delayed/detached manner from the game logic
So every game in the entire NES, SNES, Genesis, PC Engine, etc. library?

>>8314853
>Button-to-pixel has been a thing for many years to quantify the actual real-world application of input lag from the beginning to the end of the chain
epic cope
>Lol, you are one stupid motherfucker if you think a developer knows the exact delay of an entire complex chain from input to output.
epic strawman

>>8314857
For the information you're looking for you should ask >>8314853 He claims this has been a thing for many years so clearly he has all that information. Unless he's bullshitting. Personally I've only really seen this discussed where it's relevant to game play. Fighting games in particular, where they created their own more descriptive terms for it, instead of "it's input lag, no it's button-to-pixel input lag"

>>8314859
I do understand every aspect of the tech. That's one of the reasons I get suck a kick out of watching fools who don't inventing cope.

>>8314867
>that giant wall of seething and cope
Yeah, science doesn't matter. Just your personal experience. Of not wanting to neck yourself because you're a poorfag who can't afford the toys you want.

>>8314901
If you enjoy emulating games that's great. But most emufags are more interested in seething and coping than playing games. This thread is proof.

>>8315136
>Yeah, science doesn't matter. Just your personal experience.
Yes

>>8314159
Well obviously Star Fox has more input lag because it runs at 10fps. But normal 60fps games should not have any additional input lag unless the programmer did something immensely stupid.

>>8315316
There are tons of games with more than 2 frames of input lag on the NES

>>8315136
>bending reality to meet your theoretical on-paper estimates and limited understanding of the tech is "science"
fucking kek you can't be this stupid, no way you're not trolling

>>8306489
no it doesnt

>>8315326
Dumb newfag who doesn't understand greentext

>>8307474
>inaccurate
no one gives a shit when the other option is to spend $500+ on something their ADHD having ass might never play

>>8315319
Do you have an example, preferably one that has been disassembled, I would love to see what exactly the programmer did to fuck up so badly.

>>8308959
You dont play that lame shit

>>8315336
Son, reap up on it. You are misunderstanding the software and the hardware. The topic is too complex for a 4chan reply. Just read up on input lag on 3rd and 4th gen consoles--there's lots written about it, especially in the emulation development community where reducing input lag below real hardware has been a reality for years now.

>>8315357
I understand how the machines work. What I don't understand is the stupidity of human beings.

>>8315364
Lay off the Dunning-Kruger and read up on how the NES and the SNES actually worked. There was a lot of unavoidable input lag.

>>8315374
Answer the Duck Hunt question.

>>8315336
There are dozens upon dozens of them, just do frame advance with bsnes.

>>8307761
Run-ahead doesn't work with hardware accelerated cores, software only.

>>8315376
Just tested Duck Hunt and it was 6 frames (tested pause and menu selection)

>>8315393
>(tested pause and menu selection)

>>8315395
I'm testing on bsnes. The intrinsic game input lag is 6 frames.

>>8315404
Your testing methodology is beyond flawed if you think actually using the lightgun in Duck Hunt is 6 frames.

>>8306489
I'm the only person in this thread that finished a game this week

>>8315406
>I would love to see what exactly the programmer did to fuck up so badly.
>But normal 60fps games should not have any additional input lag unless the programmer did something immensely stupid.
>Outside of cases where the game code is fucked up. NES, SNES, Master system, GENESIS and all similar consoles should have a total maximum input lag of 2 frames (33ms). These machines do not have a frame buffer, so unless the game code is written in a fucked up way there is just nowhere for lag to exist.
Time to cope buddy. 6 (SIX) fucking frames of input lag kek

Test it yourself on original hardware. The time in ms from pulling the lightgun trigger to the game reacting.

>>8306587
This

>>8315406
>>8315410
Ok so I figured out how to test it. It requires you to hold the trigger for two frames, then release, and then two frames after releasing, the screen will turn black, then one frame of white hitboxes, and then black again, and then it's done.

So on original hardware I imagine it would be at least 50ms (similar to most other NES games)

>>8315376
I don't see the question in any of the post I've responded to. I'm probably not the poster you think I was.
As I said, read up on how it actually worked. Alternatively, don't, but stop spewing stupid shit. The hardware is very well-studied and very well documented. You don't need to employ half-baked epistemology anymore because we have the facts about hardware and software. Input lag was pretty high because of hardware limitations, all of which made total sense.

>>8306553
AFAIK, Run Ahead requires a pretty good computer to be useful, right? At least on my shit pc I can only go as far as using Run Ahead on NES and SNES. I didnt feel many input lag using mednafen for PSX so its pretty good somehow. Hoping Dreamcast and N64 receives more love in a near future.

>>8315482
>Run Ahead requires a pretty good computer to be useful, right?
Mt mid-range from ten years ago is fine. Does that count as "pretty good"?

>>8315490
How many frames do you set up? My limit is about 2 or 4 frames on NES and SNES (90% sure its 2) before it starts to stutter. Its impossible to do that with any other emulator.

>>8315503
That's way too high, you are skipping frames. 99.9999999% of NES games only have a single frame that run ahead can remove, that is the only safe setting to use with the feature as everything has a least that amount.

It's not a setting that you can just choose what number you want, it can only target and remove one source of latency which is from the game itself and that is generaly one frame.

>>8315391
That's a Retroarch limitation, run ahead works just fine with the Duckstation stand alone with the hardware renderer.

>>8315535
What about SNES and other consoles?

>>8315541
Megadrive is always a frame due to how the controllers were polled on OG hardware. SNES is all over the place, I just leave it at a single frame unless I am going to play a game to completion, then you want to use frame advance and check all controlls for the correct number.

>>8315549
Thanks for sharing information sir.

>>8315535
Probably like 40% of NES games have nothing lower than 3 frames, so you can use run-ahead of 2 for them. I just use 1 for everything though.

It does actually work in real-time even up to like 3 or 4 for FB Neo and Beetle PSX where you get next-frame response button-to-pixel, but I feel like it's unnecessary strain on my drive and CPU when I'm already at such low input lag already. Although, some like Beetle Saturn are still a couple frames of input lag button to pixel even with run-ahead to full (frames of lag - 1 depending on game)

>>8315325
>bending reality to meet your theoretical on-paper estimates
I put cycle count in comments after each line in the source code, ya dumb fuck. Tell me more about how you count cycles for your 2600 kernels by taking videos of mario jumping with your iphone.

>>8315441
>It requires you to hold the trigger for two frames, then release, and then two frames after releasing, the screen will turn black
Not even close to reality.
>>8315410
Is this thread some sort of elaborate troll?

MiSTER is meme/hipster bs. just run that shit on your pc like a normal person.

>>8316463
You posted a dark, grainy 60fps video where there is no indication whatsoever of when you pull the trigger. Are you retarded?

>>8316516
Lets see your one billion FPS video that totally proves it has 7 trillion frames of lag or whatever insane cope you've invented now.

>>8316463
Actually, just from this video alone (as shitty as it is), I can STILL tell there is significant input lag. There is 11 frames from when your knuckle starts flexing inwards until the screen has any reaction. For at least 3 of those 11 frames, your knuckle is actually flexing back outwards, so at BARE MINIMUM it's 3 frames of input lag.

>>8316532
The zapper has a long trigger pull. Not that you would know since you've already resorted to this mega cope over not being able to afford original hardware.

>>8306986
Hi, I'm hoping you're still here, but can a GTX 1060 handle low latency mode being set to Ultra (alongside having V-sync and triple buffering enabled)?

>>8316553
>For at least 3 of those 11 frames, your knuckle is actually flexing back outwards, so at BARE MINIMUM it's 3 frames of input lag.
Cope.

>>8316582
Yes I heard your delusional coping the first time.

>>8316584
>>8316553
>t-the frames where my knuckle was literally rebounding were totally part of the trigger pull!!!
hahahaha holy shit this is hilarious. you took a shitty, grainy 60fps video in the pitch dark and yet still managed to prove it has horrible input lag. fucking lmao

>>8316593
You are actually delusional. I don't know any other way to put it. Just completely disconnected from reality at this point.

>>8316598
You can literally go frame by frame in the video and tell that there are multiple frames of input lag. The original argument was that there was no input lag at all.

Alternatively you could just post a 240fps video in a room that isn't completely black, but of course that would just outright prove how wrong you are.

>>8316616
I don't have an iPhone or whatever to record in 240fps. The fact of the matter is there is no input lag. The game wouldn't work if there was.

>>8316620
>The game wouldn't work if there was.
Yes it would you retard fuck. You literally just unknowingly posted proof of the input lag and still continue to deny reality, it's amazing really.

It's just a few frames after you pull the trigger that the game's screen responds, and both cycle-accurate emulation and your own shitty testing prove this.

>>8316628
>It's just a few frames after you pull the trigger that the game's screen responds
We're now at "just a few frames" from "horrible input lag" in the span of two posts. That's good progress. The delusion is wearing off.

>>8316635
The input lag feels horrible due to the long trigger pull, requiring 11 frames to pull a trigger. The actual input lag itself only accounts for 3-6 frames (again, hard to tell exactly because it's a shitty video but definitely no less than that)

There is no way for you to rationalize at all that it is instantaneous or no input lag. If you remember originally I said NES games have 30-60ms of input lag in the best case (CRT, not playing one of the games with more intrinsic input lag).

There is literally nothing unique or special case about Duck Hunt at all like you tried to act like originally. I just find it hilarious you got all cocky posting that video but yet didn't even bother to go through frame-by-frame before posting it and see that it actually completely proves you wrong lmao

>>8316646
You are a shining example of the Dunning-Kruger effect at work.

>>8316653
>posts video proving himself wrong
>still hasn't gone through frame-by-frame and see how wrong he is
>still continues to completely deny reality in front of him - the video he literally recorded himself of the original lightgun on his CRT
>B-BUT IT JUST WOULDN'T WORK IF IT WASN'T INSTANTANEOUS BECAUSE... BECAUSE IT JUST WOULDN'T OK!!
you have to be trolling at this point. Either that or you are one dumb motherfucker lmao

>>8316659
You're misinterpreting in the video when the trigger is actually fully depressed. Either willfully or out of Dunning-Kruger.

>>8316665
>you're misinterpreting in this dark grainy 60fps video when the trigger is actually pressed!
>my knuckle literally rebounding back up after pulling the trigger totally means the trigger has still not compressed!
Just shut the fuck up already. You're not cute.

>>8316710
>I know the exact moment this trigger was fully depressed in this dark grainy video of a peripheral I've never used in my life
Dunning-Kruger.

>>8306553
Emulatorfags literally got too cocky and I can expect them to be as annoying as faggots, vegans and FPGiggers in the near future. The basic loop in many NES games that are actually competent is
>read NES controller ports serially
>save button press values
>execute game logic
>wait for next vertical blank
>process PPU transfers
>go back to beginning
So yes, in the developer's expected scenario, the input is shown at the next frame. This is the "internal lag" you faggots keep jerking off about.
>b-but what if the press goes after the polling, you lose another frame
This is some high concept bullshit that would not be noticed on a CRT, and wouldn't be noticed on emulators if not for the whole chain of modern hardware adding delay. Also, have you fags considered that YOU missed the input window, not the game? How's that for input lag, I could turn this whole retarded argument around and say you need to git gud for not pressing the buttons before the controller is read, lmao.
Yeah runahead is cool and all but that won't make CRTfags stop living rent free in your peabrains.

>>8316812
>So yes, in the developer's expected scenario, the input is shown at the next frame. This is the "internal lag" you faggots keep jerking off about.
Except that literally never fucking happens you fucking retard and you can confirm this through dozens of button-to-pixel tests on CRT TVs, so maybe it's time to accept the fact that your oversimplification and peabrain understanding of the technology are not completely correct?

>>8316721
I don't know the exact moment, that's why I gave a range of 3-6... Even in the most extreme possible scenario, the input lag is still at least 3 frames though.

>>8316913
Fuck off nigger everyone can see the Super Mario Bros disassembled code, I'm not falling for your bait.

>>8316919
>looking at just the code of a game alone allows you to determine the exact input lag chain in ms from button actuation to console processing to CRT displaying the image
>all the dozens of tests of original hardware with original controllers hooked up directly to a CRT TV showing that it's literally never next frame response are just all wrong

>>8316951
I now get why I'm wrong but I still feel it's hilarious that it's clear YOU don't. But yes, 2 to 3 frames is the input lag you will get on a decent NES title, and yes, looking at code can allow you to determine just that, anon.
Good thing you posted a good reaction image for your own post.

>>8307238
>>8307238
>even something like a NES hooked up to a CRT TV has like 30-60ms of input lag
this is not true.

>>8316951
>looking at just the code of a game alone
Said no one ever. But when you combine that with other readily available information such as how the system and display work it's possible to calculate it to a fraction of a microsecond. That's literally how science works.

I made the mistake of posting here without realizing people are larping for the sake of trolling. There's a very easy logic proof on why games have 2 to 3 frames of delay on a CRT yet no one said it, people are just sperging out about slow motion filming and zoomers.
What a shit board.

>>8317648
>I made the mistake of posting here
No one is going to argue with you on that point

Emulation will never be a real videogame

>>8317223
It is. Test it you stupid fuck.

>>8317509
>dozens of actual tests show that your on-paper theoretical technobabble calculations are wrong
>ignore this and cover your ears shouting "LALALALALA I'M RIGHT I'M RIGHT I'M RIGHT"
>"science"
LMAO you're an absolute shit for brains. kill yourself

>>8317509
>That's literally how science works.
No, it's not at all actually... Do you even know what the scientific method is? Like, at all? You know, the entire fucking foundation of modern science?

>>8317796
>dozens of actual tests show coping retards taking videos with their phones are coping retards
>ignore this and cover your ears shouting "LALALALALA I'M RIGHT I'M RIGHT I'M RIGHT"
LMAO you're an absolute shit for brains. kill yourself

>>8317808
You mean like where a poor angry child contrives tests to """prove""" that the toys he can't afford are bad and those claims are then debunked and laughed at by people who actually understand science? I know all about that.

>>8317826
Based schizo autismo

>>8317826
Seems like you're missing the entire experimenting and testing hypothesis step. But then again you're at the level of mental illness where you outright deny reality and just go on nonsensical schizo ramblings. Take your meds.

>>8318186
I tested the hypothesis thoroughly. Your problem is you're very confused about what the jumping mario video hypothesis is. You think it's about measuring lag, but it's not. There are tools even an idiot like you could use to measure lag. They're fairly accurate and this has been done many times and the results well know. The hypothesis of the "button to pixel" copers is that they can get enough poor angry children to shout loud enough and often enough to change the accepted definition of lag. Despite years of trying to prove this hypothesis they have failed to convince me or any other intelligent adult that their contrived redefinition of "lag" should be accepted.
But you can't see the actual experiment for what it is. Because in this experiment you aren't some noble pro science crusader fighting ignorance. You're a rat. In a maze. The stupid one that couldn't find the cheese.

>>8309134
and wireless' polling-rate is faster by now than usb's, depending on the controller.

The problem with emulation is not input lag. This can be solved, as shown in this thread. Also, most people don't even notice input lag anyways. And it's irrelevant to a lot of games (e.g. JARPIGS). The ones who notice it are speedrunners or people that developed muscle memory for games like Ninja Gaiden or Battletoads.
The real problem with emulation is scaling an image for ants in a 21th century monitor. There's no exact solution for this problem, because everything boils down to taste. And this is not an emulation exclusive problem, since many people insist in playing an N64 in their 60" TVs.

>>8316812
it's always the same with you CRTfags. you always find something wrong about modern hardware, like some polling issues or some other autistic stuff, to conclude that emulation is always incorrect. and of course you will say that this all can only be solved with CRT. magic CRTs magically solving every single lag issue and producing perfect upscaling, because it was God's design to play games on a real console and a CRT and everything else is always wrong.
yes, we get it, you have a CRT. you can shut up about it now.
>that won't make CRTfags stop living rent free in your peabrains.
projecting hard? nobody even mentioned CRTs, then a butthurt CRT fag like yourself comes in and reads you a lecture on how modern hardware bad and CRT good. yeah, keep being butthurt that people enjoy games on modern hardware. maybe if you weren't such an insecure faggot about it, you'd enjoy vidya more too, instead trying to prove to everyone than CRTs are 100 times better on an American feed & seed forum.

>input lag
Don't care lmao. Literally no one in the 90s gave a shit about autistic crap like this. It's imperceptible to normal human senses.

>>8318545
It's because it wasn't an issue in the 90s you dimmit. Everyone was playing on original hardware with CRTs

so do any of you guys actually like playing video games or is it all about setting up input lag tests and comparing emulators

>>8306553
>but even game's own internal lag
That will only work for one or two frames. Some games have an insane amount of delay that's made even worse by extra animation.

>>8318234
>I tested the hypothesis thoroughly.
Your post ended here. Either post your tests showing the real-life recorded button-to-pixel input lag or shut the fuck up, it's that simple.

The video in OP is comparing button-to-pixel input lag, which is the commonly accepted standard for input lag. You already saw the OP. You already saw the replies. You already know the whole thread is discussing button-to-pixel input lag. After all, button-to-pixel input lag is what is actually important to the end user and what actually affects your ability to play the game.

Now stop coping and changing the goalposts with your technobabble bullshit when you literally said in your original post that NES games had next frame response on CRT. You had always assumed to be the case. You always just thought when you press a button on a NES controller hooked up to an original NES hardware connected directly to a CRT TV, you thought that the game responds in the next frame (your exact words here): "Any system that allows you to change data the video processor is going to use for the current frame can do same frame response."

But when I show you the tests showing NES games on original hardware have 30-60ms of input lag, sometimes much more, you get butthurt because there is no such test anywhere for any NES or SNES showing anything close to next frame response. Instead of realizing that maybe your peabrain simplification of the tech is wrong since it doesn't represent reality, you doubled down and started schizoposting and spamming buzzwords.

Another soulless emulator tranny thread

>>8317796
i have tested my input lag before, and either you're fucking wrong or my hardware is supernatural. so go fuck yourself nigger

>>8306489
Dreamcast and PS2 have pretty bad lag. Runahead doesn't work that well on PS1

>>8319443
Post at least 120fps footage of button-to-pixel input lag on your setup retard. These tests were all done on CRT with original hardware. Cope.

>>8319489
Depends on your setup. With Beetle PSX even using software + interpreter, I can still get 2-3 frames of run-ahead in certain games. I usually just stick with 1 frame though. Some PSX games have low input lag, but typically 3D 30fps games will be higher.

>achieving feelings of validation for collecting the original games/hardware
Ok
>Inability to accept that emulation has far less lag
This i don't understand. Just accept it and move on

>>8318360
it being faster is not the problem dude, it's the timing and how how the rate is

>>8318403
>most people don't even notice input lag anyway
If they had played the originals they would. Input lag in any rhythm, fighter, platformer ruins the whole experience.

>>8306489
I realized outside of rhythm games how much lag was memed when I played JSRF in one of the Xbox emulators and could time tricks just as well as I did on hardware.

I think emu lag is just a meme started by literal boomers who never figured out how to adjust settings.

>>8319335
>NOOOOOO
>! only i can move the goalposts
>you can't move them back
Top kek kid. Your bullshit is only "the commonly accepted standard for input lag" for a handful of poor angry children. Are you even reading your own strawmanning and cope? Or are you so livid you can't read it through those delicious tears streaming down your face?

>>8306489
This is a thinly veiled Retroarch sperging thread. Input lag is only ever a noticeable problem when Retroarch is involved.

>>8320728
Are you seriously suggesting that 8ms button-to-pixel input lag is high? Are you actually this oblivious?

RetroArch has lower input lag than any standalone emulator you absolute fucking moron.

>>8320741
>Are you seriously suggesting that 8ms button-to-pixel input lag is high?
No. You're to the only talking about that. Please take your cope and leave.

>>8306489
>2 frames with all this expensive as fuck shit
Can't even beat a cheap consumer CRT + old and busted SNES

Look what you need to even mimick the power of a trash picked crt

>>8321090
>"this is a thinly veiled Retroarch sperging thread"
>when the OP shows a game in RetroArch with significantly lower input lag than even original hardware
??? are you retarded?

>>8321104
2 filmed frames (240fps), which is why it says 8ms you retard fuck. It's significantly lower than original hardware on CRT

>>8321218
NES on a trash picked CRT has about 3-4 the input lag of this emulation setup. Keep coping illiterate retard.

>>8321440
Trash picked crt is free and looks best compared to shitty chink fast TN lcds

>>8321472
That's IPS, not TN, retard. OLED looks better than your cancer tube by a mile though.

>>8321474
IPS doesn't look as good as CRTs, keep seething consumer

>>8321090
No, I'm not suggesting anything. I'm outright telling you it has markedly higher input lag. This can be tested by running whatever emulator/core standalone without the Retroarch frontend. Up to a half second of input lag can be seen when the same emulator is run through Retroarch, even when emulating systems where input lag was solved over a fucking decade ago.

>But the new runahead feature lets you have less lag than even the original hardware!
And I don't fucking care. Putting aside the increased specs needed to run it, I don't want less lag any more than I want more lag. I want the same fucking amount. I want it to be accurate to the hardware. That's all that matters. Run ahead is just Retroarch solving, poorly, a problem that Retroarch introduces.

>>8321908
>This can be tested by running whatever emulator/core standalone without the Retroarch frontend. Up to a half second of input lag can be seen when the same emulator is run through Retroarch, even when emulating systems where input lag was solved over a fucking decade ago.
What the fuck are you talking about you fucking moron..? This is absolutely 100% fucking false, and not even remotely close to being true whatsoever. I've tested dozens of cores, every driver, multiple settings, dozens and dozens of games and the input lag is consistently extremely low in RetroArch. Lower than other emulators and even lower than original hardware if you want, because you can use run-ahead.

500ms of input lag.. LMAO man you are fucking braindead holy shit hahahaha

>I want the same fucking amount. I want it to be accurate to the hardware.
Then use a cycle accurate emulator and disable run-ahead. There is absolutely no benefit whatsoever from additional input lag whatsoever and it does nothing to improve the game in any way, but emulators give you the option. And if you're that autistic about it, find the exact input lag and design a controller adapter that adds a chosen amount of input if it's so important to you. But then even on original hardware, the input lag can have a wide range depending on the game or even a wide range of variation doing same action in a game

Does Vulkan have less lag than GL?

>>8322418
From my testing DX11 has the least, then GL, then Vulkan. It's pretty minor though and I think it might depend on your core and your specs.

Retrocuchtards are insufferable.

>>8321426
>???Who are you quoting?

>>8307064

Just a thought, are any women really interested in retro gaming or emulation at all? I swear every single time i heard a female name attached to any kind of project it ends up being a tranny, never. Not once a real women is behind any projects, emulation, romhacks or whatever. Wdyt?

>>8314152
>>8314712
>>8314853
>>8314857
>>8314859

>BS basement dweller time wasting trash above. "Look maaa! I'm debating teh internetz!"

Based below:

>>8314932

>>8325154
>buying an overpriced piece of dogshit that is worse than emulation in every way
>"based"

>>8321440
No one wants your bastardised emulation anon. You will never know what its like to be a retro gamer.

>>8325159
>prefers buying filthy used overpriced consoles full of shit made 30+ years ago with failing hardware

>>8325196
I bought my NES from cash converters for around $50-80 around 14 years ago, still works like a charm. I bought Rare replay and tried to play Battletoads on that and it ran like shit compared to the original.

>>8325202
>I bought my NES from cash converters for around $50-80 around 14 years ago

Let me know where the nearest time machine is so I can tell everyone to use it to buy cheap retro consoles instead of the MiSTer you moron.

>>8325196
No... you just emulate...

>>8325256
>I NEED A TIME MACHINE
the eternal zoomer struggle

>>8325502
It far passed the "struggle phase". Even if they did have a time machine, it would all boil down to this: "10 reasons why you'd better stop travelling and should get a MiSTeR".