100% Lagless Emulation is Here!
-
- Posts: 1532
- Joined: Thu Mar 02, 2017 6:53 pm
Re: 100% Lagless Emulation is Here!
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?
Re: 100% Lagless Emulation is Here!
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 ( ) 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/
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 ( ) 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.
Re: 100% Lagless Emulation is Here!
Is there really any scientific study about this?
CapivaraGamer
http://capivaragamer.com.br
http://capivaragamer.com.br
Re: 100% Lagless Emulation is Here!
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.
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
Re: 100% Lagless Emulation is Here!
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...
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!
Re: 100% Lagless Emulation is Here!
The collision detection on the SNES Bubsy is poorly done and inconsistent.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...
We apologise for the inconvenience
Re: 100% Lagless Emulation is Here!
"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.
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!
Re: 100% Lagless Emulation is Here!
Well, most of us grew up playing Atari. That's pixel perfect hardware collision detection.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.
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
Re: 100% Lagless Emulation is Here!
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.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.
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.
Re: 100% Lagless Emulation is Here!
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.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."
-
- Posts: 1532
- Joined: Thu Mar 02, 2017 6:53 pm
Re: 100% Lagless Emulation is Here!
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?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.
Re: 100% Lagless Emulation is Here!
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.Sumez wrote: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.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.
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.
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
Re: 100% Lagless Emulation is Here!
I'm not parroting anything. I'm talking out of experience programming stuff on the SNES.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 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.Storing a frame in memory is a frame buffer. You're right that it doesnt automatically imply latency, but it is a frame buffer.
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.
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.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.
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.
Re: 100% Lagless Emulation is Here!
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.
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
Re: 100% Lagless Emulation is Here!
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.
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.
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.
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.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.
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.
Re: 100% Lagless Emulation is Here!
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.
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
Re: 100% Lagless Emulation is Here!
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
-
OmegaFlareX
- Posts: 884
- Joined: Tue Jan 25, 2005 10:15 pm
- Location: Virginia, USA
Re: 100% Lagless Emulation is Here!
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.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.
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.
-
tomwhite2004
- Posts: 319
- Joined: Fri Mar 08, 2013 12:13 pm
- Location: UK
Re: 100% Lagless Emulation is Here!
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.OmegaFlareX 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.tomwhite2004 wrote:
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.
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.
Re: 100% Lagless Emulation is Here!
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?
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?
CapivaraGamer
http://capivaragamer.com.br
http://capivaragamer.com.br
Re: 100% Lagless Emulation is Here!
Sure. We're aware.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?
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:
source linky 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!..."
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
-
Obiwanshinobi
- Posts: 7463
- Joined: Sun Jul 26, 2009 1:14 am
Re: 100% Lagless Emulation is Here!
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.
*) I sucked alright.
The rear gate is closed down
The way out is cut off
The way out is cut off
-
evil_ash_xero
- Posts: 6182
- Joined: Thu Jul 12, 2007 6:33 am
- Location: Where the fish lives
Re: 100% Lagless Emulation is Here!
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.
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.
My Collection: http://www.rfgeneration.com/cgi-bin/col ... Collection
Re: 100% Lagless Emulation is Here!
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.
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.
-
evil_ash_xero
- Posts: 6182
- Joined: Thu Jul 12, 2007 6:33 am
- Location: Where the fish lives
Re: 100% Lagless Emulation is Here!
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.
Having problems, right off the bat. Only Bilinear filter works. No other filters work.
Can't update ANYTHING. Task failed, on everything.
Advice.
My Collection: http://www.rfgeneration.com/cgi-bin/col ... Collection
-
evil_ash_xero
- Posts: 6182
- Joined: Thu Jul 12, 2007 6:33 am
- Location: Where the fish lives
Re: 100% Lagless Emulation is Here!
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?
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?
My Collection: http://www.rfgeneration.com/cgi-bin/col ... Collection
-
evil_ash_xero
- Posts: 6182
- Joined: Thu Jul 12, 2007 6:33 am
- Location: Where the fish lives
Re: 100% Lagless Emulation is Here!
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.
My Collection: http://www.rfgeneration.com/cgi-bin/col ... Collection
-
evil_ash_xero
- Posts: 6182
- Joined: Thu Jul 12, 2007 6:33 am
- Location: Where the fish lives
Re: 100% Lagless Emulation is Here!
You guys are helpful.
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.
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.
My Collection: http://www.rfgeneration.com/cgi-bin/col ... Collection
-
tomwhite2004
- Posts: 319
- Joined: Fri Mar 08, 2013 12:13 pm
- Location: UK
Re: 100% Lagless Emulation is Here!
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.evil_ash_xero wrote:I do want to understand right first...no matter the emulator Retroarch is running, it will have no input delay?
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.
-
evil_ash_xero
- Posts: 6182
- Joined: Thu Jul 12, 2007 6:33 am
- Location: Where the fish lives
Re: 100% Lagless Emulation is Here!
So this isn't lagless at all?
WTF?
Talk about getting worked up for nothing.
Groovy MAME is lagless, isn't it?
WTF?
Talk about getting worked up for nothing.
Groovy MAME is lagless, isn't it?
My Collection: http://www.rfgeneration.com/cgi-bin/col ... Collection