/vr/ - Retro Games

[Anonymous No.6700413]

>just bought a mister for the input delay
>read this

You people lied to me. Can't believe I fell for the anti-emulator shills.

[Anonymous No.6700432]

I've never talked to you before, sir. I've never lied to you.

[Anonymous No.6700434]

>>6700413
Yes OP, you should have listened.
>inb4 anti ra shills shit up the thread

[Anonymous No.6700797]

>>6700413
>taking a literal advertisement at face-value
>believing real fast save-states™ will somehow make you better at games

[Anonymous No.6700806]

>>6700413
My wife's boyfriend and I love FPGA and the MiSTer.

[Anonymous No.6700893]

>>6700432
this anon is a liar, dont listen to him

[Anonymous No.6700897]

>>6700806
but what does your boyfriend think about it?

[Anonymous No.6700942]

>>6700893
This anon is a liar, but you should listen 3 him 3 one better than 2

[Anonymous No.6701014]

>>6700413
>muh accuracy
sorry, i'm not byuu or metaljebusrocks shills.

[Anonymous No.6701074]

>>6700897
I don't have a boyfriend, only my wife does. She says it's cheating if I have a boyfriend/girlfriend.

[Anonymous No.6701541]

>>6700413
mister is emulation, though.

[Anonymous No.6701554]

>>6700413
Seethe harder emubaby

[Anonymous No.6701786]

>>6700413
Runahead is banned for speedruns, it's technically cheating as it uses many multiple save states.

[Anonymous No.6701793]

>>6701786
That page is specifically talking about Retroarch before runahead

With it, it has less input latency than real hardware :)

[Anonymous No.6701816]

Any person that has every brought up input delay is using it to cope with their lack of actual skill. We're talking about 1 frame of delay at most on emulators, it has never been noticeable to anyone.

[Anonymous No.6701820]

>>6701793
https://www.speedrun.com/dt2/thread/fx85w
>Retroarch is now officially banned with any core. Those possible tweaks and features are too risky to just let them pass.

:(

[Anonymous No.6701824]

>>6701786
BIZHAWK WINS AGAIN

[Anonymous No.6701827]

>>6701786
>>6701820
good thing im not a speedrunning tranny or else I mightve cared

[Anonymous No.6701838]

>>6701786
>>6701820
Oh noooooo retroarch has been banned from a competition meant for mentally ill trannies, noooo whatever shall we retroarch users do now this not fair oh nooooo

[Anonymous No.6701856]

>>6701827
>>6701838
Cope. Enjoy your innacurate cheat machines.

[Anonymous No.6701859]

>>6701856
Dilate

[Anonymous No.6701861]

>>6701786
>banned for being too responsive
oh no

[Anonymous No.6701862]

>>6701856
>If you use retroarch you must use this one setting.
you're the one coping hard bruv lmaoing at you

[Anonymous No.6701886]

>>6701859
>>6701861
>>6701862
Tweakers coping hard

[Anonymous No.6701889]

>>6701886
ok tranny

[Anonymous No.6701890]

>>6701886
>haha no u

[Anonymous No.6701893]

>>6701886
you sure are angry at my superiority

[Anonymous No.6701898]

>>6701889
Is that the best you've got tweaker?

[Anonymous No.6701903]

>>6701898
ok tranny

[Anonymous No.6701904]

>>6701889
>>6701890
>>6701893
>>6701903
I've really struck a nerve with you tweakers and your cheat boxes

[Anonymous No.6701909]

>>6701904
projections of someone whose nerves have been struck

[Anonymous No.6701918]

>>6701820

Doing what a tranny does best, ban something without understanding why, making an autistic shitfit over an optional feature that users are free to enable or disable at their own will.

Guess these trannies dislike choice and want to be tinpot dictators over their userbases, forcing them what they can and cannot do.

[Anonymous No.6701924]

>>6701820

"too risky" I am pretty sure not a single one of them have ever tried it or tried to measure anything.

[Anonymous No.6701948]

So does a big ass siren go off everytime someone posts a RA thread, and it calls every faggot out of their holes to bitch about their inferior program, and moan that people who don't like it are braindead zoomers?

[Anonymous No.6701951]

>>6701918
They're called rules sweaty, implemented in the interests of fair competition :)

[Anonymous No.6701965]

>>6701951
yes, retroarch was banned for being too responsive
what am I gonna do now, better use fpga shit for longer input delay so I don't upset some homos

[Anonymous No.6701970]

>>6701965
You can use an approved software emulator sweaty. Just don't use one in conjuction with RetroArch :)

[Anonymous No.6701976]

>>6701970
why would I want to get an inferior experience?

[Anonymous No.6701998]

>>6701951

Except the people in that thread point out that there's nothing wrong with RetroArch, and that Bizhawk has very similar cheating features.

You're conflating 'core' and 'runahead' issues with RetroArch. If you're too dumb to understand how things work, you should not try to run a speedrunning competition and leave it up to people who actually understand how things work.

[Anonymous No.6702000]

>>6701976
You can use real hardware or an approved emulator so you can experience not being a cheat, I'm sure that's much more satisfying sweaty :)

[Anonymous No.6702010]

>>6701970

TLDR - some literal who used RetroArch with runahead on a game.

Tranny speedrun mongols sperg, proceed to blame RetroArch, fail to understand that certain programs have certain OPTIONAL options.

They don't want to moderate either or put any actual effort in, so the lazy route out is to just ban and proceed to blame everyone but themselves for failing to understand how shit works and to be on the lookout for cheats.

[Anonymous No.6702013]

>>6702000
I'm not a cheat, I'm merely using software that has less input delay than the original system. Not everything that upsets you is a cheat.

[Anonymous No.6702027]

>>6702000

Or you can simply turn runahead off (WHICH IS ITS DEFAULT SETTING) and stop being a retard that instantly jumps to conclusions.

If you suck at moderating or testing runs that is not the fault of a program.

Read the last post again in that thread -

https://www.speedrun.com/dt2/thread/fx85w/2

"You guys do know that BIZHAWK has tasing capabilities inside of it right? but you're allowing that? also basically the runner used a core option to overclock the core. which is a core option, not a retroarch option. therefore you banned retroarch? EVEN the standalone EMU has the SAME option but you're still allowing it. IF you runahead 1 frame on retroarch there is literally no advantage. THIS IS NOT a retroarch problem."

[Anonymous No.6702030]

>>6702013
>>6702027
>arguing with a tranny
Why bother

[Anonymous No.6702036]

>>6702027
>>6702010
And why exactly should RA with Run ahead be banned? Banning something for being too good is very befitting of trannies. Envy is a sin.

[Anonymous No.6702053]

>>6702036

They want to bitch at emulators for having too much latency to try to sell you on snake oil like FPGAs and console mods (because they are buddy buddy with those people and they split the profits). They will never mention all the cons of those 'l33t' ways to play because they absolutely do not hold a candle to any emulator setup these days and are just a series of compromises and inconveniences.

But if an emulator actually manages to not only match original console latency but beat it alright, you get 'it's too fast' shitposting even though it's a completely optional feature.

Bottom line: they just want to sell you expensive snake oil shit that you don't need.

[Anonymous No.6702074]

>>6702053
FPGA being a cult of retard soisumers is nothing new. These imbeciles couldn't have probably configured RA even if they wanted to so let them have their trash.

[Anonymous No.6702184]

FPGAfags are delusional, possibly even more retarded than realhardwarefags who pretend they need the perfect no-lag setup to play RPGs or genres where the brain compensates just fine for any reasonable amount of latency. The reason FPGAfags are worse is that they are ignorant and keep parroting lies like FPGA being somehow better than software emulators (many actually believe that FPGA emulators aren't "emulators"), FPGA emulators having lower latency (when they plug them into their HDTVs). Analoguetrannies are even worse because they bought into their retarded marketing spin and now spend hundreds on closed source emuboxes that don't even contribute to the emulation scene in any way.

[Anonymous No.6702215]

>>6701793
>when you're so deluded you remain willfully ignorant

[Anonymous No.6702241]

>>6702215
>when you can't cope

[Anonymous No.6702251]

>>6701074
does she atleast let you watch her and her boyfriend have sex? mine doesnt. I had to install a hidden cam. oh god please dont let her find it. she'll kick me out of my parents house if she knows I been recording her having sex. I just want to know what she looks like naked.

[Anonymous No.6702254]

>>6702036
The funny part is that in a speedrunning setting it makes even less sense since performance is tied to your ability to memorize and reproduce a set of inputs with the right timing, not react to unexpected situation, which is arguably what getting one or two less frames of lag might help with.

[Anonymous No.6702335]

>>6700413
We tried to tell you. We tried fucking REPEATEDLY to tell you, but you really wanted to consoom yet another piece of random electronics to make yourself feel a little better for a day or two.

[Anonymous No.6702345]

>>6702053
/thread
Any further tears about the matter are cope.

[Anonymous No.6702353]

>>6700413
>Someone wrote it on the internet so it must be true!

[Anonymous No.6702378]

>>6702241
>when all you do is cope

[Anonymous No.6702384]

>>6702378
A feeling you know all too well :)

[Anonymous No.6702415]

MiSTers are only a few hundred bucks at most, what sort of adult couldn’t afford that?

[Anonymous No.6702440]

>>6702415
Look at you, thinking even half of /vr/ is an adult, let alone has income of their own

[Anonymous No.6702478]

>>6702415
>paying money for something that has no improvement over emulation
What kind of idiot would throw away their money for no reason?

[Anonymous No.6702491]

>>6702478
It has no input lag, as opposed to the substantial fundamental and inherent lag in all emulators. It's due to the way they work, byuu even admitted to it. Runahead is hacking how the game is supposed to run and creates all kinds of glitches and chaos. Just because you're too dumb to understand it doesn't make it not reality.

[Anonymous No.6702492]

>>6702491
>conveniently ignoring the op pic
Oh no, its retarded

[Anonymous No.6702540]

>>6702492
>Thinking the OP pic has more weight than an unbiased observer.
The OP pic even contradicts itself, first it says nearly imperceivable, then it says indistinguishable. It looks like it was written by a five year old.

[Anonymous No.6702548]

Also even if a person doesn't perceive it doesn't mean it's not important. You'll always be a fraction of a second behind, faililng and staring at the screen like a big dumb clown with no idea what's wrong.

[Anonymous No.6702608]

>>6700413
>Mister

[Anonymous No.6702627]

>have retroarch mainly for the ease of using it with retroachievements
>got old crt pc monitor
>decided to switch from an xbox 360 controller to a cheap n64 controller for a more "authentic" experience
>Retroarch has a weird-ass controller naming and setup. Have to bind A or B to what retroarch considers L1 or L2 of a ps2 controller
>Get it setup. Really wanted to play Mischief Makers, but put it off for a bit
>Get distracted by the Command and Conquer remake
>time passes and later think about playing Bomberman on the gameboy
>go through a lot of trouble trying to get the GB filter working without the border, still doesn't 100% work unless I make my 2nd monitor my main monitor in Windows, messing up my desktop. (Using the VGA port on the monitor for the 2nd screen, essentially the integrated graphics for it)
>End up just not playing
>after 100% Tiberium Dawn I finally get around playing Red Alert
>CRT monitor keeps occasionally sparking like theres some short hitting the tube.
>Tried to knock whatever dirt might be there to the back of the monitor
>Doesn't work
>Decide to ignore it
>Monitor dies, only powers on very briefly before shutting down. (had a flatscreen do the exact same thing earlier this year too)
>30$ for that monitor down the drain
>Tried to get the integrated graphics on my motherboard to hook up to a trinitron. Can see the computer background on it, but distorted due to the hz difference
>Can't force that 20,000x 256 res or whatever you need to do to fix this in the intel control panel
>Think about going back to play Mischief Makers or some other games.
>Realize the cheap n64 controller I got has a shitty dpad where you can press down the center.
>Remember that all new n64 controllers out there have shitty sticks and /vr/ complains about them 24/7
>Remember that if I want to play something else on retroarch I have to fix the n64 control setup to whatever new controller I have.
>Also have to fix up filter on my shitty 1080p monitor burn-in

[Anonymous No.6702657]

>>6702540
>>6702548
Keep telling yourself to justify spending hundreds for nothing

[Anonymous No.6702673]

>>6702627
I think you have actual mental problems, should see a doctor about it.
I'm serious.

[Anonymous No.6702680]

>>6702673
They are just going to say to stay away from retroarch and take the money.

[Anonymous No.6702695]

>>6702251
Yes, as long as I do exactly as she says.

[Anonymous No.6702738]

>>6702491

Byuu was not an expert in anything other than autistically emulating the SNES.

RetroArch always beat bsnes hands down in the latency department.

With RA latency is not a problem. Besides, you're memeing over input latency while you hook your MISTer up to a HDMI device anyway. 99% of the latency is going to be in your video output device. Please try to come up with better bait.

[Anonymous No.6702741]

>>6701893
No one is superior to anyone. You're a mediocre homo sapiens just like the other 7 billion of us.

[Anonymous No.6702743]

>>6702491

Not to mention your MISter device is limited to 720p/1080p HDMI output, which is already less than ideal on many 4K TVs.

[Anonymous No.6703435]

>>6700797
that's not even talking about run-ahead, just regular low latency

[Anonymous No.6703440]

in fpga we trust

[Anonymous No.6703449]

>>6702013
run-ahead shouldn't be used for speedruns, because it can be a form of cheating
run ahead doesn't just magically remove lag, it literally rewinds time then replays the last X frames as if you were already pressing that button
so you could potentially avoid getting hit or whatever by changing your inputs not at the last moment, but slightly /after/ the last moment
try setting run-ahead really high (12 frames) and you'll see what i mean, you can walk off an edge, turn around, and.. you didn't walk off the edge

note that this is not the only latency reducing feature of retroarch, everything else is legit and just brings things closer to original hardware latency, what op posted just talks about regular latency reduction which is totally legitimate

[Anonymous No.6704230]

>>6702384
>no u
slick burn zoomie

[Anonymous No.6704338]

>>6703449
incorrect usage of a function is not a fault of that function
just use the proper amount of ra frames

[Anonymous No.6704430]

>>6704338
that's what i'm saying, you shouldn't use run-ahead for competitive speedrunning, just like you shouldn't use pausing, rewinding, gameshark type cheats, or save states, they're features not available on original consoles (in unmodified form), and are unfair advantages
you could argue that only going up to that games' number of internal input lag frames is ok, and that's probably true for casual play, but if this was advantageous, then that would mean it's an advantage over original hardware, if it's not an advantage, then why use it?

[Anonymous No.6704439]

>>6704430
No, that's not what you're saying at all. You're advocating for banning a function because a small portion of people might want to use it in malicious intent or not know how to configure it properly. It's a faulty logic. Should we ban cars because there are accidents on the road? I hardly think so.

[Anonymous No.6704456]

>>6704439
well how would you use it in a way that doesn't cause an advantage over original hardware?

[Anonymous No.6704471]

>>6704456
I'm not exactly sure why the original hardware should be the baseline and nothing better than it should be allowed to compete. The lower the input delay can be, the better.
Even if we somehow imagine the feelings of those using the original hardware are important, RA can be used to reduce delay to its level, not below it, as some emulators incur additional frame delay.

[Anonymous No.6704489]

>>6704471
>I'm not exactly sure why the original hardware should be the baseline and nothing better than it should be allowed to compete.
well then you're proposing that everyone using original hardware switch to retroarch to remain competitive
original hardware should be the baseline, because if not that, then what?
should i be allowed to run the game at 65fps as well? i think it looks a bit smoother so it's all good
or overclock the emulated cpu for less lag frames or just higher frame rate in general? this makes the game much more comfortable to play
the line needs to be drawn somewhere, so people compete on a fair playing field, and it makes perfect sense for original hardware with no mods be that playing field, emulators are only allowed where they perform no better in any way to the original system, which makes sense

>RA can be used to reduce delay to its level
yes, but it's not needed to achieve this parity, so that's not a good argument for run-ahead

[Anonymous No.6704503]

>>6704489
>yes, but it's not needed to achieve this parity, so that's not a good argument for run-ahead

It's not necessarily needed, but may be needed dependent on the emulator in question.

>well then you're proposing that everyone using original hardware switch to retroarch to remain competitive
why not? sunk cost should not hinder technical advancement, and neither should luddites
>should i be allowed to run the game at 65fps as well?
no, that's a slippery slope. Reducing the latency which may be there because of the emulator/sloppy coders of the game/console architecture is not the same as running the game sped up
>or overclock the emulated cpu for less lag frames or just higher frame rate in general?
OC'ing the cpu so the game no longer has slowdowns is always a good idea, albeit the autists that find joy in competitive speedrunning have to figure the merits of that on their own
> it makes perfect sense for original hardware with no mods be that playing field
You lost me. Original hardware is perishable, emulation is eternal.

[Anonymous No.6704545]

>>6704503
accessibility is important as well
it makes no sense to me how you could accept the possibility that might be no way someone could get a WR in a game using the original hardware, what are we even competing with, then?
if there was an advantage to run-ahead or overclocking, that means anyone seriously competing will need to use those as well, both are resource-intensive features
overclocking also often has other consequences besides just lag reduction, it can uncover bugs, cause physics anomalies, etc, this means you might end up with really weird settings ending up being ideal... such as underclocking or toggling different speeds at different times to make use of bugs or tricks that don't happen on original, normal speed hardware, which again, everyone being competitive will be forced to follow
i don't see how allowing anything better than original hardware can end up making anyone happy at the end of the day

[Anonymous No.6704870]

>>6704545
> it can uncover bugs, cause physics anomalies,
I don't mind prohibiting options that lead to such abnormal behavior but yet to come across evidence that properly configured Run Ahead can lead to something of the sort.

[Anonymous No.6704880]

Gentle reminder the mister is still emulation no matter how hard you try to cope.

Literally bought a trumped up emulator box.

[Anonymous No.6704887]

>>6704870
that was in relation to overclocking

[Anonymous No.6704890]

>>6704880
Emulation has nothing wrong with it on itself. Mister does however - it provides inferior experience to software emulation, and on top of that costs money when the former is free. Imagine the kind of retard you must be to buy one.

[Anonymous No.6704906]

Funny thing is, if you tried to sell the anti-emu fags a wire or box that reduces input lag, they would buy it up like the NPCs they are.

But when you do the same thing with free software, they can’t stop whining about it.

[Anonymous No.6704909]

>>6704890
But what about the clout you'll get streaming the retro games with a big mister logo on screen????

[Anonymous No.6705142]

>>6702254
>speedrunning is memorizing and reproducing inputs with the right timing
Having to know the backup strats and reacting to unexpected fringe situations play a big part of speedrunning below the record grind level. I bet you also think shmups are an easy genre.

[Anonymous No.6705303]

>>6702254
>>6705142
only a handful of games are so well practised that they've gotten that close to TAS performance (practically just pure muscle memory)
in most games, there's enough room for mistakes, there's often several ways to complete any task, ranging from slow and safe to multiple frame perfect, sometimes you need to switch up your route part way through a run, or even go off-route entirely a for a bit, most games are complex enough that there are just way, way too many variables to get the same result every time, practice runs can be minutes apart from each other and still all look pretty good
not to mention all the background stuff like glitch hunting, strat making, route planning, etc

[Anonymous No.6705306]

>>6705303
(oh, and even for those few well practiced games, like say, mario 64, even those tend to get shaken up from time to time when new things are discovered)

[Anonymous No.6705313]

>>6702254
I don't speedrun but that sounds like bullshit just from my experience with racing games, which become all about reproducing perfect inputs in time trials. There's no perfect lap because there is no perfect driver, you'll always be making micro level mistakes and adjustments even when doing what seems like the same inputs. Any sufficiently deep speedrun game should work like that too.

[Anonymous No.6705321]

>>6700413
The only people who hate emulators are speed runners, collectors and resellers. Dont listen to them.

[Anonymous No.6705357]

>>6700413
Strawman. No one who knows anything at all would claim emulators have 3-5 frames of lag. That they choose to invalidate an invalid claim to win the argument is a literal strawman.
A software emulator CAN achieve perfect accuracy with perfect latency. It won't happen so long as windows 10 is the OS you are running it on though.
An FPGA can also achieve perfect latency. It also won't happen until we figure out how to decap a CPU and PPU and replicate the gates perfectly.
For the time being, a mister provides a hardware approach to out-of-the-box console like accuracy and latency.
RetroArch requires a high refresh monitor and a game with enough inherent lag that runahead can sit in comfortably.
Both are valid ways to play games when you don't have the real hardware and don't want to drop large amounts of time and money on a SNES, a real Mario World cart and a PVM. And both still have room for improvement.

[Anonymous No.6705362]

>>6705357
What do you mean by perfect latency? Are you aware that consoles have input lag too? Saturn for instance has plenty of it.

[Anonymous No.6705408]

>>6705357
No software emulator "CAN achieve perfect accuracy with perfect latency". No amount of seething and cope can change reality.

[Anonymous No.6705424]

>>6702184
Correct

[Anonymous No.6705435]

Why is every Retroarch thread filled with turboautists that reply until 400+ posts? It's not like they're even talking about anything, they just argue, constantly. There's never another emulator thread that goes this long with this much assblast........ really makes you think

[Anonymous No.6705445]

>>6705408
Emulation can achieve what can be described as above perfect experience.

[Anonymous No.6705457]

>>6705313
yea, exactly, and that's "just" a racing game, no doubt without any weird tricks or glitches (even seen say, a mario kart wii speedrun? not quite what you'd expect)

[Anonymous No.6705467]

>>6705408
retroarch can achieve next-frame latency, that is, it can respond to an input made during the last frame
this is, in fact, exactly the same amount of latency possible on original hardware
what you've forgotten is that an emulator doesn't need to be to-the-nanosecond to be perfect, it just needs to beat the next frame, which is not really that big of a challenge if you're trying

[Anonymous No.6705474]

>>6705362
>>6705362
I mean completely indistinguishable from the real console. Obviously if the game had input lag on real hardware it will have it in the emulator too, it just shouldn't have additional lag. (Or less lag in the case of runahead but that is and should always be your choice).
In an ideal world you should be able to wire a controller to a real console and an emulator and have the same inputs result in the same output. So far people have only really demonstrated pressing buttons on controllers resulting in the action happening on both systems on the same frame. Unfortunately they still desync like a mofo, but that's probably more to do with the OS than the emulator.

[Anonymous No.6705494]

>>6705467
>what you've forgotten is that an emulator doesn't need to be to-the-nanosecond to be perfect, it just needs to beat the next frame, which is not really that big of a challenge if you're trying
That's the big mistake everyone makes. Only consoles like the DC and Xbox onwards work like that. Older consoles read gamepad inputs through interrupts or they polled them at certain times in the frame refresh. So what an emulator does is it puts the USB input into a buffer and then substitutes that data for any read the emulated CPU makes. The time of input and the time of access are not emulated. Since most games don't require more than 1 read per frame it's not the kind of thing you'd notice, but in the hypothetical situation where you are trying to keep an emulator in sync with a real console these inconsistencies will manifest themselves. Ironically emulators are technically AHEAD of a real console for input.

[Anonymous No.6705509]

>>6701074
throw the wife out and fuck her bf, i bet he cooks better too

[Anonymous No.6705510]

>>6705494
you're right that it's not good enough for say, a TAS, but i think it's safe to say that's not a concern for most people
to be compatible at a TAS level, you'd need to basically if not litereally just be the original hardware, that might be difficult to do even with an fpga, software.. who knows, not relevant for human players though
keeping in mind those TAS's that do stuff like ACE, then change how the controllers are ready to pipe tons of data down the controller lines to do outrageous things, that's obviously completely out of the scope of retroarch, though it is technically a thing the original hardware can do

[Anonymous No.6705542]

>>6705510
>i think it's safe to say that's not a concern for most people
Absolutely. To be honest most of the problems with software emulation come not from inherent inaccuracy in the emulator but rather problems with piece of shit laggy control boards in the gamepads (some of the latency figures on fightsticks are a thing to behold), GPUs that refuse to do proper frame timings, drivers that lie to the software about vsyncs causing weirdo timing problems, windows DWM adding latency spikes for no god damn reason, background services stealing resources, etc. etc. etc. It's all fixable, but fuck me I'm old and just want to play some god damned mario kart in peace.

[Anonymous No.6706129]

>>6705445
Which emulator?

>>6705467
>spews emubaby cope
Top kek kid. Keep on copen. Don't let reality get to you.

[Anonymous No.6706137]

>>6706129
Youre an emu baby too mister faggot

[Anonymous No.6706138]

>>6706129
>when you wasted money on trash and have to cope on the internet to recuperate some of the losses

[Anonymous No.6706742]

>>6702738
>>6702743
>99% of the latency is going to be in your video output device.
wtf are you talking about? The display output will be natively output unlike emulation display output or even output from a real console to a hdtv which have to be processed, this is native output so it will be instant. That's the whole reason a lot of people like misterfpga over even the original consoles sometimes.

The tv you use is your own business, you can hook your Mister FPGA up to a CRT if you want. A hdtv tv itself has a delay, it still won't be "99%" which is a ridiculous number you pulled straight out of your ass, more like a few percent at most. A CRT has zero input lag, it can all be theoretically instantaneous from the time you hit a button to when you can see the result on screen (don't even try to conflate refresh rate with input lag). Even if frame refreshing plays a part, at least when you're on an original console or mister fpga it all goes the way it was planned to go, with emulation it's chaotic.

[Anonymous No.6706823]

>>6700413
Them: "Our thing is good! Don't use those other things!"
You: "Oh, I believe you! Yaaaaaaaay!"

[Anonymous No.6706845]

>>6706742
>. A CRT has zero input lag

Retard.

CRTs had on average 8ms of input lag.

You would know this if you weren't a retarded consoomer that operates on mystical beliefs of what CRTs were capable of.

[Anonymous No.6706854]

>>6706742

Here again addressing your retarded consoomer ass -

https://www.resetera.com/threads/crts-have-8-3ms-of-input-lag-addressing-a-common-misconception-about-display-latency.40628/

Maybe instead of buying these snake oil thingies you should inform yourself actually of this 'mystical old hardware' that you seem to believe has supernatural abilities that it doesn't actually possess. But then again, that is why you fall for overpriced snake oil to begin with.

[Anonymous No.6706889]

>>6702738
As usual, you're responding to information that is both outdated and misrepresented.
Even when he was reeing about the Super Nt, his article was supportive of RA's run-ahead to match the latency. And once he added run-ahead himself, he became a bigger supporter of it, and even wrote an article defending it. https://byuu.net/input/run-ahead/
Never miss an opportunity to shill Retroarch though I guess.

[Anonymous No.6706896]

>>6706742
> you can hook your Mister FPGA up to a CRT if you want.

Show me where the composite/SVideo/RGB scart connections are on this thing -

https://manuferhi.com/p/mister-fpga

If your response to this is 'bro just buy another expensive addon on top', then you already lost and this shit costs way more than it's worth.

That's 235 Euros there for that device alone. That's 276 dollaridoos.

[Anonymous No.6706910]

>>6706889
By the way did you ever fix the problem with your input system in Retroarch that makes certain emulators need an extra frame of latency that standalones like bsnes didn't require? Or are you still blaming Byuu for that?

[Anonymous No.6706961]

>>6701786
it appears that my superiority has led to some controversy

[Anonymous No.6706965]

>>6702184
people who write software emulators can tell you all about how much more accurate FPGAs are due to inherent limitations of the shitty chip in your PC. software emulation has come a long way since Nesticle but it will never achieve 100% accuracy in real time.
https://gendev.spritesmind.net/forum/viewtopic.php?t=3044

[Anonymous No.6706975]

>>6702491
>It has no input lag
That's literally impossible, if the image is being processed, there's lag. Maybe it's not noticeable, but it exists.

[Anonymous No.6707035]

>>6706965
FPGAs will be much more accurate when they start being made on reverse-engineered transistor layouts from real physical chips instead of being shameless ports of software emulators to verilog (introducing several new bugs in the process) as with Analogue's products. And this will happen eventually. The power of autism compels them.

[Anonymous No.6707069]

>>6707035
they can still achieve better realtime accuracy than software emulation if they're based on accurate emulators that run slower than realtime. I don't know enough about current products to say if they really live up to that standard or not (software's good enough for my purposes), but it's an inherently better technology for what they're trying to do.

[Anonymous No.6707094]

>>6706845
>>6706854
This is the same old bullshit conflating refresh rate with input lag again. He falsely assumes that you can't change lines during the refresh.

It would be impossible for CRT to have input lag because it can't store or process anything. There is some kind of switching speed associated with some things, they are in the region of nano or pico seconds, not even microseconds nevermind milliseconds.

[Anonymous No.6707104]

>>6706845
>>6706854
This is the same old bullshit conflating refresh rate with input lag again. He falsely assumes that you can't change lines during the refresh.

It would be impossible for a traditional CRT to have significant input lag because it can't store or process anything. There is some kind of switching speed associated with some things, CRT input "lag" overall is in the region of nano or pico seconds, not even microseconds nevermind milliseconds.

[Anonymous No.6707145]

>For older analog cathode ray tube (CRT) technology, display lag is extremely low, due to the nature of the technology, which does not have the ability to store image data before display. The picture signal is minimally processed internally, simply for demodulation from a radio-frequency (RF) carrier wave (for televisions), and then splitting into separate signals for the red, green, and blue electron guns, and for the timing of the vertical and horizontal sync. Image adjustments typically involve reshaping the signal waveform but without storage, so the image is written to the screen as fast as it is received, with only nanoseconds of delay for the signal to traverse the wiring inside the device from input to the screen.
https://en.wikipedia.org/wiki/Display_lag

It's literally about the speed of light. Forget the bro science, you need to stop believing everything you read.

[Anonymous No.6707161]

>>6706975
That’s different from input lag however.

[Anonymous No.6707191]

>>6707104
>This is the same old bullshit conflating refresh rate with input lag again. He falsely assumes that you can't change lines during the refresh.

You're making a strawman argument. Nowhere is he making the claim that there is no midline refresh, you're making that up to bolster your argument.

> It would be impossible for a traditional CRT to have significant input lag

Oh so now we went from 'zero input lag' to 'significant input lag'? Weasel words.

[Anonymous No.6707210]

Friendly reminder that CRTrannies don't understand basic science and are to be ignored.

[Anonymous No.6707234]

>>6707145
>you need to stop believing everything you read.

Yeah, like believing these FPGA cores are in any way or shape more accurate than emulator cores.

It's complete bullshit and most of them are more hacky and buggy than the emulators they base 100% of the code on.

[Anonymous No.6707249]

>>6706965

> people who write software emulators

Correction: two people that write autistic accuracy-obsessed emulators for two relatively simple 16bit systems that are nowhere near as complex as modern game consoles like Gamecube/Wii.

'Cycle accuracy' doesn't matter beyond SNES-era hardware. The whole 'cycle accuracy' fetish led to a new era of autism where people are just imaging latency and inaccuracies to push audiophile scams onto 30/40 yo boomer bugmen who have more money than they have sense. In reality, if you were to do an ABX test between a Raspberry Pi 4 and a Mister, none of them would be able to tell the difference. It's all complete bullshit and promoting snobbism because you spent more money on some snake oil hardware.

[Anonymous No.6707254]

>>6707191
>You're making a strawman argument. Nowhere is he making the claim that there is no midline refresh, you're making that up to bolster your argument.
Sure he is. He is thinking of it like this: if the developer wants to change a pixel at a particular point of the screen he will have to wait until the refresh. However if ANY pixel can be changed, the developer can have it written and shown instantly, thereby zero lag.

>Oh so now we went from 'zero input lag' to 'significant input lag'? Weasel words.
Seriously lol? Give me a break. That would involve electromagnetic waves going faster than the speed of light. You may as well count the time it takes to get from the screen to your eye.

[Anonymous No.6707260]

>>6707254

Bugman, let's see what Melee fags (the ultimate autists when it comes to CRTs) have to say

"Using this metric, even a CRT would not have zero lag - it would have 8.3 ms of lag. This is because it takes a full 16.66 ms to display the entire frame from top to bottom. In this particular case and in many others, when comparing to a CRT it is more fair to subtract about 8 ms from the number reported by Display Lag."

Bugman please stop now.

[Anonymous No.6707298]

>>6707260
I don't know who "Bugman" is but I'm not him. Just because he is talking about subtracting 8 ms doesn't mean he's going to use a LCD. You realize that the LCD is going to have that same refresh rate delay in addition to its own display lag right?

What do speedrunning autists use? All the ones I know of wouldn't even consider using anything other than CRTs.

[Anonymous No.6707326]

This is why the superior setup is mister + crt

[Anonymous No.6707354]

>>6707326

Mister is overpriced trash.

> No shaders
> No runahead
> No enhancements like CPU overclocking, HD texture packs, etc.

[Anonymous No.6707356]

Runahead can't achieve faithful latency like FPGA
https://arstechnica.com/civis/viewtopic.php?p=38773166#p38773166

[Anonymous No.6707375]

>>6707354
>shaders
>hd texture pack
>overpriced
Haha

[Anonymous No.6707384]

>>6707356
>https://arstechnica.com/civis/viewtopic.php?p=38773166#p38773166

> Beamracing autism

That has its own inherent advantages and disadvantages to runahead, one being that your emulator has to run in excess of 400/500fps for it to work.

[Anonymous No.6707392]

>>6707384
Did you just refer to a hardware FPGA implementation of the original hardware as an emulator?

[Anonymous No.6707402]

>>6706896
that dsub port is analog video out. monoprice sells vga to component cables for 5 bucks. think you can get a vga to scart cable too. composite and svideo would need a transcoder since they are not rgb signals

[Anonymous No.6707427]

>>6706845
I remember you getting btfo when you made a cope thread about " crts secretly have lag!"

Still confusing input with refresh, are you? Lmao

[Anonymous No.6707470]

>>6707249
You are seriously easy to bait. I could link you to anything, claim it's saying the opposite, and you'd believe it instead of reading it for yourself.

[Anonymous No.6707471]

>>6707392

It's not a "hardware FPGA implementation of the original hardware" you fucking faggot MISTER fanboy, it's an EMULATOR.

[Anonymous No.6707740]

>>6700413
There's input delay introduced by the computer/OS architecture itself, so good luck pulling this shit off, it's literally not possible

[Anonymous No.6707763]

>>6707740

> everybody using runahead and reporting lower than official hardware latency is just lying, bruh. muh mister, muh fpga, muh snakeoil dogshit said so! no i am totally not coping btw

[Anonymous No.6707768]

>>6707392
This is the most nerdiest, faggot-assed statement I've ever read on this board.

[Anonymous No.6707769]

>>6707763
Look into how a multi tasking OS works then get back to me on how anything can make any kind of timing based guarantee.

[Anonymous No.6707884]

>>6706854
crts don't have 8.3ms of input lag, this is just the average time is takes for a new frame to begin drawing at 60Hz, which has nothing to do with input lag, and also had nothing to do with display device
every display device ever made or will be made will be on average 8.3ms away from the next frame at 60Hz, because that's just what 60Hz is, it has nothing to do with display technology at all

crt's can't store frames, it can't even store lines, the signal coming into the crt goes basically straight through the guns and onto the screen, when it's time to draw pixel 1, the guns are right there at the top left of the screen ready to fire pixel 1 at the phosphors, hell, probably the slowest part of the process is how long it takes the cathode ray to excite the phosphor enough to become visible, and good luck finding a high speed camera for that

[Anonymous No.6707885]

>>6706742
>wtf are you talking about?
>The display output will be natively output unlike emulation display output or even output from a real console to a hdtv which have to be processed, this is native output so it will be instant.


>what are you talking about
>immediately starts vomiting on your keyboard
i just, what?
i don't know where to begin making sense of what you just said

[Anonymous No.6707889]

>>6706823
>Them: "Our thing is good! Don't use those other things!"
Basically the people selling fpga consoles and misters

[Anonymous No.6707893]

>>6707392
>did you just refer to a burger as a sandwich?

[Anonymous No.6707896]

>>6707769

I'm sorry if you can't understand science or actually bother to test anything. inform yourself on how runahead works and read the technical breakdown, nobody has time for your failed attempts at appeal to authority.

[Anonymous No.6707905]

>>6707893
kek

[Anonymous No.6707907]

>>6706845
>>6706854
>>6707210
>input lag
Thanks for telling us you're a retard.

[Anonymous No.6707915]

>>6707769
there are various features available in modern os's to allow programs some control over when they run relative to other programs running on the system, obviously, exact timing won't be gauranteed unless you're running a realtime kernel or something, however, this isn't needed for next-frame latency, there is some room for error before the next frame arrives, 60Hz is pretty slow relative to modern computers, there's plenty of things you can do in 16ms and still have your frame ready in time

[Anonymous No.6708054]

>>6706854
>resetera

[Anonymous No.6708074]

>>6707907

Mister Soi pls

[Anonymous No.6708092]

>>6707915
Those APIs provide simulated predictive lookahead with substandard nominal regex timings.

If you think you can do consistent sub 16ms input timing I'll recommend you for a position at SpaceX

[Anonymous No.6708103]

>>6707260
the 8.3ms you're talking about isn't something added by the display technology, it's just the average amount of time from any instance to the start of the next from at 60Hz
that is, it only relates to the vertical refresh frequency
when people talk about lag added by displays, they're specifically not talking about this inherent fact about refresh rates, they're only talking about lag on top of this
you have done absolutely zero research into what people are even talking about, and are acting like an authority on the subject

if you want to test input lag by itself, try a test where a button press changes the colour of the output immediately, mid-scanout, you can do this. you will notice that a crt will /immediately/ start drawing the new colour (button press during h/vblank notwithstanding), what you're talking about is only relevant in cases where you're only drawing whole frames

[Anonymous No.6708105]

>>6708092
retroarch can do next-frame latency WITHOUT RUN AHEAD
for fuck's sake people, try looking things up before talking about them

[Anonymous No.6708128]

>>6708105
If you don't use something, but something you do use uses that thing you're trying not to use, then you haven't really avoided it

[Anonymous No.6708138]

>>6708128
what are you trying to say? because it sounds like you're saying retroarch can only achieve low latency with run ahead, which is not true

[Anonymous No.6708146]

>>6708128

[Anonymous No.6708156]

>>6701786
speedrunning was always cancer and has always used arbitrary rules and restrictions.
You've highlighted the NT Mini but a fucking FPGA is gonna be better than the Virtual Console that you've ignored which is not only inaccurate for emulation but INTENTIONALLY changes NES games.
There's no reason VC should be allowed.

[Anonymous No.6708173]

>>6708092
can a normal configuration desktop OS go "fuck you, i've got the cpu for the next 50ms"? yes, of course it can, but think about it like this
can you practically gaurantee response within 10 seconds? probably
how about 500ms? sure..
100ms? why not?
so when why is 16ms impossible? yes, unless you configure your OS otherwise, it can ruin a frame from time to time, this is outside of any programs' control, if you configure your OS properly and don't run anything that can mess it up, you can very easily have multiple-hour sessions without a single missed frame, though, we're not dealing with putting a rocket into space here

[Anonymous No.6708175]

>>6708156
>Virtual Console that you've ignored which is not only inaccurate for emulation but INTENTIONALLY changes NES games.
>There's no reason VC should be allowed.
the VC isn't allowed because it's accurate, it's allowed because it's an official release of the game on an official console

[Anonymous No.6708186]

>>6708173
Timesharing swaps between cycles

[Anonymous No.6708193]

>>6708175
yeah but Analogue NT isn't though, neither is FCEUX, Nestopia or Bizhawk.

You may as well permit Animal Crossing playthroughs if being officially released by Nintendo on a Nintendo console counts.

[Anonymous No.6708241]

>>6708175

> If Nintendo makes a crappy emulator emulating a game inaccurately it's still GOOD because it's OFFICIAL

conSOOMER

[Anonymous No.6708273]

>>6708241
i didn't call it good, in fact, i called it inaccurate, which is the opposite of good

[Anonymous No.6708304]

>>6706137
>>6706138
>C O P E
Seethe harder little zoomies. Let the butthurt flow through you. Seethe and project, like all emubaby faggots do.

[Anonymous No.6708371]

>>6708304

Mister Soi pls

[Anonymous No.6708425]

MiSTer with vga or component cables will still render the image on a monitor faster than retroarch can with runahead and faster than analogue Nt does over hdmi to an LCD

Let that sink in

[Anonymous No.6708457]

>>6708425

It won't since runahead can exceed the original hardware's latency while mister can't.

Mister sois never learn

[Anonymous No.6708608]

>>6708425
>i haven't looked into run ahead but it can't possibly be better than 0 latency
boy do i have some news for you

[Anonymous No.6708864]

>>6708371
Nice selfie zoomie. Keep projecting. Keep seething. It might make you feel like less of a loser some day. It's hilarious that emubabies are so poor and stupid that they can't imagine anyone plays any other way.

[Anonymous No.6708987]

>>6708425
Who's gonna get to tell him?

[Anonymous No.6709360]

I don’t really know what MISTer & FPGA are, and I can’t be bothered to learn as I know I won’t really understand it anyway. I’ll stick with everdrives.

[Anonymous No.6709368]

>>6709360
Everdrives and most flashcarts actually use FPGA already, but if you got the real console it doesn't really matter.

[Anonymous No.6709378]

Original hardware is still the best way to play despite it having worse latency than emulators now.

[Anonymous No.6709404]

>>6709360
an FPGA is like a custom chip, only it's logical function is programmable, so basically, it's a chip whose function can be changed at any time
everdrives contain an FPGA, since even carts often have things you need to emulate, like memory mappers, additional sound and graphics chips, etc

[Anonymous No.6709410]

>>6709404
(ps. yes, since carts are not just dumb storage devices, an everdrive can indeed be classified a cartridge emulator)

[Anonymous No.6709426]

>>6708987
He already knows you're retarded coping emufag. No one needs to tell him.

[Anonanon No.6709427]

>>6701786
>>6706961
reminds me babies in crossplay crying that mouse aiming is "cheating" lmao

[Anonymous No.6709509]

>>6701786
Any speedrunning community that allows emulation is unless they have a compelling reason retarded in the first place.

>>6709427
Is this sarcasm? Of course it's cheating to use a mouse when other people are using controllers, how fucking dumb are you?

[Anonymous No.6709536]

>>6709509
>Is this sarcasm? Of course it's cheating to use a mouse when other people are using controllers, how fucking dumb are you?
not him but i wouldn't say cheating if mouse is actually supported by the game normally
they're not equal input methods though, so i wouldn't put both methods in the same match for anything but casual players

[Anonanon No.6709541]

>>6709509
Not really, mouse users are playing with no restrictions, where as controller users have aim assists that mechanically aim the crosshair at people

[Anonymous No.6709604]

>>6709541
i wouldn't call autoaim a restriction, and autoaim is the opposite of mechanical

[Anonymous No.6709627]

>>6709427
>mouse aiming
lol. Clicking on heads isn't "aiming"

[Anonymous No.6709664]

>>6701886
>Tweakers coping hard
Gotta love the 4chan arguing about literally fucking nothing meme
I personally feel sorry for any pony-fucking trans-faggot that would ever use hazelnut creamer in their coffee when salted caramel is the obvious patrician choice.

[Anonymous No.6709675]

>>6701886
>they deal with microseconds of frame delay and correct it with software
*gasp*

[Anonymous No.6710228]

>>6709627
>controller aiming
lol. Moving the stick to left/right and letting the aimbot do its thing isn't "aiming"

[Anonymous No.6710327]

>>6710228
>aimbot
git gud scrub

[Anonymous No.6710381]

>>6710327
>git gud scrub

[Anonymous No.6710407]

>>6709664
But sometimes I don't want the sugary sweetness in my coffee, I occasionally yearn for a nutty crunch

[Anonymous No.6710501]

>>6707384
It's accurate, doesn't require a super GPU to work

[Anonymous No.6710808]

>>6706845
> CRTs had on average 8ms of input lag.
You are confusing scan-out with input lag
Total lag = input lag + scan time (/2)

For any signal source, a crt will always be the fastest output device to view that source.
If you increase the refresh rate significantly then an lcd can beat a crt, but of course a higher refresh rate beats a lower refresh rate.
The input lag of a crt is 0, that 8ms of lag applies to all monitors, but with an lcd there will be additional input lag ontop of it.

[Anonymous No.6710832]

How do FPGAs not have lag? they still handle inputs through USB and have to convert those signals to something the hardware its emulating can use so there is inevitable lag at least as much as there would be with PC too. FPGAggots need to fuck off with the no lag myth.I can believe it might have nearly no lag but to say its just as responsive as real hardware is a fucking lie

[Anonymous No.6710871]

>>6710832

definitely, usb is laggy AF.

[Anonymous No.6710881]

>>6707915
I get zero xruns at 3ms latency audio processing (more demanding than a 60Hz emulator) on Linux with no special configuration other than disabling power saving. If I was serious about this I could get <1ms with realtime kernel, isocpus, etc. See: https://rigtorp.se/low-latency-guide/

[Anonymous No.6710906]

>>6710871
im sure they will try to feed us some bullshit like an increased polling rate which is also possible on PCs and doesnt really make FPGAs special

[Anonymous No.6710970]

>>6710832
What kind of false enthusiast would pay for FPGA and then use shitty USB. You can connect original controllers directly to FPGA.

A properly implemented fpga will have identical lag to the real console.

[Anonymous No.6711147]

>>6710970
so where do you plug your SNES controller in?

[Anonymous No.6711171]

>>6711147
Obviously the particular FPGA board would need some reserved io lines and you would need a suitable adapter. I have no idea which board that is in the picture but it looks like it has some spare io headers on the left.

Sega saturn controllers make a great all-round retro gaming controller, their layout is great for all classic consoles. I used to use a sega saturn controller with my pc over parallel port.

[Anonymous No.6712346]

>>6711171

How much more expensive is all this shit going to become after you buy all that?

Bro, I just have a PC that has tenthousand times the spec of your shitty PC and it gangrapes the fuck out of it. Same for any shitty Android phone.

Before you say 'muh lag' - it literally does not matter dude, your brain probably has more latency than the actual device does.

[Anonymous No.6712357]

>>6711171

So $280 for the entire Mister board and then having to shell out even more money on top?

Starting to seem like a much more expensive proposition than a PI 4 already

[Anonymous No.6712361]

>>6712357
i don't think anyone is calling them a cheaper option

[Anonymous No.6712368]

>>6701793
An NES connected through AV to a CRT literally has no lag. Also, please find me a digital monitor with LITERALLY 0.00ms input lag.

[Anonymous No.6712414]

>>6712357
So apparently this expensive piece of shit does not support any other controller type than usb.
Worthless garbage.

[Anonymous No.6712418]

>>6712368
>still combating runahead with "0 lag"
anon you dumb motherfucker, LOOK IT UP
run ahead is for LESS THAN ZERO LAG
yes, less, look it up, find out how the fuck that works, because it does, stop assuming it's impossible and look it the fuck up

[Anonymous No.6712429]

>>6707392
>implementation of the original hardware

Only a digital implementation. It performs estimation of all analog characteristics and parasitics and is coded to only replicate the functionality of a chip based off of a datasheet. That's what emulation is, and just because it's implemented on hardware doesn't change that. Until you know the transistor/gate layout of each chip that you're trying to replicate you can't say you aren't just emulating the functionality

[Anonymous No.6712435]

>>6712368
>>6712418
https://www.youtube.com/watch?v=_qys9sdzJKI

[Anonymous No.6712439]

>>6712418
Runahead can't telepathically tell which button you're going to press, so I call bullshit. I went and read the explanation and it sounds like certified snake-oil.

[Anonymous No.6712453]

>>6712429
only a handful of chips can say they've been completely and truly replicated, such as the 6502, this requires decapping, microscopically photographing, and reverse engineering

>>6712439
it doesn't need to, what it does is, it does save states on every frame, then when you press a button, it will reload a state N frames ago, press that button, then roll back to the present, basically making it as though you've already been pressing that button for N frames the instant you press it

[Anonymous No.6712472]

>>6712453
But the image could still take 4ms to update to your monitor, that'd still be more than the real hardware on a CRT.

[Anonymous No.6712475]

>>6712472
a run-ahead of 1 cuts 16.6ms of input lag off of a 60Hz game

[Anonymous No.6712495]

>>6712475
No way that analogue inputs on a crt have 16ms of input lag, I don't believe that for one second.

[Anonymous No.6712550]

>>6712495
you're still not getting this, are you
most video games (basically from nes onwards) do not respond to inputs on the very next frame, since they spend a lot of their time just drawing the screen, there's little time to spend each frame actually figuring out what to change for the next frame, games may have 1, 2, or maybe 3 frames in between button presses and any on-screen changes
like you see here >>6712435, when he presses jump in smb with a real nes on a crt, he does not jump the very next frame, this is not because a crt has lagged a frame, nor is it even the nes which has lagged a frame, it's the software, the game itself hasn't yet decided to move mario on the frame after pressing the button

[Anonymous No.6712559]

>>6712472
>>6712495
Why are you arguing as if you have any idea what you’re talking about

[Anonymous No.6712565]

>>6712495
>>6712550
-- and for the runahead example in the video, the game still lagged a frame, it's just that runahead made it so the moment the button was pressed, the button was immediately retroactively already pressed for a frame, so the next frame is actually the second frame of pressing jump, making mario appear to jump immediately

[Anonymous No.6712575]

>>6712453
I think the closest an FPGA would ever get is if you got your hands on the original verilog that was used for simulations prior to gate synthesis. But even that doesn't account for all the small tweaks that needed to be made in post-fab testing

[Anonymous No.6712593]

>>6712495
There's no "input lag" on a TV. Input lag is solely between your thumb and the console recognizing your thumb, but has nothing to do with it getting displayed on the TV.

[Anonymous No.6712660]

>>6712361
Then where's the benefit, because they sure aren't a more accurate option?

[Anonymous No.6712913]

>>6712660
I mean, they are a more accurate option from a hardware perspective. Just not by any accuracy metric that matters to you

[Anonymous No.6713076]

>>6712913
>I mean, they are a more accurate option from a hardware perspective.
[citation needed]

[Anonymous No.6713848]

>>6712439
Runahead is not snakeoil, and it does not predict anything. Its actually extremely simple.
The console requires at least two frames to fully respond to controller inputs, the first frame reads the controller and updates the game state, and on the next frame that updated game state is used to update the vram. Old consoles do not have a frame-buffer, they render in real time during scan-out. Emulators cannot render in real time, they must render to a frame-buffer first and then flip that to the screen, this introduces an extra frame of delay as render and scan-out are separate instead of combined.

frame 0:
read controller
step game engine
frame 1:
update vram
render/scan out

Runahead uses save states to render ahead by one or more frame such that the result of controller input is immediately available without needing to wait for the next frame.

[Anonymous No.6713901]

>>6713848
>Its actually extremely simple.
>parrots bullshit
kids. lol.

[Anonymous No.6713905]

>>6700413
I don't play console games on my PC
I also have no intention of connecting a PC to my TV

[Anonymous No.6713912]

>>6700413
>enables run-ahead and gsync
heh. nice emulator with more steps, kid

[Anonymous No.6713942]

>>6713901
What exactly is wrong with what I have said. I know what I am talking about but maybe it came out unclear.

[Anonymous No.6713975]

>>6713905
In a few years this image is going to need an update with FPGA instead of pi

[Anonymous No.6713990]

>>6713942
Just to be clear I'm a different anon from the guy calling you out. I'm not the guy calling your info "bullshit". I just want to add something constructive rather than pointless bickering.
Okay, so you have the right idea, and most of what you said is right, but the problem is you're not quite right about the why.
First, runahead is a misnomer, runahead doesn't run ahead, emulators always run ahead, that's the problem. It takes into account you are seeing a frame behind what you should be, so it sends your controller input back in time and runs forward with the new data to catch up.
Rendering to a framebuffer then swapping isn't what's creating the extra frame of lag. Think about it, a hypothetical SNES game is running the game logic while the previous frame is being rasterised (forget confusing things with interrupts), so the game logic for the next frame is done and so it's safe to consider the frame "rendered" in PC terms. Because when the console hits vblank all the DMA and register programming has to be done to get the hardware ready to draw the frame, it's not a good idea to be doing game logic in this step (though some people did). So fundamentally what's the difference between swapping a back buffer and actually drawing the pixels live? Well... none... So why are emulators "laggy"?
Because the game logic you are running was updating while the previous frame was displayed, the point the game ACTUALLY reads the controller input is MUCH closer to the start of the next frame than in an emulator where the controller is read, the logic updated, the frame drawn and then waiting for the buffer swap.
But RetroArch has late controller polling! So that argument disappears... So why is it still laggy. Because windows (and X11) will add extra latency because of the compositor.
But RetroArch also has hard gpu sync and exclusive fullscreen... So why is it still laggy?
Because your monitor buffers the frame before display.
Continued...

[Anonymous No.6713995]

>>6713990
But I'm using a 240Hz display! Why is it still behind!
Because your controller is not sending your inputs up the chain as fast as it should be.

So, if you enable Late Controller Polling, tune your hard gpu sync, run 240Hz (or even 120Hz really) and get a low latency controller then fundamentally RetroArch and bsnes ISN'T lagging more than a real console. However all that requires buying new hardware and spending time tuning it.

Runahead is a cheap, easy way to hide your lag inside the lag the original developers put into the game that anyone can do with minimal fuss. That's why it's cool. It's a different solution to a problem that's caused by PCs being big complicated general purpose devices. It doesn't ALWAYS work, however. 2600 games are the exception, but it basically works fine for everything NES and up.

[Anonymous No.6714040]

>>6701820
I thought these competition things always used real hardware though.

[Anonymous No.6714052]

>>6713990
> Rendering to a framebuffer then swapping isn't what's creating the extra frame of lag
I think its a matter of definition, I consider it to be the cause but its indirectly so

Console render
frame 0:
read controller
step game engine
frame 1:
update vram
render/scan out -> to tv

Emulator render
frame 0:
read controller
step game engine
frame 1:
update vram
render/scan out -> to backbuffer
flip backbuffer
frame 2:
scan out -> to monitor

The emulator requires an extra frame because it cannot render and scan-out at the same time. It has to emulate the console render/scan-out first and then on the next frame the real scan-out happens.

> sends your controller input back in time
I think this is the wrong conception, you are not sending the controller input back in time, you are advancing the emulator state forward an extra frame such that the render/scan out is available, you then roll the state back one frame.

[Anonymous No.6716330]

>>6713901
Except that nothing in his post was inaccurate.

[Anonymous No.6716463]

>>6713942
>I know what I am talking
No you don't. You're just parroting bullshit.
>What exactly is wrong with what I have said
Pretty much everything. It's all been covered here before. Check the archives if you care to educate yourself. Continue to bullshit if you want to continue to embarrass yourself and get laughed at. I'm not here to educate every newfag who wants to join muh secret club.

[Anonymous No.6716472]

>>6716463
>two anons who obviously know what they're talking about conversing and educating each other on the subject
>you're still trying to bait
That's kinda funny.

[Anonymous No.6716624]

>>6702627
>>Retroarch has a weird-ass controller naming and setup. Have to bind A or B to what retroarch considers L1 or L2 of a ps2 controller
I gave up trying to play N64 emulators through RA. I just use a DS4 or SNES controller for the systems that make sense for them. Still using Project64 though I imagine there are better options these days.

>>6704338
Even on the single frame setting, it means that inputs that shouldn't work can.

>>6704471
Don't know how you could possibly argue that original hardware shouldn't be the baseline.

[Anonymous No.6716645]

>>6701786
Oh no I won't be accepted into a hive mind full of degenerates who have swaths of cheaters in their ranks already, what will i do?
>>6701856
>>6701886
>>6701898
>>6701904
seething lmao

[Anonymous No.6716792]

>>6701786
nice, you can filter speed runners irl AND use better software

[Anonymous No.6716824]

>>6708103
>if you want to test input lag by itself
That's display lag. You guys are arguing up a storm while using the wrong terms. Display lag is why CRTs are superior. Input lag is why emulators are iffy since they can vary unpredictably from real hardware for a variety of reasons.

>>6707763
See >>6703449. Runahead doesn't fix input lag, it rewinds the game to give the illusion there was no input lag. Your input is being sent to the future relative to what is displayed just enough to make it seem like you're playing in the exact present. The illusion breaks down if you use too many frames.

>>6710881
>I get zero xruns at 3ms latency audio processing
What's that and how are you monitoring latency?

[Anonymous No.6716830]

>>6716824
>What's that and how are you monitoring latency?
not him, but xruns is refers to underruns and/or overruns, specifically underrunning or overrunning buffers
audio crackling for example is a result of underrunning audio buffers somewhere along the line
zero xruns just means normal, flawless audio playback

[Anonymous No.6716842]

>>6716830
Ah, I see. I don't know enough about how emulators deal with USB polling or the OS scheduler, but I highly doubt running a straight buffer is comparable.

[Anonymous No.6716845]

>>6700413
latency depends on the hardware drivers and the operating system, not the emulator or game itself, but if the program has many graphics-sound-effects additions, it will require more processing resources, cutting resources from other sectors.

Also if requires hardware that exceeds the installed capabilities, the results will be affected.If the operating system has many open programs or visual-sound-other add-ons it will complicate performance.

If the pc is not physically cleaned + virus + defragmentation and it has little ram that it in turn shares with the video, it will reduce performance.

[Anonymous No.6716848]

>>6710808
>If you increase the refresh rate significantly then an lcd can beat a crt
If your console outputs digital signal, maybe. Ever tried a composite output console on an older LCD? It's like a quarter second of display lag. Me and a buddy discovered this trying to play smash 64 on his nice flatscreen back in 2008 or something.

[Anonymous No.6716916]

>>6716472
>one anon trying to kidsplain the bullshit youtube told him
>he's still trying to cope
That's super hilarious

[Anonymous No.6716982]

>>6716848
Both our statements are true. Refresh rate is not a property of just the monitor its shared with the signal source, the console outputs 60hz always. Also I said "an lcd" I did not say all lcds. It is possible to build an lcd with very little input lag the same way that its possible to polish a turd.

[Anonymous No.6717000]

>>6716916
Well, how was he wrong?

[Anonymous No.6717013]

>>6716463
As a crt user my explanation assumed a 60hz refresh rate monitor, the explanation is less accurate for higher refresh rates, maybe this is a source for the disagreement, its not wrong but only fully applies to 60hz. You can use runahead to achieve better input lag than the real hardware, but thats only with high refresh rate monitors, when using a 60hz crt, runahead allows you to match the real hardware input lag, and that is what I was going for with my explanation.

[Anonymous No.6717105]

lmao, you idiots dont realize how easy it is to cheat with emulators like bizhawk. you can record a sequence of inputs, then play them back on stream and it looks legit as fuck. ive been doing that for 2 years and never got caught. i have over 20 speedrun WRs. you wont get caught as long as your runs look like its played by a human being, and as long as you dont submit runs for super popular games like mario, zelda or metroid.

[Anonymous No.6717124]

>>6717105
if you could be bothered, you could do the same in hardware, too
just program a microcontroller like a keylogger, in line of a real controller, reading inputs and spitting them out the other side, only you can then make it to macros or turbo with special key combos
just hide it inside the console (or controller for that matter)

[Anonymous No.6717138]

>>6717105
People who spend years mastering 1 game in speedrunning are fucking retarded. Imagine getting beaten and not being sure if he was playing legit or not. It's impossible to prove.

[Anonymous No.6717143]

>>6717124
its not that simple, many consoles have uninitialized RAM on each boot, which affects RNG and even lag. plus consoles have inconsistent lag because of audio chips. emulators dont have those issues.

[Anonymous No.6717148]

>>6717143
oh you're talking full blow TAS, not just hand-holding macros
TAS is possible on real hardware, too, your audio chip lag comment is total bullshit, fyi

[Anonymous No.6717162]

>>6717148
obviously youve never seen super metroid desyncs caused by snes audio chip, stupid faggot. go educate yourself before you post.

[Anonymous No.6717221]

>>6717105
>i have over 20 speedrun WRs in games nobody plays
might as well submit casual playthroughs

[Anonymous No.6717224]

>>6717221
>nobody plays
most of them have around 50 runners

[Anonymous No.6717260]

>>6717000
Everything's wrong with it. There are many things I've heard runahead being called, "simple" isn't one of them. He has no clue what he's talking about and has just designed his post to make it seem that way. Runahead is not accurate and if you raise it too much the glitching becomes obvious. There might be a place for it but to compare it to original hardware is ridiculous.

Emubabies just seem to want to believe that their emulating is as good as original hardware, that the lag doesn't matter and that if it does matter runahead is perfect. They just want to believe it so you know, why bother trying to debate them? You can't argue with people that don't know anything about a subject, but then knowledge was never a prerequisite for asserting emulation is as good as the same as original hardware. Sure it denies some of the most basic laws of physics and logic but it's not hurting anyone, why not just let them to it.

[Anonymous No.6717275]

>>6701816
This is basicaly it. Input lag up to a couple of frames is completely negligble.

>> b-but im super sensitive and can tell the difference in 1 frame
Doesnt matter. If you spend any time playing with it you will adjust.

Of course there are limits to this. Most of this is born out of people emulating and playing old systems on shit old lcds that had image processing making things utterly horrendous.

Anyone saying otherwise is a low skill autist screeching. No an extra frame of input lag is not why you lost or didnt get the WR. Shut. The. Fuck. Up.

[Anonymous No.6717290]

>>6717260
All those words just to not answer my question.

[Anonymous No.6717387]

>>6717000
In all the ways that have been explained here many times. Read the archives and educate yourself newfag. /vr/ isn't your private pandemic pod.

>>6717013
The source of the disagreement is you're parroting bullshit someone told you and I know how it actually works. Your "source" is some faggot who recorded Mario jumping on his iphone while my source is 30+ years of experience with the hardware we're talking about. I know from experience that I can poll the controller on nearly any console 100+ times per field and "respond" to it within a few cycles. Writing games, I regularly polled during the vertical blank and "responded" by updating the display during that same field.
If consoles really required two frames, as you claim, then run ahead would just work for every game. But they don't so it doesn't. You've even acknowledged that "old consoles" don't and yet believe that the NES is somehow slower than a 2600 because youtube told you. If would have taken a minute to think critically about the bullshit you're being fed by coping emufags you probably could have figured this out on your own.

[Anonymous No.6717417]

>>6717387
>In all the ways that have been explained here many times. Read the archives and educate yourself newfag. /vr/ isn't your private pandemic pod.
Implying you're not >>6717260

[Anonymous No.6717452]

And the assembly language larper makes a guest appearance to the thread.

[Anonymous No.6717461]

>>6717105
That's so pointless though, you'll always know you're a cheat deep down. If you're okay with that feeling then I feel sorry for you.

[Anonymous No.6717478]

>>6717417
Actually the other guy is me.

[Anonymous No.6717580]

>>6717387
> NES is somehow slower than a 2600
Actually most games on the NES would have more input lag than 2600. That is not because the NES is slower but because of the way games are coded. On the 2600 the cpu must be used during the active scan to update the display, on the NES the ppu does it for you. This means that on the NES the cpu is available for the entire frame duration to update the game state, and the actual render occurs on the next frame. With the 2600 the game state must be updated during the vblank period and during the active scan it must be used to update the display. That is why the 2600 has lower input lag because the engine and render occur on the same frame whilst NES they occur on separate frames.

I have never watched that video you speak of or any other such video. I have my own understanding based on my own knowledge. I now how retro consoles function, I have coded for them and as well.
For a typical game the code is implemented as follows.

frame 1:
1. v-blank interrupt
2. read controller for frame 1
3. update vram state frame 0
4. update game state: frame 1
5. sleep till v-blank

frame 2:
1. v-blank interrupt
2. read controller for frame 2
3. update vram state frame 1
4. update game state frame 2
5. sleep till v-blank

During the active scan the vdp renders the current frame and sends it to the television whilst the game code prepares the next frame. So in total it takes two frames for most games to respond to input. One frame to update the game state, and the next frame to render and scan-out to the television.

[Anonymous No.6717589]

>>6717105
>>6717224
>you wont get caught as long as your runs look like its played by a human being, and as long as you dont submit runs for super popular games like mario, zelda or metroid.
What is the point of cheating at something nobody cares about? Just being a dick to the other 50 players who run the game?

>>6717260
Emulation is awesome as long as you're not an autistic speedrunner who needs everyone to be on the exact same page for a consistent baseline. Even then it can be good for practice. I have tons of real hardware and old games but I emulate 99% of the time these days. I agree with you on input lag but I don't get your general hateboner for emulation.

>>6717275
Two frames difference in latency is considerable and three frames is massive if you've been playing it one way your entire life.

[Anonymous No.6717867]

>>6716848
That's the shitty upscaler + post processing

[Anonymous No.6718147]

>>6717417
lol. See >>6717478

>>6717580
>Actually I make no sense unless I change what I'm saying
Exactly. Glad we can agree that the claim "The console requires at least two frames to fully respond to controller inputs" is complete bullshit.

[Anonymous No.6718171]

>>6718147
> "The console requires at least two frames to fully respond to controller inputs" is complete bullshit.
The console literally needs two frames to fully display the results of an input. The first frame steps the game engine, the second frame renders the frame to the tv. That sounds like 2 frames to me.

[Anonymous No.6718646]

>>6718171
The console literally doesn't. You don't know wtf you're talking about and are just parroting bullshit. If you're the guy I replied to who claimed to have "coded for" old systems you're also a larping faggot. You need to fuck off back to your facebook group chat or discord or whenever all you little "that kid" faggots hang out and lie to each other these days.

[Anonymous No.6718678]

>>6702184
Retroshart is burning ass.
Real men use ZSNES and Nesticle.

[Anonymous No.6718693]

Display lag makes retroarch irrelevant.

[Anonymous No.6718706]

>>6713905
Pic is stupid.

[Anonymous No.6718714]

>>6700413
Enjoy your trash Emulator, I guess dumb faggot.

[Anonymous No.6718839]

>>6718646
You have not refuted a single thing I have said, all you do is state that I am wrong. If you are so knowledgeable why not enlighten us with your understanding of the sequence of operations a console performs to go from controller input to display output.

[Anonymous No.6718898]

>>6718839
Look at how shift register ICs work: one pulse to latch, one pulse to shift.

TWO cpu cycles before you can get your input.

[Anonymous No.6718930]

>>6718898
> Look at how shift register ICs work: one pulse to latch, one pulse to shift.
Ok now I am completely lost, how are shift registers relevant to anything.

[Anonymous No.6718954]

>>6718714
Cope, retard

[Anonymous No.6718995]

>>6718930
How do you think the system reads input?

[Anonymous No.6719021]

>>6718995
Ok so the NES reads its controller input from a shift register. How is that relevant to this discussion. Reading the controller is just one step in the sequence of operations that transforms controller input into display output.

[Anonymous No.6719030]

>>6719021
And it's one that alone makes what you're claiming impossible. Stop playing stupid, you can't be this dumb.

[Anonymous No.6719074]

>>6719030
One CPU cycle != one frame.

[Anonymous No.6719095]

>>6719074
They do when the quartz drives the frame cycle ratio towards one

[Anonymous No.6719381]

Can I hijack this thread for a quick question: what do you guys think would be the best solution for emulating old (240p) computers? That's the thing I was looking at mister for but I didn't know if there was a Raspberry Pi solution. I'd be hooking it up to my CRT.

[Anonymous No.6719389]

>>6719381
pi + composite out

[Anonymous No.6719794]

>>6718839
I have refuted everything you've said many times newfag. Read the archives and educate yourself.

>>6718930
>>6719095
Holy fuck you're stupid. You're trolling, right? No one could possibly be this retarded.

[Anonymous No.6719807]

Are we still doing the "I've been programming since the nineties" larp or have they moved on to some other dishonest bullshit? I haven't checked the thread in about a day.

[Anonymous No.6719995]

If this thread hasn't thoroughly proved that fpgafags are mentally ill retards then I don't know what will.

[Anonymous No.6720110]

>>6719794
> I have refuted everything you've said many times newfag
I am not even sure who is even saying what anymore, none of your replies have made any sense, but as far as refuting goes, you have not stated anything at all.

>> They do when the quartz drives the frame cycle ratio towards one
Hey this one is not mine, I have no clue what the hell this is about.

[Anonymous No.6720137]

>>6720110
>none of your replies have made any sense
That's because he's having a hard time keeping which one of his personas is supposed to be replying to who. He's pretending to be multiple people and it's starting to fall apart now.

[Anonymous No.6720205]

>>6720110
I'm sorry you're too retarded to understand simple English. I'm the guy telling bullshitting newfags to read the archive because I refuse to spoon feed retarded zoomers. Everyone else is someone else. I don't know or care which zoomie replies to my posts with bullshit and cope. You're all the same to me and I'm going to mock and laugh at you all.

[Anonymous No.6720245]

>>6718930
it's generally how one would serialise a whole bunch of buttons into a single digital line
take an nes controller as a very easy to understand example
it's just a bunch of membrane keys, and a shift register.

[Anonymous No.6720273]

>>6720205
>i didn't know what i was talking about either so now i'm embarrassed and in full shitposting mode

[Anonymous No.6720323]

>>6720137
>>6720205
>>6720273
I really wish this board had those poster identifier codes, because I have no idea who has said what.

[Anonymous No.6720326]

>If I say enough times that emulation is the same then it will be true.

[Anonymous No.6720328]

>>6720326
But it's not the same, it's currently better and is going to stay that way until cores made for FPGA devices get substantially more development time.

[Anonymous No.6720332]

>>6717260
>Runahead is not accurate
Correct. It's cheating, because it can make the game more responsive than on original hardware.
>if you raise it too much the glitching becomes obvious
Also correct, but highly misleading, because it falsely implies there is always glitching.

Runahead is indistinguishable from removing latency so long as you do not runahead further than the game's built-in latency. With very few exceptions (e.g. 2600 games) there is always built-in latency.

[Anonymous No.6720335]

>>6720323
>because I have no idea who has said what.
Yeah, that's the general idea. Mr. "I've been programming for thirty years" has been looking for an out of the argument he's in for the better part of a day now. He's hoping randomly shitposting and muddying the waters will give him that out. It's not enough to just close the thread and not come back. He has to save as much face as he can against the other autistic kid he was larping with. Such is 4chan.

[Anonymous No.6720345]

Let me red pill you on input lag.
If you're using a USB input device, you will always have variable input lag, because it's polling based.
Meanwhile, analog inputs like real hardware or even something like using a gamecube controller with the Wii (not pii u) is interrupt based, resulting in no lag.
Runahead does nothing about this, it also does nothing about your displays lag. What a dumb meme.

[Anonymous No.6720365]

>>6705357
How about Windows 7?

[Anonymous No.6720371]

>>6720345
> USB
> displays lag
I cannot think of an insult suitible for somebody who uses USB or an LCD, it you are using an actual CRT and some non-shit input device, then Runahead allows you to achieve input lag equal to the original device.

[Anonymous No.6720376]

>>6711147
You need a SUB adapter first, silly.

[Anonymous No.6720381]

>>6720345
1000Hz polling adds up to 1ms latency. Original hardware generally uses a latch for debouncing, which adds up to an entire frame. Modern controllers can (but usually don't because the designers don't care about latency) use hysteresis-based debouncing, which adds 0ms assuming the switching rate doesn't vastly exceed the capabilities of the human hand, or they can use optical or hall-effect switches that don't need debouncing.

[Anonymous No.6720384]

>>6718678
Remember when we were just happy enough to play Snes, Nes, Atari and.Sega games on our DOS or Windows 3.1 pc's

[Anonymous No.6720390]

>>6720381
> Original hardware generally uses a latch for debouncing
I am not aware of any consoles which denounce their inputs, can you be specific. I ma most familiar with sega master system and genesis and neither of those do such a thing.

[Anonymous No.6720398]

>>6720390
Controllers have a shift register with latch for the buttons. They only latch the switch state once per frame, so if it's bouncing and happens to be open at the time you'll have to wait an entire frame for it to stop bouncing so it can be latched in next time.

[Anonymous No.6720403]

>>6720398
This doesn't add a whole frame of latency. It adds latency up to the bouncing time (which is still much higher than necessary).

[Anonymous No.6720418]

>>6720398
>>6720403
No de-bouncing is performed nor is required. The controller state is read once a frame and whatever state the buttons are in at that instant of time is what is returned. In the case of the NES the controller latches the button state just before it is read, this is nothing to do with de-bouncing, its just so that the paralell state can be converted to serial. In the case of master system/genesis, there is no latch at all, the button state is read parallel straight from the live button state.

[Anonymous No.6720438]

>>6720418
Buttons can easily bounce for 10ms. That's potentially 10ms latency added, because the button might be sampled while open at the very end of the bouncing. If the controller uses interrupts or very fast polling and debounces by the hysteresis method you add 0ms (in practice you want some light low-pass filtering too to prevent false triggers from electrical noise, but that will add <1ms).

[Anonymous No.6720490]

>>6720438
Ok now I see what you are getting at. Retro consoles lack any de-bouncing, but that can actually increase latency because it might be bounding at the point at which the state was sampled.

Here is an interesting thought, if bounding really does take a significant amount of time, you could create a modified controller to eliminate said bounding and achieve lower input lag on the original console. Would that count as cheating in speed-runs?

[Anonymous No.6720630]

>>6720490
Depends if they allow 3rd party controllers or not.

[Anonymous No.6721130]

>>6720273
>i'm mad, coping, and projecting
Yup

>>6720323
If a board needs IDs then it's gone so far to shit it doesn't matter. Are you really planning to learn to be electronics by listening to a bunch of chucklefucks on a gook toon pixelart board?
It doesn't matter if the bullshitter who "coded for" old consoles is the same fucktard who doesn't know what a shift register is. It doesn't matter because they don't matter. One bullshit parroting zoomie isn't any more relevant than another.
Same for the faggot who keeps replying to you because he's too afraid to reply to me. I don't know which bullshitter he is or where he got btfo but he's clearly seething like a mother fucker. Another nothing.
You'll all get mad and try to convince yourselves that youtube didn't lie to you and be back shitposting the same bullshit next week. This is how it has been done since many summers ago and will be for many summers to come. IDs aren't going to change that.

[Anonymous No.6721134]

>>6721130
>If a board needs IDs then its gone so far to shit it doesnt matter
this is coming from one of the most prolific spammers on the board lmfao

[Anonymous No.6721453]

>>6721130
Why are all your posts like this? It's all just angry garbage with no substance.

[Anonymous No.6721460]

>>6721130
>to learn to be electronics
They said I could be anything I wanted, so I listened to some shitposting larper kid and became electronics.

[Anonymous No.6721470]

>>6720630
not him, but i've seen plenty of examples of speedrunners using third party controllers, and off the top of my head only extra features like turbo buttons are not (generally) allowed, i've not heard anyone talk about debouncing issues (not that i've actually looked for that specifically either)

[Anonymous No.6722025]

>>6703435
wtf is run ahead and how does it work?

[Anonymous No.6722082]

>>6721130
Looks like YouTube lied to to again, kiddo.

[Anonymous No.6722114]

>>6718171
>The console literally needs two frames to fully display the results of an input

not true, the 2600 checked line by line

[Anonymous No.6722173]

>>6722114
True, but the 2600 is rather atypical. It lacks a proper gpu so the cpu needs to do all the work. The cpu advances the game state during vblank period, and then renders the graphics during the active scan.

For consoles such as nes, snes, master system, genesis, they typically required two frames. The cpu and the gpu work simultaneously, the cpu advances the game state whilst the gpu renders a view of the previous game state. This is a two stage pipeline.

[Anonymous No.6722358]

>>6722025
Poll input
Run for 1 frame (the normal emulation)
Save state
Run for n frames, assuming input remains constant (the "run ahead")
Display result
Load state
Repeat

The "save state" and "load state" refer to internal emulator state. There's no visual indication of it happening. Assuming the game has at least n frames of built-in latency, the result is identical to sending the input n frames into the past with a time machine (negative latency). If the game responds sooner than that you get glitches.

[Anonymous No.6722871]

>>6722025
in non-technical terms
basically any game from the 3rd gen onwards has at least one frame between button press and visible response where nothing happens, yes, games themselves have input lag, even if you use the original console
what run-ahead does is cut those frames out with carefully timed save states and fast-forwarding (which you can't even see)
so run-ahead can make games lag even less than when run on an original console

[Anonymous No.6722880]

>>6722871
You forgot the part where it can cause terrible microstuttering

[Anonymous No.6722886]

>>6701951
I'm not sweaty. I shower regularly! :(

[Anonymous No.6722887]

>>6722886
I don't, but you can manage the sweat in other ways. Personally I like to squeegee my sweat onto my beard for that sweet sweet sweat smell all day. I love the smell of my sweat. The sweat from the crotch on a swampy day is best.

[Anonymous No.6722920]

>>6722880
it doesn't, unless your computer is too slow for it, or you pick a value beyond what the game has (too high a value can cut more than the lag frames out, and also cut some of the gameplay out, too, so be sure to measure what each game does)

[Anonymous No.6722934]

>>6722920
The unpredictable nature of some games can cause indeterminate states at the time of capture leading to an instance of infinite recursion with the state restoration, thus resulting in a stutter.

[Anonymous No.6722972]

>>6722880
If it causes micro-stuttering, then the implementation is shit
>>6722920
For consoles without a frame-buffer like nes, snes, master system, genesis. the value should always be 1.

[Anonymous No.6722979]

>>6722972
The concept is fundamentally unsound and must at times cause stuttering, it's not that the implementation is lacking, the concept itself must inevitably result in stuttering

[Anonymous No.6722980]

>>6721134
>this is coming from one of the most prolific spammers on the board lmfao
You mean your post?
>>6721453
Seethe harder zoomie
>>6721460
We're all electronics now
>>6722082
Youtube lies to everyone kiddo

At least now some people are just shitposting instead of shitposting parroted bullshit. We're making progress.

[Anonymous No.6722982]

>>6705435
Lol this. Just buy an n64 for $60

[Anonymous No.6722995]

>>6722972
>>6722979
what is it that makes people who haven't researched a topic want to talk about it like they know what it is?

[Anonymous No.6722997]

>>6722979
My understanding is such that I believe a proper implementation shall not result in any stuttering.
Can you expand on exactly why you think it should cause stuttering. God its always so difficult to exchange complex ideas over such a slow medium.

[Anonymous No.6722998]

>>6722972
>>6722979
>no framebuffer means no input lag, right?
no?
>the concept can't work without stuttering, right?
no?

[Anonymous No.6723001]

>>6722995
lol ok pal, I've done plenty of research and have even implemented my own super scaler so I know a thing or two about hardware. After having spent several days working on it it turns out you can not do it without stuttering.

[Anonymous No.6723004]

>>6722998
Framebuffers mean MORE input lag, not LESS!

[Anonymous No.6723005]

>>6723001
Lmao watch out we’ve got a fuckin master electrician over here. Better get out of Edison over here’s way before he invents nuclear fission

[Anonymous No.6723014]

>>6723005
Where's your superscaler motherfucker? You got triple poly axle accuracy too, huh??

[Anonymous No.6723032]

>>6723001
It is possible that we are both right if talking about different systems. The system I am most knowledgeable of is the sega genesis. In the case of that system run-ahead should not result in any stutter.

[Anonymous No.6723038]

https://www.youtube.com/watch?v=-eUaD6u9mgg

[Anonymous No.6723048]

>>6700413

The OS of your choice has a lot to do with it too.

I don't know about Windows, but in Linux you can compile the kernel to use very responsive timings, including the Preemptive option. If you play an emulator on something like that, instead of a default generic kernel which might prioritize throughput over responsiveness, you'll probably have very low latency.

[Anonymous No.6723061]

>>6701786
It's because Runahead cuts internal native latency, so it does alter the games somewhat, for the better of course. Except for the autistic speedruning trannies.

[Anonymous No.6723068]

>>6723061
No, they are correct to protest, this kind of fall ahead stutter ruing older games on a micro level

[Anonymous No.6723080]

>>6723068
if you know that a game always has 1 lag frame between input and response, then there is no disadvantage at all to use a run ahead of 1 frame
run ahead only causes stutter if you run ahead more frames than the game lags, causing it to skip frames you should have seen
i don't know what you think run ahead does, but it's not something retarded like it just blindly skipping a frame when you press a button, that would be unplayable (causing everything around the player to stutter, and the audio to get fucked, too)

[Anonymous No.6723082]

>>6722934
Obvious bullshit. Consoles with multiple independent clocks are non-deterministic, but all /vr/ emulators are deterministic, so there can be no problems with save states. Games are designed to be unaffected by the non-determinism so in most cases there is no observable difference unless you open the console up and probe traces with an oscilloscope. There are a few games that very occasionally crash on real consoles because of the non-determinism but work reliably on emulators, and this is technically an emulator bug, but why would anybody bother fixing it?
>>6722979
False.

[Anonymous No.6723085]

>>6723080
No, when running ahead for its input sometimes the latch time on the input isn't ready yet and causes an indeterminate result that can lead to an inappropriate offset in state restoration leading to a small stutter

[Anonymous No.6723091]

>>6723082
>There are a few games that very occasionally crash on real consoles because of the non-determinism but work reliably on emulators, and this is technically an emulator bug, but why would anybody bother fixing it?
not him, but some emulators care more about accuracy than just running commercial games
if a game works in an emulator, but not on console, then it's not, for example, very useful for homebrew development

[Anonymous No.6723095]

>>6723091
This too can be caused by run ahead. In the end it can result in too many unpredictable states and should be removed from emulators.

[Anonymous No.6723097]

>>6723085
This literally never happens.

[Anonymous No.6723102]

>>6723097
It happens due to the difference in resolution between the real amount of time being emulated and the amount of time it took the CPU to complete the task in amongst its task scheduling

[Anonymous No.6723104]

>>6723102
Show me footage of this happening in any game with 1 frame ahead? I tested several games and never got a single stutter.

[Anonymous No.6723116]

>>6723104
You just need to overschedule your CPU

[Anonymous No.6723118]

>>6723095
> This too can be caused by run ahead. In the end it can result in too many unpredictable states and should be removed from emulators.
If run-ahead is corrupting the game state then the emulator is broken. run-ahead strictly effects what is rendered, it has no effect on the game state. That's why you save and load state. You save the state before rendering the extra frame ahead, and then restore the state. As far as the game is concerned run-ahead never happened.

[Anonymous No.6723119]

>>6723102
it's like you've never heard of vsync
on that note, why aren't you complaining that retroarch does dynamic rate control, which slightly alters the game output rate to match the users' monitor?

[Anonymous No.6723125]

>>6723116
>Just fuck everything up willingly dude

[Anonymous No.6723126]

>>6723095
what? run ahead can't possibly effect emulation accuracy, it only manipulates time external to the game

[Anonymous No.6723129]

>>6723126
It affects accuracy in the sense that it removes latency inherent to hardware, so for speedtrannies it's a bad thing.

[Anonymous No.6723130]

>>6723118
You don't understand, I appologize, english is not my mothertongue, let me attempt again: when the resolution scale between real current time and emulated current time due to overscheduling of the CPU and a lagging task scheduler at the OS CPU management level the latching on input can miss and produce incorrect data

[Anonymous No.6723143]

>>6723130
Your CPU will never overschedule running these emulators unless it doesn't even have horsepower to run them in the first place, are you retarded? How did you come to this conclusion, did you run any tests?

[Anonymous No.6723146]

>>6723129
yes, it's inaccurate only in the sense that it's better than original hardware, not in any way that can cause issues with game code

[Anonymous No.6723147]

>>6723143
It is good modern OS design to overschedule the CPU, this is due to new microinstruction extension of x86 introduced by Intel several years ago, I believe the emulator authors are not aware of this

[Anonymous No.6723150]

>>6723147
So you don't have tests or any data to show and everyone else is wrong, gotcha.

[Anonymous No.6723151]

>>6723150
Tests are not necessary for that which is obvious

[Anonymous No.6723153]

>>6723130
>>6723147
Scheduling details of the host system should not have any bearing on run-ahead aside from requiring more cpu power. Run-ahead is not tied to any real-world timing event, the only thing it requires of the computer is more cpu time.

[Anonymous No.6723160]

>>6723153
CPU time and real time are inexorably linked

[Anonymous No.6723161]

>>6701786
>You must use a shitty inaccurate emu otherwise you run doesn't count.
lmao. Might as well only allow ZSNES in for snes games.

[Anonymous No.6723164]

>>6723160
Yes but that's not a problem with run-ahead specifically. Its a problem with your machine not being fast enough. Obviously you cannot use run-ahead if the computer is too slow.

[Anonymous No.6723165]

>>6723130
This nigga is drunk.

[Anonymous No.6723167]

>>6723164
You fail to understand the link of the times delta

[Anonymous No.6723179]

How can Retroarch perform better than real hardware if I can't get latency lower than 1 frame? If anything it has the potential to perform the same but not faster, unless you count laggy garbage like Mario World.

[Anonymous No.6723182]

>>6723179
That's exactly it, it plays out the next couple of frames while displaying the current, tried the input against those frames, and then can conditionally restore to a previous state to correct for incorrect input predictions

[Anonymous No.6723237]

>>6723179
because most games don't act on inputs the very next frame
retroarch can exploit this by basically folding time such that your inputs do show results on the very next frame, resulting in being a frame ahead of real hardware

[Anonymous No.6723243]

>>6723179
Typical hardware latency is 16+8 ms (middle scan)
If you are running your monitor at 144hz, then you can achieve a latency of 7+3.5 ms (middle scan)

[Anonymous No.6723245]

>>6723237
Which can break any game that heavily relies on RNG, not recommended for RPGs.

[Anonymous No.6723253]

>>6723245
> Which can break any game that heavily relies on RNG, not recommended for RPGs.
If it has been implemented correctly it will have zero effect on the game state, it renders ahead but when its done it throws away that new state and reverts back. The game will never know that run-ahead happened.

[Anonymous No.6723254]

>>6723245
Fuck off retard, you've been debunked several times already.

[Anonymous No.6723261]

>>6723253
I still can't wrap my head around how it works. I'm literally retarded.

[Anonymous No.6723296]

>>6723261
https://byuu.net/input/run-ahead/

[Anonymous No.6723306]

>>6723261
without explaining how exactly it does it, you can imagine it as though every time you press a button, the emulator is able to retroactively press that button N frames ago, showing you what you would have gotten if you pressed the button N frames earlier than you actually did
it doesn't actually skip any frames, it's really just rewriting history

[Anonymous No.6723324]

>>6723243
you wouldn't want to run 60Hz games on a 144Hz monitor, since that would either cause jitter (144 isn't a multiple of 60), or a speedup of 18% to make it match
if your monitor can do 144Hz, it can do 120Hz, so use that

[Anonymous No.6723335]

>>6723324
It was just an example, I had free-sync in mind when I chose that arbitrary refresh rate. That seems to be all the rage these days.

[Anonymous No.6723338]

>>6723261
>>6723306
also, to help you understand what's going on, remember that even if you aren't pressing buttons, with run ahead on you're always shown the future
so i guess one way to look at it is that your controller is in the present, but your display is in the future, since it's always a constant amount in the future, everything looks as it should without any skipping around

[Anonymous No.6723341]

>>6723335
How do you cope with the de-syncs though?

[Anonymous No.6723343]

>>6723341
what desyncs?

[Anonymous No.6723347]

>>6723343
The ones that result from the runahead, because of the CPU overscheduling

[Anonymous No.6723364]

>>6723347
you're not making sense

[Anonymous No.6723369]

>>6723161
I pray this is bait.

[Anonymous No.6723384]

https://www.youtube.com/watch?v=Sw0hbW-05k0

[Anonymous No.6723391]

>>6723364
retroarch defense force go home

[Anonymous No.6723393]

>>6723391
this is my home

[Anonymous No.6723415]

>>6723384
Why would you post a video of someone testing the obvious? That's not what anyone is arguing about in this thread.

[Anonymous No.6723434]

>>6723415
plenty of people are talking about run-ahead
the video shows both issues discussed in this thread, op's realisation that software emulators can match real hardware, and also run-ahead, which can surpass real hardware

[Anonymous No.6723443]

So what's the /vr/dict? Is the MiSTer just as good as the original hardware?

[Anonymous No.6723474]

>>6723434
People are arguing about whether run-ahead causes glitches and whether it has non-deterministic issues when run on a multi-tasking operating system, with or without polling-based input devices vs. interrupt-based input devices. That video sheds light on nothing.

[Anonymous No.6723501]

>>6723474
run ahead has nothing to do with any of that

[Anonymous No.6723504]

>>6723443
it can in theory be just as good as retroarch (without run ahead) or original hardware
it still depends on the accuracy of it's emulator cores though, same as software emulators

[Anonymous No.6723517]

>>6723501
And that's why you have nothing to contribute to this conversation.

[Anonymous No.6723538]

>>6723517
run ahead doesn't cause glitches or non-determinism on multi-tasking operating systems
nor does it have any effect on any kind of input device or polling method
it's really not that complicated a feature

[Anonymous No.6723549]

>>6723538
I'll defer to the people ITT who have a lot more process and system call knowledge than I do. I doubt you're one of them.

[Anonymous No.6723601]

>>6722980
>At least now some people are just shitposting instead of shitposting parroted bullshit.
Care to link to the Youtube video you got this shit opinion from, kid?

[Anonymous No.6723913]

>>6723504
>it can in theory be just as good as retroarch
So it's shit then?
>or original hardware
So it's amazing then?

[Anonymous No.6723918]

Imagine arguing over 400 posts about Emulators skipping some frame ...

[Anonymous No.6723941]

>get mister because mah latency
>retroarch beats it
>latency isn't that important anyway
>it's not the original latency
>who can even see a frame of latency anyway
kek

[Anonymous No.6724158]

>>6723306
>>6723338

Thanks anon, this made it much more clear.

[Anonymous No.6724165]

>>6723941
The appeal of MiSter is that everything "just works" I guess. As a thinker autist you spend more time thinkering settings than playing anything if you're given so much freedom as Retroarch gives you. I am a happier person now that I dusted off my real SNES and an everdrive than I was playing on Retroarch and trying to satisfy my OCD. I still use RA for everything else, but I can see the appeal of the MiSter.

[Anonymous No.6724167]

>>6724165
I mean tinker obviously, fuck autocorrection

[Anonymous No.6724180]

>>6701816
In "most emulators" it's upwards of 3 to 5. You don't notice it untill you fire up RA with all the latency mitigation options, then you just can't go back. Mario World is an example of a game that feels awful to play on other emulators in comparison since it has 2 frames baked in, and standalones will easily give you 3 or 4 more.

[Anonymous No.6724191]

>>6724180
So I have heard that Mario World has two frames of latency. If this is true then that is some really sloppy coding, I wonder if they are reading the controller after stepping the game engine instead of before.

[Anonymous No.6724246]

>>6723306
https://byuu.net/input/run-ahead/

Dude ... It dose skip frames

[Anonymous No.6724260]

>>6724246
Not really, read the article again.

[Anonymous No.6724269]

>>6724260
//we can run-ahead as many frames as we want

while (runAhead > 1) {
emulator.run();
//these frames are also discarded
runAhead--;
}

This literally running the logic without rendering the image ...

[Anonymous No.6724272]

>>6723601

[Anonymous No.6724278]

>>6723182
>then can conditionally restore to a previous state to correct for incorrect input predictions
False. It *always* restores the previous state, and it doesn't matter if the input prediction was correct or not because because it never runs ahead far enough for it to affect the display.

[Anonymous No.6724284]

>>6701074
JARED?

[Anonymous No.6724297]

>>6724246
not in the traditional sense
like, it's not just going like button pressed > skip a frame > done, because this will cause stuttering for other things and the audio, and just be an unplayable mess
the way it actually works is that it's constantly showing you N frames ahead of time, so when you press a button, you see the effect of that button press in the future
the end result for both you and the game is perfectly consistent, like, you could record your inputs like a TAS and it'll still be a valid single instance of the game
>>6724269
i suppose in a sense lag frames are skipped, like, those frames aren't actually shown to you, rather you go right from pre-button-press to alternate-universe-where-you-pressed-the-button-N-frames-ago

[Anonymous No.6724340]

>>6724297
Like missing out 16.6ms makes an unplayable mess.

I mean i understand what you try to explain me there but even if it works like you explained (which is clearly not the case for bsnes) wouldn't be the outcome the same. The frames that causes the 1-2 of input lag are skiped.

[Anonymous No.6724390]

>>6724340
what would be a mess is if the emulator just jumped forward 2 frames every time the input changed
run ahead skips lag frames, but does so in a way which conceals this fact perfectly (rather than actually seeing the skip occur, they get skipped "in the past")
it's more like it avoids showing you lag frames rather than skipping them, it's hard to describe it like skipping frames, since you're not really skipping anything in any existing usage of the word

[Anonymous No.6724456]

>>6724297
>the way it actually works is that it's constantly showing you N frames ahead of time, so when you press a button, you see the effect of that button press in the future
No, it's showing you the future but the effect of a button press shows up as if you'd pressed it in the present (or past, relative to the future). Which is why stuff like >>6703449 can happen if you set N higher. Go ahead and try it on the platformer of your choice right now. This is of course always happening but it takes a higher N for a human to notice the weird effects. I definitely agree with the decision to ban the setting from speed running.

[Anonymous No.6724527]

>>6724390
OK but then i dont get the problem of OP. No matter if you skip 1-2 frames "backward" or forward its not like the same concept could be used on a fpga.

But i dont see any reason to do that except starting another shitpost thread on /VR/ to bitch around what is "better"

It makes sense for software emulation to compensate the overhead of the OS and the disadvantages of the non native architecture. I think the people should rather be happy that there are so many options to choose from to play some good old games no matter if its super accurate or pretty impressive work of software emulation or even a chink handheld that works ok.

[Anonymous No.6724543]

>>6724456
>Which is why stuff like >>6703449 (You) can happen
heh
yea i know of the possible artefacts of "cutting out" more frames than just the lag frames
my point is that your not skipping frames in the normal way people would think of it, like you're still doing every frame in order, 500, 501, 502, 503, etc, only when you press a button on say, 501, instead of giving you a lag frame on 502, it instead does 501 over with the new button press so the 502 you get is not a lag frame
>>6724527
i see no reason you couldn't do run ahead on an fpga, it will just require more resources (bigger fpga)

[Anonymous No.6724552]

>>6724543
(if people are wondering where the lag frame went, well, it becomes the one you just saw when pressing the button, you can't see it... because it's a lag frame, that's the whole point in getting rid of it)

[Anonymous No.6724554]

>>6724543
And my point is that you're being shown the future and then you see the effects of a new input in the PAST.

[Anonymous No.6724556]

>>6724554
yes
sorry, but i also find it a big difficult to visualise, we might not even be in disagreement

[Anonymous No.6724689]

>>6714052
Although it's not the 90s anymore. We can scan out line by line or pixel by pixel now if we want to.

[Anonymous No.6724707]

>>6720371
What do you do for your controller then? Wire a gamepad up to work with the ps/2 keyboard port? Do you only play old games without analog sticks? Or maybe you have an old pci sound card with a gameport?

[Anonymous No.6724717]

>>6724689
good luck getting the cpu involved with individual pixels in real time during scanout
what do you think you're going to do, even at 640x480x60 we're talking about pixel clocks near 21MHz, you're going to interrupt the cpu 21 million times a second to clock out pixels?
forget the 90's, this isn't the 70's anymore, we have video chips and frame buffers for a reason

[Anonymous No.6724720]

>>6724707
When I used to play games, I had a sega saturn controller hooked up to the parallel port. And I used the ppjoy driver to read it.

The nice thing about the parallel port controller is that the latency is literally zero. When you ask DirectInput to update the controller state it actually goes directly to the driver and polls the game pad on demand.

[Anonymous No.6724726]

>>6724717
I don't think that is what he was getting at. I think he was talking about racing the beam and rendering in strips instead of entire frame at once.

[Anonymous No.6724734]

>>6724726
if you don't mind tearing you could use run ahead to cut input lag back to the frame currenly being scanned out

[Anonymous No.6724783]

>>6724272
Heh! Didn't think so little fella. Looks like Youtube lied to you again.

[Anonymous No.6724936]

>>6724783
>seething intensifies
zoom zoom

[Anonymous No.6725095]

>>6724552
But this would interfere with game animations to just have a whole frame disappeared like that.

[Anonymous No.6725114]

>>6725095
no, it would not

[Anonymous No.6725121]

>>6725114
It would have to, you can't remove frame 2 of a three frame sequence without any visual impact

[Anonymous No.6725185]

>>6700797
>cries about how one of the features of this completely free software is "advertising"
>shills pointless overpriced hardware on the internet for free
anon....you are the advertisement

[Anonymous No.6725207]

>>6700432
/thread

[Anonymous No.6725303]

>>6725121
The game has built-in latency, and that's what you remove. You remove the frame where nothing happens before the animation starts.

[Anonymous No.6725320]

>>6725303
That's not how frame based animation works

[Anonymous No.6725332]

>>6725303
You know that polling the controller data is not the only thing that is happening between the frames

[Anonymous No.6725484]

>>6725320
Unless you're playing a 2600 game it is.
>>6725332
Irrelevant. The emulator handles everything else (e.g. polling memory cards) too, exactly the same as without runahead.

Runahead cannot cause glitches or any gameplay differences other than reduced latency unless misconfigured.

[Anonymous No.6725549]

>>6725484
Sorry but this is bullshit ... The only thing that run ahead is compensating is the time between the button press and the time the player moves (and this is a comstant number of frames) ... Its not that in the removed frame nothing else is happening but waiting for the next frame to do something. Sounds keep playing, logic is updated and animations keep going. If you remove this frames everithing is skiping.

Runahead is fucking skiping frames!

https://github.com/bsnes-emu/bsnes/blob/8e80d2f8a43e34a82931e25143b279e5fbcfaedc/bsnes/sfc/ppu/ppu.cpp

Line 194

Now stfu talking bullshit if you have no fucking clue what you are talking about.

[Anonymous No.6725579]

>>6725549
You don't seem to understand how runahead works.

[Anonymous No.6725620]

>>6725579
Yeah let me take a closer look ...

The Viewport ist only updated after the counter for the runahead reaches 0.

The DSP calculations are skipped until the counter reaches 0.

Same for the PPU ...

And wow even the msu1 even if nearly nobody uses it...

So i rushed over the bsnes source just to confirm you are a fucking retard talking bullshit.

[Anonymous No.6725645]

>>6725579
And if you dont get what this means it is calculating all the logic for the next frames without wasting time rendering them or bother the DSP ... Only after n steps the logic runs trough the full "pipeline" and is shown to the user ... It is literally skipping frames

[Anonymous No.6726018]

>>6725620
>>6725645
you're getting closer to understanding it
guess it's not as simple a concept as i thought, because your brain is practically on fire figuring out how retroarch is able to be in two different places at once

[Anonymous No.6726034]

>>6725549
Thank you, finally, somebody does a little fucking research!

I fucking TOLD YOU all that it causes skipped frames and stuttering,

CASE FUCKING CLOSED.

[Anonymous No.6726059]

>>6726034
>it works
>well it can't work, because <reason>
>but it literally works, like i'm using it right now
>yea but the source code is telling me it can't work
anon, it works, you can use it right now, there's no skipping or stuttering

>apple falls off tree right in front of your eyes
>that's impossible, this behaviour is not supported by my understanding of physics, it cannot be true

[Anonymous No.6726062]

>>6726059
Enjoy your altered animations and broken timing and RNG generation

[Anonymous No.6726106]

>>6726062
mate, if simple and technical explanations, as as well as video demonstrations won't help you, there's nothing else i can do
you don't want to know how this works, you're somehow convinced it can't despite being given resources on how it does.

[Anonymous No.6726110]

>>6726059
No one said it doesn't work, genius.

[Anonymous No.6726135]

>>6726110
you're still saying it causes stuttering, which is does not unless you configure it to run ahead more frames than the game lags, and even then it only causes your movement to look weird, everything else (like enemy movement or audio) in unaffected, even in this case
configured correctly, it does not alter animations, it does not break timing, it does not mess with RNG, and it does not cause stuttering
the only thing it skips is the time between pressing a button and the game acting on that button press, that's it, nothing happens on the screen so you're not missing anything

[Anonymous No.6726152]

>>6726135
YOU CAN'T SKIP TIME WITHOUT FUCKING UP TIMING

[Anonymous No.6726410]

>>6726018
Runahead is basically time-travel logic, so it's not surprising brainlets can't understand it. The skipped frames belong to a discarded timeline and have no influence on game logic in the main timeline.

[Anonymous No.6726701]

>>6700432
This post is the embodiment of the internet.

[Anonymous No.6726852]

>>6726135
Stop misrepresenting this to people, yes, it's great for some stuff like RPGs, but for fighting games for instance it'll really throw off your timing. No EVO tier player would play with this on.

[Anonymous No.6727168]

>>6726852
I can't stop. I'm an underage poorfag who has a serious chip on my shoulder because I can't afford the toys all the cool kids have. I fill the emptiness in my soul with the porkie pies I tell on the Internet.

[Anonymous No.6727173]

>>6726152
You can actually. You're always looking at n frames ahead with runahead.

[Anonymous No.6727174]

>>6727168
>>6726852
Why are you so angry at Retroarch's superiority?

[Anonymous No.6727419]

>>6727168
>porkie pies

>luv me amiger
>luv me speccy
>ate nintender and amerifats
>simple as

[Anonymous No.6727434]

what are your thoughts on ps1 dithering anons? i'm experimenting with resident evil 1 and retroarch has an option to up the colour to 32 instead of 16 and it helps eliminate some of the colour banding that happens without dithering. but i kind of like the dithering, except it looks so different depending on internal resolution.. do you typically turn dithering off or leave it on for the nostalgia/accuracy?

[Anonymous No.6727436]

>>6727434
Dithering goes well with a crt shader so I always leave it on.

[Anonymous No.6727521]

>>6726852
>for fighting games for instance it'll really throw off your timing. No EVO tier player would play with this on.
RA has configurable late polling, so you can perfectly match the timing of the competition hardware using a high-speed camera. Correctly configured runahead is ideal for training with less responsive hardware than used in competition.

[Anonymous No.6727534]

>>6700797
>Make you better at games
Anon I have real life shit that I work on getting better at. Games are supposed to be fun. Remember fun?