Some RetroArch complaints

RetroArch General
#1

(I’m posting this here because I can’t figure out anywhere else to post it :slight_smile: )

First off I want to say I love RetroArch. I use it a lot, and in particular I’ve used its NetPlay feature with several far away friends, since it has the benefit of being the only emulator NetPlay feature that actually works. RetroArch and libretro are wonderful things. However, this post contains only complaints :slight_smile:

My first and foremost complaint is that the binaries distributed by the build bot are, as far as I can figure out, impossible to reproduce. It’s probably easy enough to get retroarch itself to the exact revision, but the cores that are distributed along with it have, as far as I can find, no documentation of the exact revision they were built from. Perhaps there is, and if there is I would love to be pointed to it, but I can’t find a file in the release that makes any such claims. I can assume that it’s probably a revision on the day of the release, but it’s hardly unheard of for there to be multiple revisions on a single day, and there’s no way of knowing if I have the right one, especially given that with distributed SCM like git, it’s quite possible that a revision was committed before release but pushed after release. Aside from the fact that many of these cores are GPL licensed, so it’s legally questionable to distribute them with no hint as to exactly which source code revision was used to make them, it’s a huge PITA if all I want to do is create on Linux a version that exactly matches the version my friends will use on Windows. Perhaps I’m being overly persnickety about the particular versions, but it just seems obvious that they should be documented somewhere.

My other complaints are about NetPlay and its documentation. I’ve used RetroArch’s netplay a lot. It is RetroArch’s killer feature. And nobody even knows about it because it’s barely documented to exist, and the documentation that does exist is full of lies. The wiki says that both the server and the client should set the same delay frame value. That is not true. I’ve used NetPlay a lot, and what I find is: If both are 0 and your connection isn’t magically fast, you get stutter; if the server is >0, regardless of the client, you get desync; if the client is >0 but the server is 0, you get perfect NetPlay. I seem to recall previous documentation claiming that the server and client were equal peers, which is also demonstrably untrue since I can reproduce desync with friends with either of us serving, so long as the server as delay frames >0. Reliable netplay = server uses 0 delay frames, client sets it as high as they can stand. Now I can go edit the wiki (that is the point after all), but I feel like it must have been originally written by someone who knew what they were talking about, right? Why is it that nobody at all seems to understand how NetPlay works, so I had to poke around to figure out how to make it reliable? Where the heck is the documentation?

(I’m relying on the wiki documentation for this last complaint, as I haven’t actually tried this:) Finally, NetPlay seems pointlessly lacking in one major way: You can’t play single player systems with NetPlay. It should be that any system that supports rewind supports NetPlay; if it’s a single-player system (handheld, ScummVM, whatever) it should just have both player grapple for the same controls. That’s fine if they’re just playing cooperatively. I’ve frequently played ScummVM over VNC with friends, which is stupid, and doing that over RetroArch would be much better, if only it worked.

Thanks for hearing my moaning. I do genuinely like RetroArch a lot.

#2

The netplay feature was created by maister a loooong time ago as a fun experiment, and he wrote what little documentation there is. Netplay requires more than just rewind, it also requires deterministic cores or else the client and server can desync at any rollback.

I’ve been petitioning to tag each repo with a release stamp each time we do a release for netplay consistency purposes but it’s a lot of effort to hit them all and nobody with admin access over all of the repos (which is really only 1-2 people) seems very interested in doing it. I’ll bring it up again next time we get ready to do one. I don’t suppose it really matters if they’re actually tagged at the time of release, as long as there’s a single commit that everyone can sync to.

The rest of your complaints are fine but this one crosses a line and you need to gtfo with this bullshit. It’s FUD like this that gives the GPL a bad name.

EDIT: sorry for jumping all over you. This is your first post, so you probably aren’t privy to the context that surrounds my admittedly abrasive response. We’ve gotten takedowns from the Play store and other harassment from vague license-y stuff like that in the past, so I/we am/are a bit sensitive to it. The source and all of its revisions are available in the github repos, which we feel fulfills our GPL requirements and we’ve never had a rightsholder complain otherwise.

If you would like to suggest that we include github revisions in our builds, that’s a thing we can explore, but framing it within the implication of a license violation is srs bzns as far as I’m concerned.

#3

Ah yes, that makes sense. Well, I don’t know about ScummVM, but I’d assume all the major handhelds generally are deterministic.

[QUOTE=hunterk;46978]The rest of your complaints are fine but this one crosses a line and you need to gtfo with this bullshit. It’s FUD like this that gives the GPL a bad name.

EDIT: sorry for jumping all over you. This is your first post, so you probably aren’t privy to the context that surrounds my admittedly abrasive response. We’ve gotten takedowns from the Play store and other harassment from vague license-y stuff like that in the past, so I/we am/are a bit sensitive to it. The source and all of its revisions are available in the github repos, which we feel fulfills our GPL requirements and we’ve never had a rightsholder complain otherwise.

If you would like to suggest that we include github revisions in our builds, that’s a thing we can explore, but framing it within the implication of a license violation is srs bzns as far as I’m concerned.[/QUOTE]

Yes, I’m aware of some of this history, as well as of course Hyperkin ripping you off, lying about it, and probably still lying about it (but oh well that’s just conspiracy theories). Licensing messes are never fun.

But to be perfectly honest, that history should be a reason to be VERY, VERY CAREFUL about licensing, and this is hardly careful behavior. Under the GPL if you release binaries you must release (or promise to release upon request etc etc) corresponding source, and you are releasing corresponding source, but I hardly think it’s an attack to suggest that if you’re not also releasing what the correspondence is, that’s dubious. I don’t think there’s any malicious intent here, and thus I doubt that any of the rightsholders would particularly be on the offensive, and it may even technically be within the requirements of the license, but yeesh, my statement alone should not be controversial. I can see the perspective that tagging everything is both a hassle and frankly pointless since the cores are genuinely not versioned with RetroArch itself, but having the buildbot do

for i in `find . -name .git`; do printf '%s ' "$i"; ( cd "$i/.." ; git rev-parse HEAD ); done > component-revisions.txt

is hardly onerous, useful for end users, and yes, good CYA in case of legal snafus. I am not your enemy here.

#4

Oh yeah, I also meant to say: It’s unfortunate that NetPlay is evidently viewed as a sort of sideline experimental thing. It’s genuinely a killer feature, and it works really, REALLY well. It’s the reason why everyone who has any interest in multiplayer should be using RetroArch.

#8

I’m glad you like it :slight_smile:

It’s definitely awesome when it works, though it’s some of the least-maintained, cobwebby code in the entire codebase. Nobody really understands it (including maister anymore, IIRC), so there’s no real way to improve it, unfortunately. There was a guy who was trying to work with it to at least add analog support but I think he gave up on it. We’ve also talked about adding a laggy netplay option that would work on weaker platforms and with non-deterministic cores but nobody has taken it on yet. In the meantime mednafen standalone has its own netplay support, but I haven’t tried it to say how it performs.

For the proposed revisions doc, is that really any more effective than just saying ‘it’s the revision at the time you download the core’? Anyway, I’ll talk to the other guys and see if we can come up with something. Maybe embed the git revision hash at build time and then have the core report it to the frontend so it can show up in a verbose log. That would at least be a do-it-once solution instead of tagging each release in the repos, and it wouldn’t be dependent on the buildbot itself, in case someone gets the binaries second-hand from somewhere else.

EDIT: lol whoops, looks like I sat on this reply too long. I, too, like the embedded thing, but yeah, it has to be done in each codebase, and we haven’t accomplished that with overscan cropping yet, so…

For the license thing, we’ve bent over backwards to meet the demands of GPL maximalists (not even rightsholders, at that) at significant and ongoing personal expense. Their complaints were also based on personal (read: not legally tested) interpretations of the spirit of the GPL and they, too, presented themselves as “allies” until we said we weren’t interested in meeting their demands, at which point they became hostile and presumably caused us quite a bit of trouble by abusing Google’s automated complaint process (we have no way of knowing who actually did that, since Google provides no way to even see the complaints, but the timing was uncanny if it was another party). So, you’ll have to excuse us for being suspicious of that sort of behavior, since we’ve been burned by it before.

#9

Radius:

It’s just that “nobody’s complained” is not a valid argument. Nobody’s complained because people generally don’t complain, or frankly don’t notice. And yes, all the cores are git HEAD, but git HEAD as of when? The official builds are just blobs, I’ve been going based on the timestamp there. I suspect the timestamp is probably close enough (except of course it’s presumably when it was uploaded, not when it was built, or at best when it was built, not when the cores were checked out), but the nature of distributed SCM, and git in particular, is that it is at best difficult to figure out what “HEAD” was at any given time, since commit time and push time are different, plus timezone nonsense. Perhaps no repos ever get pushes on the day of a release, but I doubt it. In all likelihood we’re talking about a couple of revisions at most, but if a behavioral change is introduced or removed, that could matter. I just want to be able to say that the version I’ve built locally IS 1.3.6, and not that it’s approximately 1.3.6.

hunterk:

I get the distinctive feeling that I’m going to be poking at NetPlay code in the near future. Urgh. I hate when I do this stuff to myself X-D. … no promises.

The problem is simply that it’s not the revision at the time “you” download the core, it’s the revision at the time the buildbot downloaded the core, and I can’t ask it what time that was. I have the timestamp when it finished building, but nothing else. Plus, distributed SCM problems (distributed SCM is great, but it definitely does not have the CVS property that a revision and timestamp are interchangeable). I genuinely don’t think this is a major problem, and I regret that it’s spun out of control here, but simply having it documented is a boon. No, it doesn’t help further distribution down the road, but it’s a step in the right direction.

I agree that having the cores report their own version is a cleaner solution, but as there is also a trivially simple interim solution, it should be a nonissue.