[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/vr/ - Retro Games


View post   

File: 17 KB, 350x86, Retroarch.png [View same] [iqdb] [saucenao] [google]
1877125 No.1877125 [Reply] [Original]

Give this to me straight, /vr/. What does RetroArch have that my regular emulators (VBA, Snes9x, etc...) doesn't have? What makes it "superior"?

>> No.1877135

Active development means there are little improvements going on here and there.

Besides that, not much. The guy at the head of the project is your archetypal bitch nerd with anger problems, as can be seen in any forum thread he participates in.

To be fair, he probably gets a lot of shit from folks about something he's doing for free, so I'm not saying his attitude isn't understandable.

Typically it's just the fact that it's a one-stop-shop I think that makes it desirable, but that UI is horrid.

>> No.1877138

Retroarch is just a front end for several emulators. It uses the same emulators you do, it just updates them for you and keeps them all in once place.

>> No.1877145

A bunch of shitty filters and a crummy interface, basically.

>> No.1877158

it compiles all the most accurate emulators into one frontend, and has a lot of filters, and you can stack filters too, which is neat

>> No.1877163

Retroderp is basically training wheels for casuals that are too afraid or lazy to get their hands dirty and deal with specific emulators first-hand.

>> No.1877169

shitty frontend
people will try to convince you it's not a frontend, they are just shills for the android version of the emulator, which you have to pay for

>> No.1877175

>>1877169
all the versions are free
I just like retroarch because it makes emulation possible outside of PC.

>> No.1877181

>>1877175
not the mobile
the author is a chinese crook who literally slapped a bunch of emulators without permission and charged for them. There are even ads.

>> No.1877185
File: 36 KB, 479x351, KingFloors.jpg [View same] [iqdb] [saucenao] [google]
1877185

>>1877125
http://emulation.gametechwiki.com/index.php/RetroArch

>> No.1877190

>>1877181
pretty sure you are talking about someone else then. I got retroarch on my android device and i didn't pay. Squarepusher (retroarch's author) seems to have the problem that people just take retroarch and sell it with another name and ads.

>> No.1877209

Absolutely nothing. In fact it is distinctly lacking in features you would come to expect of other emulators due to its one-size-fits-all approach to handling them.

>> No.1877294

>>1877125
I'll be completely honest. I just use RetroArch with the Pheonix GUI to use the BSNES accuracy core without needing to do funky stuff with my ROMs, as I would need to under higan.

Other than that, I just use individual emulators.

>> No.1877296

Retroarch isone of the first emulators every to be able to play more then one game console
so it's prety tite.

I donated like 5$ to the devs paypal cuz hes a bro

>> No.1877303

>>1877125
I think it's very neat and practical to have all emulators running from a single program in a standardized, unified GUI that was designed to fully work with a gamepad, without the need for keyboard and mouse. This way I can switch between roms and emulators while I'm sprawled on my couch without even taking my hands off the controller. That's the main reason I like and use RetroArch.

Of course, other features like its filters, standardized fast forward/rewind for almost every core and the video/audio syncing capabilities are great too.

If only it also had good Saturn and Dreamcast cores, plus a MPC-HC or VLC core, I'd configure my entertainment PC to boot straight into RetroArch.

>> No.1877310

>>1877125

It's a good frontend. I read this summary:

>RetroArch is necessary if you want perfect audio/video sync and/or low input latency. A large number of the standalone emulator frontend applications only do bare minimum in regards to sync quality, which can go a long way to making emulation feel "inferior" to the real console since a lot of these emulators have problems with tearing, stuttering, input lag, audio lag, etc, as many of these systems are very difficult to vsync and still maintain audio synchronization so issues happen when you aren't re-sampling the audio to make sure the audio buffer never underruns or overruns to avoid blocking on audio and causing dropped frames. Also, leveraging control over video buffers with things like GL Hard GPU sync and DRM/KMS can minimize input lag that emulators are infamous for, as many video drivers will tend to buffer excessively to get better performance on benchmarks when using vsync, which causes much of the lag.

>When you have perfect sync and minimal latency, it will actually be almost exactly the same as playing a real console if the emulation core is accurate. Things like shaders, audio DSP filters, and other niceties are just icing on the cake.

Also it's a unified frontend for various emulators with a single control, and the cores are actively updated, so you can be sure it's pretty recent versions. There's lots of people who use builds of stuff from 2009 and shit yo.

Plus, it has the best cores from Mednafen, but with a GUI.

And speaking of GUI, RA's GUI is pretty ugly. Others are in development.

There's also ZERO REASON that other front-end emulators can't step up their game and copy the features of RA so their frontends are just as good. Dynamic Rate Control should be a standard freature in most emulators.

>> No.1877357

>>1877303
Forgot to add, RetroArch Android is also great for similar reasons - it's a lot more practical and elegant to be able to emulate everything in a single app instead of having at least half a dozen emulator apps. Especially when its cores usually are better emulators than individual emus.

However for me RetroArch Android has a serious problem that needs urgent improvement - touchscreen input. Touchscreen input sucks big smelly sweaty donkey balls on RA for some reason. It's laggy, imprecise and unresponsive. It's only a problem with RA, in other emulators touchscreen input works a lot better.

>>1877310
I don't understand why everybody disses RA's gui on Windows. Yeah, it's not pretty, but so what? It's practical, straightforward and fully controllable with a gamepad. Plus you're using RA to play games or to keep ogling at the pretty interface? You're not going to see the GUI anyways while actually using it.

>> No.1877510

>>1877158
As far as I've seen it only supports a small number of systems.

>> No.1877785
File: 38 KB, 240x260, seinfeld_jerry.jpg [View same] [iqdb] [saucenao] [google]
1877785

>>1877125
>What's the deal with RetroArch?

>> No.1877803

>>1877163
>get their hands dirty
u wot? Having a dozen executables instead of one is hands dirty? It doesn't make any fucking difference.

>> No.1877812

Well, after another shitty emulator on my hacked wii decided it would be HILARIOUS to replace my oracle of seasons save file with a multi-gig undeletable file, I found Retroarch. Following notes are from my sole experience playing Oracle of Ages and Seasons through homebrew>retroarch>gambatte on the Wii

Current pros:

1) Doesn't fail to save files/states
2) Doesn't keep writing garbage until you fill every byte of your USB drive
3) Plays GBC games

Cons:

1) Doesn't recover a kb save file out of several gb of garbage
2) You can't fucking reduce the screen size by a percentage. The GBC ratio is 10:9 which is displayed as 1:1. It doesn't matter how much you play with the video settnigs, the top 10% and bottom% are cut off on my hmdi tv. You can barely tell how much life link has. I assume in other GBC this would be even worse.

>> No.1877815

>>1877163
>there's a convenient option for running emulators natively on platforms they weren't designed for
>lel casuals can't use REAL emulators

You're an idiot.

>> No.1877817

>>1877181
nigga u high?

>> No.1877825

RetroArch isn't an emulator, it's a frontend that uses emulation cores written by third parties, such as the developers of NEStopia or FCEUltra. It's just throwing a wrapper around others' software and taking credit for it. Making a frontend for something like MAME is understandable since it doesn't have a GUI of its own, but the RA frontend is just an attempt to piggyback others' work. This is evident in the fact that the same guy who keeps spamming these RA threads has on numerous occasions claimed RA is an emulator and denied any insistence that it's simply a frontend.

As for the frontend itself, half or more of its configuration options are broken, it doesn't play nice with most of the emulation cores it's packaged with and some cores won't even write SRAM or savestates. All these emulation cores have their own GUIs, which actually work as intended. Why would anyone want to throw a superfluous, broken frontend on them? Don't answer that, because it's just going to be some stupid bullshit about RA offers improvements over the cores' native features. It does no such thing. It doesn't even support all of the same options that the emulation core supports, and many options you try to configure don't communicate any actual changes to the core.

>> No.1877845

>>1877825
They don't take credit for the cores. I don't know what gave you that idea.
It's also not a frontend, it's an API. An API that has A/V sync that the standalone emus don't offer. That also has a GGPO-like netplay implementation.

As for issues, I've yet to come across any in my usage. All core options work (although some, such as internal resolution in Mupen, require the core to be reloaded to take effect).
Missing options are, as I recall, being implemented, but tell me what's missing that is so vital, and be specific.

>> No.1877848

>>1877169
>>1877181
First, it's not a frontend, see: >>1877845
Second, Squarepusher does not sell the official Retroarch releases, so you must be using some shit a get-rich-quick bitchass decided to push.

>>1877303
There is an FFMPEG core floating around, actually. Which VLC is based on.
There won't be a "good" Saturn core until Yabause gets a nice update or SSF goes open source, all the Win shit is cut, and then someone else ports it to libretro.
As for Dreamcast, it's a similar situation, though there were whispers of a reicast libretro implementation a long while ago.

>>1877510
Check the dev builds and all the cores. Sure, there are a lot of redundant cores, but the list of systems it supports is rather long now. Issue is that those cores aren't necessarily completed yet.

>> No.1877849

>>1877296
>isone of the first emulators every to be able to play more then one game console

You couldn't be long gone away from the truth

in b4
>but I said one of the first, not the first
Not even close to one of the first.

And retroarch is not an emulator
Nothing you said was right.

>> No.1877852

>>1877848
What dev builds? I'm only seeing a few mainstream systems supported.
http://www.libretro.com/index.php/ecosystem/
http://emulation.gametechwiki.com/index.php/Libretro#Cores

>> No.1877864

>>1877852
>https://www.dropbox.com/sh/91sakv0qdyxjx9f/cGOfV7ZOKd
They've added a good few, and if PSP isn't in there, that's coming too.

I've got emulators for Amiga, 2600, 7800, Atari ST and friends, GB(C/A), Lynx, MSX (and the blueMSX core says it supports ColecoVision), Neo-Geo Pocket/Color, NES, N64, DS, PC-Engine (and PCE-CD), PC-FX, PSX, PSP, ScummVM, Sega MD/GG/CD/32X, Saturn, SNES, Vectrex, VirtualBoy, and Wonderswan (Color).
There's also cores for DOSBox, Doom, Quake, MAME, FBA, MESS, FFMPEG, and NXEngine.

If the current dev build doesn't have something, that means it didn't compile, try a slightly older one.

>> No.1877868

>>1877864
>If the current dev build doesn't have something, that means it didn't compile, try a slightly older one.
That sure makes things a lot easier than having to download individual emulators.

>> No.1877869

>>1877868
Then just wait for an official build?

>> No.1877871

https://www.dropbox.com/sh/91sakv0qdyxjx9f/cGOfV7ZOKd

Dev build downloads.

>> No.1877875

>>1877181
I just downloaded retroarch right not to check this out. It's absolutely free, idiot

>> No.1877882

>>1877169

It is a frontend. And it's a good frontend.

>> No.1877887

>>1877882
It's not a god damn front end.

>> No.1877891

>>1877887

RetroArch itself is a frontend that can play anything properly ported to the Libretro API.

The cores are (mostly) emulators.

>> No.1877893 [DELETED] 
File: 1.11 MB, 1000x1500, 1408467161183.jpg [View same] [iqdb] [saucenao] [google]
1877893

>>1877125
You just have to understand what it is.

RetroArch is a user-friendly way of running Libretro. Libretro is a platform. First, software (like emulators) is ported to Libretro, which has happened for most of the worthwhile emulators. Then all you need ot do is port Libretro to another OS, and all the emulators start working there.

That's why you can have all the serious emulators on Linux or Android or Wii or PS3. And that's what RA is good for.

People confuse the term "front-end" with the term "GUI". RA is not a GUI, nor is it a frontend for the emulators. It's a frontend for Libretro (and I've already explained the gist what Libretro is).


Apart from portability, RetroArch has the best audio latencies and a unified configuration file for all platforms (although seperate configs are easily possible). I personally use RA on Windows, because that's what I use on my Linux and Android machines. Until I switched to Linux a couple of years ago, I was comfortable enough with seperate emulators on Windows.

>> No.1877894

>>1877296
>Retroarch isone of the first emulators
RetroArch is not an emulator. See >>1877893 .

>> No.1877896

RetroArch isn't an emulator. It's a framework for displaying any audio/video with perfect sync and minimum latency. No standalone emulator synchronizes so well, and very few have such good latency. RetroArch gives you these benefits for every emulator that's been ported to the libretro API, and there are a lot of them.

>> No.1877901

>>1877209
>In fact it is distinctly lacking in features you would come to expect of other emulators due to its one-size-fits-all approach to handling them.

Such as?

>> No.1877903

>>1877125
>emulators

I'd just like to interject for a moment.

What you’re referring to as an emulator, is in fact, Libretro/Retroarch, or as I’ve recently taken to calling it, Libretro plus Retroarch. Retroarch is not an emulator unto itself, but rather another free component of a fully functioning Libretro system made useful by the Libretro core API, shell utilities and vital system components comprising a full suite of tools as defined by Themaister.

>> No.1877908

>>1877903
OP probably doesn't recognize the interjection anyway, so, you know, deaf ears.

>> No.1877913

RetroArch/libretro just makes sense. Every emulator needs perfect a/v sync, netplay, rewind, video streaming, black frame insertion, etc. These are all difficult to get right, and no standalone emulator gets all of them right. It's a huge waste of time for every emulator author implement these individually when they can port the emulator to libretro and you get them all for free. Retroarch/libretro lets emulator authors focus on the actual emulation.

>> No.1877914

>>1877893
Why aren't the cores written for libretro? Aren't you always lagging behind if you have to wait for them to be ported?

>> No.1877917

>>1877914
>Why aren't the cores written for libretro?

Devs are resistent to change. They don't like some guy coming in and telling them what to do. So no one ports things to Libretro directly. It's just how devs are. They're stuck in their ways.

>> No.1877918

>>1877914
If I wrote an emulator, or any game that runs at a fixed framerate, I'd target libretro as my primary platform. The only reason people don't is because they don't realize how much work it saves them or because they're control freaks who don't want players using RetroArch features.

>> No.1877920

>>1877914
No complex software is made of one piece of code, and no software bundle is always up-to-date in all of its components.

Do you think your Windows distribution is always perfectly up to date with all of its components? All you properly updated software using the newest libraries? That simply isn't how it works. Every now and then the big software transitions to newer versions of the software it's built upon, but that happens only once in a few years for reasons of stability, convenience and for lack of incentive to incorporate every update.

>> No.1877927

How does Retroarch compare to MESS?

>> No.1877929
File: 28 KB, 200x200, Digiorno.jpg [View same] [iqdb] [saucenao] [google]
1877929

ITT: it's not an emulator, it's a front end.

>> No.1877930

>>1877927
Retroarch has a MESS core, so it's on par but with superior A/V sync and such.

And then each individual core is probably a lot more functional (i.e. N64 and PSX) for playing games.

>> No.1877931

>>1877927

Interesting different approaches. RA takes pre-existing emulators, and then binds them by a common frontend.

MESS creates everything on its own. It's a bit of a mess though. Pun intended. A lot of the stuff isn't as well developed. But they aim for EVERYTHING. All those super obscure things.

And on top of that, MESS can be used within RA.

>> No.1877934

>>1877927
MESS is a multi system emulator. RetroArch/libretro is a set of features useful for emulators (perfect a/v sync, filter stacking, BFI, rewind, etc.). MESS is lacking most of these features. If you want to play something that's best emulated by MESS, the correct option is to use MESS as a libretro core in RetroArch.

>> No.1877935

>>1877929
>ITT: it's not an emulator, it's a front end.

It's a frontend, and it has a bunch of emulators bundled with it.

>> No.1877936

>>1877935
It's not a frontend. It includes a frontend but that's the least important part.

>> No.1877940

>>1877927

Retroarch is VERY dangerous becuase it glues emulators together. It's motivated by a "i want to play it now" mentality as opposed to MESS, which does it the right way.

>> No.1877943

>>1877869
How much longer would I have to wait until they add 3DO, Apple II, Atari 8bits, C64, CPC, FM Towns, FM-7, Intellivision, Macintosh (68k and PPC), PC-6001, PC-88, PC-98, Sharp MZ, X1 and X68000? At least the ones that have open source emulators available.

>> No.1877945

>>1877940
RetroArch doesn't emulate anything, so the emulation itself is exactly the same as the emulation of the cores. Unlike standalone emulators, RetroArch does all the other features needed for a good play experience the right way.

>> No.1877947

>>1877945
>RetroArch doesn't emulate anything,

Exactly. It leads to people not knowing the source of these so called "cores". End users just run it and run the games. That leads to them thinking that this RetroArch made everything. The original devs do not get the credit.

Just one of the reasons why this thing is so dangerous.

>> No.1877951

>>1877947
If you don't want people improving your emulator you should have made it proprietary.

>> No.1877954

>>1877940
>glues emulators together
I don't even understand what the fuck you mean by that.
Each core stands on its own, and some (bSNES, Nestopia, Mednafen PSX) are pretty much accurate (or accuracy focused) much like MESS is aiming to be.

>>1877943
There is a 3DO core in the works, but 3DO emulation was shit last I heard.
I want to say there WAS a C64 core in the works, but I can't promise you that. Even the computer cores they have now are fairly new and kinks are being worked out, but now that there are ideas, anyone who wants to port for it can.
I'd love to see an Apple II and PC-98 core.
Go drum up some interest over on their forums, head up the project yourself, scout around the emulator project's forums, check out the emugen thread (and attempt to get them to stop bitching about modern emulation for a minute), or just play the waiting game.

And for what it's worth, there's an Odyssey 2 core in the works, so there's hope.

>>1877947
Author credits are listed in the core info file.
The reason people don't get credit is because of the end user who doesn't give a rat's ass who wrote the damn thing anyway.
And the nature of open source is to port and improve, not stick your name on something so they'll suck your dick.

>> No.1877957

>>1877943
>3DO emulator in the works
https://github.com/libretro/libretro-3doh

>CPC emulator in the works
https://github.com/libretro/libretro-cap32

>SAM Coupé emulator in the works
https://github.com/libretro/libretro-simcoupe

>Early Mac emulator in the works
https://github.com/libretro/libretro-minivmac

>Chip8/16 emulator in the works
https://github.com/libretro/maxe

Mind you, these are the ones in the libretro repo and there may be more.

>> No.1878048

>>1877940
>copypasting Haze's post

lol

>> No.1878053

>>1877825
Nice copypasta

>> No.1878059

>>1877903
How's life, Squarepusher?

>> No.1878072

>>1877936
It's the part that most people use it for.

>> No.1878078

>>1877947
Yeah because manchildren emulating JRPGs on their laptops give a moment to acknowledge the creator of the emulator they use.

>> No.1878079

>>1878048

The point is that MESS does it the right way. RA does not. There are two competing philosophies at play here. MESS tries to reverse engineer every console out there. Learning the parts from one system can be of use in many others. It's a collaborative group project based on the idea of high accuracy and completion of ALL consoles eventually. It is a long term preservation project.

Single devs working on single consoles have achieved nowhere near as much as the MESS team. Devs get bored or die and then their work is mostly never picked up again. With MESS the group nature of the project allows for the constantly inject new blood to work on project to ensure that it never dies.

Retroarch is dangerous because it is part of the trend of "toyification" of console emulation. Turning it from a noble pursuit of hardware reverse engineering to a "I want to play it now!" short term mindset. No preservation, low accuracy, just get things working for only a small handful of consoles and glue them all together. As such this project should be viewed with caution.

And as for this so called high end frontend, I should point out that MESS/MAME have had dynamic rate control since the late 90's. It's nothing special. Retroarch brings absolutely nothing new to the table and I've seen nothing to convince me otherwise.

>> No.1878080
File: 42 KB, 677x544, RA.png [View same] [iqdb] [saucenao] [google]
1878080

So is there an easy way to update all your cores now?

Ever since this stopped working I don't think I've actually bothered updating anything.

>> No.1878085

>>1878080

Oh wow. That's ancient.

Yes, just redownload.

https://www.dropbox.com/sh/91sakv0qdyxjx9f/cGOfV7ZOKd

>> No.1878115

>>1878079
MESS's emulation is almost always inferior to single system emulator cores, and is only useful for systems who otherwise have non-existent emulation.

>> No.1878127

>>1878080
Compiling from source isn't that tough.
Although I would love an automated process like the updater offered.

>> No.1878130

>>1878079
Sup haze
still as massively assblasted as always i see

>> No.1878131

>>1878079
>>>Single devs working on single consoles have achieved nowhere near as much as the MESS team.

>byuu contributes to MESS while developing bsnes
>MESSdev drives him off after banning him from forum.bannister.org
>MESS SNES driver remains behind bsnes in accuracy

MESS accomplishes jack shit without people from the rest of the emulation scene.

>> No.1878147

>>1878079
>console emulation ... a noble pursuit
What the hell are you on about, you crazy fuck?

>"I want to play it now!" short term mindset
That's not the point of Libretro at all. you're heavily misrepresenting it here. As for RA, it's just a you-know-what for Libretro, it doesn't adhere to a particular design philosophy apart from the somewhat-unified interface.

>> No.1878149

>>1878131

MESS emulation is set to overtake bsnes in only a short period of time.

>> No.1878152

>>1878147
>>console emulation ... a noble pursuit
>What the hell are you on about, you crazy fuck?
i think he is talking about emulators on console like GPGX on Wii etc

>>1878149
yeah and it will only take an overclocked 3930K to get 10fps

>> No.1878154

>>1878079
MESS is fucking garbage, fuck off to your dev channel.

>> No.1878162

>>1878149
>anything overtaking bsnes in accuracy

lol. A massive autist like byuu wouldn't allow that to happen, he'd just make bsnes circuit accurate or something

>> No.1878175

>>1878162
sssssh don't tell him i'd like bGBA and bNES finished one day

>> No.1878179

>>1878175
Not gonna happen. byuu already said this consoles don't tickle his autism as much as the SNES did.

>> No.1878181

>>1878179
Don't break my dream anon or i'll shove pineapples in your urethra

>> No.1878192

>>1877896
I keep seeing people (the same ones apparently from the writing style ?) making this claim but it sounds a lot like an advertising slogan and I don't have any sync or latency issues with my emulators.

Has anyone actually verified this and came up with actual measures/proofs/videos comparing retroarch cores with standalones ?

I'm curious.

>> No.1878198

>>1877918
> If I wrote an emulator I would tell other emulator devs they are stupid control freaks because they don't do it like me

that's stupid, people write emulators for challenge and for fun, not to do the same thing as everybody else

>> No.1878202

>>1878192

I was using SNES9x stand-alone before I switched to RA and since then I don't have any trouble with vsync anymore. Before that I had to chose between screen tearing without vsync or audio crackling with vsync. That's the only real advantage for me but it's enough to keep me on board.

>> No.1878205

>>1878192
It's slighly better if you are using windows
It's really noticeable if you are using linux with DRM/KMS
but generally other factor will come into play like having a shitty LCD or using a retarded controller setup (anything involving joytokey, motioninjoy, software remapper etc)

>> No.1878206

>>1878198
Where's the fun in writing something that somebody else has already done better? RetroArch does all the audio/video/ui stuff perfectly already. This kind of thing is tedious and annoying anyway, especially getting it working on a lot of platforms. The actual emulation is where the challenge is, and where there's huge scope for improvement. RetroArch does no emulation at all.

>> No.1878210

>>1878205
>>1878202

Like I said, I do not notice any differences when using retroarch or my previous emulators

Is there any videos showing the difference ? I can only see people claiming one or another is running better for them (including people who complain about sound stuttering issues with Retroarch) but it always seems like it's bound to hardware issues rather than emulators

>> No.1878219

>>1878210
If you speak in term of input lag ou're not gonna see a difference unless you're a seasoned speedrunner or a very proficient shmup player (read the kind of guy who will see a 1 frame input lag on a 60fps game)
other than that things like >>1878202
But as always just use what you're comfortable with but if you have a problem with it don't complain about it

>> No.1878221

>>1878206
to learn by yourself or try different/better solutions because this is how things constantly improve ?

retroarch is obviosuly not perfect so I don't see the problem with people wanting to do it their own way, even if it ends up being worst

what about letting people do what they want instead of forcing them to use your API ? It's not like emulation was something so much important that we should care about wasted efforts and I have the feeling that forcing people to adhere to your ideas never achieve anything good generally.

>> No.1878243

>>1878192
Emulators having issues with blocking on audio with vsync is well known. Various methods of combatting this have been developed, including a static resampling method where the audio rate is manually adjusted to match video output rate (this is what bsnes/higan uses), but it needs to be extremely exact to eliminate all audio blocking issues so you would have to to get a large number of audio rate samples to get an accurate reading. A member of byuu's forum, Themaister, came up with the idea of "dynamic rate control" by using some fancy math to resample audio on the fly to keep from blocking on audio and preventing dropped frames on vsync. He implemented this in SSNES, his frontend for bsnes, which became RetroArch later on. As far as I know, nothing else has implemented this dynamic method for synchronization.

>> No.1878246

>>1878206
you admitted yourself you never wrote an emulator so you probably can not understand it

you are assuming that the end result is what drives people to work on emulator and that the faster they got their ROM playing, the happiest they are

that's often not the case, for most of devs, the fun is with coding and learning / trying new things

some of them do no want to bother with host platform audio/video stuff and would prefer rely on external libraries or API like retroarch but some others have fun doing the dirty job themselves, I see nothing wrong in letting each one deciding what is fun to himself personally

>> No.1878247

>>1878246
I agree as long as they are cool about people porting their stuff to libretro unlike some people

>> No.1878248

>>1878243
yeah, like I said, this is theory and this is nice taht this is something taht was never done by before

but in practice I see or hear no noticeable differences on my PC between Higan for example and the BSNES core in retroarch , hence why I was asking for video comparisons and actual measures

>> No.1878250

>>1878248
Maybe you just don't notice the screen tearing?

>> No.1878252

>>1878247
it's open-source anyway so as much as they brag about it, there is nothing they can do against it
I say let' em brag and prove them wrong

>> No.1878256

>>1878252
some menaced to relicense their whole project just to stop a libretro port

>> No.1878264

>>1878250
I now what screen tearing is and I don't have any in retroarch or higan with VSYNC ON
no lag or sound hichup issues either, pretty much perfect and no differences in the gaming feel apart from the different user interfaces

the only reason I prefer retroarch actually is because of the outstanding choice of shaders

>> No.1878268

>>1878256
source ?

I doubt they care that much about retroarch so this sounds like crap

>> No.1878270

>>1878264
>no lag or sound hichup issues either

Congratulations to your high quality monitor, I guess.

>> No.1878271

>>1878268
I don't have a link but it's in the comment section of one of the MAME devs blog for the 0.152ex4 and 0.153 build

>> No.1878279

>>1878271
>>1878268
http://mamedev.emulab.it/haze/2014/04/07/ume-0-153
http://mamedev.emulab.it/haze/2014/03/21/ume-0-152ex4

>> No.1878297

>>1878279
I could not see anything in there about changing MAME license to explicitly prevent a libretro core ?

>> No.1878302

>>1878297
It's in the comment section i think
then again it could have been on the IRC and i don't keep logs so

>> No.1878305

>>1878302
ok, so it never happened and that's just usual rumor spreading starting from distored or misunderstood comments

thanks for confiming

>> No.1878317

>>1878264
Enjoy your input lag.

>> No.1878319

>>1878305
> Arbee
April 9, 2014 at 19:25

>But the end result is going to be the same anyway – MAME/MESS/UME will continue being a library, it will continue being usable in applications that have nothing to do with MAME, and there’s nothing you can do to stop that.

>I think you’d be surprised how quickly MAMEdev and Haze can agree on new license terms if you want to keep playing that kind of chicken.
lrn2read fagit

>> No.1878330

>>1878317
sorry to disappoint you, no input lag either, like i said, playing feels exactly the same in both, using same USB SNES controller

I know input lag is very subjective but most people complaining about lag are generally experiencing serious laggy input response which make games awful to play (the famous "Punch Out" example seems the most loved one), i seriously would have stopped playing with emulators long time ago if it was hapenning to me

>> No.1879067

So I finally so around to trying RetroArch. It's a huge hassle to install. KMS mode crashes the stock Ubuntu kernel, so I compiled my own (updating 14.04's broken kernel-package first), taking the opportunity to tweak for better latency). Then I had to get 120Hz working on KMS, which required making a custom EDID file and embedding it in the kernel (another recompile). The some permissions tweaks to get input working, convert the pixellate.cg shader to GLSL, and I have RetroArch working in glorious KMS 120Hz BFI perfection.

It's absolutely rock solid, none of the occasional timing glitches I'd get with SDL emulators, and super responsive. Worth the effort.

>> No.1879185

>>1877125
>What makes it "superior"?
The only way it's superior is the desmume core actually has smooth scrolling. The standalone desmume emulator does not run at 60hz and therefore the scrolling is jerky.

>> No.1879192

>>1879185
But on android drastic is clearly the best DS emulator. Before people start crying about it being a paid app, just get the fucking apk off the internet and go nuts.

>> No.1879346

>>1877125
>What does RetroArch have that my regular emulators (VBA, Snes9x, etc...) doesn't have?

an arrogant self-important developer who told us we were idiots when we told him to fix his stupid retropad shit only to finally "come up" with those same ideas "all by himself"

>> No.1879362

>>1877190
>Squarepusher (retroarch's author) seems to have the problem that people just take retroarch and sell it with another name and ads.

He's a stupid retard who thinks people have some kind of moral obligation to subject themselves to his own moral standards. He's so idiotic he didn't even read his own license.

Not it'd matter anyway. Even if he added some non-commercial clauses, it's not like he'd drag his faggot ass to court in order to enforce it.

>> No.1879370

>>1877903
>posting that neutered version

I'd just like to interject for a moment. What you're referring to as RetroArch, is in fact, Emulator Cores/RetroArch, or as I've recently taken to calling it, Emulator Cores plus RetroArch. RetroArch is not an emulator unto itself, but rather another free component of a fully functioning GUI system made useful by the Emulator Cores, Libretro API and vital system dependencies comprising a full frontend as defined by Squarepusher.

Many emulator users run an inferior version of the RetroArch system every day, without realizing it. Through a peculiar turn of events, the version of Emulator Cores which is widely used today is often called "RetroArch", and many of its users are not aware that it is basically the Emulator Core system, developed by individual emulator projects.

There really is a RetroArch, and these people are using it, but it is just a part of the system they use. RetroArch is the frontend: the program in the system that allocates the machine's resources to the other Emulator Cores that you run. The RetroArch is an essential part of a frontend, but useless by itself; it can only function in the context of a complete frontend system. RetroArch is normally used in combination with the Emulator Cores: the whole system is basically Emulator Cores with RetroArch added, or Emulator Cores/RetroArch. All the so-called "RetroArch" distributions are really distributions of Emulator Cores/RetroArch.

>> No.1879372

>>1878130
>>1878079
the mame devs be hard at work
representing hardware in software
haze maintains his own website
where he distributes standard fare

hundred percent unmodified
built from standard source
the freshness of the builds
promised features and performance

in the modest comments section
where praise and respect is duly given
SP ventured in and did things
for which he would never be forgiven

first he started small
wasn't really noticed
just threw the idea around
and then the issue was closed

the next version however
he arrived very early, motivated
determined to win over the devs
he set out to make his case

adopt libretro! he preached
I just don't understand why not
you could target all the platforms
that we painstakingly support

look buddy, I understand
but this is my website
I do what I want with it
you all liking it or not

this is not the first time we've talked
apparently being subtle didn't work
sorry buddy I'm just not a fan
of your mame fork

nothing short of epic
was the shitstorm that ensued
innocent bystanders, annoyed,
struggled to understand the issue

but come here, it be simple, yo
its about pure power and control
I have my project and you have yours
let us not mix, it just won't work

arguments deconstructed with care
hypocrisies exposed true and bare
attacks were made close and personal
quickly it all became extremely banal

nobody wanted to give an inch
by both sides the fire was fanned
from the mame devs IRC channel
SP was eventually banned

when values differ
and ideas clash
all bets be off
and all cameras flash

this internet discussion was
recorded in time forever for shame
so that we can all laugh at it
and the autists who popped their veins

don't forget to take
your pressure meds

>> No.1880034

https://www.dropbox.com/sh/91sakv0qdyxjx9f/cGOfV7ZOKd

Not sure why that is the only link where you can get recent builds of Retroarch, but that's where I get the Android build from, there's a Windows one there too.

>> No.1880598

>>1880034
http://builds.libretro.com/nightly/

>> No.1880618

WHY CAN I STILL NOT CHANGE KEYBOARD KEY BUTTON MAPPINGS WITHOUT MANUALLY EDITING THE NIGHTMARE THAT IS THE RETROARCH CONFIG.INI???

is there at least some external program I can use to do it?

>> No.1880639

>>1880618
Change Settings->Input Options->Bind Mode to Keyboard.

>> No.1880650

>>1877125

retroarch is a common plaftorm for various emulators.

basically the core of retroarch talks with the actual os on a given machine, worries about handling joysticks, opengl, sound, loading and saving data and emulators work as plugins of retroarch that only talk with retroarch.

it can work with typical inputs, gamepads, touchscreens and whatever else you might have. some desperate guy might make it work with kinect maybe. and all emulators provided by retroarch will work with it.

you port an emu to retroarch and you do not have to worry about adapting it to any special os anymore - where retroarch runs, your emu will also run (assuming the hardware requirements are met, of course).

if someone ports retroarch to e.g. PS4 in the future, your emu will also be there. and with very little effort, unless it has to be optimized for ps4 specifically.

this approach takes out a lot of maintenance out of writing an emulator. now there is no need for every emulator to work out its own ports to various hardware and operating systems.

it might also make more emus available on systems that didn't have specific emulator ported to them before.

>>1877169

the frontend is also a plugin, and can be replaced. if you find it shitty, write a better one.

>> No.1880658

>>1880639

why was i then lied to?

https://github.com/libretro/RetroArch/wiki/RGUI
>Configuring keyboard input
>Configuring keyboard input is currently not supported. To configure keyboard binds, it must be done outside RGUI.

>> No.1880671

>>1879067
After playing for some time, I'm still getting occasional glitches. Plenty of CPU and GPU headroom, so it's probably some kernel latency problem. More work to do with realtime configuration.

>> No.1880679

>>1880658
It's a wiki, fix it yourself if it's wrong.

>> No.1880718

>>1880658
That page is outdated.

>> No.1880738

>>1880679
>>1880718

Is there no up to date documentation?

>> No.1880753

>>1880738
They launched a wiki using Mediawiki here recently, so documentation will probably be moved there and updated sometime.

>> No.1880868

>>1880671
I accidentally had Legacy USB support enabled in BIOS. Turned it off, seems to fix it.

>> No.1880898
File: 2.07 MB, 294x210, 1326298144763.gif [View same] [iqdb] [saucenao] [google]
1880898

>>1880738
>>1880753

>actively developed open-source projects getting proper documentation

>> No.1881104
File: 450 KB, 255x180, guy-takes-off-ones-set-of-sunglasses-but-has-a-second-set-on-aswell[1].gif [View same] [iqdb] [saucenao] [google]
1881104

>>1880598
Nice, thanks.

>> No.1881110
File: 60 KB, 600x1398, visionaries.png [View same] [iqdb] [saucenao] [google]
1881110

>>1879372

>> No.1881123

>>1878319
And yet here I am, running the latest Mame version on Retroarch and enjoying all the emulation without having to actually use that piece of shit. Top kek. Fuck Mame.

>> No.1881124

>>1881123
Pulling this kind of shit would basically mean a slow and agonizing death for M.A.M.E as a project

>> No.1881128

>>1881124
It already runs a shit ton of games. What's left for it to run? I don't care if it dies. MESS can die for all I care, it's garbage.

>> No.1881134

>>1881128
There is always more to do
If it dies before L.A Machineguns is playable i'm gonna be pissed

>> No.1881138

>>1881134
Can't you run that on Dolphin?

>> No.1881143

>>1881138
It has a GC/Wii port?

>> No.1881147

>>1881143
Yup

https://www.youtube.com/watch?v=1XAMlRWI3a0

Complete with pointer support

>> No.1881156

>>1881147
AW YISSS
sucks i'm too poor to buy the cabinet itself

>> No.1881273

>>1877125
i just cant figure out how to make it work with crt filters, keeps crashing everytime.

>> No.1881315
File: 143 KB, 450x338, 3289571.png [View same] [iqdb] [saucenao] [google]
1881315

>>1879372

>> No.1881323

>>1881273
What platform are you on, what version of RA are you using and what particular filter are you trying to run?

>> No.1881412

>>1881323
windows 7 64 bit, latest version and crt-geom-curved

>> No.1882889

>>1880868
Nope, still not perfect. Given retroach a whole CPU core to itself with isolcpus boot parameter and taskset, maybe this will be perfect. PCs suck for hard real time stuff, and BFI doubles the latency sensitivity of emulation, so this is harder than it should be.