The State of Emulation topic

Anything from run & guns to modern RPGs, what else do you play?
User avatar
null1024
Posts: 3809
Joined: Sat Dec 15, 2007 8:52 pm
Location: ʍoquıɐɹ ǝɥʇ ɹǝʌo 'ǝɹǝɥʍǝɯos
Contact:

Re: The State of Emulation topic

Post by null1024 »

fandangos wrote: I really don't get the concept behind halfway image on fixed displays. I do understand it on crt tvs/monitors that display from top to bottom and left to right while drawing the screen but that's not the case.
Look up a video of an lcd display recorded with a slo-mo camera. You'll see it fade between frames from top to bottom. The whole screen doesn't quite update at once, it still goes left to right, top to bottom.
https://www.youtube.com/watch?v=3BJU2drrtCM
skip to 4:26
Come check out my website, I guess. Random stuff I've worked on over the last two decades.
fandangos
Posts: 144
Joined: Tue Sep 18, 2012 3:48 am

Re: The State of Emulation topic

Post by fandangos »

null1024 wrote:
fandangos wrote: I really don't get the concept behind halfway image on fixed displays. I do understand it on crt tvs/monitors that display from top to bottom and left to right while drawing the screen but that's not the case.
Look up a video of an lcd display recorded with a slo-mo camera. You'll see it fade between frames from top to bottom. The whole screen doesn't quite update at once, it still goes left to right, top to bottom.
https://www.youtube.com/watch?v=3BJU2drrtCM
skip to 4:26
I remember seeing this video but didn't grasp it updates the same way a crt does.

Still where does 8ms comes from? Are you inferring that rtings method might get different results based on the part of the screen is refreshing?
This can be solved using a just the average value you get from your test.

The only other assumption is, he is saying that rtings measurement are overestimated because of the point the screen is refreshing but it should be the other way around.
If it claims 10ms on a certain display the real lag is 18ms because the time the screen takes to draw from top to bottom.

But I believe in that they get it right if you take several measurements and just do the math to get the average value.
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: The State of Emulation topic

Post by orange808 »

It takes 16 2/3 ms for a CRT to draw a frame at 60 frames per second.

rtings.com measures the total latency at the center of the screen. That's a measurement taken when half the frame is drawn. rtings doesn't worry about anything but how long it took to draw half the screen.

That means: rtings measures how long the display takes to draw one half of a frame.

It takes a CRT ~8ms to draw one half of a frame, because the CRT draws each frame in 16 2/3 ms in a smooth and uniform manner.

Bottom line:
"Real" lag for video games designed to run at ~60fps on a CRT and measured at the center of the screen will be: the difference between the new modern display being tested and a real CRT.

Therefore: rtings.com lag measurement - 8ms (CRT lag at center of screen) = True display lag

rtings just measures how long it takes to draw half the frame. If you like you can say that the average display lag of a CRT at 60fps is about 8ms, but that's the lowest possible number a CRT can deliver. It's not sample and hold, so drawing the frame faster would create flicker.

So, there you go. ~8ms at the center of the screen is a perfect score, because CRT's are the gold standard.
We apologise for the inconvenience
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: The State of Emulation topic

Post by Xyga »

I think it's a lot about people's own understanding (or lack of it) or preference about the lag thing,

Some only look a the raw input lag (top of the screen very beginning of the frame) typically monitor reviews websites such as tftcentral, pcmonitors.info, etc
Some only care about the center-of-the-screen display lag (most popular/mainstream)
Some only mind the bottom, where the frame ends,
Some even take the three measurements and average the three figure, like displaylag.com, idk why.

Personally I prefer to know about the input lag first (top of the screen) even though I know the mid-screen total display lag is the most pertinent in practice.

What matters most is that people understand what the measuments mean. In lots of displays discussions people mix different fashions of lag measurements in total confusion, but I can't blame them since most websites that show lag measurements also fail to explain clearly-enough what they mean, how it works, what they're showing you and why.

That's why I've been for a while in favor of always showing all three lag measurements, top, middle, bottom, if all websites would do that that people might be confused for while but in the end there will be no room left for confusion anymore.
fandangos wrote:And when you say "lagless" how much is it? is 20ms lagless?
Well 0 is lagless...but we're only humans so honestly even about 1/4 of a frame (4~ms) at the top of the screen/beginning of the frame (+4ms = 8~ms midscreen), which is quite common today for monitors, can reasonably be called 'lagless'.

20ms, assuming we're talking about a middle screen measurement is not lagless but still quite good for most gaming, and again unless one is a competition cyborg it won't get in the way.
fandangos wrote:If retroarch had a decent scanline shadder (all sucks and are not what a scanline looks like) I would play it at 2048x1536@60hz on it at it's native resolution.
CRT-Royale can look pretty awesome http://shmups.system11.org/viewtopic.ph ... h&start=60 for shaders you absolutely need to use the native resolution of your display otherwise your output gets rescaled by the dispplay. Plus for shaders the higher output resolution to work on the better the results as they have more room to actually draw finer details.
But as good as those can look the motion of flat panel display's isn't as good as CRT's and when it moves a lot many details by those shaders are lost in the blur.
fandangos wrote:But that's not the focus of this discussion but I also want to add one other thing, maybe if you can convince me around this I would be happy to be proven wrong.
The Hi-Def NES is way sharper compared to retroarch at 4k. This doesn't make sense. I have bilinear filtering disabled and such but let me put it this way:
The hi def nes is sharp as the OSSC x5 and retroarch is sharp like the framemeister. Hope my analogy can paint a clear picture of how I see it.
I think something's wrong in your RA configuration.

Also remember the Hi-Def NES outputs 1080p at best, which means it is upscaled to 4K by your TV, so it can't be pixel-sharp, there's a bit of interpolation smoothing (most displays don't have a setting to allow disabling scaling interpolation), same for the OSSC and Mini.
RA on the other hand is output from a PC and therefore can use the full 4K resolution of your TV, and be pixel-sharp since when the full panel resolution is used and assuming you're in game or graphics mode (all tv processing disabled).
Really look into your RA settings and force it to output at 4K, then try shaders again, and if you see scaling artifacts ('scanlines' of uneven thickness, banding, or moire patterns) try enabling integer scaling in RA's settings as well, although this will force the picture to show at exact multiple values (selectable don't worry) and in cases mean you will see black borders or the opposite a pictore slightly too big, the result will often be cleaner and more accurate compared to the usual fractional scaling.
Strikers1945guy wrote:"Do we....eat chicken balls?!"
fandangos
Posts: 144
Joined: Tue Sep 18, 2012 3:48 am

Re: The State of Emulation topic

Post by fandangos »

orange808 wrote:It takes 16 2/3 ms for a CRT to draw a frame at 60 frames per second.

rtings.com measures the total latency at the center of the screen. That's a measurement taken when half the frame is drawn. rtings doesn't worry about anything but how long it took to draw half the screen.

That means: rtings measures how long the display takes to draw one half of a frame.

It takes a CRT ~8ms to draw one half of a frame, because the CRT draws each frame in 16 2/3 ms in a smooth and uniform manner.

Bottom line:
"Real" lag for video games designed to run at ~60fps on a CRT and measured at the center of the screen will be: the difference between the new modern display being tested and a real CRT.

Therefore: rtings.com lag measurement - 8ms (CRT lag at center of screen) = True display lag

rtings just measures how long it takes to draw half the frame. If you like you can say that the average display lag of a CRT at 60fps is about 8ms, but that's the lowest possible number a CRT can deliver. It's not sample and hold, so drawing the frame faster would create flicker.

So, there you go. ~8ms at the center of the screen is a perfect score, because CRT's are the gold standard.
I think I'm starting to get it now. This must be one of the most interesting things I've read in this forum.
But if this is correct, some monitors have 9ms according to rtings, does it mean it's actually 1ms display?

If this is true, it's really awesome.
But according to this:
https://forums.libretro.com/t/an-input- ... n/4407/424
A real snes on a real crt actually has 60 ms of input lag.

So if I understand you correctly, a crt takes 16ms to draw a frame, than 60 - 16, 44 ms are caused by the controller and the snes?
fandangos
Posts: 144
Joined: Tue Sep 18, 2012 3:48 am

Re: The State of Emulation topic

Post by fandangos »

Xyga wrote: CRT-Royale can look pretty awesome http://shmups.system11.org/viewtopic.ph ... h&start=60 for shaders you absolutely need to use the native resolution of your display otherwise your output gets rescaled by the dispplay. Plus for shaders the higher output resolution to work on the better the results as they have more room to actually draw finer details.
But as good as those can look the motion of flat panel display's isn't as good as CRT's and when it moves a lot many details by those shaders are lost in the blur.
The problem with crt-royale is it's not just scanlines.
I don't get the hype with shadders that emulate like tv apperture grile, or the curvature of the tube.
What I would like to find and RA is missing one that does it correctly, even if you disable all features of crt royale, is a x5 or x6 or even further scanlines for 4k displays.
My display is in game mode and everything is turned off. Sharpness is set to 50 which is half, because less causes a blurriness in the picture and more adds artifacts.

All we need is a "draw a black line here" shadder that can multiply correctly up to 6x.
I believe there's one simply called scanlines which multiplies up to 4x only. That's one, but not only problem with scanline shadders with RA.
There's just no option that I'm aware of and I looked into it.
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: The State of Emulation topic

Post by Xyga »

fandangos wrote:The problem with crt-royale is it's not just scanlines.
I don't get the hype with shadders that emulate like tv apperture grile, or the curvature of the tube.
Well the CRT shaders attempt to reproduce what CRT scanlines actually look like (tip; scanlines are the lit lines, not the black lines)
But Royale in particular takes a lot of learning, it can emulate various types of CRT that each look different assuming you take the time to learn what the settings do, one by one. Things like curvature, vignetting, bloom, dots, phosphors etc are all configurable and/or switchable.
fandangos wrote:What I would like to find and RA is missing one that does it correctly
But again CRT Royale is the one doing scanlines the most correctly, it seems you have the wrong idea.
Although of course it goes without saying that you're not forced to like it.
fandangos wrote:All we need is a "draw a black line here" shadder that can multiply correctly up to 6x.
I believe there's one simply called scanlines which multiplies up to 4x only. That's one, but not only problem with scanline shadders with RA.
There's just no option that I'm aware of and I looked into it.
I'm surprised there isn't a simpler 'lines' one that doesn't do that. Sorry I can't check myself as I don't currently own a 4K display.
I assume you have already discussed the topic on libretro forums?
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: The State of Emulation topic

Post by orange808 »

fandangos wrote: I think I'm starting to get it now. This must be one of the most interesting things I've read in this forum.
But if this is correct, some monitors have 9ms according to rtings, does it mean it's actually 1ms display?
Yep. 1ms in the middle of the screen. :)

That number is probably slightly larger at the top of the screen, because the monitor took a moment to do some processing before it drew the frame.

LCD and OLED draw the entire frame and hold it, so there's no worries about drawing too fast. With that in mind, LCD and OLED often draw a frame faster than a CRT can: faster than 16.66ms. The ability to draw so fast helps the display recover the time it spent processing a frame. So, there's a good chance there's zero, or negative, input lag (versus a CRT) at the bottom of a rtings "9ms" monitor.

Faster than a CRT! OMG! Well...
In the words of "The Wolf" after Tarentino says "I can't believe this is the same car.", let's not all start start (umm.. celebrating..) just yet. Sample and hold gives us shitty motion blur in return for a few milliseconds less of input lag at the bottom of the screen. It's not really worth celebrating.
fandangos wrote: If this is true, it's really awesome.
But according to this:
https://forums.libretro.com/t/an-input- ... n/4407/424
A real snes on a real crt actually has 60 ms of input lag.
I have never programmed a SNES, but I have enough exposure to speculate confidently. The machine doesn't have any significant hardware input lag.

The machine has registers (places in memory) that store the last known state of the controller. It's up to the software programmer to determine when the controllers are polled. The polling process itself is virtually instant. So, a specific game with 60ms of lag would be slow to react because the developers designed it that way. The process of the controller reading an input and transmitting the controller state to the console would never be more than one millisecond (and probably less than that).

What is being said there is that the results of the input for Yoshi's Island didn't appear on screen until after three frames. That's the software and display lag.

The SNES itself doesn't create lag. In theory, the controller could be polled more than 60 times per second. The big limitation is that the console can only send a new frame to the screen about sixty times a second. The second limitation is system's processing power versus the amount of things the game designers want the machine to perform.
We apologise for the inconvenience
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: The State of Emulation topic

Post by Xyga »

orange808 wrote:Yep. 1ms in the middle of the screen. :)
:lol:

No.
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: The State of Emulation topic

Post by orange808 »

Xyga wrote:
orange808 wrote:Yep. 1ms in the middle of the screen. :)
:lol:

No.
You know what I meant. :)

Also, I can't keep the websites straight. Is that one averaged or just the middle number?

And, do any of these people know the OSSC does lag testing?

But, I digress...

-------

Also, given the new time machine ability of Retroarch, I'll be grabbing a y wired cable, microswitch button, a pair of c&l joysticks, a raphnet usb, and a 120Hz camera in the next week to find out how good it really is with a PC versus real hardware on CRT's. Should be interesting.

I have a feeling that FPGA isn't magic anymore.

Across the board on many systems, it looks like a free frame just landed in our laps. Combined with the ability to delay frame processing, I'm expecting good results.
We apologise for the inconvenience
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: The State of Emulation topic

Post by Xyga »

orange808 wrote:
Xyga wrote:
orange808 wrote:Yep. 1ms in the middle of the screen. :)
:lol:

No.
You know what I meant. :)
I'm afraid not, I read you and I find your statement vs crt lag kinda convoluted, if the lag in the middle of the screen is 9ms it is 9ms period, that lenght is real, and it is therefore 1ms at the top, it can't be higher than the middle, when talking about a lagless monitor it always means input lag and therefore at the top.
If you begin to tell people it's 1ms in the middle and higher at the top they will just believe that and spread it...
orange808 wrote:Also, I can't keep the websites straight. Is that one averaged or just the middle number?
Well here's their new thing http://www.rtings.com/company/input-lag-tool not much better than the LB imho.
orange808 wrote:And, do any of these people know the OSSC does lag testing?
I'd trust the OSSC more but they absolutely want a tool fit for all resolutions up to 4K, well...
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: The State of Emulation topic

Post by orange808 »

Yep. 9ms is 9ms. Agreed.

My comparison to a CRT is convoluted, but input lag with emulators isn't a straightforward subject.
We apologise for the inconvenience
ZellSF
Posts: 2642
Joined: Mon Apr 09, 2012 11:12 pm

Re: The State of Emulation topic

Post by ZellSF »

RetroArch 1.7.2 is out with the new runahead feature, for people who didn't want to deal with the nightlies.
User avatar
soprano1
Posts: 3029
Joined: Wed Sep 18, 2013 4:44 pm
Location: Portugal

Re: The State of Emulation topic

Post by soprano1 »

http://www.uoyabause.org/
http://www.uoyabause.org/static_pages/download
Unofficial port of Yabause for Android, but it has a Windows port that works well. Small caveat, you must use the bin/cue format for games, iso doesn't have sound and mdf doesn't work. You also better use the real BIOs files, emulation of it is finicky. Configuring memory is a pain, but this post from reddit explains how to properly do it: https://www.reddit.com/r/emulation/comm ... r/dxzefzs/
ChurchOfSolipsism wrote:I'll make sure I'll download it illegally one day...
ZellSF
Posts: 2642
Joined: Mon Apr 09, 2012 11:12 pm

Re: The State of Emulation topic

Post by ZellSF »

PPSSPP 1.6 was out a few days ago (followed quickly by a 1.6.1 bugfix release):
OpenGL backend now properly multithreaded, giving a good speed boost.
Various Vulkan performance improvements (like #10911) and memory allocation fixes.
GPU command interpreter performance improvements (#10658)
Various fixes for app switching and widgets (#10855) on Android
Bugfixes and some performance improvements in the ARM64 JIT compiler and IR interpreter
Shader cache enabled for Vulkan
Multiple iOS fixes, including JIT (#10465) and file browser (#10921).
Improved compatibility on Mac (#10113)
Texture replacement ID bugfix (note: some textures from 1.5.4 may become incompatible)
Adhoc multiplayer fixes (#8975)
Vulkan support on Linux/SDL (#10413)
Retroarch support
Probably really nice if you're on a device that can't use Vulkan for whatever reason.
User avatar
WelshMegalodon
Posts: 1225
Joined: Fri Dec 11, 2015 5:09 am

Re: The State of Emulation topic

Post by WelshMegalodon »

The latest MAME adds support for a rather interesting peripheral:
Added preliminary keyboard support, hooked up to The Typing of the Dead, La Keyboard, and Lupin 3: the Typing on Naomi.
In case your machine is too new to run the Windows port of Typing of the Dead. Or you want to play with a friend.

Also:
Arbee wrote:A user on another board noted that the Saturn improvements in this version made NiGHTS Into Dreams almost completely correct except for one obvious glitch that doesn't hurt gameplay. Here's a video:

https://www.youtube.com/watch?v=Vt7xzBzoNRE
Indie hipsters: "Arcades are so dead"
Finite Continues? Ain't that some shit.
RBelmont wrote:A little math shows that if you overclock a Pi3 to about 3.4 GHz you'll start to be competitive with PCs from 2002. And you'll also set your house on fire
ZellSF
Posts: 2642
Joined: Mon Apr 09, 2012 11:12 pm

Re: The State of Emulation topic

Post by ZellSF »

WelshMegalodon wrote:The latest MAME adds support for a rather interesting peripheral:
Added preliminary keyboard support, hooked up to The Typing of the Dead, La Keyboard, and Lupin 3: the Typing on Naomi.
In case your machine is too new to run the Windows port of Typing of the Dead. Or you want to play with a friend.
Not that it's important, but the PC version of Typing of the Dead is pretty easy to get running on newer computers (and you can even force is to use high resolution using dgVoodoo2). Your best option for playing it would still probably be Dreamcast emulation though.
User avatar
soprano1
Posts: 3029
Joined: Wed Sep 18, 2013 4:44 pm
Location: Portugal

Re: The State of Emulation topic

Post by soprano1 »

https://github.com/snes9xgit/snes9x/releases/tag/1.56
SNES9x v1.56 is out. I know many people won't care for good reason, but the cheat system has been changed for the better, no more weird machine code. Many other fixes for some games as well.
ChurchOfSolipsism wrote:I'll make sure I'll download it illegally one day...
fandangos
Posts: 144
Joined: Tue Sep 18, 2012 3:48 am

Re: The State of Emulation topic

Post by fandangos »

I never fully grasped the entire concept of the run ahead thing but after seeing SmokeMonster's video:
https://www.youtube.com/watch?v=XGuLDsEkFXA

I think I fully understand it.

This must be the most retarded thing someone ever implemented into an emulator, ever.

Basically, you have 2 instances of RetroArch running or one that needs a cpu fast enough to be able to run at 2x speed.
You set the amount of frames you want to skip and when you press a button, you jump those frames.

When he is testing Mortal Kombat, he counts the frames and when you press a button you jump those amount of specified number.
This would only make any sense if the other character would stand still. The reason for reducing latency is that you can react faster but if I got this right, when you jump ahead, the rest of the game jump ahead too.

So what's the point? You are not reacting faster, the game isn't reacting faster.
You can do this by pressing a button, blinking your eyes and there you go: run ahead.

When people show this feature with Super Mario, it seems pretty awesome because Mario is standing there and jumps faster, that's great but the goomba is coming faster at the same time.

I'm amazed. Someone correct me if I'm wrong but if this works the way I'm thinking it does it's the most stupid thing ever created.
I can be wrong, though...
User avatar
tomwhite2004
Posts: 319
Joined: Fri Mar 08, 2013 12:13 pm
Location: UK

Re: The State of Emulation topic

Post by tomwhite2004 »

fandangos wrote:You set the amount of frames you want to skip and when you press a button, you jump those frames.
No, that's not how it works at all. The amount of frames removed does not take effect when you press a button, otherwise everything would be a stuttery mess and of no use to anyone. It brings the entire emulation forward by the amount of frames set so whilst you remove the sofwares input lag the game looks, plays and performs exactly as it would if the feature was not there at all.
fandangos
Posts: 144
Joined: Tue Sep 18, 2012 3:48 am

Re: The State of Emulation topic

Post by fandangos »

tomwhite2004 wrote:
fandangos wrote:You set the amount of frames you want to skip and when you press a button, you jump those frames.
No, that's not how it works at all. The amount of frames removed does not take effect when you press a button, otherwise everything would be a stuttery mess and of no use to anyone. It brings the entire emulation forward by the amount of frames set so whilst you remove the sofwares input lag the game looks, plays and performs exactly as it would if the feature was not there at all.
Not sure if it's the way you are describing but it makes no sense still.

The way you are saying seems like "if the game has 2 frames of lag is removes those 2 frames".
If it's not save state on demand this means if you play for 10 minutes and get 10.000 frames (random number just to make a point).
If you fast forward 2 frames this solved nothing. It would mean in a 10 min play you had 9.998 frames.

It must have a condition to where you shave those frames and all the explanations I saw where: it is a save state on demand. It jumps the amount of frames you desire to the state the other instance of the emulator is running.
User avatar
tomwhite2004
Posts: 319
Joined: Fri Mar 08, 2013 12:13 pm
Location: UK

Re: The State of Emulation topic

Post by tomwhite2004 »

fandangos wrote:If you fast forward 2 frames this solved nothing. It would mean in a 10 min play you had 9.998 frames.
Those two frames make up for the input lag that my HDTV has, meaning the response (visual and input) is then in line with what I would experience if I was playing real hardare on a CRT, that's the problem this solves.

And in ten minutes you would still see 10.000 frames, not 9.998.
ZellSF
Posts: 2642
Joined: Mon Apr 09, 2012 11:12 pm

Re: The State of Emulation topic

Post by ZellSF »

fandangos wrote:I never fully grasped the entire concept of the run ahead thing but after seeing SmokeMonster's video:
https://www.youtube.com/watch?v=XGuLDsEkFXA

I think I fully understand it.

This must be the most retarded thing someone ever implemented into an emulator, ever.

Basically, you have 2 instances of RetroArch running or one that needs a cpu fast enough to be able to run at 2x speed.
You set the amount of frames you want to skip and when you press a button, you jump those frames.

When he is testing Mortal Kombat, he counts the frames and when you press a button you jump those amount of specified number.
This would only make any sense if the other character would stand still. The reason for reducing latency is that you can react faster but if I got this right, when you jump ahead, the rest of the game jump ahead too.

So what's the point? You are not reacting faster, the game isn't reacting faster.
You can do this by pressing a button, blinking your eyes and there you go: run ahead.

When people show this feature with Super Mario, it seems pretty awesome because Mario is standing there and jumps faster, that's great but the goomba is coming faster at the same time.

I'm amazed. Someone correct me if I'm wrong but if this works the way I'm thinking it does it's the most stupid thing ever created.
I can be wrong, though...
Just Google "Retroarch runahead explained"? You're wrong, but you're far from the only person who has trouble comprehending this and there's plenty of explanations out there.

Basically: you're sending inputs to the past. That goomba that hit you? Press jump and it'll send an input to the past before the goomba hit you, and then show you the result of that alternate timeline.

Now you're thinking "hold on, won't that look weird, won't I have reacted to a scenario that didn't happen"? Which is why you need to set runahead to equal that of the game's internal lag.

If Mario takes 2 frames to react to any command, set runahead to 2 and he'll now react instantly because you told him to react 2 frames in the past. Since neither of the 2 frames you skip to get to the "present" would create any reaction, the game wouldn't be in an inconsistent state ("jitter"). Mario would just react 2 frames faster. Now if your HDTV has 2 frames of lag, guess what? You're playing the game as intended.
Last edited by ZellSF on Mon Jun 11, 2018 5:55 pm, edited 1 time in total.
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: The State of Emulation topic

Post by orange808 »

Hats off to tomwhite for explaining that calmly. :)

It only works for removing lag that is created by software. When set to one frame (you can do more), the feature (effectively) moves your button press to the frame before you pressed it. If thinking about juggling the save states makes your head hurt, just think of it as a time machine for your button presses. That's the best explanation for the results you'll feel.

Naturally, if you start moving your button presses too far back, you'll exceed the software's inherent developer programmed input lag and things will glitch out. This is just to remove software input lag.

As tomwhite noted, removing software lag can offset display lag, emulation overhead lag, and/or controller lag.

There's nothing "retarded" about it.
We apologise for the inconvenience
fandangos
Posts: 144
Joined: Tue Sep 18, 2012 3:48 am

Re: The State of Emulation topic

Post by fandangos »

tomwhite2004 wrote:
fandangos wrote:If you fast forward 2 frames this solved nothing. It would mean in a 10 min play you had 9.998 frames.
Those two frames make up for the input lag that my HDTV has, meaning the response (visual and input) is then in line with what I would experience if I was playing real hardare on a CRT, that's the problem this solves.

And in ten minutes you would still see 10.000 frames, not 9.998.
Ok, you explained nothing but I was completely wrong as how it works and it's quite bizarre.
It works the same way as Net Code in network game play.

Image

It IS triggered by your input but what it does is, it inserts your input actually in the amount of frames you specify BEFORE you actually pressed and it keeps the instance of the emulator where you would have pressed the button before.

Actually I eat my words, it's not retarded at all, it's clever as hell.
fandangos
Posts: 144
Joined: Tue Sep 18, 2012 3:48 am

Re: The State of Emulation topic

Post by fandangos »

ZellSF wrote: Just Google "Retroarch runahead explained"? You're wrong, but you're far from the only person who has trouble comprehending this and there's plenty of explanations out there.

Basically: you're sending inputs to the past. That goomba that hit you? Press jump and it'll send an input to the past before the goomba hit you, and then show you the result of that alternate timeline.

Now you're thinking "hold on, won't that look weird, won't I have reacted to a scenario that didn't happen"? Which is why you need to set runahead to equal that of the game's internal lag.

If Mario takes 2 frames to react to any command, set runahead to 2 and he'll now react instantly because you told him to react 2 frames in the past. Since neither of the 2 frames you skip to get to the "present" would create any reaction, the game wouldn't be in an inconsistent state ("jitter"). Mario would just react 2 frames faster. Now if your HDTV has 2 frames of lag, guess what? You're playing the game as intended.

Yeah, I founded the explanation in this blog:
http://filthypants.blogspot.com/2016/03 ... cy-in.html

I understand the concept of two timelines in emulation but it IS triggered by your input.

If you have a CRT and a LCD in Movie mode (130 ms lag++), if you run a game intro, without pressing anything, just load your rom and leave it.
If you have a fast speed camera, you would still see the image to show up first on the CRT.

It's clever, I was wrong, but still this doesn't solve a problem, you see the image first on the CRT.
Or is this wrong to assume?

EDIT: I just read your reply after finding out this blog explaining it. That's the reason I'm double posting.

EDIT 2: Also, if a game has 2 frames of inner lag and your display has 2 frames of lag, you would still have 2 frames of lag if you set run ahead 2 frames. I mean this part must be wrong but I can't find why 4 frames wouldn't be the correct answer here.
ZellSF
Posts: 2642
Joined: Mon Apr 09, 2012 11:12 pm

Re: The State of Emulation topic

Post by ZellSF »

fandangos wrote:If you have a CRT and a LCD in Movie mode (130 ms lag++), if you run a game intro, without pressing anything, just load your rom and leave it.
If you have a fast speed camera, you would still see the image to show up first on the CRT.

It's clever, I was wrong, but still this doesn't solve a problem, you see the image first on the CRT.
Or is this wrong to assume?
Why's that a problem? You see the introduction 130ms later on a LCD, just turn on the LCD 130ms earlier? I know time is precious, but I think you can spare 130ms whenever you start a game...

In what scenario is this realistically a problem that needs to be solved?
fandangos wrote: EDIT 2: Also, if a game has 2 frames of inner lag and your display has 2 frames of lag, you would still have 2 frames of lag if you set run ahead 2 frames.
Yes, you would, because you're trying to replicate a game that has two frames of lag. Getting rid of those two frames of lag would be cheating.
fandangos wrote:I mean this part must be wrong but I can't find why 4 frames wouldn't be the correct answer here.
Not sure where you're getting 4 frames from anywhere in this conversation.
fandangos
Posts: 144
Joined: Tue Sep 18, 2012 3:48 am

Re: The State of Emulation topic

Post by fandangos »

ZellSF wrote: Why's that a problem? You see the introduction 130ms later on a LCD, just turn on the LCD 130ms earlier? I know time is precious, but I think you can spare 130ms whenever you start a game...

In what scenario is this realistically a problem that needs to be solved?
That's not what I meant. But I think I understand the confusion I'm making here.
An LCD with lag will have a consistent 100+ ms, for some reason I was thinking this would be added all the time but that wouldn't make any sense because this would just sum up.

And also, I was trying to say that if the image takes longer to show up on a LCD panel, you would still see the image later so you would react later but since your input goes into the past you are reacting at the correct time. My confusion here.
fandangos wrote: EDIT 2: Also, if a game has 2 frames of inner lag and your display has 2 frames of lag, you would still have 2 frames of lag if you set run ahead 2 frames.
ZellSF wrote: Yes, you would, because you're trying to replicate a game that has two frames of lag. Getting rid of those two frames of lag would be cheating.
I mean this part must be wrong but I can't find why 4 frames wouldn't be the correct answer here.
Not sure where you're getting 4 frames from anywhere in this conversation.[/quote]

Ok, this I'm not following.
Games have inner lag, a lag caused by the code of the game, this means a real snes hooked into a crt would have this lag.
Let's say this is a 2 frame lag.
Now this game is hooked into a LCD panel that adds another 2 frames of lag.

Now if you turn run ahead on, set it to 2 frames you would be covering the game internal lag, caused by the code, like in the SmokeMonster's video you see that MK Snes has more lag compared to Genesis version.
But you would still have the 2 frames of lag on your display.

Also if I understand it correctly, when you boot the game, the way it works you would not see the initial 2 frames so it can catch up with what it should be on a CRT. I mean, this would also mean if you have a fast speed camera and have a counter rolling on the CRT and LCD both would be exactly on the same frame?
User avatar
tomwhite2004
Posts: 319
Joined: Fri Mar 08, 2013 12:13 pm
Location: UK

Re: The State of Emulation topic

Post by tomwhite2004 »

fandangos wrote:but it IS triggered by your input.
No it isn't. Retroarch polls the controllers every frame and does the run ahead regardless of if you press any buttons or not. In other words run ahead is always on, you are always being shown a future frame and that is NOT triggered / activated by your input.

https://www.resetera.com/threads/retroa ... st-6914153
fandangos wrote:EDIT 2: Also, if a game has 2 frames of inner lag and your display has 2 frames of lag, you would still have 2 frames of lag if you set run ahead 2 frames. I mean this part must be wrong but I can't find why 4 frames wouldn't be the correct answer here.
4 frames isn't correct because you have removed 2 frames from the game, all you then have left is the 2 frames of lag from your display.

However for the sake of balance there is more than likely additional lag from a PC's operating system and other processes which contribute to you still having more lag than if you were playing real hardware on a CRT. And a lot of games I have tested only have a single frame to remove from the game, it's still an improvement however and a nice option to be able to claw back some, if not all of the lag introduced by our modern screens and hardware.
Last edited by tomwhite2004 on Mon Jun 11, 2018 7:13 pm, edited 1 time in total.
ZellSF
Posts: 2642
Joined: Mon Apr 09, 2012 11:12 pm

Re: The State of Emulation topic

Post by ZellSF »

fandangos wrote: Ok, this I'm not following.
Games have inner lag, a lag caused by the code of the game, this means a real snes hooked into a crt would have this lag.
Let's say this is a 2 frame lag.
Now this game is hooked into a LCD panel that adds another 2 frames of lag.

Now if you turn run ahead on, set it to 2 frames you would be covering the game internal lag, caused by the code, like in the SmokeMonster's video you see that MK Snes has more lag compared to Genesis version.
But you would still have the 2 frames of lag on your display.
They're just different sources of lag, where your lag comes from doesn't really matter as long as your end result is 2 frames of lag (as the hypothetical game here is designed for).
fandangos wrote:Also if I understand it correctly, when you boot the game, the way it works you would not see the initial 2 frames so it can catch up with what it should be on a CRT. I mean, this would also mean if you have a fast speed camera and have a counter rolling on the CRT and LCD both would be exactly on the same frame?
If you delay the startup of the CRT to match the LCD then they would match up, yes. If they you don't, they won't. It's not actually real time travel.

I'm really confused as why you keep talking about this, what scenario do you have that requires syncing up a CRT and LCD exactly to within a few frames?
Post Reply