Zombeaver

I feel like it's a good middle ground in terms of visual impact between Easymode-Halation and Kurozumi. I typically find Easymode-Halation to be a better all-rounder because it's not so dramatic whereas Kurozumi looks really great in some situations and really off in others (basically anything that isn't sprite-based). I think Hyllian-Glow fills a nice spot in between; I think it has a nicer glow effect than Royale too. It's still early but I could see it becoming my daily driver. On another note, I've been working on my own deinterlacing shader for a handful of games that need it like Tobal no. 1, Tobal 2, and the Tekken games. It is blurry but there doesn't seem to be much of a way around that - your options are: 1) no blur with interlacing artifacts 2) no blur and no interlacing artifacts but with scanline and game UI judder 3) blurry with no interlacing artifacts and no judder Obviously none of those are ideal, but option 3 looks better to me than the other two. I tried quite a few different shaders and they basically all fell into the first two categories. I feel like this could definitely still be improved as I'm basically just fumbling around, but it's a start. CRT Deinterlacing.cgp

I've been doing some experimenting lately. I figured I'd share some comparison shots. CRT-Easymode-Halation and CRT-Royale-Kurozumi have been my go-to shaders for quite a while now, but I have to say - I'm really digging CRT-Hyllian-Glow. I've been using it for a few days now and I'm really liking it. It looks quite nice in a range of situations and I especially like the way it looks in areas of high contrast. It's bloomy but not too bloomy. It looks pretty good on 3D content as well - I was playing Dino Crisis with it and it looked quite nice. I'm not sure what the deal is with the weird letterboxing going on in the screenshots as it's not present while playing, but you get the idea (probably has something to do with my viewport settings in RA). These really have to be viewed at full size for them to look correct. EDIT: As some of these seem to be producing an internal server error (@Jason Carr, I'm not sure what that's all about - maybe a bug when posting large images?) I've included a zip of all of them too (which is probably easier for comparison purposes anyway). Shader Comparison.zip Tales of Destiny II - No Shader: Tales of Destiny II - CRT - CRT-Calagiri: Tales of Destiny II - CRT - CRT-CGWG-Fast: Tales of Destiny II - CRT - CRT-Easymode: Tales of Destiny II - CRT - CRT-Easymode-Halation: Tales of Destiny II - CRT - CRTGlow_Gauss: Tales of Destiny II - CRT - CRT-Hyllian-Glow: Tales of Destiny II - CRT - CRT-Royale: Tales of Destiny II - CRT - CRT-Super-XBR: Tales of Destiny II - CRT - GTUV50: Tales of Destiny II - CGP - 2XBR-Hybrid-CRT-Hyllian: Tales of Destiny II - CGP - CRT-Royale-Kurozumi: Tales of Destiny II - Denoisers - CRT-Fast-Bilateral-Super-XBR: Tales of Destiny II - Analog Shader Pack 3 - Professional Monitors - Sony BVM - RGB: Suikoden II - No Shader: Suikoden II - CRT - CRT-Caligari: Suikoden II - CRT - CRT-CGWG-Fast: Suikoden II - CRT - CRT-Easymode: Suikoden II - CRT - CRT-Easymode-Halation: Suikoden II - CRT - CRTGlow_Gauss: Suikoden II - CRT - CRT-Hyllian-Glow: Suikoden II - CRT - CRT-Royale: Suikoden II - CRT - CRT-Super-XBR: Suikoden II - CRT - GTUV50: Suikoden II - CGP - 2XBR-Hybrid-CRT-Hyllian: Suikoden II - CGP - CRT-Royale-Kurozumi: Suikoden II - Denoisers - CRT-Fast-Bilateral-Super-XBR: Suikoden II - Analog Shader Pack 3 - Professional Monitors - Sony BVM - RGB:

It's not something you'd need to mess with - I was doing that on my work PC which doesn't have LB on it; so in lieu of LB, I just created shortcuts in Windows and changed the target path to what I needed in order to achieve the same effect as using LB. Adjusting the target path is basically what you're doing with LB, but LB makes it so you don't have to do it by hand for every game. Adding "-L "cores\blahblah.dll" etc. at the end of the target path of a Windows shortcut is the same thing as putting it into the "Default Command Line Parameters" field in LB - it's just that with LB you're then injecting those parameters into every game you launch for that platform instead of just one specific shortcut (which I was directing to a specific rom file). I just wanted to be able to verify that the shader/overlay separation still worked in the nightly build of RA but didn't want to wait until I had access to LB to test it

After some testing it doesn't appear that the changes in the nightly builds will actually break my existing setup, so that's good. I downloaded the 10-06-16 Nightly, copied over my configs and cores and did the same ghetto Windows shortcut test as before and it's working fine. Bezel Core+Config Shortcut Target Path: "C:\Path\To\NightlyBuild\retroarch.exe" -L "cores\bsnes_accuracy_libretro_bezel.dll" -c "config\bsnes_accuracy_libretro_bezel.dll.cfg" "C:\Path\To\Rom\Rom.zip" No Bezel Core+Config Shortcut Target Path: "C:\Path\To\NightlyBuild\retroarch.exe" -L "cores\bsnes_accuracy_libretro.dll" -c "config\bsnes_accuracy_libretro.dll.cfg" "C:\Path\To\Rom\Rom.zip" I set an overlay + shader on the bezel one and no overlay + different shader on the other and they were still separate and individually configurable. I then did one additional test where I used the same base core dll as the one with no bezel, but specified the config file for the bezel, and that worked as well; so in this case duplicating the core dll isn't actually necessary. I've had to do it in the past for splitting up things like different control layouts for the same core, but it looks like in this case separate config files directed to the same core is sufficient. I've just kindof gotten into the habit of duplicating them when I want to split something up like this, whether that's actually overkill for the situation or not...

The main reason this is important is because the Link/Big Picture attempt to figure out what kind of application you're running and modify the controller output (traditional controller or desktop navigation) accordingly. Most traditional PC games will correctly be picked up as needing the normal controller mode but for some emulators it just doesn't understand what they are and falls back into desktop (mouse+keyboard emulation) mode and the B button sends a back/escape input by default in that mode. If you remove all of the desktop mode controls (so that A can only send an A input, B can only send a B input, the joystick doesn't send mouse inputs, etc.) you basically force it to only function as normal controller regardless of whether or not the Link/Big Picture think that's what you should be using for the task.

Doubtful. Again, how is your controller configured in Steam Big Picture? It needs to be setup to never function as mouse+keyboard. This is a big red flag for me that it likely has to do with how your controller is configured in Big Picture. It should look like this in the configuration:

Have you tried running LB or BB themselves as admin?

For the purposes of use with emulators, you basically just want to configure your controller in Big Picture to never function like a keyboard+mouse - it should look like this. "Captain Keeb's" was the community config I used a long time ago but I'm not sure if it's still around - it doesn't really matter though, the buttons just need to be configured the way they are in that picture. I also recommend disabling the Steam overlay - it causes issues for some emulators. These posts are old but there's still some information in them that you may find useful. I posted these on the Steam Link forums a long time ago: http://steamcommunity.com/app/353380/discussions/0/485622866440318860/ http://steamcommunity.com/app/353380/discussions/0/485623406943314193/

I use a Steam Link + Big Box and Dolphin. Strangely though I don't recall having to setup anything particularly special in order for Dolphin to work via the Link. I'll take a look at my settings tonight though. How do you have your controller setup with the Link? You have to disable keyboard+mouse mode for it to work properly with some emulators - it should just look like this. I also recommend disabling the steam overlay as that too can interfere with emulators. Here are a couple of posts I made over on the Steam Link forums quite some time ago that you may find useful as well: http://steamcommunity.com/app/353380/discussions/0/485622866440318860/ http://steamcommunity.com/app/353380/discussions/0/485623406943314193/

Are you sure you don't have an incomplete/corrupted download? Maybe try downloading it again.

Generally speaking you can continue using an older version and just update the cores yeah (I was actually on 1.2.2 for a long time), but subsequent RA releases do bring improvements. In some instances specific cores actually do depend on newer versions of RA though like ParaLLel (which admittedly is mostly broken/preliminary anyway, but still). I guess I'll have to try downloading a nightly build and try it out with my existing setup and see what happens.

Happy to help! Glad it's all sorted now. I'm genuinely a bit worried about the next stable now though... reading the instructions in that thread for using overrides, it seems like it's even more cumbersome/time-consuming than what I'm doing now... I seriously use this technique for a lot of stuff. I really hope they don't break it in future builds...

Based on this post it looks like Configuration Per-Core has been deprecated in nightly builds which is... a bit alarming since I use it pretty extensively. Read that post and the one below it though - it sounds like you might be able to get it to work with "overrides". I'm just not sure how that will work within the confines of the same core. I hope all my configs aren't gonna be borked on the next stable because I'll be pretty pissed... If you use 1.3.6 stable though, the option should be there.

Weird. Are you using a nightly build? I've never seen that "content-specific core options" thing.

It's in Configuration:

True, but I always have Vsync turned on so it'd theoretically yield an improvement for that reason (though potentially negligible, I don't know). This is what I have currently. It's not amazing but it's okay as long as it's set to low latency (gaming) mode. I'm actually really interested in trying out a G-Sync monitor with C64 emulation because it ran at an unusual 50.125hz. Emulators do their best to compensate for this and sync to standard modern rates, and they do a pretty good job of it, but it's not perfect and can occasionally cause a few hiccups.

Yep, exactly. There are many games that I love immensely and my first encounter with them was within the context of emulation. Like they said in the video, it allows everyone to be exposed to a huge range of games that they may have never known about or even heard of outside of the advent of emulation. I understand the desire to have a physical copy of some games, but that doesn't have any impact on my appreciation of the game itself - regardless of the method I use to play it. Yep, definitely. I think the vast majority of such complaints (if made more recently anyway) have much more to do with people using high-latency LCDs than anything to do with emulation. If you were to hook up real hardware to that same crappy LCD you'd have input lag on it too. And yeah, some games just have it innately - some by design (such as animation-heavy games like Flashback, Out of this World, etc.) and some that are just...well...poorly made. I'm gonna give G-Sync another year or two to come down a bit before I pick one up; I've done fine for years without one but it'd still be nice. Haha, yep. DCP™

I already said that. He doesn't want to do that

There's definitely some amount of that, yeah. I honestly think in most cases that sort of response is just an excuse though - Mike even basically admits as much in the video when he talks about his own thoughts on it prior to his "enlightenment". I mean look, I get it - I love collecting too, but emulation doesn't devalue that collection at all. In fact, it's precisely because of emulation that some games are worth as much as they are; because without it many of the better obscure titles would have remained just that - obscure - and nobody would care about them. I drove to another state to pick up a physical copy of Suikoden II, but I only did that after I played through it on an emulator. But for the people that actually do feel really strongly about it in earnest (that a lack of accuracy has been the deciding factor) yeah, you're absolutely right - it's come a LONG way. I can't shit on ZSNES too much because that's kinda where I got my start with emulation so long ago, and I still remember it fondly, but I'm not deluded - obviously we have much better options today; options that frankly are so close to the real thing that anyone bemoaning them is really just looking for something to complain about. When you get into the nitty-gritty details of things like input lag, something that's long been bemoaned by purists, in a lot of cases you're looking at something like 5-6 frames of delay with the proper equipment and settings in RA. People that would complain about something like that just want something to complain about. I could beat Contra III just fine long before the arrival of Retroarch. Most people that have super negative things to say about emulation don't really know much of anything about it, in reality; in my estimation anyway. A lot of it I really think comes simply from the negative stigma and connotations that have long been associated with emulation because it's too often discussed without the proper context.

I appreciate anything that spreads goodwill for emulation which has been horribly misconstrued, misunderstood, and maligned over the years. I'm really really happy to see more and more mainstream proponents of emulation in recent years. For me it primarily comes down to the basic principle that this stuff needs to be preserved for the future and emulation is the only viable and reliable way to ensure that. I don't care how immaculately you maintain your hardware and games - they will all break down someday regardless (and this is coming from someone who's an avid retro collector). Chances are it'll happen outside our lifetimes but it will happen. And then what? It's just lost forever because emulation is so eeeeeeeevillll? Seriously? 90% of American films made prior to 1930 are lost forever - with no known remaining copies in existence. NINETY freaking percent. 75% of all silent films are lost. That's an absolute tragedy. Laugh, Clown, Laugh (1928) is one of my favorite films of all time, but I'll never be able to compare it to London After Midnight (another Lon Chaney silent film) because it's lost forever. I'd love to hear someone justify how the world is better off for that loss, just because people didn't have the foresight (or, in the case of emulation, were actively told not to) make backups of this stuff. I know I rehash this same rant every time this comes up, and I realize it's probably just preaching to the choir given the focus of these forums, but people really need to understand how important emulation is; it's not just a neat facilitator to play SNES games on your phone - it's a way to ensure that those same games can be appreciated and examined by generations to come.

So I tested this out on my work PC which doesn't have LB but I do have RA on it. For whatever reason, in order for me to be able to get this to work I did have to specify the configs (and "Configuration Per-Core" is on with "Load Override Files Automatically" turned off). I'm not sure why I don't need to on my home PC but do here, but whatever works I guess. As I don't have LB here, I had to make do by making custom Windows shortcuts to achieve the same effect, modifying the target path in the shortcut as necessary - one specifying the core + config that I'm using for the bezel and the other specifying the core + config that doesn't use it. C:\path\to\retroarch.exe -L "cores\bsnes_accuracy_libretro_bezel.dll" -c "config\bsnes_accuracy_libretro_bezel.dll.cfg" "C:\path\to\rom\rom.zip" C:\path\to\retroarch.exe -L "cores\bsnes_accuracy_libretro.dll" -c "config\bsnes_accuracy_libretro.dll.cfg" "C:\path\to\rom\rom.zip" Based on this, once you append the config files to your Retroarch emulator entry in LB, you should be good. I hope anyway... again I'm not sure why there's a discrepancy between this instance of RA and the one I'm using at home (they should be the same version) but I was experiencing the same troubles you described on my work computer. "Big Blur" overlay shader that I set for the _bezel one (using a traditional Overlay works fine too, but for some reason the overlay doesn't show up in screenshots, even with GPU screenshots enabled): No shader for the normal one:

I don't have any that have 2 cores (at least not within the same LB emulator entry) - some have a specific config file specified though. That's what the -c "config\blahblah.cfg" sections are for. You shouldn't need that for what you're wanting to do though. I don't for the instances that I mentioned before where I loaded up one, set X shader and loaded up another and set Y shader. That brings up something pertinent to this though - do you have "Configuration Per-Core" set to on? It needs to be. It's in "Configuration" in RA. If it's not turned on, turn it on and test again. If it still doesn't work, we can try actually specifying the configs. In your Retroarch folder there's a folder just called "config". If you have Configuration Per-Core turned on it should generate configs for each of your cores when you load them. It should be named [core name].dll.cfg. If you want to try adding those in, update your Retroarch emulator entry in LB with them like I have in my screenshot: -c "config\[configname.dll].cfg" and when you load one of the corresponding games, check to make sure that config has been loaded in the RA menu - normally where it will say Retroarch.cfg but instead you'll see the one you specified. I think "load overrides" may need to be disabled in Configuration as well. I can't recall what I have mine set to as I'm not at home to look at my RA but I can confirm when I get off work in a couple hours. I think overrides are basically designed to do what we're talking about here, except that it doesn't seem to work if you're duplicating core dlls like this. It'd probably be fine if you just wanted each core to be configured differently, but dividing up the same core to do different things like what you're wanting seems to give it some problems.

Try this: Try messing around with the "Zoom Amiga display (crop)" settings in the video section:

No problem! Happy to help

Sorry it was formatted a bit weird. Try this: ; This section closes [emulator] when pressing Escape $Esc:: { Process, Close, {{{StartupEXE}}} }