100% Lagless Emulation is Here!

A place where you can chat about anything that isn't to do with games!
Dochartaigh
Posts: 1519
Joined: Thu Mar 02, 2017 6:53 pm

Re: 100% Lagless Emulation is Here!

Post by Dochartaigh »

Question for you guys, less lag can always be good, but when it's been scientifically proven that even fighter pilots, Formula One drivers, and championship video game players still take 100-120ms at the ABSOLUTE lowest to react to what they see on screen. If I did the math right on the lower end that's 0.1 seconds, or 6 frames of lag (on a tradition 60 FPS retro video game), so if that's the case why would dropping lag even lass than the native hardware ever even matter?
User avatar
Keade
Posts: 384
Joined: Mon Jul 16, 2007 8:44 pm

Re: 100% Lagless Emulation is Here!

Post by Keade »

You are kind of comparing apple and oranges, games are not about reacting about things on screen at the moment they happen, most of the time at least. Also, they are a continuous feedback loop, which is why the tighter that loop, the more natural it feels.
Even if they were only about reacting to instaneous events, delay would still be detrimental. Do you think a formula one driver would be happy to drive a car that delays wheel input ( :mrgreen: ) by 100ms, because 100ms is his own reaction time ? Of course not ! ;)

edit : I think there are scientifical studies. The 100ms is probably accurate (it is really, really low). Here is a link if you want to read more about it https://www.blurbusters.com/human-refle ... tion-time/
Last edited by Keade on Mon Aug 06, 2018 8:36 pm, edited 12 times in total.
fandangos
Posts: 144
Joined: Tue Sep 18, 2012 3:48 am

Re: 100% Lagless Emulation is Here!

Post by fandangos »

Is there really any scientific study about this?
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: 100% Lagless Emulation is Here!

Post by orange808 »

Yes. The lag was planned and the devs deemed it necessary. When you play the real game, it's in there. The point of removing the software input latency is to circumvent display latency and get the same experience as real hardware.

Lag in your game loop can come from: managing a frame buffer, avoiding odd timing issues, collision detection, and good old fashioned hardware limitations. I never programmed the SNES in any way, so I have no idea how the frame buffer is handled. I do know that good "timing safe" libraries weren't really a thing in 1991 and the games use collision boxes.

For SMW, it feels very nice. Although, there are still some odd hitches in scrolling here and there. It was probably the first game written on the SNES, so it was a learning experience for Nintendo. I can't complain.

FWIW, Bubsy feels much more sluggish than SMW and the game sucks, so I think Nintendo did the right thing. Yoshi's Island is also more sluggish, but it is excellent; so, credit to Nintendo again.
We apologise for the inconvenience
User avatar
Despatche
Posts: 4196
Joined: Thu Dec 02, 2010 11:05 pm

Re: 100% Lagless Emulation is Here!

Post by Despatche »

Please, "it's in the game" didn't even work for EA Sports. Devs did strange things (probably while drunk/high), many people either totally gloss over these strange things or worship them, etc.

Uh, the 2D Bubsys are alright games... a little cruel to the player, but very playable. Haven't played the Jaguar game as much as I'd like though, Jaguar emulation is still a pain. Kinda want a Jaguar at some point...
Last edited by Despatche on Mon Aug 06, 2018 8:51 pm, edited 1 time in total.
Rage Pro, Rage Fury, Rage MAXX!
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: 100% Lagless Emulation is Here!

Post by orange808 »

Despatche wrote:Uh, the 2D Bubsys are alright games... a little cruel, but very playable. Haven't played the Jaguar game as much as I'd like though, Jaguar emulation is still a pain. Kinda want a Jaguar at some point...
The collision detection on the SNES Bubsy is poorly done and inconsistent.
We apologise for the inconvenience
User avatar
Despatche
Posts: 4196
Joined: Thu Dec 02, 2010 11:05 pm

Re: 100% Lagless Emulation is Here!

Post by Despatche »

"collision detection" is generally a matter of personal preference, with no real standards or even guiding principles. It shouldn't be at all, but it is, and far too many games with no clear collision problems are rated as otherwise because one idiot back in 1993 was terrible at the game and everyone else believed what they said. "collision detection" is almost always a buzzword from undiscerning children, and very rarely a legitimate criticism of a video game.

Imagine if everyone got similarly mad at the first Goomba in World 1-1 of Super Mario Bros and had the game hanged. Just imagine that for a second.
Rage Pro, Rage Fury, Rage MAXX!
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: 100% Lagless Emulation is Here!

Post by orange808 »

Despatche wrote:"collision detection" is generally a matter of personal preference, with no real standards or even guiding principles. It shouldn't be at all, but it is, and far too many games with no clear collision problems are rated as otherwise because one idiot back in 1993 was terrible at the game and everyone else believed what they said. "collision detection" is almost always a buzzword from undiscerning children, and very rarely a legitimate criticism of a video game.

Imagine if everyone got similarly mad at the first Goomba in World 1-1 of Super Mario Bros and had the game hanged. Just imagine that for a second.
Well, most of us grew up playing Atari. That's pixel perfect hardware collision detection. :)

So, my complaints aren't a buzzword and I wasn't a kid in 1993. When I was a kid, I got accustomed to perfect collision detection. Play what you like, but I'm not going to back down on games I know have issues.
We apologise for the inconvenience
User avatar
Sumez
Posts: 8019
Joined: Fri Feb 18, 2011 10:11 am
Location: Denmarku
Contact:

Re: 100% Lagless Emulation is Here!

Post by Sumez »

orange808 wrote: Lag in your game loop can come from: managing a frame buffer, avoiding odd timing issues, collision detection, and good old fashioned hardware limitations. I never programmed the SNES in any way, so I have no idea how the frame buffer is handled. I do know that good "timing safe" libraries weren't really a thing in 1991 and the games use collision boxes.
The SNES doesn't have a frame buffer. The stuff you are talking about only really applies to modern hardware with more layers of abstraction. On "primitive" hardware like most 8 and 16 bit consoles, you poll the controller hardware directly, and write "directly" (ie. through registers or DMA) to the memory that the PPU will draw from on the next frame during each vblank. There's really nothing there to add lag aside from code intentionally designed to do it.

It could be a "collision detection" thing I guess - ie. the game spends one frame checking if Mario is free to jump, and then moves the first coordinate on the next frame. But even if that didn't sound strangely illogical on its own, it would also mean that the lag would hardly be consistent across all action (jumping, walking, shooting, etc.).

What especially puzzles me here is that every time people talk about this runahead thing, they make it sound like this isn't a rarity, but rather that the majority of retro games supposedly have some sort of inherent input lag. Either I'm misunderstanding something, or I'm overlooking something really obvious.
Last edited by Sumez on Mon Aug 06, 2018 9:40 pm, edited 2 times in total.
User avatar
DietSoap
Posts: 238
Joined: Thu Jul 29, 2010 8:42 pm

Re: 100% Lagless Emulation is Here!

Post by DietSoap »

Shepardus wrote:please, even if input lag was a known thing developers had to deal with, I would hardly call it a part of their "vision."
Even it it's not part of their vision (obvious), it affects the final product because they balanced their game with that lag in mind. While I think this is cool, I'd rather just play without added lag.
Dochartaigh
Posts: 1519
Joined: Thu Mar 02, 2017 6:53 pm

Re: 100% Lagless Emulation is Here!

Post by Dochartaigh »

orange808 wrote:Yes. The lag was planned and the devs deemed it necessary. When you play the real game, it's in there. The point of removing the software input latency is to circumvent display latency and get the same experience as real hardware.
Great way to put it right there....but what happens when people go even further, and 'cheat' the system? I know a lot of people are into the speedrunning and competitions and high-scores and all that (which I could care less about). Think the gameplay itself, if you're ONLY playing for fun, will suffer in any way if you take out even the lag which the developers, on purpose, added to the games?
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: 100% Lagless Emulation is Here!

Post by orange808 »

Sumez wrote:
orange808 wrote: Lag in your game loop can come from: managing a frame buffer, avoiding odd timing issues, collision detection, and good old fashioned hardware limitations. I never programmed the SNES in any way, so I have no idea how the frame buffer is handled. I do know that good "timing safe" libraries weren't really a thing in 1991 and the games use collision boxes.
The SNES doesn't have a frame buffer. The stuff you are talking about only really applies to modern hardware with more layers of abstraction. On "primitive" hardware like most 8 and 16 bit consoles, you poll the controller hardware directly, and write "directly" (ie. through registers or DMA) to the memory that the PPU will draw from on the next frame during each vblank. There's really nothing there to add lag aside from code intentionally designed to do it.

It could be a "collision detection" thing I guess - ie. the game spends one frame checking if Mario is free to jump, and then moves the first coordinate on the next frame. But even if that didn't sound strangely illogical on its own, it would also mean that the lag would hardly be consistent across all action (jumping, walking, shooting, etc.).

What especially puzzles me here is that every time people talk about this runahead thing, they make it sound like this isn't a rarity, but rather that the majority of retro games supposedly have some sort of inherent input lag. Either I'm misunderstanding something, or I'm overlooking something really obvious.
Except, my first programming experience was with LISA assembler on the Apple //. I know what you're saying, but you don't really get it. You're just parroting the internet--and you're spreading some dangerous misinformation here.

Storing a frame in memory is a frame buffer. You're right that it doesnt automatically imply latency, but it is a frame buffer.

Unless you were Dan Gorlin, we used a 2x frame buffer and flipped the graphics pages between $2000-$3FFF and $4000-$5FFF. That was double buffering and it wasn't modern hardware.

And, even if I only had one page of memory, it would still be a frame buffer because it holds the entire frame. That would be a single buffer. So, let's not spread misinformation and redefine what a frame buffer is--or say that frame buffers are new. That's simply not true.

The only console with no frame buffer is the Atari. It doesn't have the RAM. Thus the term: racing the beam.

Timing problems with collision detection happen very easily. It's not as complex as coding thread safe can be, but you still can encounter some bizarre gotchas. Pause Blaster Master some time and you'll see a bug in this family. Even better, touch the key and Bowser's nose at the same time in SMB or jump into a brick backwards while ducked and let go of the control pad. Congrats, you glitched the collision detection. Getting stuck in the bricks is the best example, but they are all related.
We apologise for the inconvenience
User avatar
Sumez
Posts: 8019
Joined: Fri Feb 18, 2011 10:11 am
Location: Denmarku
Contact:

Re: 100% Lagless Emulation is Here!

Post by Sumez »

orange808 wrote: Except, my first programming experience was with LISA assembler on the Apple //. I know what you're saying, but you don't really get it. You're just parroting the internet--and you're spreading some dangerous misinformation here.
I'm not parroting anything. I'm talking out of experience programming stuff on the SNES.
Storing a frame in memory is a frame buffer. You're right that it doesnt automatically imply latency, but it is a frame buffer.
I think that's a misleading way to put it, since you aren't buffering anything, and talking about frame buffers usually refers to completely different things.
First of all, you aren't storing "a frame" of anything, you are simply managing the nametable and object table memory areas of the video chip, which is being used to generate something that looks likes a video game when it draws each scanline, based on other settings like the active video mode, scroll coordinates, etc.
I've never in my life heard anyone referring to the video RAM of the SNES as a "buffer". It's never reading a pixel by pixel indication of what a frame looks like, and that information isn't stored anywhere. It's sent live, directly to the TV/monitor via progressive scan analog video. That's actually an extremely important detail when we're on the subject of what causes lag.

Now, during the game logic you might want to calculate a lot of stuff that needs to be modified for the next frame, so you can put that in a buffer (or some times even spend two frames putting it in a buffer), and read from that buffer on the next vblank. Actually, for the SNES that's how you need to do it, since the only way to write to video RAM is via DMA. But that's not a frame buffer.
Unless you were Dan Gorlin, we used a 2x frame buffer and flipped the graphics pages between $2000-$3FFF and $4000-$5FFF. That was double buffering and it wasn't modern hardware.
That kind of stuff probably makes sense for the Apple II, which is more of a home computer than a video game console. I don't know anything about it, but if it's anything like the C64, its video hardware is completely different from the console games we are talking about here.
Trust me, aside from some video rendering trickery, no classic 8- or 16-bit consoles did any of the sort. The best example I can think of is homebrew demos such as this whichruns at 15fps (I think?) using nametable switching for double buffering. Normally on the NES, changing nametables is done exclusively to simulate scrolling an area bigger than two screens.
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: 100% Lagless Emulation is Here!

Post by orange808 »

I'm sorry you never got the memo, but that block of video memory we manipulate is a frame buffer by definition. That's what we call that. We may or may not build additional buffers with our own code, but it is the frame buffer.

Once we start poking around in assembler and working on the metal, the key differences with these machines are the built in convenience routines we have available. AKA, you have routines that we can call directly that outperferm the code we write--because our code runs with multiple inherent overhead penalties. So, the video convenience routines you have available on a game console aren't black magic.

The SNES was designed with video in mind and you have a library of convenience routines that run directly on the metal? Every machine is like that. It depends on the hardware's intended purpose.

That doesn't mean we aren't manipulating the frame buffer.

And, actually, the C64 is much much more like a game console than the Apple or IBM machines are. So much easier... That was my first exposure to proper hardware sprites.
We apologise for the inconvenience
User avatar
Sumez
Posts: 8019
Joined: Fri Feb 18, 2011 10:11 am
Location: Denmarku
Contact:

Re: 100% Lagless Emulation is Here!

Post by Sumez »

No, video memory is not necessarily a frame buffer. If it doesn't contain complete copy of the next frame it needs to output (typically as a bitmap), using that terminology doesn't make any sense. Even Wikipedia agrees with me.

Either way, we are discussing semantics here. I can see that you know what you're talking about even if you got some terms wrong, so I kinda get what you were talking about when you first brought it up. Again, it just doesn't make sense in terms of input lag, as SMW has no realistic way of storing video data that isn't used immediately on the next frame.
orange808 wrote: The SNES was designed with video in mind and you have a library of convenience routines that run directly on the metal? Every machine is like that. It depends on the hardware's intended purpose.

That doesn't mean we aren't manipulating the frame buffer.
I'm really confused what you are talking about here. Either you are actually misunderstanding how the SNES works here, or this is just another case of your terminology being misleading.

Everything going on with the SNES outputting an image is 100% hardware, done on the fly for every single scanline! I don't know what a "convenience routine" is, but if you're talking about calling a series of registers to activate a DMA transfer, yes you have that. But you make it sound a lot less low level than it is. The SNES does not let you do anything to communicate with the video chip via your code, aside from moving blocks of data from the CPU RAM to video RAM, it's pretty hands-on.
Or are you maybe talking about the hardware process that reads from the designated areas in ram to calculate what color of pixel to output? Because that's a video chip, in the case of the SNES dubbed the "PPU". It is its entire purpose. Referring to that as a "library of routines" is a surefire way to make sure no one understands what you are talking about.
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: 100% Lagless Emulation is Here!

Post by orange808 »

We're definitely arguing terminology and semantics. :) I'm using video and frame buffer interchangeably. Depending on the situation, it might be convenient to only reference user allocated memory as a frame buffer? Okay. I'll give it you.

I don't have much affection for jargon. It always gets in the way. Of course we're discussing low level here, it's assembler! :) At the same time, telling people that we have to use an opcode and registers doesn't really do much to help them understand, either.

Each new machine I encountered had a different set of routines I could call to handle some tasks more quickly--at least in theory, but messing with video games in high school gave away to different pursuits and I ended up dealing with computers and worrying about timing issues with databases. So, I definitely don't have any specifics on programming a SNES. On the other hand, from my point of view hacking code, the differences between machines (besides the syntax, op codes, and convention for addressing) really always boiled down to the basic hardware routines I could call to get things done faster/easier.

Anyhow, I still stand by the devs here and their choices; they used some latency in their design and that's fine. All of us get invested in our design choices and use a hack or two to make it work. Also, the game feels responsive enough, so no harm and no foul.
We apologise for the inconvenience
User avatar
JBC
Posts: 3818
Joined: Wed Mar 30, 2005 3:14 am

Re: 100% Lagless Emulation is Here!

Post by JBC »

I've been able to get this to work in Picodrive with Knuckles Chaotix, a game I knew to be notoriously laggy in Retroarch compared to running it on real hardware. However, when I try it with Viper Phase 1 using MAME 0.199 I can't seem to get any results. Does it not work for MAME?
Godzilla was an inside job
User avatar
OmegaFlareX
Posts: 884
Joined: Tue Jan 25, 2005 10:15 pm
Location: Virginia, USA

Re: 100% Lagless Emulation is Here!

Post by OmegaFlareX »

tomwhite2004 wrote:Ditto, with both MAME and Final Burn Alpha. From what I have read and experienced it seems that it is 50/50 if a game will work properly or not with those cores. Some have the sound too fast, some too slow with no way of correcting anything if that is the case.
Regarding MAME in Retroarch, for whatever reason, regardless of sync settings, the audio will always output at the speed of your monitor's refresh rate, if that makes sense.

Since lots of arcade games are non-60hz, this creates a problem. Flying Shark, for example, runs at 54.9hz. In Retroarch, the audio will be too high-pitched (it's running too fast), even though the video is updating at the proper rate.

Until Retroarch fixes this, it is useless for MAME emulation of non-60hz hardware.
User avatar
tomwhite2004
Posts: 319
Joined: Fri Mar 08, 2013 12:13 pm
Location: UK

Re: 100% Lagless Emulation is Here!

Post by tomwhite2004 »

OmegaFlareX wrote:
tomwhite2004 wrote:
Regarding MAME in Retroarch, for whatever reason, regardless of sync settings, the audio will always output at the speed of your monitor's refresh rate, if that makes sense.

Since lots of arcade games are non-60hz, this creates a problem. Flying Shark, for example, runs at 54.9hz. In Retroarch, the audio will be too high-pitched (it's running too fast), even though the video is updating at the proper rate.

Until Retroarch fixes this, it is useless for MAME emulation of non-60hz hardware.
I was referrring more to run ahead causing additional issues than the dynamic rate contol skewing the audio to match you refresh. For example audio runs at half speed with Garegga + run ahead, it just doesn't work properly.

But yeah for the reason you mentioned and various UI issues I dont like Retroarch for MAME at all, however I was still curious to see if it worked or not as for a few regular games that I play which are all near as dammit 60hz already it could have been a nice option.
Last edited by tomwhite2004 on Wed Aug 08, 2018 4:28 pm, edited 1 time in total.
fandangos
Posts: 144
Joined: Tue Sep 18, 2012 3:48 am

Re: 100% Lagless Emulation is Here!

Post by fandangos »

Are you guys aware of this?

https://www.bountysource.com/issues/608 ... untysource

There's a beta version of groovymame with it.
And I might be wrong but MAME supports more than arcade pcbs, correct?

So it would be really cool to test it with some genesis and snes games.


Also, since many people here understand much more than me about emulation, could someone clarify this for me:
If lagless vsync or raster beam racing is properly implemented and you output 15khz to a CRT, would still be any difference compared to a real hardware?

Or second scenario, you using raster beam racing with runahead just to compensate windows and usb lag, that would be pretty spot on, right? Or am I missing something?
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: 100% Lagless Emulation is Here!

Post by orange808 »

fandangos wrote:Are you guys aware of this?

https://www.bountysource.com/issues/608 ... untysource

There's a beta version of groovymame with it.
And I might be wrong but MAME supports more than arcade pcbs, correct?

So it would be really cool to test it with some genesis and snes games.


Also, since many people here understand much more than me about emulation, could someone clarify this for me:
If lagless vsync or raster beam racing is properly implemented and you output 15khz to a CRT, would still be any difference compared to a real hardware?

Or second scenario, you using raster beam racing with runahead just to compensate windows and usb lag, that would be pretty spot on, right? Or am I missing something?
Sure. We're aware.

This technique removes the overhead of vsync and managing the frame buffer. It is meant to produce 1:1 timing sync between the machine and the display. In theory, you could have 240p output; I don't see why not--as long as the video card allows it.

USB hardware input lag is not directly related to this at all. If you're doing it right, that shouldn't be an issue under any conditions--anymore. Get a good USB controller adapter that polls every millisecond. Any additional input lag would depend on the emulator itself and the game you are playing.

Mark from Blur Busters explains the technique very well here:
Mark at Blur Busters wrote: "...While high-frameslice-rate beamracing requires a powerful GPU, especially with HLSL filters, low-frameslice beamracing makes it easier to run cycle-exact emulation at a very low latency on less powerful hardware - the emulator can merrily emulate at 1:1 speed (no surge execution needed) spending more time on power-consuming cycle-exactness or ability to run on slower mobile GPUs. You're simply early-presenting your existing incomplete offscreen emulator framebuffer (as it gets progressively-more-complete)...

...

...Emulators can merrily run at original machine speed. Essentially streaming pixels darn-near-raster-realtime (submillisecond difference). What many people don't realize is 1080p and 4K signals still top-to-bottom scan like an old 60Hz CRT in default monitor orientation -- we're simply synchronizing to cable scanout, the scanout method of serializing 2D images to a 1D cable is fundamnetally unchanged. Achieving real raster sync between the emulator raster and real raster!..."
source linky here:
https://www.bountysource.com/issues/608 ... untysource

Also, this technique is interesting for more than latency. If we can get a high enough frame rate to render one scanline each frame, we can start to simulate CRT behavior--and kill that nasty persistence blur.
We apologise for the inconvenience
User avatar
Obiwanshinobi
Posts: 7463
Joined: Sun Jul 26, 2009 1:14 am

Re: 100% Lagless Emulation is Here!

Post by Obiwanshinobi »

Does Guardian Force played on a real Saturn lag as badly as - word is around - emulated PCB does? I've never been any good at the game*, but it didn't feel all that less responsive than your typical Saturn shmup to me (those that came from ST-V included). Could the console's response times be much different from PCB's (whereas that's one console version which seems to add precisely nothing else to the experience)?

*) I sucked alright.
The rear gate is closed down
The way out is cut off

Image
User avatar
evil_ash_xero
Posts: 6181
Joined: Thu Jul 12, 2007 6:33 am
Location: Where the fish lives

Re: 100% Lagless Emulation is Here!

Post by evil_ash_xero »

Uh...OK...

I tried to figure out Retroarch once, and I gave up. If anyone would be SO KIND as to upload it all put together, and send me the link, that would be awesome.
No ROMs, obviously.
I've done this for people with other emulators, but I'm not sure if anyone else is so kind as me. :wink:
User avatar
tnc
Posts: 81
Joined: Sun Jun 03, 2018 11:31 am

Re: 100% Lagless Emulation is Here!

Post by tnc »

Using higan and run-ahead, the framerate dropped to half so I tried Snes9x. It works full speed using run-ahead but thelanczos shader I use now doesn't scale correctly at any setting. What I noticed is that using higan, there are black borders on top and bottom of the screen with integer scaling turned off. With snes9x however, it scales leaving no borders and there is no setting to change the internal resolution. higan is at 512x480 by default, changing it results in a similar error the way snes9x does with shader scaling. Does anyone know how I can solve this? Worst case scenario is I won't be using a shader.

By the way, do you guys set vsync on? Vsync off, runs the game at original speed but also introduces jitter and scrolling isn't smooth. Now that run-ahead solves the input lag issue (Am I right assuming that vsync introduces more input lag?), I guess there is no reason to turn it off other than a small change of the games speed? (Hagane for instance seems to run at a little above 60 frames.)

edit: There seems to be something wrong with lanczos. I'm using quilez now and everything is fine. Also, bsnes mercury accuracy works at full speed on my pc. It seems to not have the added 1 more frame of input delay higan has.
User avatar
evil_ash_xero
Posts: 6181
Joined: Thu Jul 12, 2007 6:33 am
Location: Where the fish lives

Re: 100% Lagless Emulation is Here!

Post by evil_ash_xero »

Trying Retroarch again. Nice PS4 look, it's got going.

Having problems, right off the bat. Only Bilinear filter works. No other filters work.
Can't update ANYTHING. Task failed, on everything.

Advice.
User avatar
evil_ash_xero
Posts: 6181
Joined: Thu Jul 12, 2007 6:33 am
Location: Where the fish lives

Re: 100% Lagless Emulation is Here!

Post by evil_ash_xero »

OK bros...

I've been messing around with this Retroarch. I've made some progress. I've failed completely at other things.
I do want to understand right first...no matter the emulator Retroarch is running, it will have no input delay?
And yes yes, I know which ones are the recommended ones.

If so, I'm going to need some Shmups Forum help. That still exists, right? :wink:
User avatar
evil_ash_xero
Posts: 6181
Joined: Thu Jul 12, 2007 6:33 am
Location: Where the fish lives

Re: 100% Lagless Emulation is Here!

Post by evil_ash_xero »

Specifically, this won't update. And I don't know how to put other scalers/filters/palettes in it. So everything kind of looks like crap.
User avatar
evil_ash_xero
Posts: 6181
Joined: Thu Jul 12, 2007 6:33 am
Location: Where the fish lives

Re: 100% Lagless Emulation is Here!

Post by evil_ash_xero »

You guys are helpful. :lol:

I got this working on my Alienware PC. But it still will not update on my normal PC. That is really weird.

Also, I'm going to have to figure out why some emulators give me half a screen. Very frustrating.
User avatar
tomwhite2004
Posts: 319
Joined: Fri Mar 08, 2013 12:13 pm
Location: UK

Re: 100% Lagless Emulation is Here!

Post by tomwhite2004 »

evil_ash_xero wrote:I do want to understand right first...no matter the emulator Retroarch is running, it will have no input delay?
No, and the title of 100% lagless emulation is completely misleading and false. Run ahead can only remove the latency present in the games software itself, most of the time that is only 1 frame when dealing with nes, snes and megadrive but quite a bit more can be removed from fba. All the other factors that cause latency in emulation are still there. Also, it only works with cores that play nice with the way save states need to work with run ahead so that means no PSP, no Higan etc etc.

Shaders and filters are all included with the standard retroarch install and can be selected once in game by going into the core options (press f1) and going to the shaders section. Additional palettes for the NES can be used by following the instructions on the retroarch wiki:

https://docs.libretro.com/library/mesen/

If I were you I would start from scratch with the latest stable version of Retroarch available on their website and go from there. Then follow one of the many videos and guides out there to get it set up.
User avatar
evil_ash_xero
Posts: 6181
Joined: Thu Jul 12, 2007 6:33 am
Location: Where the fish lives

Re: 100% Lagless Emulation is Here!

Post by evil_ash_xero »

So this isn't lagless at all?

WTF?

Talk about getting worked up for nothing.

Groovy MAME is lagless, isn't it?
Post Reply